5 ms·

They could keep starting products and instead of killing them, release them as open source. Or one click deploy on GCP. Actually, that last one makes a lot of

They could keep starting products and instead of killing them, release them as open source. Or one click deploy on GCP. Actually, that last one makes a lot of sense for pushing for more GCP adoption.

vlovich123 3y ago
Open source is very hard for a bunch of reasons: * Code at Google3 is one giant monolith that has dependencies on things that aren’t open sourced. Even if they could be, they don’t make sense outside of Google * most services internally run on internal services like Borg and GFS rather than GCP for historical reasons. That maybe has changed now but I suspect a lot of stuff depends on internal infra not available on GCP * A product can often have data dependencies. Just being able to spin up a separate copy may not mean much in terms of keeping a product alive past Google’s interest if the data is locked away behind Google’s private data stores. Then you want Google to start adding easy export options so that data can be exfiltrated from Google’s onto 3p versions of the product which is a legal, business, PR and technical risk * Google has invested some amount of money and resources into a product. If a competitor takes that concept and is successful it’s embarrassing to execs at Google who missed the opportunity. Google Wave was dropped even though in many ways it’s a precursor to slack (it was open sourced though and went nowhere). It’s a nice wish but I can’t imagine any realistic scenario where any business would go down this road until their shown a successful roadmap by a more enterprising business first.
- wyclif 3y ago
  Google Wave was my fave sunsetted project or Google graveyard project. First time I used it I could really see the potential. But as you pointed out, it's often not that simple.
  - cjmcqueen 3y ago
    I'm hard pressed to remember a feature in Wave that does not exist in Docs now. What is it that you miss? I just remember it being dog slow with a lot of latency.
    - wyclif 3y ago
      Wave was supposed to be "equal parts conversation and document" (their description). It seems like they separated out the conversation part to Google Talk and made the document part Docs. Wave was kind of the precursor to the state of affairs we have now with Slack and Discord.
- eastbound 3y ago
  So, Google’s choice of architecture prevents them from open-sourcing or maintaining projects a tad longer than absolute necessary. I’d say they dug their own grave, if it has such a large impact on the trust of customers. Maybe Google3’s architecture was excellent for worldwide scalability and costs, but let’s see which one matters in the long term.
  - _heimdall 3y ago
    Google and their codebase architecture have been around for a while now in the scale of software lifecycle. How far out do we need to wait before its "long term", and how will we know if failure was from decades of business decisions vs repo architecture?
    - eastbound 3y ago
      Let’s say their repo architecture didn’t help soften the blow of various business decisions of abandoning products. There was a time when Google was also Guava and a myriad of Java libraries helping the rest of the world. It’s a design choice, they chose to stop helping, because of their repo. Perhaps it also helped avoid leaks, since copied code can’t be used outside of Google.
      - vlovich123 3y ago
        If anything Google releases more open source now than ever. Because of TensorFlow (if I recall correctly - my memory is fuzzy on timeline of what product it was) they released Bazel and then Abseil. Chrome didn’t have the clout to accomplish that but those things are open sourced and very high quality libraries. Tcmalloc is open sourced even though Google reaps no rewards from that. There’s a bunch of stuff released by Googlers as open source.
  - vlovich123 3y ago
    I listed many reasons why open sourcing wouldn’t make sense and you seem to have hyperfixated on just one. Yes - Google chose a monorepo because of the engineering and business advantages it gave them. For example, all binaries had a common dependency that implemented all sorts of common functionality they found binaries on their servers needed out of the box - that’s why a simple c++ hello world on Google3 results in a many many mib binary that includes an http server for performance monitoring. It’s an opinionated codebase but the opinions are largely documented and explained and aren’t crazy (just because you may make other decisions or prioritize things differently doesn’t mean Google’s choice are wrong). And again, please don’t hyper focus on what I wrote as “oh it only has this one advantage”. There’s lots of advantages and I’m just giving very basic examples. It’s been a fairly long time since I worked at Google and someone who works there is going to have a more authoritative explanation of how things work now as things will inevitably changed some. You may say they dug their own grave while the internal teams find it helps them run services and maintain things because there’s 1 way of interacting with the artifacts of lots of different teams. And they weren’t going to open source EOL projects anyway and maintenance decisions have nothing to do with google3 and are product and engineering led decisions. Also, they have a bunch of tooling to manage open source projects that mirror google3 projects. It’s doable for projects that care / who it’s important to but it is also a lot of work (eg can write rules that bidirectionally rename files, functions, c++ namespaces, comments that can strip out code before outgoing synchronization, etc etc). if I recall correctly the tool itself was open sourced too. As for customer trust, again I point out that not only is the Google3 aspect a minor detail, open sourcing wouldn’t even impact customer trust in a large way. It might with a certain segment of the technical population, but that’s not the people Google cares about in terms of public trust. And any open sourcing also has to find motivated maintainers who are not going to be motivated by 0 pay and a huge amount of bug reports and feature requests from users who started with maintenance support of paid engineers and focused product vision. Make sure not to extrapolate your own predilections as a tech engineer onto the general population.
- Uehreka 3y ago
  > Code at Google3 is one giant monolith I’ve heard this stated before, and something about it feels off. There’s no way all of Google’s code is in one repo. Like, does that monorepo contain the full Android operating system with Google Services and the firmware for all the Pixel devices? I feel pretty sure multiple teams at Google must have forks of the Linux kernel for one reason or another, would those be in there too? Is Chromium in there too? What about the whole golang project? Even if I’m off about some of this, it feels like the statement “Code at Google is one giant monolith” needs some qualifiers.
  - rightbyte 3y ago
    Ye, like, is there a google.exe at 3912GB with 10k command line options like '--search-server --port=80' or '--Gsolitaire'?
    - why_only_15 3y ago
      no, there are thousands of Blaze build files that each have their own binaries, tests, libraries, etc.
      - vlovich123 3y ago
        To be fair though, the baseline hello world C++ binary is quite hefty (10s or 100s of MiB - can't recall) & comes with a bunch of command-line options & an HTTP server out of the box. Or at least did when I was there & I doubt it's changed much. All that functionality is to integrate the baseline set of SRE ops tooling that are common to all services that are deployed on Google servers (eg. HTTP server is to support scraping for performance monitoring integration similar to Prometheus/OpenTracing). It's mildly annoying because any command line tools you write pick up all of that useless functionality but it is easy to teach so trade offs.
  - morgante 3y ago
    There are certainly a few notable exceptions (Chrome and Android), but google3 really is a massive monorepo. It does contain forks of tons of open source code in the third party folder. I don't recall if the Linux kernel is in /third_party but I would not be surprisied if it is. A fair amount of the operations are actually documented publicly, ex. https://opensource.google/documentation/reference/thirdparty/ https://opensource.google/documentation/reference/thirdparty...
willi59549879 3y ago
I like that idea

They could keep starting products and instead of killing them, release them as open source. Or one click deploy on GCP. Actually, that last one makes a lot of sense for pushing for more GCP adoption.

vlovich123 3y ago

Open source is very hard for a bunch of reasons: * Code at Google3 is one giant monolith that has dependencies on things that aren’t open sourced. Even if they could be, they don’t make sense outside of Google * most services internally run on internal services like Borg and GFS rather than GCP for historical reasons. That maybe has changed now but I suspect a lot of stuff depends on internal infra not available on GCP * A product can often have data dependencies. Just being able to spin up a separate copy may not mean much in terms of keeping a product alive past Google’s interest if the data is locked away behind Google’s private data stores. Then you want Google to start adding easy export options so that data can be exfiltrated from Google’s onto 3p versions of the product which is a legal, business, PR and technical risk * Google has invested some amount of money and resources into a product. If a competitor takes that concept and is successful it’s embarrassing to execs at Google who missed the opportunity. Google Wave was dropped even though in many ways it’s a precursor to slack (it was open sourced though and went nowhere). It’s a nice wish but I can’t imagine any realistic scenario where any business would go down this road until their shown a successful roadmap by a more enterprising business first.

wyclif 3y ago
Google Wave was my fave sunsetted project or Google graveyard project. First time I used it I could really see the potential. But as you pointed out, it's often not that simple.
- cjmcqueen 3y ago
  I'm hard pressed to remember a feature in Wave that does not exist in Docs now. What is it that you miss? I just remember it being dog slow with a lot of latency.
  - wyclif 3y ago
    Wave was supposed to be "equal parts conversation and document" (their description). It seems like they separated out the conversation part to Google Talk and made the document part Docs. Wave was kind of the precursor to the state of affairs we have now with Slack and Discord.
eastbound 3y ago
So, Google’s choice of architecture prevents them from open-sourcing or maintaining projects a tad longer than absolute necessary. I’d say they dug their own grave, if it has such a large impact on the trust of customers. Maybe Google3’s architecture was excellent for worldwide scalability and costs, but let’s see which one matters in the long term.
- _heimdall 3y ago
  Google and their codebase architecture have been around for a while now in the scale of software lifecycle. How far out do we need to wait before its "long term", and how will we know if failure was from decades of business decisions vs repo architecture?
  - eastbound 3y ago
    Let’s say their repo architecture didn’t help soften the blow of various business decisions of abandoning products. There was a time when Google was also Guava and a myriad of Java libraries helping the rest of the world. It’s a design choice, they chose to stop helping, because of their repo. Perhaps it also helped avoid leaks, since copied code can’t be used outside of Google.
    - vlovich123 3y ago
      If anything Google releases more open source now than ever. Because of TensorFlow (if I recall correctly - my memory is fuzzy on timeline of what product it was) they released Bazel and then Abseil. Chrome didn’t have the clout to accomplish that but those things are open sourced and very high quality libraries. Tcmalloc is open sourced even though Google reaps no rewards from that. There’s a bunch of stuff released by Googlers as open source.
- vlovich123 3y ago
  I listed many reasons why open sourcing wouldn’t make sense and you seem to have hyperfixated on just one. Yes - Google chose a monorepo because of the engineering and business advantages it gave them. For example, all binaries had a common dependency that implemented all sorts of common functionality they found binaries on their servers needed out of the box - that’s why a simple c++ hello world on Google3 results in a many many mib binary that includes an http server for performance monitoring. It’s an opinionated codebase but the opinions are largely documented and explained and aren’t crazy (just because you may make other decisions or prioritize things differently doesn’t mean Google’s choice are wrong). And again, please don’t hyper focus on what I wrote as “oh it only has this one advantage”. There’s lots of advantages and I’m just giving very basic examples. It’s been a fairly long time since I worked at Google and someone who works there is going to have a more authoritative explanation of how things work now as things will inevitably changed some. You may say they dug their own grave while the internal teams find it helps them run services and maintain things because there’s 1 way of interacting with the artifacts of lots of different teams. And they weren’t going to open source EOL projects anyway and maintenance decisions have nothing to do with google3 and are product and engineering led decisions. Also, they have a bunch of tooling to manage open source projects that mirror google3 projects. It’s doable for projects that care / who it’s important to but it is also a lot of work (eg can write rules that bidirectionally rename files, functions, c++ namespaces, comments that can strip out code before outgoing synchronization, etc etc). if I recall correctly the tool itself was open sourced too. As for customer trust, again I point out that not only is the Google3 aspect a minor detail, open sourcing wouldn’t even impact customer trust in a large way. It might with a certain segment of the technical population, but that’s not the people Google cares about in terms of public trust. And any open sourcing also has to find motivated maintainers who are not going to be motivated by 0 pay and a huge amount of bug reports and feature requests from users who started with maintenance support of paid engineers and focused product vision. Make sure not to extrapolate your own predilections as a tech engineer onto the general population.
Uehreka 3y ago
> Code at Google3 is one giant monolith I’ve heard this stated before, and something about it feels off. There’s no way all of Google’s code is in one repo. Like, does that monorepo contain the full Android operating system with Google Services and the firmware for all the Pixel devices? I feel pretty sure multiple teams at Google must have forks of the Linux kernel for one reason or another, would those be in there too? Is Chromium in there too? What about the whole golang project? Even if I’m off about some of this, it feels like the statement “Code at Google is one giant monolith” needs some qualifiers.
- rightbyte 3y ago
  Ye, like, is there a google.exe at 3912GB with 10k command line options like '--search-server --port=80' or '--Gsolitaire'?
  - why_only_15 3y ago
    no, there are thousands of Blaze build files that each have their own binaries, tests, libraries, etc.
    - vlovich123 3y ago
      To be fair though, the baseline hello world C++ binary is quite hefty (10s or 100s of MiB - can't recall) & comes with a bunch of command-line options & an HTTP server out of the box. Or at least did when I was there & I doubt it's changed much. All that functionality is to integrate the baseline set of SRE ops tooling that are common to all services that are deployed on Google servers (eg. HTTP server is to support scraping for performance monitoring integration similar to Prometheus/OpenTracing). It's mildly annoying because any command line tools you write pick up all of that useless functionality but it is easy to teach so trade offs.
- morgante 3y ago
  There are certainly a few notable exceptions (Chrome and Android), but google3 really is a massive monorepo. It does contain forks of tons of open source code in the third party folder. I don't recall if the Linux kernel is in /third_party but I would not be surprisied if it is. A fair amount of the operations are actually documented publicly, ex. https://opensource.google/documentation/reference/thirdparty/ https://opensource.google/documentation/reference/thirdparty...

willi59549879 3y ago

I like that idea