X
Tech

The hardest job in open source is picking winners

A winner, in the open source sense, is a project with a lot of support, an active community, and a growing user base. It's something you can bet the company on with confidence.
Written by Dana Blankenhorn, Inactive
Secretariat
What's a winner? (That's the late, great Secretariat, one of the all-time winners in my book, to the left.)

A winner, in the open source sense, is a project with a lot of support, an active community, and a growing user base. It's something you can bet the company on with confidence. Secretariat went out at something like 1:30 in the 1973 Belmont and the bookies still lost.

When you choose an open source winner for your own enterprise system, you know you're going to get help. Questions will be answered. Expertise will be found. Enhancements will become available. And when you need to hire someone with specific application knowledge, there will be several good candidates to choose from.

The trouble is that, outside of those working at enterprises who make it their business to support a particular open source tool, the winners change. People are free agents. A project may look active, but then a few people fiinish their development work, or lose interest, and you're orphaned. Worse, you could see a fork, or developers could split from the sponsor. Today's winner could become tomorrow's loser.

This is why open source houses like Covalent and JBoss are so vital in the enterprise space. Sure, they're in it to make money. But they assure all users of the projects they support that there will be someone there for them, even at a price A price is something a going business can deal with.

And there is where more-and-more of the open source world is heading. As companies find they can make a profit supporting open source code, more adopt the business model, and more projects get a steady (paid) base of support. That's why the rise of such companies was such an important trend in 2005, and it's why I think that trend will remain vital throughout 2006.

Because if you're going to bet your company on a piece of software you don't want to be relying on amateurs. Even in open source.

Editorial standards