6 ms·

We are splitting hairs. Most of both what you say and I say is true and the point still stands. I never claimed cross platform porting is trivial, and that is n

We are splitting hairs. Most of both what you say and I say is true and the point still stands. I never claimed cross platform porting is trivial, and that is not the point of this exercise. The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. (In fact the inverse case happens pretty frequently, whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending). No need to make it more complicated than that. > Do...do you work at any of the companies you're talking about? Because people in this thread, who do, are telling you you're wrong. They are all entitled to their own opinion. I'm open to being proven wrong, but I'm sure you can guess how different opinions can be even in 'those companies' so let's not assume there is a clear, unquestionable truth they have access to. It is hard to attest anyone's credentials on a pseudonymous forum and that is OK.

joshuamorton 6y ago
> The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. That's not at all what they said. Their actual point was that because Google uses highly custom infra, it is not easy for them to open source or spin off a singular thing. This is valid even if Google's internal infra is strictly worse than what is available openly. Their point has nothing to do with magic infra. It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. > I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. Yes, you claim this, and you were and continue to be incorrect. > whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending There is a difference between a situation where you are acquiring a thing for $LOTS, and are therefore willing to invest $EXTRA to make it work with your stuff, and the situation where you are divesting from a thing and therefore don't have the same budget. But even if you reject that: the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of). And, even when they aren't, "you decided to purchase them" is a really good justification to management, to use your words, to make additional exceptions. > They are entitled to their own opinion. But these aren't opinions. You're just factually, demonstrably wrong. Your (now deleted) statement that there may be efforts underway to better align the internal and external infrastructures may be true, but if it is, it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. To address your other comment: > You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc. Yes, but you can't run an RSS aggregator built to run on Google's infrastructure without either rewriting it or using Google's internal cluster management infra. The useful about having ecosystems like those is that you can couple couple very tightly between infra and application.
- anticensor 6y ago
  > This is valid even if Google's internal infra is strictly worse than what is available openly. Indeed it is, because Sod's, Parkinson's and Wirth's laws. > This is insane and a sign that something is deeply wrong in Google. Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce. Given such a massive rewrite will not be possible without bankrupting the company, and such an open source would just amount to going non-profit (they would essentially lose all trade secrets and profit-making advantages), forcing a public domain of intellectual property, replacing the top executives without severance and stripping of for-profit status will be way better economically, than splitting it.
  - joshuamorton 6y ago
    > and stripping of for-profit status will be way better than splitting it. The US can't just make a company suddenly a non-proft. The current shareholders would have, in the case of Google, about a trillion reasons to complain.
    - anticensor 6y ago
      They would receive their respective share capitals in the liability payment stage of utilisation process, the business would continue too, so no valid reason to complain.
- acituan 6y ago
  > It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. Completely foreign platform is moving the goalposts here. I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions. Besides, the giant leap the OP and you make is that cost prohibition is the reason these spin-offs don't occur. I've been arguing not only the cost is not as high as you make, it is also unlikely to be the reason for us not seeing spin-offs. To invert your premise, if cost of giving the keys of any killed Google product to someone else was less than the money they could get, would they really transact away all of those products? I voted a strong no since my first reply to OP. > the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of) Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer. As I stated, that accommodation game becomes combinatorially explosive. Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large. Which is why the internal and external versions of could offerings don't diverge but converge too, their infrastructure is general purpose enough. > it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. I explicitly stated multiple times that I am not claiming 100% API/service parity, so you are fighting a strawman here. Not being identical, while being are sufficiently convergent, doesn't prove cost prohibition at all. > Yes, you claim this, and you were and continue to be incorrect. > But these aren't opinions. You're just factually, demonstrably wrong. I don't hear any demonstrations or facts, only your willful assertion that "it is so". Which is fine in a pseudonymous forum, because as I mentioned we don't need to spill our credentials to just win an argument, but also like I said, don't ask people to ascribe any more authority to it than mere opinion.

joshuamorton 6y ago

> The OP believes in a secret sauce in Google's infrastructure and that it should justify its breaking up, which enables products like Google Reader not to be shut down. That's not at all what they said. Their actual point was that because Google uses highly custom infra, it is not easy for them to open source or spin off a singular thing. This is valid even if Google's internal infra is strictly worse than what is available openly. Their point has nothing to do with magic infra. It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. > I claim cross-platform porting is not necessarily cost prohibitive, let alone porting from interal APIs to external APIs, and thus their argument is moot. Yes, you claim this, and you were and continue to be incorrect. > whenever there is an acquisition, unless it is a pure acquihire, external products get ported into corporate platforms without the world ending There is a difference between a situation where you are acquiring a thing for $LOTS, and are therefore willing to invest $EXTRA to make it work with your stuff, and the situation where you are divesting from a thing and therefore don't have the same budget. But even if you reject that: the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of). And, even when they aren't, "you decided to purchase them" is a really good justification to management, to use your words, to make additional exceptions. > They are entitled to their own opinion. But these aren't opinions. You're just factually, demonstrably wrong. Your (now deleted) statement that there may be efforts underway to better align the internal and external infrastructures may be true, but if it is, it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. To address your other comment: > You can run an RSS aggregator service without depending on Google's particular monitoring or cluster management infrastructure etc. Yes, but you can't run an RSS aggregator built to run on Google's infrastructure without either rewriting it or using Google's internal cluster management infra. The useful about having ecosystems like those is that you can couple couple very tightly between infra and application.

anticensor 6y ago
> This is valid even if Google's internal infra is strictly worse than what is available openly. Indeed it is, because Sod's, Parkinson's and Wirth's laws. > This is insane and a sign that something is deeply wrong in Google. Splitting Google up, forcing this infrastructure to become open, etc would be much healthier than perpetually killing small products to protect Google's secret sauce. Given such a massive rewrite will not be possible without bankrupting the company, and such an open source would just amount to going non-profit (they would essentially lose all trade secrets and profit-making advantages), forcing a public domain of intellectual property, replacing the top executives without severance and stripping of for-profit status will be way better economically, than splitting it.
- joshuamorton 6y ago
  > and stripping of for-profit status will be way better than splitting it. The US can't just make a company suddenly a non-proft. The current shareholders would have, in the case of Google, about a trillion reasons to complain.
  - anticensor 6y ago
    They would receive their respective share capitals in the liability payment stage of utilisation process, the business would continue too, so no valid reason to complain.
acituan 6y ago
> It is cost prohibitive to spin off anything because it has to be ported to a completely foreign platform. Completely foreign platform is moving the goalposts here. I said in my original response that everything Reader depended on is very likely to be available on GCP, and is very likely to be in a form that is very similar to its internal versions. Besides, the giant leap the OP and you make is that cost prohibition is the reason these spin-offs don't occur. I've been arguing not only the cost is not as high as you make, it is also unlikely to be the reason for us not seeing spin-offs. To invert your premise, if cost of giving the keys of any killed Google product to someone else was less than the money they could get, would they really transact away all of those products? I voted a strong no since my first reply to OP. > the internal systems are usually more flexible than the external ones (they have to be, they're what the external systems run on top of) Once your internal infrastructure is serving thousands of different engineering teams, there is only so much flexibility you can offer. As I stated, that accommodation game becomes combinatorially explosive. Which means internal infrastructure already has to be as general purpose as the variety of products a company has, which for these companies is pretty large. Which is why the internal and external versions of could offerings don't diverge but converge too, their infrastructure is general purpose enough. > it just proves the point that the infra isn't the same today, and that as of this moment such a migration would reasonably be cost prohibitive. I explicitly stated multiple times that I am not claiming 100% API/service parity, so you are fighting a strawman here. Not being identical, while being are sufficiently convergent, doesn't prove cost prohibition at all. > Yes, you claim this, and you were and continue to be incorrect. > But these aren't opinions. You're just factually, demonstrably wrong. I don't hear any demonstrations or facts, only your willful assertion that "it is so". Which is fine in a pseudonymous forum, because as I mentioned we don't need to spill our credentials to just win an argument, but also like I said, don't ask people to ascribe any more authority to it than mere opinion.