Quebec Lawsuit Highlights Problems With The Software Procurement Process
from the time-to-rethink-things dept
FACIL, a free software advocacy group based in Quebec, recently filed a lawsuit against the provincial government (via Michael Geist) for favoring proprietary software without considering the free and open source alternatives. This story got plenty of attention a few weeks ago, but it’s important to break down the details to understand what’s really happening here.
The government is required by law to place contracts over $25,000 for tender, yet FACIL cites over $25 million worth of contracts between February and June 2008 alone in which no bids were solicited. The government is not being sued for buying proprietary software, as some headlines suggest (via Slashdot), but for failing to adequately evaluate the other options.
The lawsuit highlights a larger problem the procurement process has dealing with software. In the procurement process, the government publishes specifications for what it wants, companies submit bids and an open and transparent method is used to determine the best offer. This is mandatory except in a few special cases, like when only one supplier can meet the requirement. So, if the government publishes specs for Microsoft Office, rather than “office productivity software” then only one supplier can meet the requirement. It would be like seeking bids on a Ford Taurus. It’s obvious which company is going to win.
This process may work well for tangible goods, but it’s awkward for software because governments tend to use the process to acquire licenses, rather than “software.” Everyone is automatically licensed to use free software, so the process isn’t even needed here — and since only the copyright holder (or someone they’ve authorized) can sell a proprietary software license, the whole process isn’t even legally required. The important decision isn’t where to obtain a license, but which software to use in the first place. In other words, the process has a huge loophole. As long as the gov’t defines what it needs as “Microsoft Office” rather than “office productivity software,” no competitive bid is necessary, and the law isn’t broken. The copyright loophole for proprietary software basically turns the procurement process into an announcement system.
So, the real problem isn’t that the gov’t broke the rules, but that the rules are set up with this huge loophole due to the nature of software.
The process should really be adapted so that it can evaluate both proprietary and free options in the open and transparent setting it’s supposed to facilitate. The government should solicit bids for office productivity software rather than for Microsoft Office specifically — and the process itself should be more open so that the “bid” isn’t limited to just one offering. The answer is more complex though, since one contract has implications for another throughout the software stack (open standards can help) and the financial incentives for participants need to be reconsidered (not all companies sell software), but finding a solution is imperative for the government to truly act within the spirit of the law. That’s what the lawsuit is really about.
Filed Under: canada, facil, procurement, quebec, software
Companies: microsoft
Comments on “Quebec Lawsuit Highlights Problems With The Software Procurement Process”
The solicitation of competitive bids is the norm in the majority of procurements by governments throughout most of the industrialized nations. Unfortunately, the procurement process is oftentimes “gamed” by certain companies in the private sector having under influence is helping their government counterparts define performance specifications, support requirements, etc. Of course, in these latter situations the end goal is to craft a set of specs that essentially eliminates all but one company. BTW, there are valid bases for the award of sole source contracts, but these are generally limited to cirsumstances involving exigent cirsumstances where time is of the essence.
As a general rule, COTS software (both open source and proprietary) tend not to be well suited for specialized software needs in industries such as aerospace, but that is a gap that is narrowing. Until that gap closes, I believe that custom designed proprietary software will hold the upper hand for high end applications, if for no other reason than government procurement officials place significant emphasis on having single points of contact (a specific company) to hold responsible should something go wrong.
Clearly, guidance should be provided emphasizing competitive procurements to the maximum extent possible. Like anything else, however, old habits die hard.
Re: Re:
But custom, proprietary software isn’t the same issue. In the case of custom software, the procurement process is looking for bids on creating software to meet a particular set of requirements. So the procurement isn’t “we need a bid for company XXX to build YYY”, it is “we need bids to build YYY”.
Now one can argue that the procurement process is designed to only allow select contractors to bid (size, experience, etc.), but that’s a different criticism. At least the process is open to “all qualified bidders”.
In the Quebec case, the issue is “we need bids for product MSO”, which is identical to “we need company MS to sell us product MSO”, since MSO is only made by MS.
Re: Custom != Proprietary
“Custom” doesn’t have to mean “proprietary”. If development of a piece of software was paid for by tax dollars, why shouldn’t it be freely available?
Great overview, Blaise
Thank you for breaking down this difficult topic.
Open Source - Difficult for Government
Unfortunately, the government has a real problem understanding how to tackle open source. And to be honest given the structure of the environment, the way accountability works, the general skills of the staff, I can understand it.
For example, with open source software, government organizations have FUD regarding the lack of a specific organization to hold accountable for problems and security. Without a contract, the government is on its own. Open source also tends to lag in the area of accessibility for the differently-abled, for which, at least in the US, all government implemented software must meet certain legal criteria.
Regardless of the realities of how well (or more likely poorly) commercial software addresses these areas, woe unto the government official that was the one accountable for the decision to use open source software when a breach or failure is found. No one will care that the comparable commercial software was equally vulnerable.
Re: Open Source - Difficult for Government
Realize though that the problem being pointed out is not about ‘open source’ in particular. If the procurement was for “office productivity software” (i.e. state the problem to be solved) and not “microsoft office” (i.e. one potential solution) then the government and the public get the benefit of competition by a variety of vendors. Some of those options may be proprietary, some may be open source, but the competition (and openness) is what is key.
I’m a huge Open Source proponent, but I wouldn’t want to dictate that “open source” must be a candidate. It isn’t acutally the particular software that is important, it is the SOLUTION, which includes services and support. If no vendor sees a benefit to their bid by leveraging “open source”, then that to me is ‘open source’s” problem, not a vendor/government problem.
#1
There’s always a market for specialized systems, otherwise the software would not exist. Open-source is closing the gap in many areas, but there are still very specialized niche markets (your example and health care come to mind) where the number of customers is very narrow.
What the article refers to is the commodity software, business productivity applications. A government entity should be evaluating options whenever a contract comes up for renewal or replacement to evaluate the TCO on the system (*and not just some sales drones’ baked numbers) to determine the best solution for the taxpayer dollars. Maybe it’s Microsoft or Corel, OSS or Lotus.
Of course this is the government we’re talking about…
Great Article
For 99.9% of routine office work, open source software such as Open Office would do just fine.
Thanks, Blaise
At least part of the problem with Governments is that they bought into the Microsoft monoculture for desktop applications some years ago and now feel stuck.
Where IT and things like controlling departmental applications and such are concerned my bet is that Quebec, like British Columbia (who I am very familiar with) the bureaucrats in charge are more concerned with control than TCO or productivity. As in “You get this because everyone else in your group gets it and you don’t get that because no one else has it.”
Add to this the presence of Microsoft lobbyists in places like Quebec City and Victoria who feed the purchasers every bit of FUD about FOSS that they can come up with.
(Yes, Virginia, we have lobbyists in Canada!)
Specifying a product, MS Office, rather than a broad application line (office productivity software) allows the purchasers to honour the letter of regulations regarding the bidding processes while violating the spirit of it which is to ensure an open bidding process.
For Microsoft losing the province of Quebec would be more of a monetary hit than losing B.C. would be though perhaps losing B.C. might be worse PR given that Victoria is a 30 minute flight from Seattle or a two hour drive and ferry trip through some of the nicest scenery in the area.
As has been noted specifying open standards such as ODF would go some way to resloving this though I’m sure the answer would come back that Excel spreadsheet applications won’t work in OpenOffice.org (true) though the vast majority can be adopted to work there.
ttfn
John
specifications vs. requirements
I was very tangentially involved in a US military procurement process in the mid 1990s where the Navy specified that desktop machines would be standardized on a particular configuration of Office 95.
This worked fine at first, and fixed a problem where each unit was previously optimizing machines for their own needs and units before long had technology that would not effectively talk with other units’ technology (remember interconnectivity was not as good back then as it is now.)
But as MS released newer product, and as some in the Navy recognized that significant money could be saved by using thin desktops for many applications, this specification resulted in locking every unit into buying product that did not quite make sense for them. It takes a huge procurement engine (like the DoD) some time to upgrade a standard. And, in this case, the market was moving much faster than the procurement engine was able to follow.
The result was inappropriate software purchases with short term use horizons, and money wasted that possibly totaled in the tens, if not, hundreds of millions, of dollars.
The way the Navy should have handled this in the beginning was to be clear about the difference between requirements and specifications. They should not have set specifications as their rock standard, but instead should have set requirements for performance characteristics and interoperability. Then individual units would have had some flexibility to move with the marketplace while maintaining the level of software quality the Navy needed.
Like it or not, procurement officials prefer to deal with dot com companies over dot org organizations. You can beat up on the former should a screw-up happen, but it is harder when the latter is involved.
Re: Re:
Yes, but nothing should preclude a .com company from bringing .org technology as part of their proposed solution.
Eclipse, OpenOffice.org and JBoss don’t propose solutions. IBM, Sun and Red Hat do, using these technologies.
Problems With The Software Procurement Process
The following is a link to an article I wrote last year that hit a nerve amongst my readership in the public sector regarding FOSS; (http://procureinsights.wordpress.com/2007/09/27/the-fossilization-of-the-supply-chain-the-risks-of-a-strategy-centered-on-free-open-source-software/)
Titled “The FOSS(ilization) of the supply chain: The risks of a strategy centered on Free and Open Source Software,” it views the challenges you have touched on except from a Federal Government perspective.
This story took on additional signifigance given the GoC’s continuing struggle with attemps to reform their procurement policies and practice (re what was originally referred to as the Way Forward initiative).
For those of you who may be interested in the source, the Procurement Insights Blog reaches 300,000 syndicated subscribers each month worldwide.