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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: canada, facil, procurement, quebec, software
Companies: microsoft
Reader Comments
Subscribe: RSS
View by: Time | Thread
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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?
[ link to this | view in chronology ]
Great overview, Blaise
[ link to this | view in chronology ]
Open Source - Difficult for Government
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.
[ link to this | view in chronology ]
Re: Open Source - Difficult for Government
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.
[ link to this | view in chronology ]
Re: #1
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...
[ link to this | view in chronology ]
Great Article
[ link to this | view in chronology ]
Thanks, Blaise
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
[ link to this | view in chronology ]
specifications vs. requirements
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.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
Eclipse, OpenOffice.org and JBoss don't propose solutions. IBM, Sun and Red Hat do, using these technologies.
[ link to this | view in chronology ]
Problems With The Software Procurement Process
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.
[ link to this | view in chronology ]