Months ago I researched an open source laboratory information management systems (LIMS) project hosted on Sourceforge (Gnosis LIMS). I work customizing a commercial LIMS so I was excited to see a fully open sourced system. I did not ask to participate in the project mainly because it was Java based and already had lots of developers and two admins. I left this issue alone for six months and came back to see how the project was doing. It went nowhere. Even with half a dozen developers and a project plan no work whatsoever was actually done code-wise. The principal of the project either could not or would not surrender the project to someone able to bring it to completion. My e-mail discussion with him revealed that he was considering giving the project to someone else but had not come to any decision. That was a year ago.

In another instance I found an open source shopping cart system (AgoraCart) that needed what I perceived to be a change to its core code. The script was using $ENV{'SERVER_ADMIN'} for error messages when failing to load libraries rather than using the variable for the admin e-mail in the setup. (On a shared server you have to call the system administrator to change the environment variables passed to your script versus you changing it yourself in the script's configuration file.) When I asked the maintainer to make the change he balked that he would not. I explained that the configuration item in the script was there for this reason. He did not seem to care.

You may be thinking, "If the project is open source, why not just make your own project?" I can answer that with an example: Imagine that there were one hundred Apache projects all using slightly different versions of the same source. Chaos would ensue. Users would become angry. The whole project would dissapate. Open source projects should be like rivers. As they grow they should encompass the knowledge of many participants. A change in the name of a project for a mid-level enhancement divides mindshare. This is because people know something by its name -- it is only human. If the project is known as Quickie-Foobie and you branch off too many times you lose the force of acceptance the product has already gained. You are effectively starting over. So it is best to change those things about the core source of a product that others have found can be improved as time and skill allow.

I have learned the following from my experiences:

A. Popular open source projects are victims of their development strategies.

Gnosis seemed to suffer from "analysis paralysis." There was documentation early on and no actual code or prototype. I think a project that starts purely with documentation in the open source community is doomed to failure. There needs to be a combination of planning and reality. Had they utilized some open type of discussion methodology right from the start along with periodic prototypes they would probably have a working product today.

B. The best strategies utilize structured come-one-come-all approach to enhancements.

Agora is a good example of a script that has captivated many different prosumer type users. One of the most often heard statements from their Yahoo group list participants is that they are not developers. The actual code could use some rewriting but it seems to work. There are quite a few modular enhancements written by the user community, particularly for gateways to credit card processing centers and for shipping, but attempts to actually rewrite the core are largely ignored.

C. There needs to be a framework (or a tool) for open source projects to use that allows for high level discussion of the application

Internet Request for Comments (RFCs) are a good example of this process. Everything is open to discussion and debate. The best technology meets the (hopefully) best minds and is reshaped, not ignored. Many open source projects are ignorant of this long standing example.

We need to have a solid plan for reviewing and accepting issues/problems with core product code. This goes beyond bug tracking. Problems with architecture do not directly map to bugs, but rather are the root cause of many performance and enhancement issues. Open source projects should judge change requests purely on technical merit. The open source community needs to focus more on RFC-like methodologies for source code improvements as well as for actual project planning. This practice needs to be taught alongside the seemingly endless discussions of the benefits of open source development methodology. In short, open source is of limited value unless you have an open type of development coupled with some structured manner of review.

Celebrate Intellectual Diversity