It is pretty amusing, because I have repeatedly seen government (and corporate) IT talk about avoiding Macs because they are a Single Source Solution: you can't buy Macs from anyone but Apple, so you are locked into dealing with only one vendor. Then these same people would turn around and specify Microsoft Windows solutions. Precisely how many vendors do they think make Microsoft Windows?

If any of these people were honestly interested in avoiding vendor lock-in, they would require that all solutions be free and open source software. And preferably "open source hardware," if there actually can be said to be such a thing.

I couldn't visualize it from the description, but this video shows how it works

http://www.youtube.com/watch?v=UesbkO3NvoY [youtube.com]

Pretty crazy. It'll come down to whether they can actually make something like that reliable.

They were corrupt under Reagan, Bush and Clinton too.

http://en.wikipedia.org/wiki/Cobell_v._Kempthorne [wikipedia.org] for one.

A lot of discussion on "How come only Microsoft".

While I agree it's not "competitive", I think they are looking for bids on hosting a Microsoft based solution - not Microsoft, the company, providing the hosting

They aren’t restricting the bidding to only Microsoft... third-party contractors could bid on it as long as they were going to use Microsoft’s products.

Basically, they’re trying to avoid taking the low bid and then at the end of the contract finding out that all of the workstations are running some free flavour of Linux that isn’t supported and none of their employees know how to use. It’s reasonable from that perspective, although cutting Google out of the mix probably still wasn’t really the smartest move.

Mostly weapons systems:
http://washingtontechnology.com/Articles/2010/04/07/Contract-countdown.aspx?Page=1 [washingtontechnology.com]

There's also a requirement to have a PRODUCT that could be put into the Schedule to begin with. I'm pretty sure they've got a DUNS number at the least (Most major corps typically have one.) and the rest is easy.

Don't seize on what the GSA did for a reason for refusal here. I'm strongly suspecting that they were finding out what they needed to do to possibly get the business before they went and did the rest- because they'd have had to.

No, there's an issue there. It's called an EXPLICITLY CLOSED contract when they're obligated by law to provide OPEN bids for things. Claims of "enhanced security" and "integrated mail, etc." is bunk. There's a handful of actual solutions that meet all those criteria, actually, and Google was one of the prospective providers. I don't know where the lawsuit will go, but there IS a serious problem with the DOI deal there.

You left out a lot:
Zimbra
Zafara
OpenXchange(that one I know sucks)
Scalix
the list goes on and on.

This clearly indicates bribery, no one hears "Microsoft" and thinks enhanced security.

Does Google's professional mail solution support S/MIME? Gmail doesn't, and it's a gaping hole in their messaging offering when compared to pretty much any popular messaging application on the market.

You write up an RFP when you know your problem and you need a solution. Language often specifies a technology, but allows for equivalent substitutions. Protests often happen over debate of what qualifies as equivalent, but if the DOI was looking for a solution, they would write an RFP.

But they weren't looking for a solution, they were looking for a vendor, and already knew what solution they wanted. That's when you write an RFQ, specify exactly the technology you want and then let everyone submit pricing. The disadvantage is that you have to choose the low quotation. In an RFP, you do not have to take the low proposal, even in the public sector.

So it might feel wrong, but way before the RFQ was even written the DOI determined that they wanted the Microsoft solution and just wanted pricing. Google lost before it even started. Which is probably short sighted by the DOI, but well within the law. As a public sector person who deals with this, it's not easy to get what you know you need at a price you want. Most public entities aren't being corrupt, but like someone else mentioned, the spirit of the law has long been lost and both sides spend inordinate amounts of time and money just trying to game the system. Like the vendor who protested that his 7200rpm SATA drive SAN was equivalent to the 15k SAS version and that he won on price... ugh.

Good lord. You're mounting an argument by citing serial liar Andrew Breitbart and the right-wing Washington Examiner?

Gmail doesn't [support S/MIME], and it's a gaping hole in their messaging offering when compared to pretty much any popular messaging application on the market.

There are various client-side plugins which support S/MIME for Gmail (which is actually the right place to do it). See Gmail S/MIME [mozilla.org] and other similar plugins.

I was very surprised, though, to see that once they started using it, some of the people who had been the most doubtful, became the biggest advocates of the Gmail way. It's dramatic enough that if we wanted to go back to Exchange or Outlook or Entourage, there would be blood, and the execs, not IT, would be the ones protesting the loudest.

Once you do an honest cost/benefit analysis of (paid-for, corporate) Google mail, it's not a hard sell at all. The problem, if it is one, is persuading decision makers to actually be honest and disinterested in their analysis. That's often much, much more difficult than it should be.

The issue that Google has wasn't about any particular feature that is required. I'm pretty sure that FIPS 140-2 (if it was a requirement) would be implemented for any Google product if at all possible. Main issue is the requirement to use Microsoft BPOS-Federal product as the basis of the service.

The only thing that FIPS 140-2 implies is that someone in marketing figured out that by using the correct algorithms, they can sell crap products to the government. Congratulations - you just screwed the public for $210 for a flash drive that is no more secure than commercial grade sticks and a copy of TrueCrypt (which uses FIPS 140-2 compliant algorithms, no less)

But hey, why should you care? Enjoy your job security.

Disclaimer: I work for USGS/DOI.

Not really true. (Not true at all, actually...) FIPS 140-2 requires much more than just certain algorithms. Much of the requirements relates to making sure keys are properly handled, that RNGs function as desired, and that the device is tamper-resistant and tamper-evident.

Further, regulations stipulate that sensitive, but unclassified (continuity of operations and contingency plans) and personally identifiable information (PII) (social security numbers and such) data must be encrypted using a FIPS 140-2 certified encryption systems, not merely FIPS 140-2 compliant systems (as you suggest). (Becoming certified is a costly process, one which has granted firms that submit to the process a high level of economic rents [wikipedia.org].) If I could deploy systems which I felt were of an equivalent security level as FIPS 140-2 requires, I would certainly do so (spending $250 on 5 USB drives doesn't help me in any way).

An article recently discussed on schneier's blog (http://www.schneier.com/blog/archives/2010/11/control_fraud.html) argues otherwise... That under-deterrence creates an environment where corruption can become systemic and that regulatory frameworks need to be designed keeping in mind the possibility of fraud at the highest levels, and optimized to reduce it, rather than be designed based on economic models that wish corruption away as a market inefficiency that is somehow automagically eliminated by free market forces.