Engines, steering wheels, and open source

The vice president of technology at a leading  software vendor recently told me that he spends a lot of time wondering how open source projects can possibly work. “You take out the internal combustion engine, yet somehow the car still runs,” he said. But my take was that there is a powerful engine purring under the hood of open source and creative programming is addictive. Part of the rush comes from the endorphins released when the mind enters a state of flow. And part comes from the peer acclaim.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

What open source projects often lack is not an engine, but a steering wheel. “Too many programmers, but not enough product managers,” says Tony Byrne, who tracks commercial and open source content management systems at CMSWatch. Paul Everitt, co-founder of Zope, puts it this way: “We suck at finishing work.” Writing documentation doesn’t make endorphins flow. Neither does organizing

a usability study, doing triage on bug reports, writing a bulletproof installer, internationalizing a product for 14 languages, or creating an intuitive user interface.

Mind you, I’m not complaining. Every day I use Perl, Python, Linux, Apache, Mozilla, Zope, emacs, and countless supporting libraries and tools. But I also use Windows, Mac OS X, MSIE, Outlook, and a bevy of commercial software products. We tend to think of the open source stuff as low-level, developer-oriented infrastructure and the commercial stuff as user-facing applications.

But the two realms need not be separate and distinct, as I am daily reminded when I check my Outlook e-mail. Thanks to the SpamBayes plug-in for Outlook (see "SpamBayes Knows Spam When It Sees It,"), this is an experience I no longer dread. The open source SpamBayes engine could be integrated with any e-mail program. The problem is most open source folk wouldn’t want to actually do the integration work. But Mark Hammond saw an interesting challenge. He did the finishing work, packaging up the Python distribution needed to run SpamBayes and the plug-in, writing the user-interface code that enables the plug-in to work with Outlook filters and folders, and delivering the whole thing as a clickable installer.

I once asked two open source wizards if they were inspired because their software could improve the lives of millions of people. Nope. “We build infrastructure for other developers,” they said. “If they use it to make software that makes people happy, then fine. But it’s not what motivates us.”

You can’t argue with success. The infusion of open source infrastructure into the enterprise is a remarkable success story, and I truly do regard those responsible as heroes. But there are only so many infrastructure projects to go around. Whether and how open source energy flows into user-facing applications is a key question for enterprise IT.

Mark Hammond is a different kind of open source hero, and I hope more like him will appear. Finishing work is at least as great a challenge as infrastructure work, and may even produce endorphin flow in some minds. Of course, the act need not be its own reward. SleepyCat Software, MySQL AB, and other open source companies are proving there’s money to be made on licensing, support, and customization. These projects are built from the ground up. But there’s also an opportunity to piggyback on the finishing work that Microsoft has already done.