For the same reason why everyone else should open-source their infrastructure and why others do - Yahoo's Hadoop, Facebook's Open Hardware, Rackspace's OpenStack. Because others are building similar technology and cross-pollination (and honest trials) of BigTable with, say HBase, or their web stack with node, would mean that they break out of NIH and start improving both the state of the industry and their own code.
That said, I'm not saying that they need to, but that nobody should credit them with transparency or open-source goodwill in terms of actual core stack when what we're actually seeing is zero transparency and lots of in-house closed code. To the point that even what they're using is a question mark, and our guesses like BigTable often meet with a smirk and an 'oh, no, we're on to InternalProjectX, which is so much better.'
Thank you. Like others, I believe Google keeps its infrastructure secret because that is a competitive advantage. Their infrastructure is their business. It makes sense for Facebook to openly publish its datacenter design because that's not what Facebook is about: they could be running from AWS for all we care -- the social graph is kept very much closed, however. Opensourcing seems to be the radical approach to commoditizing complements.
But I would love if Google opened up about that, anyway. I am an avid reader of their service failure post-mortems because they reveal a tiny bit of what goes on inside their data centers. And because the way Google stuff fails is admirably beautiful.
Here's an ex-Google engineer who thinks Google's software infrastructure is obsolete, compared to opensource offerings:
http://rethrick.com/#waving-goodbye
I wasn't one of them, but I agree. Google's internal infrastructure has its warts, but it's generally light years more stable and reliable than anything you can get open-source. I have a teammate that worked with Hadoop in previous jobs; he said that there's no comparison between it and MapReduce. I used JSON for my previous startup's core data storage; were I to do it over again, I'd use protocol buffers, which are much, much more efficient. I use both Closure and JQuery on a daily basis; I consider them as occupying different niches, and wrote a bit more about that last night:
Absolutely. I think the criticism is that Google has credibility amongst the tech community for 'openness', which is based on shrewd PR rather than them actually behaving differently to any other large corporation.
I see proponents of Google make arguments of the form:
"Google is open so we want them to win. Because we want Google to win, it's ok for them to keep things closed to give them an advantage."
Google is and remains primary a for profit company, which has to report to it's share holders. But they are better compared to others. They made large contributions to open source, for example Android and Chromium. Neither of the two are generating direct revenue for Google.
Also they choose to publish their map reduce, page rank and other algorithms, in the first place. I think if it were not for Google, there was no Hadoop. Also if Yahoo was the first to develop map reduce, I doubt they would have open sourced it either.
My point is overall Google's existence is beneficial for the opensource and tech community in general.
Why doesn't Apple get credit for their huge investment in Webkit which was crucial (by Google's own admission) for both Chromium and Android?
I'd argue that the difference in perception is down to PR. Apple does little to make itself look like a benign actor, whereas Google puts a lot of effort into associating itself with 'openness' (and other things like 'science'). I'm pretty sure that's intentional image making.
That said, I'm not saying that they need to, but that nobody should credit them with transparency or open-source goodwill in terms of actual core stack when what we're actually seeing is zero transparency and lots of in-house closed code. To the point that even what they're using is a question mark, and our guesses like BigTable often meet with a smirk and an 'oh, no, we're on to InternalProjectX, which is so much better.'