FLOSS and COTS: Natural partners for decreasing costs and increasing quality

When we read about "scandals" such as the government paying $800 for a toilet seat or $400 for a monkey wrench, we may initially think that waste, fraud and corruption are at work, but a closer look reveals a less sensational reality. What we are seeing are the natural consequences of custom procurement. For an interesting article exploring this issue in detail, see "The US Army as a Rational Economic Agent" (eh.net/Clio/Conferences/ASSA/Jan_94/Kauffman) The problem is not with paying too much, it is with buying the wrong thing. If you need a television, you go into Best Buy and pick one off the shelf for a few hundred dollars, you do not write elaborate specs for a specialised product and then ask a major company to build you ten of them. So naturally the thought occurs, if I can buy television sets through the commercial marketplace, why can't I buy my software development tools, libraries, operating systems, etc., in the same way? Indeed the answer is that you can often do this very successfully, but we still see a lot of specialised development going on. Why is this? Several fundamental economic factors prevent more extensive use of COTS tools. The first is COTS' 'take it as it is' business model. You purchase some standard software product, and if it is exactly what you want, fine. But if you need the slightest change, you are in big trouble. I have no idea what Microsoft would charge for a custom modification to Vista, but it would likely be a scary number. If you are procuring custom software, then you can of course specify exactly what you want. A second important issue concerns support, both short term (for a current product release) and long term (for older product versions). Although COTS tools often seem easy on the budget, their low price comes at the expense of effective customer service. Going back to our Vista example, Microsoft can afford to supply copies of this extraordinarily sophisticated operating system for less than the cost of a meal in a good restaurant, but they cannot be expected to provide extensive individualized support. If you are building a mission critical system, this lack of support may be a serious drawback. Even more significant is the issue of long-term support. Critical systems often have lifetimes measured in decades and thus need to commit to specific (baselined) versions of the software products they depend upon. The consumer marketplace, however, operates under very different dynamics: 'new and improved' is the order of the day, and indeed software companies make money from frequently selling new versions with new features. That may be fine for most consumers, but not for long-term projects. Again Vista provides a good example. Many users would prefer to stay with Windows XP, but this Operating System is getting harder and harder to buy, and Microsoft is determined to discontinue all support. Furthermore, since it is proprietary, no one else can effectively step in to provide the needed service. In some cases, software vendors employ licensing or distribution policies to actually enforce moving to new versions. For example, if you have purchased Quicken to manage your accounts and are using their online backup capability, you will eventually find support terminated if you do not update to a new release. Customised products These considerations often add up to a decision to buy a customised product. Although this may seem exorbitantly expensive, it may be much more practical and less costly in terms of life cycle costs once we take into account the need for customisation and long term support. So, what's the relevance of the other half of the subject title for this article? The principles of free licensing embodied in FLOSS (Freely Licensed Open Source Software) can solve the traditional problems with COTS procurement: lack of product adaptability, and lack of effective support. First, let's clear up one confusion. Often people distinguish between the 'Free' of 'Free Software', and 'Commercial'. But that's an incorrect distinction. In fact there are many companies (including our own company AdaCore that makes high end development tools for critical systems) who market commercial software using free licenses such as the GPL. 'Commercial' does not have to mean 'proprietary'. Shortcomings of normal COTS procurement So how does FLOSS work to overcome the shortcomings of normal COTS procurement? First let's look at the issue of specialised modification. Since typical FLOSS software comes with the program source code and permission to change it, there are clearly no intellectual property rights issues standing in the way of making needed modifications. There are thus three possibilities: you as the customer can modify the software, you can hire a third party to do the modifications, or you can ask the supplier to do the modifications. The difference from proprietary software in the third case is that since you have the other two options, a FLOSS supplier cannot charge some outrageous amount on the basis of being the only one who can do the work. AdaCore's major product, an Ada development environment including a compiler and toolset and supplemental libraries, illustrates how FLOSS works in practice for software modifications. We don't see our customers wanting to change the compiler themselves, but they commonly ask for enhancements. Small enhancements can often be performed as part of our standard support, and larger enhancements can be contracted for. However, for the AdaCore supplied run time libraries that are distributed with applications, customers frequently find it useful to be able to inspect the source code and make small changes. The license provided for the libraries give customers these freedoms and also allows them to develop applications that may be proprietary or classified. Turning to the issue of support, again as a customer, you have far more flexibility under FLOSS than with proprietary software. Since you have access to the source code, you can if you like build up expertise and use internal resources to handle support on your own, or you can hire a third party. Again, you can expect the supplier to provide support at a reasonable cost, given that you have the other two options. The 'take the money and run' model does not work well with FLOSS products, since users have permission to redistribute the software. At AdaCore, we know that the company will prosper if customers find that our support meets their needs, so we have a strong incentive to provide effective support. Similar principles apply to long term support for baselined product versions. If a company producing FLOSS software chooses not to offer long term support, then a third party can step in as an alternative solution. Again, given this possibility, a vendor of FLOSS products has a high incentive to provide long term support themselves. At AdaCore, we quite often enter into agreements with customers who have very long term requirements for support, and we are able and willing to provide this service. The benefits of COTS can be substantial, not only in reducing costs, but also in increasing reliability. If you are among thousands of people using the same piece of software, it is much more likely that problems will be found and fixed than if you are the sole user of a custom software product. The combination of FLOSS principles and COTS software makes it practical to use the COTS approach even for procuring critical systems with expected usage cycles spanning many decades. AdaCore's Ada-based development systems have been used to generate applications in such diverse areas as military/aerospace, air traffic control, medical equipment, and high-reliability banking applications. These are not normally areas where you would expect to find COTS at work!