Don Marti has some choice words for Braden’s post on Scott McNealy and government open source contracting:
Let’s say that one of those Rent-to-Own stores that sells electronics under a confusing, one-sided contract got a big idea. Hey, we’re going to get a piece of the government market for LCD monitors!
Wait a minute, though. The government has a competitive bidding process for electronics, and no bureaucrat is going to commit to paying two grand for a $300 monitor. Even if you could bribe him, somebody is going to look at the books eventually.
Looks like life is tough for our fine-print-slinging rent-to-own sales weasel. But all is not lost. Next step: hire a fake-Libertarian rent-seeking lobbying operation out of Washington, D.C. Now you can re-cast the corporate welfare you want as having the freedom not to get your rightful corporate welfare, I mean property, taken away from you.
Put some Libertarian-sounding spin on the rent-to-own monitor plan, and now it’s: There’s a Regulatory Mandate to buy only Open Bid Monitors! Why can’t we have Fair Competition betwen the Open Bid model and our business model?
I don’t think the name-calling is necessary, but Don does raise some interesting points. My thoughts:
- I don’t think there’s really a matter of libertarian principle on either side of this debate. When the government is buying goods and services for its own needs, its primary obligation is to be good stewards of taxpayer funds. So if the evidence showed that buying free software tended to be a consistently better deal than buying proprietary software, it might make sense for the government to decide it was always going to buy free software.
- I don’t think the “regulatory mandate” language makes very much sense. Ordinarily, when libertarians talk about “regulatory mandates,” we’re talking about mandates that get imposed on private parties who are minding their own business. But there’s no getting around the fact that when government purchases software for its own needs, it has to “mandate” the criteria for purchasing the software. And licensing terms certainly seem like fair game to me.
- Freedom matters. That is, the advantage of free software isn’t simply that the government saves on licensing fees. When you adopt a proprietary software product, you’re locking yourself into that vendor’s products and services. If the vendor screws up, you can’t just fire the vendor and hire someone else to maintain the infrastructure. Firing the vendor means, at a minimum, switching software, and may require switching file formats.
- If the government is the primary customer for some category of software product, the case for requiring open source solutions is considerably stronger. The point of proprietary business models is to allow the vendor to spread the initial cost of development over multiple customers. But if the only customer is the taxpayer, then choosing a proprietary software product simply amounts to the government putting itself (and by extension, taxpayers) in a weaker position in future contract negotiations. Voting machines are a good example. There isn’t much of a private market for DREs, so it’s hard to see the argument for accepting bids from vendors who won’t provide access to source code.
With all that said, I think there are solid practical reasons not to exclude proprietary software from government contracting across the board. If a product like Office or Photoshop dominates a market, it doesn’t make sense to exclude that product from consideration. The government is a small part of those markets, and insisting on open source products is more likely to simply leave the government with inferior software and/or higher costs.
There’s also a basic Hayekian point that a certain amount of decentralization is critical to the success of any large organization. The head of IT for a large government agency isn’t necessarily going to know about all of the software being used within his agency, and excluding proprietary software from considerations could cause significant hardships for units within the agency that depend on particular proprietary software products. It probably makes more sense for the head of IT to make sure that the relevant decision-makers clearly understand the benefits of open source software and the problems of lock-in, but leave the final decision up to people doing the actual work.