4 ms·
It's nice at least a few dead Google products get open sourced instead of deleted outright. I have to imagine this is only possible because it's pretty much ent
by ocdtrekkie 6y ago
It's nice at least a few dead Google products get open sourced instead of deleted outright. I have to imagine this is only possible because it's pretty much entirely a client-side desktop application that doesn't rely on Google servers for much.
Exactly why building apps for the cloud is a big downside.
- nexthash 6y agoOn the other hand, cloud software is often more convenient to use, allows for syncing on multiple devices, and is more powerful due to having access to the computing resources of large data centers. So you can't really say that building cloud apps is only a downside. Tilt brush just happens to be the type of application that doesn't overlap much with these benefits, making it easier to open source. Also, cloud software isn't much more difficult to open-source, see self-hosted open source applications like NextCloud: https://nextcloud.com/ https://nextcloud.com/
- eropple 6y ago> Also, cloud software isn't much more difficult to open-source What's the open-source, production-ready, 100%-API-compatible implementation of AWS SQS or Google BigTable? Genuinely curious, because I've been down these roads and they're not simple.
- a_e_k 6y ago> that doesn't rely on Google servers for much. My understanding is that it used to interact with Google Poly. But a couple of months ago it was announced that that is shutting down. (See https://news.ycombinator.com/item?id=25277615 https://news.ycombinator.com/item?id=25277615 for the HN discussion about that.)
- ocdtrekkie 6y agoYeah, Poly was like the content store, but it wasn't fundamental to the app's functionality.
- azurezyq 6y agoI 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 agoIt'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 agoThose 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 agoEven 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 agoYep, 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...
- onion2k 6y agoI have to imagine this is only possible because it's pretty much entirely a client-side desktop application that doesn't rely on Google servers for much. Tilt Brush models could be shared through Google's "Poly" 3D asset library, but they're shutting that down too.