Something very interesting happened this month. We were working on a product review of the Guardian Digital Linux Lockbox (http://www.guardiandigital.com), which is a secure Web and e-business server based on Guardian Digital's EnGarde Linux distribution and Zelerate's AllCommerce application. Then something really funny happened (and not funny "ha, ha") -- Zelerate went out of business and started liquidating their company.
Something very interesting happened this month. We were working on a product review of the Guardian Digital Linux Lockbox (http://www.guardiandigital.com), which is a secure Web and e-business server based on Guardian Digital’s EnGarde Linux distribution and Zelerate’s AllCommerce application. Then something really funny happened (and not funny “ha, ha”) — Zelerate went out of business and started liquidating their company.
Now, in theory, this should not have made any difference. After all, Zelerate’s AllCommerce is a completely open source application, licensed under the terms of the GNU GPL. So no matter what happened to Zelerate, the source code for AllCommerce will always be out there, available to anyone that wants or needs to modify it. Zelerate going out of business should not have made any difference — again, in theory.
Unfortunately, however, I wasn’t sure that the availability of the source code was sufficient to warrant running a review of a product that was based on software created and supported by a company that is out of business. So, despite a tremendous feeling of disappointment, I was compelled to yank the review.
This whole experience got me thinking harder about the relationship between the commercial world and the open source world and the differences that exist between them. Can a corporation really initiate an open source project?
There is indeed a difference between a project that is Open Source (as defined by the Open Source Initiative’s “Open Source Definition,” or OSD) and a project that springs forth from the open source community. When a bunch of developers come together to work on an open source project — as is the case with Linux, Apache, and MySQL — they do it because they all share common technical needs and requirements.
In contrast, software developed by a corporation is generally created to fill a demand that the company perceives in the marketplace. Thus, there is very little incentive for developers outside of that company to work on other open source projects related to that software. The needs of the company’s customers may be completely different from the needs that drive open source developers to work on the well-known projects that exist in the open source world.
Projects that grow out of shared developer needs seem to allow for community growth as well; projects that grow out of corporate initiatives seem to not possess that property (or exhibit it to a lesser degree). As we all know, there are many open source projects that were initiated by corporations that never gained the critical mass their founders had hoped for. Mozilla and StarOffice are two good examples.
The moral of the story is this: you can slap the GPL on a bundle of code, and technically, you’ll be able to call it Open Source. But for a piece of software to truly be considered a viable open source project, it must have more than just the label of an open source license. It needs to have a thriving developer community constantly working on developing and improving it.
Open Source is not just about licenses. It’s about community. And companies that want to truly leverage the open source development model are going to have to devote a substantial amount of resources to building community as well as to enhancing their own code base.
See you next month,
Adam M. Goodman
President & Publisher