Steering open source

The technology executive 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.

The technology executive 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 that 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.

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 organising a usability study, doing triage on bug reports, writing a bulletproof installer, internationalising 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 email. Thanks to the SpamBayes plug-in for Outlook, this is an experience I no longer dread. The open source SpamBayes engine could be integrated with any email 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 and other open source companies are proving there’s money to be made on licensing, support and customisation. 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.

Udell is lead analyst for the InfoWorld Test Center.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags Strategic Developer

More about ApacheLinuxMicrosoftMozillaMySQL

Show Comments