eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Theres an awfully big tent enclosing at least a three-ring circus of options for “open-source development.”
In the first ring, there are open-source tools for proprietary platforms—for example, the Open Watcom C/C++ and FORTRAN compilers, taken open in 2003 by SciTech Software Inc., of Chico, Calif., and available for DOS, Windows and OS/2 application development.
Notably, the Open Watcom code is not licensed under the well-known GPL (General Public License) but under the Sybase Open Watcom License, one of 57 distinct licenses as of this writing that are approved by the Open Source Initiative organization for labeling as OSI Certified Open Source Software.
The OSI listing includes the admonition, “We encourage you to select a license that is consistent with your business model. And consult with your own attorney, because OSI does not provide legal advice.” Both for those who offer and those who use open source code, these are good ideas.
At the other end of the tent are commercial tools for open-source platforms—for example, the Kylix development suite, with superbly integrated tools for C++ and the object-Pascal dialect Delphi, from Borland Software Corp., in Scotts Valley, Calif.
Commercial toolsmiths desire to gain mind share in the open-source community has led to another bewildering array of licensing options with differing feature sets for these products. Kylix, for example, is offered in Professional and Enterprise versions that include advanced data access components. These are absent in the Open edition of Kylix thats targeted at developers wishing to produce GPLd applications. Developers considering commercial tools for their open-source work may need to wade through fine print to determine exactly what theyll be able to create.
In the center of the big top, theres the headliner of open-source tools for open-source platforms, including the application stack known by the acronym LAMP: the Linux operating system running the Apache HTTP server; the MySQL database; and the PHP, Perl and/or Python scripting language for Web-deliverable applications.
The star of this show may arguably be the Eclipse project, a royalty-free “universal platform for tools integration,” in the words of eclipse.orgs Web site. The independent Eclipse Foundation kicked off this month with the release of a draft Architecture Plan whose top-level projects include Web Tools, Test and Performance Tools, and Business Intelligence and Reporting Tools.
Another act making its debut in that center ring is phpBeans, a GPLd effort to offer developers a more enterprise-class capability of secure and scalable construction built on their broad foundation of PHP skills—with developers involved in the project planning to extend the framework to other languages as well.
Client-side code in a phpBeans project is the same that would be used to access a local object, but objects are instantiated remotely on the server via the phpBeans interfaces instead of locally by a simple “new” object invocation. With that small added effort, developers get the benefits of an n-tier architecture in which application loads can be balanced and business logic access can be controlled.
In the meantime, running around all those lions and tigers and acrobats is a troupe of additional open-source tools for developer collaboration, application testing, security validation and other utility functions. Released just last month, for example, is Version 4.3 of the TestMaker tool set for constructing Web-application test agents. This version of TestMaker is GPLd, unlike previous versions that used an Apache license. That switch requires that future changes be fed to the community. This is yet another example of the importance of staying abreast of changing license terms and conventions if placing ones bets on open-source tools.
That said, having tools available in source code form means much more than getting them free. It means being able to customize them, to improve them and to audit them. Project stakeholders will have to decide how much they can afford to invest in such efforts, but open source makes the decision theirs rather than a vendors.
These are among the reasons why open-source development is not just a low-end commodity substrate to “real” application development efforts. On the contrary, open source was identified more than four years ago by the Presidents Information Technology Advisory Committee as “a viable strategy for producing high-quality software through a mixture of public, private and academic partnerships” to address “a growing national vulnerability based on the inadequacies of the current system to build reliable and secure software.”
In October 2000, a report from that committee cited a European Union study from 1999 that projected open-source benefits of “reduced costs, greater economic activity, and widespread diffusion of new technologies.”
Its very much in any teams interest to enjoy those benefits.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.