During the recent erubycon conference, there was a lot of twitter traffic from attendees about how great the conference was. One who did not attend wondered if a conference discussing "Ruby in the enterprise" was wishful thinking or reality?.

Sorry if this disappoints anyone, but there was almost no wishful thinking, and a lot of reality. But there's a third option: planning next moves. There was a lot of discussion about how to promote Ruby effectively in enterprises that aren't already using it—not because Ruby is the be-all, end-all of programming (it's not) but because we have all found it helpful across a wide variety of programming tasks, and we think it is a good antidote for the more common, "enterprisey" tools that often bring more bad than good to a project.

During a panel discussion right after my keynote (Why "Enterprise Tools" are Bad for the Enterprise), someone asked "What do we say to a manager who doesn't trust open-source tools to still be around in a few years?"

Something snapped in me—I'd heard that same question one too many times. Commercial tools are available solely based on their customers. If the tool gets enough customers, the tool continues. Otherwise, it will all disappear. And it must disappear, given the nature of the software business.

There are three scenarios (with variations) for new software development tools, and all are common:

• get enough customers to be profitable, and continue for many years.
• get enough customers to look viable, get purchased and see the tool squashed or sidelined by the new owners.
• get just a few customers, and have your board shut you down.

When you choose a commercial tool, you're making a bet that enough other people will purchase it to make it viable, and that it won't be purchased and shut down by a competitor.

When you choose open-source tools, there is no monetary pressure on the toolmaker to continue; only community pressure. It's much easier (and cheaper) to bring community pressure. Additionally, even if the toolmaker chooses not to continue, the community can keep the tool alive. Many open-source development tools that have long since dropped from most people's radar (think Tcl, for example) still have thriving communities that actively support the tools and help each other with difficulties. With a proprietary tool, the legal structures surrounding it virtually guarantee that the tool will die if the vendor loses interest.

In every respect, open source tools have a better chance of surviving than their commercial cousins. Sure, some of those commercial tools will be viable for a long time, but most won't. Whereas most open source tools will be around for a long time. Open source tools actually diminish risk, not enhance it.

Anyway, getting back to the panel question at erubycon: I decided it was time for action, because this is such an easy point to refute with just a little preparation.

So I volunteered to play scribe during the party that evening, and I spent much of the party sitting in a chair with a pad and pen, while attendees helped me remember "enterprise tools" that have come and gone. We built a list of commercial, "enterprise" software development tools of one sort or another that were commercially viable no longer ago than 1995 (when Java first hit the scene) but which are now "dead". ("Dead", for purposes of this list, means either that there is no longer commercial support for the tool, or that there has been no significant new development on the tool in the past five years.)

It's a long list.

The point of this is not to prove that open-source tools are better than proprietary tools (obviously I think they are in most cases, but this list won't prove it either way). The point is to show clearly that there is no guarantee that a tool will still be around and supported after a few years, proprietary or not.

I'm sure there are other tools that we didn't think of. I'm equally sure that some of the tools currently on the list are actually alive; the fact that attendees at erubycon haven't heard of a tool for a while doesn't mean it isn't still being maintained and supported somewhere. (Here's a good example. I thought of a tool that seemed like an open-and-shut case for this: NetDynamics, the original Java application server. A little research shows that it was purchased by Sun, and some of its code formed the basis for the iPlanet application server, which was later called Sun ONE, and then the Sun Java Enterprise System, and is now called GlassFish. Nevertheless, I strongly doubt that old apps written for NetDynamics would run on GlassFish, and I'd be interested to know whether there was ever a clear migration path for NetDynamics customers.)

So I'm starting the task of double-checking that list. If you're interested in helping, send me email! I'll blog about the results here.