This week I'm speaking at Open World Forum in Paris on the subject of open source and the digital recovery (la relance numérique), and for a change I'm going to try writing down all my references before my talk rather than after it.
To speak to the subject of a digital recovery, one must also address the question "recovery from what?" This is easy for me, as I have been talking about the cost of "bad software" since the meme was first published in CIO magazine in October 2001 entitled Let's stop wasting $78 billion a year. Quoting from that article:
Between November 1999 and July 2001, Lawson released seven new versions of its software to fix bugs or add functionality that had been promised but absent in each previous version. Seyk [the CIO of VisionQuest] was outraged. He documented his problems in a series of letters to Lawson executives, met with them on two occasions, and sank a total of $594,974 into software and maintenance to correct the flaws in their products.
And then it dawned on Seyk why the software and support were so bad: That's the way vendors make money. They push products on the market before they've been adequately tested, demand payment up front and then are often not available to deal with the sequelae of poorly performing products.
The article then introduces a study by the Standish Group (whose assumptions and findings appear to me to be unchanged between 1994 and 2009) that 18% of all applications are abandoned before ever reaching production, 55% are "challenged", meaning they are either late, missing key functionality, buggy, or some combination of the three that results in measurably degraded performance. Back when this study was done, the scope of the analysis concluded that $78B/year was being wasted by US CIOs on "bad software", but that is the tip of the tip of the iceberg: with global ICT spending over $3.4T USD in 2008, money wasted on "bad software" now exceeds $1T USD per year. That is an amount of money worth recovering.
In my OSS 2009 whitepaper, I attempt to explain in detail the specific mechanisms that lead to the extraordinary divergence between the quality and value measured for proprietary software (which is very poor) and that of open source software (which, depending on what is measured, scores 30-150 times better). Certainly if we begin from a position where the primary hypothesis is that poor quality leads to dismal results, we should be very interested in how exceptional quality can at least lead us to acceptable results. But input quality will only get us so far. To achieve a true recovery, we must aim for sustainable quality, and that requires profound change.
One profound change has been the activation of The Long Tail in software development. As empirical data examined so exquisitely by CMU Professor James Herbsleb et al. suggests, a long tail of software developers helps complex systems like Apache and Mozilla achieve functional milestones faster, with fewer defects, which are fixed more rapidly than comparable proprietary software development projects. This empirical evidence supports precisely the same result predicted by game theory models developed by Harvard Business School Professor Carliss Baldwin: free software provides a better architecture and a better economic (reward) model for development and innovation than proprietary regimes under a wide range of circumstances. In 2009 these findings were further corroborated when Red Hat was selected to join the S&P 500 index less than 10 years after its IPO. Open Source software development enables a new, viable, and robust model for digital recovery.
Nevertheless, it is extremely difficult for authors considered avant garde to understand, let alone even articulate, the very crux of their new theories and observations. When Malcolm Gladwell muses toward the end of Outliers how much richer our society would be if there had been more high schools with the kinds of computers that Bill Gates enjoyed as a boy, he demonstrates his absolute misunderstanding of the fundamental premise of a monopoly: there can be no other. When Chris Anderson explores The Long Tail, he considers very low cost, but never dares imagine free. Then when he does write about Free, he avoids the most profound implication of the model, namely that digital products become digital services, as Corey Doctorow so eloquently points out. Both Gladwell and Anderson have the mental capacity to see over the horizon, but neither are willing to leave the armchairs of the economic paradigms in which they are so heavily invested to acknowledge the logical conclusions that are inescapable.
Lately, I have seen an increasingly important and new implication even beyond what Corey Doctorow has said about free when it comes to software: when the cost of acquisition goes to zero, the cost of retirement (aka "exit cost") cannot be ignored.
In a normal procurement process, a pre-defined period is announced at the beginning of the procurement procedure. It is assumed that all costs related to the procured software that will be incurred during that period, such as upgrades, will be taken into account in the evaluation of the bids. A basic assumption of normal public procurement is that at the end of the pre-defined period, the procuring public administration has no contractual obligations towards the original vendor. When software based on proprietary standards and proprietary interfaces is procured, these assumptions of normal public procurement break down. Although no contractual obligations exist towards the original vendor beyond the pre-defined lifetime of the original procurement, the technical and financial cost of moving to a system from another vendor or producer, or even acquiring support from another independent vendor, may be very high.
Software is used to create documents, databanks and customised applications that, in the public sector, have a life-time that may be well beyond the originally announced life-time of the procurement procedure for the software. If the software originally purchased makes it difficult to use the documents, databanks and customised applications with similar software from other producers, then there is a high cost in terms of changing from the original software to another software - the exit cost. With proprietary software this also means there is a high cost in terms of changing from the original vendor to another vendor.
Thus, the assumption of normal procurement procedures, that all costs and obligations relating to a procurement are completed after the pre-defined period for which the procurement takes place, appears to fail when applied to software. Contractual obligations do not extend beyond the original procurement period for the software; but the need of the public administration to be able to continue to use its own data and applications means that technical obligations come into play, as well. Proprietary standards provide technical obligations that result, in effect, in contractual obligations - explaining why so many public administrations publish tenders for software refer to proprietary software simply by brand name. They do this because they find the exit cost too high, and may simply not quantify it.
Since an essential principle of public sector IT systems is sustainability and independence, the ability to change vendors and systems in the future is essential, and the cost of doing so should be included in the evaluation of the cost of the original software purchase. Hence the term exit cost, as these costs are essentially a result of the technical and business model choices of the original software vendor.
The initial selection of proprietary software, if it uses proprietary standards or implements standards in a way that is not exactly the same as software from other producers - can limit future software choices.[...]
In brief, long term dependencies on a particular vendor - extending past the boundaries of individual procurement actions - are not good procurement practice and may even be against applicable rules. Any decision, such as a further procurement action, that re-inforces this dependency on a particular vendor, should be avoided, and will only increase the exit costs.
As my fellow OSI board member (and report draft author Rishab Ghosh) explains "If you cannot quantify these exit costs, then you should limit them. If you cannot limit them, then you either need other software, or you need better criteria." When the question is "How do we wasting $1T USD per year on ITC spending?", the answer is that we're using inferior tools when superior tools are available. When the question is "Why are we wasting so much year after year after year?" the answer is proprietary lock-in that was never part of our initial procurement calculations. I have spoken with procurement people around the world in both the public and private sectors, and the single best way we can help them do the best job is for a line of business (or a public adminstrations) to communicate clearly and concretely the message that exit costs are real costs, and should be considered in all tenders. They have the necessary expertise to see that those costs are properly evaluated in the context of future procurements.
Finally, we must consider how the digital recovery can be delayed or destroyed by the misapplication of software patents. In a 2008 presentation, user-driven innovation guru Eric Von Hippel teams up with modeling guru Carliss Baldwin to explain The Economics of Free Innovation. In this presentation are several charts that show when one type of innovation or another is economically feasible or not. In Slide 6 we see every type of innovation considered by the paper, but let us focus on the triangle labeled C, Producer Innovation Only. Patents effectively drive up design costs for all those who do have rights to practice the patent. The effect is to make infeasible both competitive designs (conventional competition) and collaborative designs (such as we see in free and open source software). On Slide 14 we see that there are certain collaborative models that are feasible even when Producer-only innovation is not. Thus, patents can clearly foreclose those innovations which are profitable for no single entity, yet which may still be beneficial to the marketplace as a whole. Or, put another way, internet-enabled collaboration can achieve in practice what captial cannot (in theory or in practice).
The current status quo is clearly unsustainable. Monopoly has created a system of exit costs so high that not even the monopolist can manage them anymore. (Nor did they ever anticipate what it would mean, from an engineering requirements point of view, to design an operating environment based on the assumption of "No Exit". That model is not unsustainable. The good news is that as painful and as difficult as it may be to break the chains of bondage to the bad procurement decisions of the past, the costs and the benefits of open source are great, rapidly achieved, and can improve sustainably over time. Let the recovery begin!