The proprietary thing is dead-on, though. I started listing major proprietary technologies, got close to twenty, and decided I wasn't sure how much of that was trade secret, and deleted it. Google technology looks like we're on a different Galapagos island from the rest of tech, and the landbridge sunk into the sea in 2003, and once in a while a bird in a windstorm carries a seed across. Usually Google tech is superior to comparable outside tech, sometimes it's inferior.
As an aside for Googlers, have you seen that Facebook thing "Buck", that some ex-Googler named Michael Bolin "invented"? I don't even know what to say.
Protocol Buffers was this back in ... 2007? Too bad Thrift happened first, right?
This is leading up to the kernel of another post: how to undercut the competition: hire the people who created their Secret Sauce, then have them build it again, but this time, release it to the world. Now the competition doesn't have their exclusive magic carpet to ride around on any more.
I guess it's a viable strategy, but nobody likes it when it's done to them.
Now, however, every time they release something like this, I just crack up laughing. The servers, the software-defined switched network, all of it. It just keeps going. The real magicians have moved on and are now sharing their creations with the rest of the world.
If only I had a copy of that internal post which basically said "either we open-source our own stuff, or other people are going to do it for us, and we're going to be behind the eight ball". I want to say it was a Yegge Buzz post but I can't remember for sure. It's been three or four years.
Leakers, you know how to find me. Contact info in profile.
It's also interesting to look at the mailing list for Cap'n Proto - there are a bunch of folks from FourSquare, Twitter, etc. helping out. Many of them are ex-Googlers, and many cited being big fans of proto2 as their reason for helping out with Cap'n Proto.
As for proprietary parts not being important, I have major disagreements with your characterization of how well the linux kernel upstreaming works (having worked in that team) and other assertions about stock desktops (Stock Ubuntu ? Really ?) but I suspect that discussion will quickly veer into areas of confidentiality (if it hasn't already).
As for MapReduce and BigTable, I'm still wishing and hoping for the open-source world to catchup with the originals (Why do people keep writing enormous in-memory data stores in Java!??) Enough said.
> there's no denying that google recruiters covet fresh
> college grads from well-known schools and your grades in
> school are an important factor.
> I have major disagreements with your characterization
> of how well the linux kernel upstreaming works (having
> worked in that team)
> other assertions about stock desktops (Stock Ubuntu ? Really ?)
LOL its about 10x funnier if you read it as a seminary allegory. It really does fit pretty well.
That could easily create a bias towards using things made in 20% time in preference to industry-standard tooling.
In reality I assume it's a combination of the two: Sometimes the internal tools really are the best for Google's specific needs; other times there's probably Not Invented Here Syndrome at work, same as anywhere else.
MongoDB does not provide this type of visibility. Either within that common toolset or in any other way.
First, Google really doesn't care as much about education as people think they do. They do love experience. I never graduated high school, and was hired into an SRE position (= programmer writing large-scale sysadmin tools) based on previous work experience. Grades are only useful if you've got nothing else to show off.
Second, if you want employees to be loyal to a company with unusually good perks, taking them fresh out of school is a terrible approach. Many people working here indeed have no real idea what working at non-tech companies is like, and that means they assume every other company is like Google. I have heard stories of employees getting frustrated on some project, leaving to work at (e.g.) a bank or webdev shop, and not realizing until their first day that there's no free food, or gym, or weekly heckling of the CEO. I used to work at a defense contractor, I know what it's like being a programmer employed at a non-tech company, and I don't want to ever go back.
(In other words, Google might get better retention by implementing Rumspringa)
Third, the proprietary parts aren't as pervasive as the article portrays. Our Linux kernel has weird Google-specific interfaces, but they're always in some stage of upstreaming and will eventually be in Linus's trunk. Our RPC system uses the same protobuf rpc-stubs that are generated by the open-source protobuf compiler. Desktops and Laptops run stock {Ubuntu,Windows,MacOS} with a few extra binaries. MapReduce and BigTable were published and inspired dozens of open-source implementations. Many of our Python-based tools have web frontends written with Django. Many systems persist data in MySQL.
When Google engineers avoid particular in-fashion systems such as Rails or MongoDB or node.js, it's not because we're ignorant of them, it's because we think they're not good enough.