Let's think (and be) bigger about open source and government procurement | Opensource.com

Let's think (and be) bigger about open source and government procurement

Posted 19 Apr 2011 by 

Rating: 
(1 vote)
Image by : 

opensource.com

submit to reddit

Last time I covered two reports assessing a potential move by The Netherlands government toward the use of more open source software. The commonality between the reports, with quite different conclusions, was the focus on cost and cost savings. 

Public procurement has evolved from the early days of being required to go with lowest cost, to comparing total cost of ownership (TCO) metrics, and to sometimes incorporating more complicated calculations that take into account narrow benefits. In an intentional manner, governments steered procurement to become more isolated and routinized through strict policy with the goal of making an efficient (cheaper) machine and one less susceptible to political meddling and special interests.

In times without outside influence, buyers generally go on their merry way where cost, whatever methodology used, guides their decisions, assuming functional requirements are met. In the last decade other areas of government have been stirring when it comes to open source and procurement: the legislature/parliaments, agencies/ministries, auditors, actual CIOs.

In but a few exceptions that make headlines, the discussion is in the same language of cost savings and TCO—an effort to maintain those procurement inspired aires of efficiency and demonstrative disinterest. There’s nothing wrong with a government focused on lowering costs and trying for fair opportunity. However, when that’s the only criteria, and we’re not at the very least exploring other considerations, it’s a disservice.

There are a few variations of an overused academic joke. A guy loses his wallet on the street at night. A passer-by stops to ask what he’s doing crawling around under the street lamp. Oddly, she learns the guy lost his wallet on the other side where there’s no lamp. The passer-by then proclaims “Oh, you must be an economist.”

It’s easy and tempting to look only where the light is, especially when it’s politically safe to do so. We’re piling up reports with wins in the open source category and wins in the proprietary category, continuously tallying the scores as if the final balance will tell us who is really superior.


My feeling is: Who cares?

One of the latest studies, just underway by researchers at London School of Economics is “...focusing on the total cost of ownership and acquisition of FOSS. The prime rationale for such a study is that FOSS financial benefits are commonly claimed, but that independent evidence is only available by exception, and may be wrapped in supplier generated reference studies.”

Indeed, that’s the state of evidence out there. But, I can predict their findings already (if they only focus on TCO as a prospectus suggests): ‘open source probably saves money, it depends.’

Adding another tally to the board, even if from a reputable non-vendor organization is not going to clear things up. And this study although sponsored by the UK Government is also sponsored by OpenForum Europe, so that will no doubt give critics something to latch onto.

When it comes to actual real-world implementations there will always be cases that prove an exception to the rule, if one is ever established. There are too many variables and parameters have too wide a berth. Vendor prices can always be discounted, time horizons change, labor prices and talent fluctuate, existing systems vary wildly, and available alternatives in the software landscape change everyday. Even if things settle down enough that a definitive direction of costly or cost savings is agreed upon, the magnitude of that difference will always vary.

Sure, cost is and will always be a leading factor in decision making and we should be promoting sound methodologies.  But, in this age of increasing reliance on systems and a move toward e-government, we can’t think about software in the same way as getting a ream of paper from the office supply store. 

At the behest of fairness and efficiency in decision making, we’ve lost sight of the strategic role software and systems play in making today’s government work and have also forgotten that the non-policy behavior of government can have reverberations throughout an economy. No matter your stance, or no stance at all, the debate and government introspections need to be restructured broader than simply on cost. 

I can hear cries of industrial policy or ideologue, but no, I’m not advocating a blanket requirement or even a preference rule, only that we collegially talk about and understand these potential other impacts (see at the end). Accusations like those are not new.

A highly referenced piece is Evan’s & Reddy’s provocatively titled “Government Preferences for Promoting Open-Source Software: A Solution in Search of A Problem.” 

Aside from mentioning communism, centralized planning, and industrial policy in only the first two pages, and apparently having a bone to pick with Lawrence Lessig, these authors’ lines have irked me for years:  

“He [Lessig] seems to be suggesting that the government should use open source software in ways that one would never suggest for a profit-maximizing business— or perhaps even Stanford Law School.... As we have noted earlier, governments do not have good track records at picking technology winners and losers.”

I’m not sure what government has profit-maximization in its constitution, but more importantly it’s rhetoric like this that has set the cautionary tone for inquiries into open source and government: stay on the track of cost, or you’re a meddling bureaucrat, or worse.

The dirty little secret is that going along with vendor standards and formats, paying for proprietary code not reusable in other parts of the same government, funding projects no matter the license, and forcing citizen and business interaction on certain technological platforms, IS STILL picking winners and losers.

Ignoring the inescapable role of government as an influential hub and not even exploring or fairly debating criteria other than cost is akin to enacting a procurement policy requiring you to plug your ears, close your eyes, and hum loudly.

Here are some often mentioned issues and interesting areas of study we should better understand. Even if some of these seem intuitively true, I’ll be the first to say we don’t quite have the evidence yet to be certain. I’ve seen theoretical modeling, and in a few cases data-driven work with mixed findings. Despite that, if you’re a legislator, agency head, auditor, or the like, and the next software procurement report that ends up on your desk doesn’t explore these issues, send it back.

  • productivity improvements
  • potential for process innovation
  • portability to other (people) languages
  • security, both current, and responsiveness
  • re-use potential internal and external, public-good production
  • long-term preservation of information
  • transparency, audit ability for code (sometimes in line with democratic ideals)
  • industry competition effects
  • tipping points in adopting technologies in networks
  • domestic economic impact
  • impact on future procurements—stretch that time horizon
  • effect on future adaptability and switching costs (lock-in in a sense)
  • influence on copyright infringement levels
  • digital divide-like issues, is there an inequitable impact on certain populations 
  • improvement of labor force skills, both internal and external

 If you’re interested in this, these make for a good introductory read.

 And for some examples:  ODF, VistA, PLONE.

submit to reddit

Art is the Research Manager for New Kind where he focuses on research and analysis for new methods of community engagement and participation. He's also a Government Fellow at the Center for Advanced Communications Policy at Georgia Tech and the Center for Innovation in Local Government.

Prior to New Kind, he was a partner with The Estis Group, a public policy consultancy, in Atlanta, Georgia. He's been a member of the government affairs team at Red Hat and has served a number of U.S.

 APIs are key to extending platforms

What is open government (promo)