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.

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