Brendan Scott, June 2008
Groundwork
Many people focus on the “hard” costs of software acquisition and maintenance such as licence fees and implementation costs. However, the adoption of a closed source solution has a number of hidden costs which are rarely properly accounted for. Many of these costs arise because of the extreme lack of flexibility in closed source licences and they are likely, at least in some cases, to be far more significant than the hard costs. In this series of posts we will work our way through the closed source acquisition and maintenance path and have a look at some of the more obvious ones.
Underlying Reasons – Natural Monopoly
Software is a natural monopoly (because it has a high fixed cost and low marginal cost to produce). As such there is a tendency for the market to become increasingly concentrated, first within a particular product line (such as databases, operating systems or word processing software), then across groups of product lines (typically because of the creation of artificial cross product dependencies).
Underlying Reasons – Good Enough for Most
Professor Pamela Samuelson and Mr Mitch Kapor have run a lecture series at UC Berkeley on open source (which, by the way is worth a listen). In one of their lectures they give the example of the university sector in the United States having particular requirements for their accounting, requirements which are not met by the closed source software industry. Indeed, the gap between their requirements and the capability of close source solutions is so great that Universities have banded together to create their own (open source) accounting software – at substantial expense. Ordinarily you would expect that Universities would have enough market power to get additional functionality into closed source solutions – but they don’t. Remarkably, the US University sector is not important enough to influence the direction of closed source software vendors on features of their accounting software. This is not an isolated case.
If this sector isn’t influential enough, what hope does an ordinary organisation have? Any implementation which is designed to be sold on a per unit basis (regardless of the unit – eg copy, seat, site, user etc) means it must be designed to maximise sales of that unit. Here the 80-20 rule comes into play, with the vendor coding features to attract a large chunk of the market for the lowest cost. That is, in order to maximise profits a closed source vendor must aim for a product which is “good enough for most”.
While the market is young there may be niche players who will provide products into that tail 20% that is not properly served (or that there might be multiple different products each covering a different 80%). However, this market structure is unstable because software is a natural monopoly (as described above). As products begin to win market share they crowd out competitors starting with the competing 80%-ers and then to niche players.
If your organisation has specific feature requirements it is likely not only that closed source solutions will not meet your needs, but also that you will be unable to influence the vendor to implement features to meet your needs. Even offering to pay the development costs will not necessarily influence a vendor to implement the feature because this would burden their code with additional modules which would need to be maintained going forward and the vendor maybe unwilling to take on this maintenance burden.
In short, for those who fall into “the many” category, they will be reasonably well served by their closed source vendor. However those in “the few” (roughly 20% according to the 80-20 rule) won’t be. I will use the terms The Many and The Few for convenience in the balance of these posts.
Tragically Closed
Closed source vendors are typically reluctant to interoperate with others, especially if they vendor is well positioned in the market. Indeed, a vendor’s support for interoperability is inversely proportional to their market share – when they have small market share they need their software to be able to work with other people’s software, since by assumption most people have other people’s software. As the vendor’s market share grows interoperability transforms into intraoperability – the ability to operate with other components in the vendor’s software portfolio. Indeed, vendors with large market share will even argue that intraoperability and interoperability are the same thing, since that vendor controls the market, (they argue) intraoperatibility is all that a customer needs de facto.
As the market share grows offering interoperability is only assisting the growth of the market share of the smaller players in the market, so beyond a certain market share, vendors have a disincentive to interoperability and that disincentive grows as the market share grows. In the extreme examples, for someone with no market share to enter the market their first sale must interoperate with the existing software so they support interoperability. Equally, for someone with 100% market share, support of interoperability necessarily means that they lose some part of the market.
It follows from the fact that software is a natural monopoly that, over time, because the natural tendency of a closed source market is to market concentration, there is also a natural tendency towards lack of interoperability. So, even if you invest in a closed source product which supports or promotes interoperability today, you will likely be in trouble in five or ten years’ time. By then, either the product will have emerged as a market leader and therefore no longer supports interoperability or they will have fallen by the wayside and the actual market leader will be trying hard to lock out the product that you have in fact invested in. Moreover, there is now a move among some closed source vendors to trade interoperability against patent rents, thus increasing the cost of interoperability. Therefore long term interoperability prospects for any closed source solution are poor (I have used the heading “tragically” closed here in Hardin’s sense – that the long run closure of the system follows almost inexorably from the nature of the industry ).
The lack of interoperability is an enormous problem because interoperability is a precondition to competition. When software lacks interoperability it is a symptom that there is no competition in the market. As competition in a market decreases not only do the costs of products in the market become artificially inflated, but the quality and diversity of the products simultaneously decreases. Lack of interoperability means that a customer cannot avail themselves of self help to implement features that they want in a product or remove dis-features (1) (2) from a product. As we mentioned above, unless your requirements are shared by a substantial proportion of the target market, you will be unlikely to be able to have specific features implemented – even if you are willing to pay the cost of implementation.
A result of this Tragic Closure is that closed source software tends to be monolithic rather than modular.
In part 2 we look at some costs of acquisition.
Brendan Scott's Weblog 