The Limits of Open Source

There was an article this week in InfoWeek entitled How Linux is Testing the Limits of Open Source Development which really hit home. In many ways, it's reflecting some of the issues that our much smaller opentaps Open Source ERP + CRM project is going through as well, and it made me realize that there may be a natural, self-correcting mechanism which limits the growth of open source projects.

Let me give you an example of how I think this works: Imagine a really smart developer sat down and started an open source project. She starts writing code, and pretty soon the software is useful. More and more people download it, and soon some other contributors/developers show up. The rate of development increases, and more features show up, leading (hopefully) to more developers. There's a positive feedback loop until the bugs also creep up. Eventually, if the bugs aren't contained, the software will become so unstable that new users would stop using it. Then all of a sudden, the project stalls out.

What to do? One logical answer is just to shrink the project down, fix the bugs, and get it stable again. This may mean the project has to be smaller, but that's no shame--open source should be about having fun writing great code, not about which project is bigger.

If, however, the project is trying to solve large-scale problems, then it must create an infrastructure similar to that found at commercial software development firms:

1. It would have to invest in documentation, so that both users and developers know how the application should work.
   
2. It would need to invest in a large amount of unit testing and recruit human testers, so that new features don't break existing ones.
   
3. Above all, it must create and enforce a common code culture, so that every developer could take over code written by another developer.
   

Such an infrastructure is necessarily less "efficient" in the sense that the lines of net code generated per developer would fall, because developer time would be taken up testing and reviewing. It also may be less fun for some developers to be reviewing code, enforcing standards, or devising unit tests rather than writing cool code. (Believe me, I tried to put it off as long as I could--but I can't any more.) Finally, it's hard for open source projects to turn away features or enforce standards. Somebody is so nice that he wants to contribute a new feature. Do you really want to hurt his feelings by saying "Your code doesn't conform to our standards?"

However, having observed several large scale open source projects up close, I'm convinced that there is no alternative if you want to build large scale open source software. We're going to have to make documentation, testing, and standards an integral part of our development process at opentaps if we want to scale up our development and deliver the features our community needs.