4 ms·

This raises questions (that you probably can't answer, but still) about why Google doesn't have a "maintenance subsidiary" playbook, where instead of killing a

This raises questions (that you probably can't answer, but still) about why Google doesn't have a "maintenance subsidiary" playbook, where instead of killing a project off, they spin it off, with a bucket of cash to last that project 3 years, after which they'll have to have figured out their own monetization plan (or open source transition) while still having access to everything Google because it'd just be another Alphabet-owned company. Not every engineer wants to live the fast-paced "create and move on" life, there are so many skilled engineers who would happily take the lower salary, but also lower-pressure, maintenance jobs. If a project makes a million bucks under Google, that doesn't even remotely push the needle and it gets shut down. If a 5 man subsidiary makes a million bucks, that's a million bucks. Foster that?

titanomachy 3y ago
It’s not necessarily straightforward or cheap to migrate a living product to open-source land. Backend services at Google are built using proprietary frameworks and infrastructure for which no equivalent exists out in the real world. They could help people out a bit by open-sourcing the web front-end, but that’s substantial work and you’re still a long way from having a working clone of the product. EDIT: I see I misread your comment and you’re talking about keeping it on Google infra but separating it for accounting purposes. It’s an interesting idea but I don’t see why it would fundamentally change the viability of the product. Also, there’s an ongoing maintenance cost to having more products on shared infra. If you’re the team that runs the global distributed relational db (for example), or maintains the C++ discrete optimization library, it’s much simpler to support two products that make a billion each rather than 2,000 subtly different use-cases each making a million each. Not to mention costs incurred by non-engineering departments (marketing, accounting, legal).
- TheRealPomax 3y ago
  Not just separated for accounting purposes: literally make it a new company under the Alphabet umbrella (spinning up an LLC is basically a Tuesday afternoon for Alphabet) and then seeing if, as its own entity with an Alphabet "series A" grant, it can keep the product alive or not. And then if that company fails: bonus, Google didn't kill it, the market did.
deleted 3y ago
[deleted]

titanomachy 3y ago

It’s not necessarily straightforward or cheap to migrate a living product to open-source land. Backend services at Google are built using proprietary frameworks and infrastructure for which no equivalent exists out in the real world. They could help people out a bit by open-sourcing the web front-end, but that’s substantial work and you’re still a long way from having a working clone of the product. EDIT: I see I misread your comment and you’re talking about keeping it on Google infra but separating it for accounting purposes. It’s an interesting idea but I don’t see why it would fundamentally change the viability of the product. Also, there’s an ongoing maintenance cost to having more products on shared infra. If you’re the team that runs the global distributed relational db (for example), or maintains the C++ discrete optimization library, it’s much simpler to support two products that make a billion each rather than 2,000 subtly different use-cases each making a million each. Not to mention costs incurred by non-engineering departments (marketing, accounting, legal).

TheRealPomax 3y ago
Not just separated for accounting purposes: literally make it a new company under the Alphabet umbrella (spinning up an LLC is basically a Tuesday afternoon for Alphabet) and then seeing if, as its own entity with an Alphabet "series A" grant, it can keep the product alive or not. And then if that company fails: bonus, Google didn't kill it, the market did.

deleted 3y ago

[deleted]