Cord Blomquist did a good post over at TLF about the USTR/open source software issue. It set off a lively debate in the comments that, I think, reflected a common misconception about what free software is and why it’s valuable.
Before digging into that, I should be clear that I don’t generally think it’s a good idea for government software procurement decisions to be dictated from the top down. I’ve had first-hand experience with working at the bottom of large IT hierarchies, and so I know it’s incredibly annoying to have distant bureaucrats constrain the tools you’re allows to use. I wouldn’t endorse a proposal for the federal CTO to mandate that all federal agencies use free software.
But a some people, including a significant number of libertarians, make the stronger claim that government agencies at all levels have an obligation to be neutral between proprietary and free software. This is generally phrased as saying that the government shouldn’t “distort the market” or “pick winners and losers.” On this view, the government has an obligation to make its decision based on the characteristics of the software, without discriminating based on licensing or business models.
To see why this is wrong, consider the following hypothetical. Suppose federal agencies had a long-standing practice of obtaining their care fleets by renting them from companies like Enterprise and Hertz (or, more likely, government contractors that charged ten times as much as Enterprise and Hertz would). Now suppose the GSA did a study and found that the government would save hundreds of millions of dollars by purchasing automobiles rather than renting them. Suppose further that many agencies were finding that the limitations of their rental contracts (mileage limits, reporting requirements, slow repair service, whatever) were making it harder for them to do their jobs. So the GSA issues new guidelines saying that government agencies should henceforth prefer buying to renting.
Now, there are all sorts of good arguments on both sides of the renting-vs-owning decision. But one argument that doesn’t make sense is to say that government would be “distorting the market” if it decided to buy cars rather than leasing them. A purchased car is a different kind of product than a leased car. If car ownership serves the government’s needs better than car rental, the government is entitled to purchase cars without worrying about how this affects companies in the business of renting cars.
The same point applies to software. The difference between Windows Server 2008 and Red Hat Enterprise Linux isn’t just that one was produced by humorless suits in Redmond and the other was produced by dirty hippies in Raleigh. It’s not even that one costs a lot of money and the other one is free. (Support costs will often dwarf licensing fees anyway).
The key difference is that proprietary software comes with a lot of restrictions about how it may be used—restrictions that don’t apply to free software. Probably the most important freedom free software gives provides is the freedom to switch vendors. If a government agency chooses a proprietary software package, the agency is likely to find itself with serious lock-in problems down the road. Switching vendors will mean switching software platforms, which will involve large conversion and training costs. In contrast, if an agency chooses a free software-based solution, the lock-in problems will be less severe. The agency can easily bring in a new firm to provide support for the existing software. Or it may not need to hire outside contractors at all—the internal IT staff may be capable of fully supporting the system internally.
The freeness of free software is not an esoteric detail about how software was produced, nor is it primarily a matter of ideology. Rather, free software provides direct and tangible benefits to their users. If property rights is a bundle of sticks, free software vendors give you all the sticks up front, whereas proprietary vendors give you only some of the sticks so they can charge you later for the others. And some of the missing sticks are things that actually matter to government agencies. So it strikes me as a no-brainer that the government would—all else being equal—prefer the type of software that comes with fewer strings attached.
It’s absurd to say that the government has an obligation to be indifferent between firms that attach strings to their products and firms that don’t do so. Obviously, there are circumstances where a firm makes such a great product that it’s worth putting up with the associated strings. But it should be equally obvious that software freedom is a factor to weigh in software purchase decisions. And I don’t anything wrong with reminding government IT workers to keep this factor in mind when they make software purchasing decisions..
I really have no problem with governments using their purchasing power responsibly. This is exactly what’s going on here, but more importantly they’re responding to the way the market works.
I think you’re correct mostly for abstract software such as code manipulation tools, standards-compliant servers (like J2EE), open source code libraries and etc. These are usually either easily extricated, switched, phased out or deprecated. Because you can still keep them in some cases, free means you don’t have to worry about continuing to pay for them after a switch.
There are at least a few pieces of software that would be worth the trouble of not being free (purchase or support) which include anything business critical such as point of sale software, intranets, servers. I would only feel comfortable though if I knew that I could switch with relative ease, but that it would cost me more to create it than to get support.
The monumental arrogance of a U.S. judge to patent living programming languages was the basis of all of these arguments – Try granting patent on say, Spanish and watch the proverbial stuff hit the fan! Right now Arrogant assholian Americans are trying to patent pigs, cabbage, corn, wheat! Goddammit! They don’t even consult the Russian Babushkas that have grown theses things since before they were pups! Next they’ll buy a judge, and patent sperm, in an attempt to impose a “Corporate Tax” on you know what! Microsoft – the biggest blood-sucker ever! Even Hitler didn’t have that much nerve! Watch for better software and computers out of China, and soon! With Indian programming, just like Microsoft only with annual improvements that make sense!
Actually, business-critical software may have even more reason for being open source than non-critical software. Again, it comes down to support.
Proprietary software is supported only by the vendor, and the vendor doesn’t have the same interests as you. You want your system to work; the vendor merely wants to get money out of you in the most efficient way possible. (Note that I’m not putting making a value judgement here; the vendor is simply doing what is in its best interests, which is perfectly natural.) Thus, any support you get from the vendor is going to be negotiated: you will ask for things and threaten to withhold other things if you don’t get them, and the vendor will decide what it will and won’t give you.
In a non-critical system, this isn’t usually a big deal. If you can’t get a feature that you want or get a very annoying bug fixed, you live with it. In a business-critical system, however, problems like this can hurt a lot more, to the point where even very expensive workarounds become economical or, in the worst case, you need to change or abandon entire lines of business.
This is where open source giving you more options for support makes a difference. Not only can you look for new support vendors if your current one doesn’t satisfy you, but you also have the option of internalizing some of that support: doing it yourself. If something’s important enough to you, and you’re spending a fair amount of money on it anyway, it can be worthwhile to hire someone who is or can become a developer of that open-source software. That gives you the ultimate in support because you’re now not negotating with the vendor for features or bugfixes; you’re sinmply telling your developer what to work on. It also makes finding bugs considerably cheaper because it removes the gap between the person who understands the internals of the software and the person who understands the context within which the software is used: one person now has both of those sets of knowledge.
Hrmm. Yes you’re right. I suppose I should have included “modify” as well as “create” in the last sentence of my earlier comment.
On the other hand, having that expertise is not always possible, which is why purchasing then paying for support business models exist in the first place. It also tends to be that which is business-critical is also peripheral to the service or product you’re providing, which makes it unlikely you’ll want to spend time or effort improving those systems.
I’d counter your point that the provider is only out to make money with the fact that its business model is based on the service they’re providing, which means they have the incentive to improve and update their product consistently. Their sales department wouldn’t have customers long otherwise.