Credit Eric Raymond for writing The Cathedral and the Bazaar, which is an excellent dive into the strengths and weaknesses of open source.

Like any written work, it comes with many interpretations. Raymond’s recommendations are awesome and should be recognized as lessons learned from the Linux software development model.

However, it’s no complete guide from point A to point B for your project. I think it would be a poor decision to take the Linux model and assume that your application should follow the same exact steps in order to be successful.

Yes, iterative improvements to a project codebase are a great idea. But when you’re trudging through piles of shit trying to decide whether or not to rewrite an application, you shouldn’t look at Raymond’s essay and believe, “If I fix this small piece, the rest will follow.” That sounds an awful lot like blind faith.

Invariably, at some point, a project hits significant crossroads; rewrites, branches, different languages. My take on Raymond’s essay was that each project endures these by drawing on sound judgment from its leaders. Of course, in the essay that means Linus and Eric. As Raymond laid out, each iterative improvement was never a miracle or sponateously generated.

Eric chose his starting point for his mail client project. He changed it, destroyed it, rewrote it. Linus chose his starting point and went through many of the same challenges.

Each improvement was borne from a specific need that was unfulfilled for a member of the community. The leader of each project was able to effectively manage their primary resource (their user base) in order to facilitate an organized effort to scratch any collective itch. This is what made all bugs shallow, given enough eyes.

The common thread that struck me was the presence of a central body in both cases. For all the clamour and praise for a distributed development model that uses the force of the community, it still seems as though any effort would die without organization and leadership. At some point hard decisions are made — like, “Should we rewrite this entire thing?”

In his epilogue, Raymond touches on the unknown nature of open source in general. Yes, it is sometimes a tremendous success story, one of the best, probably better than watching Rudy play garbage time in the fourth quarter. But I fear people forget about the pitfalls and weaknesses of open source.

Remember, for all of open source’s grandeur, it’s still just a part of the natural ebb and flow of a necessity-driven sea of developers. It’s evolution, in all of its greatness and all of the horrible wreckage it leaves behind.

The process of finding that leader, that epicenter of motivation and organization is a part of digital darwinism. Sometimes projects find it, the leaders match the community well, and progress is made. Other times, more often than not, a project can stagnate and spiral towards extinction.

So what did I learn? Know your needs — understand them. When your application doesn’t meet them it’s time to tear things down and write one that does; piece by piece or all at once — doesn’t matter. Don’t worry about what happened to project X; do what’s right for your project and its users.

Be willing to fail, and fail hard. Be willing to build things up, burn it all down, and rebuild it. Do it again. Include as many people as possible, ride the wave but scratch all of your itches. Then finally – succeed together, quietly, but don’t be surprised.

It’s not just software evolution.