“Affirmative action in procurement for open standards and FLOSS” by Mathieu Paapst was published a while ago, and I just got around to reading it. I made a mistake. It’s an insightful look into how the Dutch government handles open source in their contracts. I learned that they have a few principles for this:
- Open source is not mandatory, but its use should be strongly encouraged.
- Open source software should be preferred if it is equally suitable.
- Providers of open source software should have the same opportunities as providers of closed source software.
So Paapst asks a great question: how’s that policy working out?
He polled 94 Dutch agencies, and found that 72% of procurements didn’t follow the rules. In fact, 29% of them actually preferred proprietary software. So that’s not great.
You’d think they’d named specific companies or products in the tenders, which is obviously against the law, but that only happened twice in his research. I’m fascinated by these other tactics that prevented open source from being used:
- Limit the available resellers to those who only offer the proprietary software you want.
- Insist that the vendor be certified by a closed source company: as a partner, as a support vendor, or staff certified for a particular closed source product.
- Ask that the product be certified by a named closed source vendor.
- Asking for an operating system that can be downgraded to Windows XP. (Sneaky!)
- Asking for software that can be used under the Microsoft Campus Agreement.
- Tendering for hardware (e.g. laptops) while also asking for named software (in most cases Microsoft) to be installed on that hardware.
He also found that some tenders introduced requirements for open source that proprietary software didn’t have to meet:
- If your bid is open source, you should give extra guarantees concerning the stability of the open source community.
- The vendor has to be the copyright owner.
- Not allowing licences to be offered for a “zero-price”.
- Demanding that offered applications must be certified by Microsoft, are Oracle 10 compliant and use the official Microsoft style guide as much as possible.
It’s no surprise that government procurements are often rigged for an already-chosen vendor, but I found these two lists a pretty handy field guide to the tactics they’ll use.
This kind of behavior is not just bad for open source, but bad for your domestic technology industry. Government procurements are notoriously difficult to handle, and few companies have the stomach for the necessary paperwork, terms, and conditions. Small business and upstart proprietary software has a hard time getting into this market, and procurement language like this virtually guarantees that you’ll see the same incumbent bidders on every tender.
He also discovered something more alarming: when the agency wrote the tender themselves, these tactics were found ~37% of the time. When the tender drafting was outsourced, it occurred 80% of the time. Wow.
We could charitably think of this as, maybe, sophistication: you’ve hired a firm to create the tender, and they’ve done this a dozen times, and they know how to get you the result you want. I think it’s more likely that the firm is making product choices without any prompting from the government.
So while the paper is trying to determine the evenhandedness of the Dutch procurements, and whether open source needs special concessions from their tenders, I’m drawing a different lesson. The problem isn’t pro- or anti-open source language, it’s a system that can be rigged to favor one product over another with very little effort.
I think the problem is much more basic: these tenders, and those who write them, are thinking about stacks of software. That’s all wrong – I talk about this at length in Cult of the Product. When the government issues a tender for something, they should be describing the problem, and the constraints to solving that problem. So it’s not that I need some software under some company’s “Campus Agreement,” it’s that I need to solve a problem without spending more money than what I’m already paying under that Agreement. See the difference?
Presenting a problem and the constraints on a solution not only avoids any procurement violations, but makes your agency available to all kinds of new ideas, approaches, and business partners that are completely missing from how we conduct procurements today.