Digiwonder?

Scenario A: A new piece of software is needed. A company hires a team of developers. Team works on the software. The team develops, tests, de-bugs, all internally. The product is released to the world with a PR blitz. People buy it. The company makes money and continues to issue patches and upgrades, internally improving its own code.

Scenario B: A developer needs a new piece of software to fill a need. Starts noodling and working on it. Goes as far as he/she can and then puts the project out to a larger community of developers via the Net. Turns out, these programmers also have the same need. So they start looking at the work, developing, testing, de-bugging. The software is improved and improved until it finally moves out of development or “beta” status and is launched to the world. This time, no PR blitz, it just spreads via word of mouth from the programming community out to the larger world.

In his seminal paper on open source development, scenario A is what Eric S. Raymond calls the “Cathedral”. Scenario B is the “Bazaar”. Think of the cathedral as a traditional business—there are managers and staff who are paid to carry out the goals of their superiors. In the Bazaar, there is more free flow exchange of information with everyone giving a little and everyone gaining something back. And the direction of work naturally evolves according to the participants’ needs.

Which scenario is better?

The A Team: We pay our developers. So they have to get the job done and done well.

The B Team: Well our developers are like volunteers, tinkering on code that matters to their own personal interests. They don’t need a boss to motivate them. And they can also make money from their efforts. (I’ll get to that.)

The A Team: We hire good coders. We know them and their skills. We can trust them to do good work.

The B Team: Well, given that people are working in a community, if you are lazy or you screw up code, word will get around. We’ve got a natural accountability system not based on performance reviews. If you had potentially hundreds of folks looking at your homework, wouldn’t you dot your Is and cross your Ts?

Oh, and we can have any number of programmers working while you can only have as many as you can afford to pay.

What does my little banter indicate? The Open Source model of programming works. It’s responsible for Linux, Firefox and a host of other well-known and trusted applications.

My own experience with open source software is highly positive. In my job, I dance between programmers and non-profit clients in need of website facelifts and new back-end tools like content management systems, which allow them to keep content up to date without needing to know html.

I’ve hired or used in-house programmers to customize an open source content management system called Joomla many times over. Each time we’ve had success. It’s very easy for my clients to learn and navigate. And it’s attractive because they only have to pay us and/or my programmers the time to manage the project and customize the system to their particular website. They save literally tens of thousands in licensing fees.

Basically, I feel that the software itself is totally on par with the proprietary solutions out there for many small to mid-sized non-profits. The x-factor with open source is whether the software has a robust development community around it.

Raymond’s right in emphasizing the importance of open source projects having good people persons behind them. And I’d add that these people need one more thing—an eye on their end lay-users. That’s the key for widespread adoption—at least when it comes to things like content management systems.

My biggest bone to pick is simply that, as Raymond admits, programmers hate to document. This means that unlike Microsoft, lay-users don’t usually get slick user manuals with their new open source tools. There are online help areas and tons of discussion boards to post questions to, but many of my clients still want an old-fashioned user manual. So that’s one area where I think the open source folks could brush up on and improve.