Although organizations are not realizing the full potential benefits of open source due to the way open source projects are currently managed, this does not mean that there are no benefits from developing in open source as we discussed in the first installment of this series (see http://opensource.sys-con.com/read/485127.htm). Once you get past the “free developer” presumption and carefully look at the larger picture, it becomes clear that open source, even in its limited participatory forms today, brings real value. In this installment and the next, I will briefly summarize the benefits of developing in open source based on the experience from the Eclipse Data Tools Platform (DTP) project.

Broad and Deep Testing
Once an open source project establishes a strong community (as DTP did during late 2006), the number of users grows and the feedback increases. Some users might only evaluate the software and not use it over a long period of time. Many users, however, will express their pleasure and displeasure through newsgroup/mailing lists posts, and bug entries.

We can not assume that testing done by users is either systematic or complete, but there are still some interesting characteristics. First, it seems that open source is very attractive to those running multiple platforms. Hence, you get (at least) smoke testing on a wide variety of deployment configurations. These include not only operating systems, but also language locales, hardware, and various peripherals. Further, when platform-specific bugs are found, these users tend to be willing to work with the committers to determine the cause and validate the fix (it seems many users even take pride in running different configurations). This wide variety of deployment environments would be costly and time-consuming for individual companies to replicate. By making software available in open source, you can leverage the heterogeneity of the community for your testing.

Suggestions in Definition and Design
As mentioned earlier, open source communities are willing to offer opinions about requirements and design. Committers new to open source often find this daunting, but they need not. The default assumption in open source communities is to ask for everything, but expect only what the project committers are willing to work on. So, there is no harm in getting an overwhelming number of feature and design requests. Ultimately the committers will choose what to work on – in commercial settings this is typically driven by the sponsoring company’s requirements – and users are savvy enough to understand this.