I posted the first draft of this at http://www.relevancellc.com/blogs/?p=36#comments in response to a query along the lines of "What would it take for Ruby to be considered enterprise software? Transactions?". It received some positive responses, so I thought I'd save a copy, revise it slightly, and share it with a wider audience.
I wish I were online at the moment so I could add references, since this essay draws on the ideas of many other people, in particular "Enterprise software" is software that gets sold to a so-called enterprise. Native English speakers might think an "enterprise" is something brave, noble, and dangerous, such as starting a small business, but in this case, "enterprise" is used to mean the opposite: the executives of a large, risk-averse company have chosen to flatter themselves by pretending that they're engaged in something brave, noble, and dangerous. These "enterprises" use a lot of software, but most of that software doesn't get sold to the "enterprise" itself; if it gets sold at all, it gets sold to one of the employees of the "enterprise", who has the authority to spend $400 or whatever to get the software they personally use to do their job. That's not "enterprise" software, because it's sold to an individual, not a so-called enterprise. "Enterprise software" is software that has to be sold to an "enterprise", where someone who doesn't use the software (typically a manager) must be persuaded to use his purchasing authority to buy the software. It's different in a variety of ways from other software, but none of these ways are strictly technical. First, "enterprise software" costs more. If software doesn't cost a lot, individuals can generally buy it themselves without managerial buy-in, although other factors may interfere; for example, everyone has to use the same bug-tracking system for it to work. Getting managerial buy-in often involves expensive salespeople, whose commission comes out of the software's price, and managers everywhere have a well-known perverse incentive to expand their budgets. Second, "enterprise software" doesn't necessarily work, although sufficient effort can usually make it work. An up-front $50 000 price-tag makes it seem more reasonable to spend $1000 or $10 000 to customize it to your needs before you can use it. In extreme cases, such as ClearCase and Oracle, keeping the software operational requires a team of expensive, specialized full-time employees. The nontechnical background of many managers, in addition to the perverse incentives in many managerial structures, often allow enterprise software to sell well even if it does not work at all, no matter how much effort is applied. Third, "enterprise software" is surrounded by consultants who will sell you the service of making it work, as explained above. In some cases, these ecosystems of consultants are competent and highly skilled. In other cases, such as the case of Java, many of them are spectacularly incompetent, vociferous in their ignorance, and prone to attack competing systems. This results directly from the sales process for "enterprise software," in which expert persuaders gull technically incompetent managers into adopting the software. Managers who aren't technically well-informed enough to select the software in the first place will also not be well-informed enough to distinguish between competent consultants and incompetent consultants, so both competent and incompetent consultants will flourish --- but the competent ones will eventually get sick of it and go elsewhere. I didn't really understand this until KnowNow, the startup where I worked, got turned into an enterprise software company by its VCs and management; although I had previously had the opportunity to observe most of the pieces of the puzzle, I had clung to the idea that "enterprise software" was technically better in some way from the software I was used to using. It turns out that the differences are entirely social, not technical, and one of the major differences is that "enterprise software" is under much less pressure to have any technical merit.
