3 ms·

I don't think "Cloud" matters here. Apps are not created from vacuum, they may link to proprietary code (a lot), not to mention infra dependencies. E.g., a Goo

I don't think "Cloud" matters here. Apps are not created from vacuum, they may link to proprietary code (a lot), not to mention infra dependencies. E.g., a Google Reader like thing: * Google internal library dependencies * Internal storage systems like BigTable * Borg configurations * Service dependencies: group management, access control, telemetry.... Basically, the closed enclosure of a service is just too big to open source.

bsimpson 6y ago
It's the other edge of the monorepo/standardized tooling sword. You get nearly unlimited access to the work of people who have come before you, but separating your work from the internal commons is no small task. I suspect most Google projects would be non-trivial to open source (even without legal concerns). Building software with Google's internal tools is very different than what's popular in the open source world. It cuts both ways: Many open source tools would be difficult to use at Google, because they presume open source tools and package managers that don't have equivalents in the Google codebase.
ocdtrekkie 6y ago
Those are essentially what I meant: Google building on Google infrastructure makes their shuttered web apps nearly impossible to open source. An app you download and install from Steam that runs on your PC... pretty straightforward. They have to remove the SteamVR library, but it's available for you to plug it in yourself.
- tjohns 6y ago
  Even client-side apps can link to lots of proprietary dependencies or require internal tooling that a company is not willing (or sometimes just not staffed) to opensource.
  - Ajedi32 6y ago
    Yep, looks like they put in a non-trivial amount of work replacing proprietary libraries in order to make this possible: https://github.com/googlevr/tilt-brush#systems-that-were-replaced-or-removed-when-open-sourcing-tilt-brush https://github.com/googlevr/tilt-brush#systems-that-were-rep...
- philsnow 6y ago
  there was an effort at one point to write internal things on (internal) google app engine, which would make open sourcing more straightforward, but I don't know how far that got.

bsimpson 6y ago

It's the other edge of the monorepo/standardized tooling sword. You get nearly unlimited access to the work of people who have come before you, but separating your work from the internal commons is no small task. I suspect most Google projects would be non-trivial to open source (even without legal concerns). Building software with Google's internal tools is very different than what's popular in the open source world. It cuts both ways: Many open source tools would be difficult to use at Google, because they presume open source tools and package managers that don't have equivalents in the Google codebase.

ocdtrekkie 6y ago

Those are essentially what I meant: Google building on Google infrastructure makes their shuttered web apps nearly impossible to open source. An app you download and install from Steam that runs on your PC... pretty straightforward. They have to remove the SteamVR library, but it's available for you to plug it in yourself.

tjohns 6y ago
Even client-side apps can link to lots of proprietary dependencies or require internal tooling that a company is not willing (or sometimes just not staffed) to opensource.
- Ajedi32 6y ago
  Yep, looks like they put in a non-trivial amount of work replacing proprietary libraries in order to make this possible: https://github.com/googlevr/tilt-brush#systems-that-were-replaced-or-removed-when-open-sourcing-tilt-brush https://github.com/googlevr/tilt-brush#systems-that-were-rep...
philsnow 6y ago
there was an effort at one point to write internal things on (internal) google app engine, which would make open sourcing more straightforward, but I don't know how far that got.