Which platform: Cathedral or open source?

Have you ever experienced a software bug and thought to yourself, "I could fix that"? If you could, would you? How could that even be possible? There are two fundamental approaches to building software, and they're often called the Cathedral and the Bazaar, as described by Eric Raymond over a decade ago as a presentation at a Linux conference.

"Cathedral" software is built by a group of developers based on a central plan. They code, find bugs, fix as much as they can, and then after a year or so they eventually ship a product. Much like building a cathedral where everything is painstakingly crafted and installed before the doors open. Think Microsoft Windows or Office -- monster projects with a new release every few years and point releases more than six months apart.

"Bazaar," or open source software, is created more independently. Building upon a basic kernel, independent developers improve functionality or fix bugs as they see a need. It's basically crowdsourcing for software. Well-known examples include Linux and Apache. But not Firefox or Eclipse -- while many people assume that they follow the Bazaar model, there's more to it than that, as we'll shortly see.

In the earlier days of software, the Cathedral model dominated because only a few companies had the resources and the infrastructure required for software development. But the model is flawed. Keeping control of the code within a relatively small group of developers limits the ability to both locate and fix bugs. Even when software is exposed to a very large beta, the issues found must be triaged, meaning that not everything gets fixed. Even final release software is guaranteed to ship with bugs, which is made all the more painful by the long wait for each new release.

Consider Microsoft Vista. Microsoft develops all of its software products using the Cathedral model. I could rail on about the problems users have had with Vista but that wouldn't be fair to Microsoft's developers. They have a multitude of groups to satisfy and a limited amount of time to do so. There are guaranteed to be issues.

Today, with the Internet and tremendous collaboration and social networking available, the Bazaar model exposes the code to thousands of developers, who can both find and fix the bugs. Frequent releases may make the code problematic for some companies that require a stable off-the-shelf product, but they guarantee that the it will be improved even more quickly, leading to stable releases. And the Bazaar philosophy enables the creation of "long tail" products -- a utility or app required by only a small population. Such a product might never see the light of day in the commercial world, where Cathedral approaches dominate.

The downside to the Bazaar model is the difficulty in charging for something that you can get for free. Open-source software is usually free. Companies like Red Hat, which markets a suite of products centered on the open-source Linux operating system, deal with the free problem by charging for support, already a huge selling point for Cathedral software companies.

Personally I'm a big fan of the Bazaar model. I'm writing this using NeoOffice, which is a Mac version of OpenOffice. I switched to it a couple of weeks ago because my last automatic Microsoft Office update deleted legal copies of Excel and PowerPoint from my machine. I use Eclipse as my development environment. Like 19% or so of you, I use Firefox. And I've even created an offline blogging tool called Bleezer, which I am about to open source because I know that opening it up to lots of smart people will improve it dramatically. http://www.neooffice.org/neojava/en/index.php

Firefox and Eclipse are a bit different, however. They are hybrids. Both started as Cathedral projects -- Firefox grew out of from Netscape and Eclipse from IBM -- before they were let into the wild. They seem to have experienced tremendous success as a result.

Perhaps the best way to be successful is to start with an idea and create the first iteration as a Cathedral project. That way developers can see the potential, and see how it can benefit them. Then free the project and invite contributions. Then when you're using the software and you see that bug, you can jump right in and fix it. Or add something else you need. And then suddenly, everybody benefits.

I wrote Bleezer because I couldn't find a blogging tool that did what I wanted, and I believed that others might have the same problems so I would also have an opportunity to give back to the community that had helped me. It was a combination of code I wrote from the ground up, augmented by other open source code that provided functionality I didn't have the time or inclination to create. And users have responded very well, often thanking me and giving me tips to improve it.

Lacking time to give it the support it needed, I was made the decision to open source it -- my first such project -- agonizing first over whether I wanted to let it go, and then whether it would be good enough for the developers who might want to work on it. After all, developers don't take insults about their code well. (Next week I'll take you through my experiences building Bleezer, and the process of open sourcing it.)

Here's a thought. Perhaps Microsoft would consider open-sourcing Vista. Let the world find the issues and improve on it. Now that would be brilliant PR.