Hacker News new | comments | show | ask | jobs | submit login
Google Sues The US Government For Only Considering Microsoft Solutions (techdirt.com)
192 points by ssclafani on Nov 1, 2010 | hide | past | web | favorite | 59 comments

>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.

Nevertheless, an RFQ that shapes its requirements in such a way as to essentially name the winner before-hand is a serious problem.

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.

IANAL and I didnt read the DOI paper, but as I think you are mostly right.

I think the DOI can require that a solution must be compatible with or have the same features as Microsoft's solution.

However, they cannot say the solution MUST be the Microsoft product, and I think that is what Google is arguing.

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

Really depends on the department. I have seen some that are almost "we already picked the winner" type stuff.

You don't get how these things things work.

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.

Couldn't they ask for "compatible with Microsoft Business Productivity Online Suite" in that case? Or something similar.

Absolutely - but they they should have stated that.

There is a big difference between "should be compatible with" and "must be".

BPOS is now called Office 365.

I don't see governments considering more than Microsoft for most things: desktop OS, office suite, etc.

I would be glad if this changed that, though. There's a potential for quite a bit of money to be saved.

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.

The competition here isn't Linux, it's Google's cloud docs offering. Google does offer support and it's much cheaper than Microsoft.

A lot of other-than-US governments are adopting linux and FOSS, and the Obama administration's been fairly friendly with Mac desktops.

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.

Does Google actually have a claim under the Tucker Act? Some quick searching limits claimants to those who have an actual contract.


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.

Sovereign immunity prevents certain types of lawsuits against the government. It doesn't mean you can't sue the government ever.

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)

Could I also please sue various world governments for not considering me ;)

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?

Less functionality can be an advantage if all you ever do is create new documents (i.e., you're a developer or a writer).

It's a huge disadvantage if all you ever do is edit existing documents (i.e., you work in government).

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.

Gah. I thought I was used to the whole "loose" vs "lose" mix up that so many do.

But seeing it 3 times in rapid succession feels like fingernails on the blackboard.

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.

I was thinking along the same lines.

However, I assume Microsoft behaves in a similar manner.

I'm fairly sure they do - as do pretty much all large corporations. That doesn't make it right, of course.

This is a frivolous lawsuit. There is no reason anyone would sue a private company for not using their software.

Well that's how closed source software makes money.

I think a MS employee wrote this RFQ.

am i the first one who sees the hidden message FOCMS in this title ?

huh? Potential customer not into you? Time to sue him.

I hope Google wins. I don't care if the government uses Google or not, but this unreasonable entrenchment of Microsoft is ridiculous.

Like what other solution?

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.

Governments are going to pick winners and losers. Big deal.

IF you don't like that, just get rid of the government agencies.

Yeah, who knows what the Dept of the Interior does anyways? If I can't explain it in 2 witty sentences, there's no way it's important.

Screw over Indian land management, but I gotta like their fish and wildlife guys and gals. (really hoping you were being sarcastic)


The RFQ was for Microsoft's cloud based offering called "Business Productivity Online Suite".


"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...

This argument would be more compelling if Microsoft sold open source software.

I don’t think the government is big fan of open source either. They mostly worry about support.

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).

The two are intimately related. With open source, you can always get support even after the company has ditched the product.

Technically, to the US government Windows is open source.

Yes, but that doesn't mean they get a community of people pouring over the source code.

That "community" goes by the name of The NSA.

For the US government, a community isn't nearly as important as having someone to blame. Same seems to go for a lot of companies, unfourtunely.

Indeed. I was only talking about the original comment's argument, not about the reality of government.

I don't think you know what you are talking about. Google "dod open source".

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact