>Specifically, the DOI stated upfront in the RFQ that the solution had to be part of the Microsoft Business Productivity Online Suite. Google is making the argument that this is "unduly restrictive of competition,"
I don't actually know what the Microsoft Business Productivity Online Suite is, but if they're already using it for a lot of other stuff, I think it's pretty understandable to want their email system to integrate with it.
This is actually a perfectly legitimate practice - there are various regulations that govern these types of single-vendor/single-product requests. Usually you have to show (based on an analysis of currently available solutions) that no product except the one named could possibly meet your requirements.
In this case, it appears that the DOI actually followed those rules and came to the conclusion that only MS could provide a working solution. Google is essentially saying in the complaint that
a) Their solution meets the stated requirements and the DOI knew about it.
b) It is unclear if Microsoft's solution even meets all the requirements (specifically the security requirements since Microsoft is not currently FISMA compliant and has a bunch of known problems in its exchange server)
therefore the justification for naming Microsoft's solution is invalid and solutions involving Google's product should have been allowed for consideration.
Since I didn't actually read the DOI justification (only Google's summary of it) and I am not familiar enough with the specific regulations that govern this sort of thing to comment on its validity, I simply wanted to point out that "naming the winner" in the RFQ is not enough to invalidate it and is not necessarily a problem if the proper research has been done.
Common practice. When I was involved in doing RFPs for hardware, you were allowed to say "We need a computer. It needs to be 32 bit. It needs to have such-and-such amount of memory, be able to run Unix, and ..." You could even say what color it had to be.
Then they'd print a bunch of copies of these several hundred page documents up and mail them to IBM, Honeywell, Wang, DG and DEC and so forth for bids.
The guy at (say) DG would get this, see that the Govt wanted a Vax, and toss the RFP. IBM might try a bid, but usually the "Unix" bit would cause them trouble. [This was well before any serious IBM effort in Unix].
Are they naming the winner before-hand? A quick Google search seems to indicate that there are companies besides Microsoft that sell Microsoft BPOS. Presumably those companies can bid on this job.
BPOS is a Microsoft-hosted cloud service. There are various "Qualified Microsoft partners" who will essentially act as consultants to asses your needs and point you at the right Microsoft plan, but the per-user-month pricing is the same whether or not you go through any of those or direct to Microsoft, and the fee is always paid to Microsoft. The business model for the partners is just a time-and-materials on the consulting bit; they aren't true vendors who can compete on service price.
Their requirement is a single-vendor, single-source service that can only be obtained from Microsoft. That's naming the winner before you hold the contest.
Agreed. I'm really supprised that language like that made it through to the final RFP. I have been involved with RFPs at government organizations and legal is always supper careful about writing requirements that potentially restrict competition exactly because of risks like this. It is also just poor requirements writing, you should never specify the solution in the requirements, you are just cutting off so many possibilities
An RFQ (request for quote) by its very nature is a request for specific commodities from an existing purchase contract, which are evaluated on a cost basis.
In it's simplest form related to IT, a server vendor has an part number for a hard drive listed on the GSA contract. Multiple resellers are able to sell that part. A RFQ is a solicitation that says "We would like to purchase 50 units of part #12345". The reseller with the lowest price wins.
The French have adopted Ubuntu as their primary systems. Stock markets now run on Linux. So does whitehouse.gov. Obama's campaign servers ran on FreeBSD.
It's not entirely unreasonable to see it changing. Plus, as you said, it would save the government plenty of money in licensing and support.
Maybe, it will save licensing costs, but it will not save on support costs. Contracting companies are not going to lessen their support bids for Linux compared to Windows. I wouldn't be surprised if the bid for support was higher to compensate for the lesser number of Linux-trained support people. It will probably be a wash.
Even if it is, the government would have easier access to and better control over an open-source stack than it would with Windows. It would also have a wider possible market because support vendors would not have to get Microsoft's blessing before providing services.
Actually, the US government probably could get Microsoft to make a change / add something a lot quicker than it could from the Linux community (money is a fine leverage). Many support organizations don't exactly get permission from Microsoft to bid.
Red Hat/Novell/Canonical could add/change Linux features just as easily as Microsoft could add to or change Windows. The Linux community isn't just a bunch of people who are writing code for the fun of it.
Not only that, but you can make Red Hat, Novell and Canonical compete against each other for the best solution.
As much schizophrenic as Microsoft's various divisions are, you can't make the Xbox division compete with the Office division on which one wins a contract for adding a feature to the Windows 8 kernel.
For better or worse, the US government has a lot easier time dealing with a central point of control and owner's of products are their institutional experience. Also, I gotta wonder how a change that was not popular would work if made by one of the distribution companies.
Also in this case the "desktop" would then be just any old client which could easily be upgraded/swapped out and something other than Windows could be used as OS.
EDIT: Note that in general sovereign immunity would preclude a contract suit against the government. The Tucker Act permits several types of claims against the US Gov't.
The news article is a bit light on all the details. I did some work for some of the people bidding and probably the best summary of who 'won' is in the GSA's (who supply the IT infrastructure to other govt agencies) press release found here:
Note that a lot of http://apps.gov is based around vendors built on Amazon EC2/S3 and Salesforce force.com platform. Microsoft is not a dominate player in government IT, in fact I probably see far more tax money going to IBM and/or Oracle every year if it makes anyone feel better. /s :)
It is true in the area of office apps that Google have an case here, but another way to look at this is that Google are mighty sore for having gone through all that security accreditation (FISMA) without winning more business. They put a lot of effort into the RFQ (as did Amazon, who did well out of this)
This is a thick-headed publicity ploy on Google's part. Hate on Microsoft all you want, but Google Apps are not even close to Office in terms of functionality.
Less functionality is an advantage for most tasks at hand.
The functionality overload in recent versions of MS Offfice was so huge it made Microsoft develop entirely new user interface (`Ribbon') as the traditional pull-down menus weren't able to cope with it anymore.
Are you sure you need Kate the Average Secretary to toy around with countless functions? Will that add to the bottomline?
This is great in the long run, but seems to be loose loose for google. Either they loose, pay for legal fees, and the goverment continues buying Microsoft, or they win, get a payout from microsoft, and still don't get business, because Microsoft probably won't buy enterprise software from the company they were just sued by.
I would love a different way of handling Government RFQs: If your company engages in income shifting to avoid paying taxes, you are ineligible for government contracts.
Because one of the largest contract purchasers, the government, limits their options to one solution, the ecosystem is really small for alternatives. Once this is opened up, there is increased potential for more options to arise. Having Microsoft being the only option is artificially retarding innovation and options.
"Microsoft Business Productivity Online Standard Suite is a set of messaging and collaboration tools, delivered as a subscription service, that gives your business rich capabilities without the need to deploy and maintain software and hardware on-premise."
Google's argument is that it wasn't a real RFQ if it was required to be from MS. Perhaps they already decided on Microsoft Business Productivity Online Suite but legally had to put up an RFQ and worded it as such that their chosen package was the de-facto winner. I guess we'll find out.
The RFQ could easily have excluded Google in other ways, for example "Business productivity software shall be from a company with a minimum of ten years experience in providing business productivity software to government agencies."
"A minimum seven years" would also have excluded Google.
As would "five."
Google's track record with business productivity apps for large organizations just isn't very long...
They are warming to it, especially when it is offered by solid companies who can provide the support. The 'services not licenses' business model of a lot of OS suppliers actually works quite well with Govt IT. The downside is that the existing players are huge (due to large contracts) and hard to dislodge. It is getting better though (I spent some time building http://apps.gov if you want a sort of overview of the type of 'free market' that is trying to be provided to federal agencies here).
I don't actually know what the Microsoft Business Productivity Online Suite is, but if they're already using it for a lot of other stuff, I think it's pretty understandable to want their email system to integrate with it.