Project Fuchsia: Google Is Quietly Working on a Successor to Android(bloomberg.com)
bloomberg.com
Project Fuchsia: Google Is Quietly Working on a Successor to Android
https://www.bloomberg.com/news/articles/2018-07-19/google-team-is-said-to-plot-android-successor-draw-skepticism
213 comments
Per the article, Google has over 100 engineers working on Fuchsia. If these are all "senior engineers" that "Google is trying to retain", the cost of keeping them must be at least 50 million per year.
That's a lot of money to pay just for retention of people who are not producing anything of value, consuming many other resources (office space, network, hardware, perks), and deeply committed to a project that supposedly will never benefit their employer.
A rich employer may retain an unproductive employee for a limited amount of time if they expect it to ultimately pay off. It just doesn't make any sense to retain someone indefinitely if they're not going to produce anything of value, and (implicitly) will quit the moment you try to put them on any sort of real-world valuable work. Google is a public company with fiduciary responsibilities to its shareholders and a legally accountable board, it can't just throw tens of millions of dollars away without good reason or explanation.
> You see all these different projects competing against each other (multiple messaging apps are a good example) and you think: why is Google so unfocused?
There are many good reasons to have multiple teams competing against each other, building the same product. Often it will bring a strong drive and pace to all competing projects, as well as cross-pollination, and eventually they often merge to a single deliverable that is better than any of the projects could produce individually.
> what Google basically wants to do is hoard engineers
I'm not sure why all these improbable theories make more sense to you than the plain fact that Android was designed quite a few years ago, has many natural deficiencies, and - like all technologies - will eventually be replaced by a superior successor.
That's exactly what Fuchsia is about. Its existence does not require any elaborate conspiracy theory. On the contrary: given how strategically important the Android market niche is for Google, it would be very surprising if Google was not working on a viable successor. It's as if Sony didn't have a successor for the PS4 in the pipeline, and just expected it to sell forever, with minor patches here and there.
That's a lot of money to pay just for retention of people who are not producing anything of value, consuming many other resources (office space, network, hardware, perks), and deeply committed to a project that supposedly will never benefit their employer.
A rich employer may retain an unproductive employee for a limited amount of time if they expect it to ultimately pay off. It just doesn't make any sense to retain someone indefinitely if they're not going to produce anything of value, and (implicitly) will quit the moment you try to put them on any sort of real-world valuable work. Google is a public company with fiduciary responsibilities to its shareholders and a legally accountable board, it can't just throw tens of millions of dollars away without good reason or explanation.
> You see all these different projects competing against each other (multiple messaging apps are a good example) and you think: why is Google so unfocused?
There are many good reasons to have multiple teams competing against each other, building the same product. Often it will bring a strong drive and pace to all competing projects, as well as cross-pollination, and eventually they often merge to a single deliverable that is better than any of the projects could produce individually.
> what Google basically wants to do is hoard engineers
I'm not sure why all these improbable theories make more sense to you than the plain fact that Android was designed quite a few years ago, has many natural deficiencies, and - like all technologies - will eventually be replaced by a superior successor.
That's exactly what Fuchsia is about. Its existence does not require any elaborate conspiracy theory. On the contrary: given how strategically important the Android market niche is for Google, it would be very surprising if Google was not working on a viable successor. It's as if Sony didn't have a successor for the PS4 in the pipeline, and just expected it to sell forever, with minor patches here and there.
$50M is tiny compared to the opportunity cost of having 100 of your best engineers jump ship to a competitor or found a new one. Google will pay $50M for a startup with 10 proven engineers and then shut down their product, just so that they aren't on the open market where they can challenge the $50B+ golden goose.
Silicon Valley basically works on the principle of "Never let your employees do to you what you did to your past employer or competitors." There have been multiple cases where a small group of 10 or so engineers has quit en masse and then gone on to found or strengthen a billion-dollar competitor, eg. Shockley => Fairchild => Intel => AMD, HP => Apple => [General Magic, Claris, Radius, NeXT] => Apple, Cisco's revolving door of startups, [Western Digital, PARC, Bell Labs] => Google => Facebook. The cost to the company of this is easily in the hundreds of millions, oftentimes billions, and sometimes existential. It makes sense to blow $50M or so to keep a proven team of tech talent in-house.
Silicon Valley basically works on the principle of "Never let your employees do to you what you did to your past employer or competitors." There have been multiple cases where a small group of 10 or so engineers has quit en masse and then gone on to found or strengthen a billion-dollar competitor, eg. Shockley => Fairchild => Intel => AMD, HP => Apple => [General Magic, Claris, Radius, NeXT] => Apple, Cisco's revolving door of startups, [Western Digital, PARC, Bell Labs] => Google => Facebook. The cost to the company of this is easily in the hundreds of millions, oftentimes billions, and sometimes existential. It makes sense to blow $50M or so to keep a proven team of tech talent in-house.
> $50M is tiny compared to the opportunity cost of having 100 of your best engineers jump ship to a competitor or found a new one.
See my comment to nnq. You can't just take "100 of your best engineers", and stick them on some bogus project that regularly gets raided for its best talent by hiring managers.
If they'd rather work on a bogus project than on a real product, they're not very useful engineers.
The project will quickly be seen as a joke, and not just by one unnamed "person who has spoken to Fuchsia staff", but by everyone in the company. No serious engineer would stay on it.
There's literally no evidence for this far-fetched theory, and no verified examples of this happening in the industry at all. If an engineer isn't producing something worthwhile, he's not a good engineer, certainly not "one of my best engineers".
The whole theory is pretty crazy and it's funny it ended up so high in the comment thread that we're discussing it seriously.
> Silicon Valley basically works on the principle of "Never let your employees do to you what you did to your past employer or competitors." [...]
This is a lot of unsubstantiated hand-waving with no real data to back it up. The data I've seen is that involuntary turnover (aka termination) in FAANG is 5-8% annually, which is very reasonable for healthy companies.
Have you worked for a FAANG? People are regularly put on notice and fired for poor performance. Even a very successful company can't afford to keep poor performers indefinitely. If they do, they would not remain successful for long.
You're describing a public company with fiduciary accountability to its shareholders as if it can be run like some corrupt retirement home for aging diva former-engineers. You realize that if Google was throwing away $50-100m of investor money per year, an exec would eventually have to publicly explain to the shareholders why their money is wasted this way, and if Google was trying to hide that it is a bogus project, then they would be lying to investors, which is a criminal offense?
This theory is frankly nonsense.
See my comment to nnq. You can't just take "100 of your best engineers", and stick them on some bogus project that regularly gets raided for its best talent by hiring managers.
If they'd rather work on a bogus project than on a real product, they're not very useful engineers.
The project will quickly be seen as a joke, and not just by one unnamed "person who has spoken to Fuchsia staff", but by everyone in the company. No serious engineer would stay on it.
There's literally no evidence for this far-fetched theory, and no verified examples of this happening in the industry at all. If an engineer isn't producing something worthwhile, he's not a good engineer, certainly not "one of my best engineers".
The whole theory is pretty crazy and it's funny it ended up so high in the comment thread that we're discussing it seriously.
> Silicon Valley basically works on the principle of "Never let your employees do to you what you did to your past employer or competitors." [...]
This is a lot of unsubstantiated hand-waving with no real data to back it up. The data I've seen is that involuntary turnover (aka termination) in FAANG is 5-8% annually, which is very reasonable for healthy companies.
Have you worked for a FAANG? People are regularly put on notice and fired for poor performance. Even a very successful company can't afford to keep poor performers indefinitely. If they do, they would not remain successful for long.
You're describing a public company with fiduciary accountability to its shareholders as if it can be run like some corrupt retirement home for aging diva former-engineers. You realize that if Google was throwing away $50-100m of investor money per year, an exec would eventually have to publicly explain to the shareholders why their money is wasted this way, and if Google was trying to hide that it is a bogus project, then they would be lying to investors, which is a criminal offense?
This theory is frankly nonsense.
> Have you worked for a FAANG?
I was at Google for 5.5 years and was the beneficiary of an engineer-retention project for a year of that. I'm now working on a startup.
Think of it from the company's perspective: they have an engineer who has already been "paid off" in the sense of having generated more revenue for the company than they are likely to get in salary during a lifetime, and is likely independently wealthy through stock options. That engineer comes to them and says "I'm unhappy here and thinking of leaving so I can work on personal projects." The company does not want to see them on the open market, where they can potentially compete with Google or work for a competitor. So their manager asks them "Well, what is it you really want to work on? Maybe we can make it happen here and you don't have to leave all the perks of Google behind." The engineer says "I've always wanted to do OS development, and there's a bunch of neat research developments like capabilities that haven't yet been incorporated in a production OS." The manager says, "Hmm, I know of some guys over in this other department that have similar ideas. Why don't you connect with them and see if your interests align?"
Google wins because it keeps these talented engineers off the market, and if the project succeeds they can win in a really big way. The employee wins because they don't have to deal with all the risk and bullshit of being unemployed or starting their own thing. Competitors lose but screw them. Consumers probably lose, but it's not a sure thing because if their project succeeds, consumers can win in a big way, so Google doesn't get into antitrust or anticompetitive trouble for it.
This is not unlimited, BTW. The unofficial rule-of-thumb when I was at Google is that "you get one freebie" - if you were instrumental to the success of a project that made Google much more than you're ever likely to make in salary, you get one chance at a self-directed project. If that fails, you either go back to being an ordinary rank-and-file engineer and have to prove yourself, or you get marginalized and usually leave. Public examples of such projects include Google Scholar (Anurag basically ran the crawl single-handedly for many years, and so he gets to indulge his passion project because Google wouldn't exist without him), Golang (Ken Thompson is Ken Thompson and Rob Pike basically built the log handling infrastructure for Google), Google Wave (the Rasmussen brothers basically founded Google Maps), Hello.com (Orkut Buyokokkten's passion project, eventually spun out), and Andy Rubin's robot collection.
I was at Google for 5.5 years and was the beneficiary of an engineer-retention project for a year of that. I'm now working on a startup.
Think of it from the company's perspective: they have an engineer who has already been "paid off" in the sense of having generated more revenue for the company than they are likely to get in salary during a lifetime, and is likely independently wealthy through stock options. That engineer comes to them and says "I'm unhappy here and thinking of leaving so I can work on personal projects." The company does not want to see them on the open market, where they can potentially compete with Google or work for a competitor. So their manager asks them "Well, what is it you really want to work on? Maybe we can make it happen here and you don't have to leave all the perks of Google behind." The engineer says "I've always wanted to do OS development, and there's a bunch of neat research developments like capabilities that haven't yet been incorporated in a production OS." The manager says, "Hmm, I know of some guys over in this other department that have similar ideas. Why don't you connect with them and see if your interests align?"
Google wins because it keeps these talented engineers off the market, and if the project succeeds they can win in a really big way. The employee wins because they don't have to deal with all the risk and bullshit of being unemployed or starting their own thing. Competitors lose but screw them. Consumers probably lose, but it's not a sure thing because if their project succeeds, consumers can win in a big way, so Google doesn't get into antitrust or anticompetitive trouble for it.
This is not unlimited, BTW. The unofficial rule-of-thumb when I was at Google is that "you get one freebie" - if you were instrumental to the success of a project that made Google much more than you're ever likely to make in salary, you get one chance at a self-directed project. If that fails, you either go back to being an ordinary rank-and-file engineer and have to prove yourself, or you get marginalized and usually leave. Public examples of such projects include Google Scholar (Anurag basically ran the crawl single-handedly for many years, and so he gets to indulge his passion project because Google wouldn't exist without him), Golang (Ken Thompson is Ken Thompson and Rob Pike basically built the log handling infrastructure for Google), Google Wave (the Rasmussen brothers basically founded Google Maps), Hello.com (Orkut Buyokokkten's passion project, eventually spun out), and Andy Rubin's robot collection.
There's more: Cos and the open source Vanadium, John Hanke and Ingress/FieldTrip, Niniane and Lively, Hartmut and the quantum lab, Craig N-M and google.org, etc.
But you left out the largest retention side project: Jeff Dean and Brain.
But you left out the largest retention side project: Jeff Dean and Brain.
Google Brain has been pretty awesome for academia: https://ai.google/research/pubs/?team=brain
pours one out for Vanadium, wipes a tear away
also sebastian thrun and google[x] / self driving cars
craig got a whole new york office. he did well.
> So their manager asks them "Well, what is it you really want to work on? Maybe we can make it happen here and you don't have to leave all the perks of Google behind." The engineer says "I've always wanted to do OS development, and there's a bunch of neat research developments like capabilities that haven't yet been incorporated in a production OS." The manager says, "Hmm, I know of some guys over in this other department that have similar ideas. Why don't you connect with them and see if your interests align?"
What you describe is simply allowing a well-performing engineer to switch to new project, which of course happens all the time.
It's very different from "a bogus project for the sole purpose of retaining some engineers" that OP theorized.
> Google wins because it keeps these talented engineers off the market, and if the project succeeds they can win in a really big way.
So more or less like any ambitious new project? :)
> This is not unlimited, BTW.
Right, and again, goes against what OP was implying, that Google is going to run a huge project indefinitely just to retain a bunch of diva engineers who wouldn't work on anything else.
As I wrote above: "a rich employer may retain an unproductive employee for a limited amount of time if they expect it to ultimately pay off".
This is exactly what you are describing.
> if you were instrumental to the success of a project that made Google much more than you're ever likely to make in salary, you get one chance at a self-directed project.
Right, and Fuchsia is not a "self-directed project" of this kind. It's a big project with over 100 engineers, the vast majority of whom did not have the impact of Rob Pike or the others you mentioned.
Your comment is good and informative, but ultimately does not lend any support to the notion that Fuchsia really is some bogus project with no business case or future, solely for retention purposes, which is what OP was implying and what I am disputing.
What you describe is simply allowing a well-performing engineer to switch to new project, which of course happens all the time.
It's very different from "a bogus project for the sole purpose of retaining some engineers" that OP theorized.
> Google wins because it keeps these talented engineers off the market, and if the project succeeds they can win in a really big way.
So more or less like any ambitious new project? :)
> This is not unlimited, BTW.
Right, and again, goes against what OP was implying, that Google is going to run a huge project indefinitely just to retain a bunch of diva engineers who wouldn't work on anything else.
As I wrote above: "a rich employer may retain an unproductive employee for a limited amount of time if they expect it to ultimately pay off".
This is exactly what you are describing.
> if you were instrumental to the success of a project that made Google much more than you're ever likely to make in salary, you get one chance at a self-directed project.
Right, and Fuchsia is not a "self-directed project" of this kind. It's a big project with over 100 engineers, the vast majority of whom did not have the impact of Rob Pike or the others you mentioned.
Your comment is good and informative, but ultimately does not lend any support to the notion that Fuchsia really is some bogus project with no business case or future, solely for retention purposes, which is what OP was implying and what I am disputing.
Wave and Hello.com each had over 50 engineers, and Andy Rubin spent several hundred million (perhaps billions) on robotics acquisitions, all for projects that ended up getting canceled.
At some point the difference between "engineer retention project" and "risky venture that probably won't pan out but could win big" ceases to matter. Larry Page is exceptionally good at "Heads I win, tails I win even more" gambits - historically, these included Google Toolbar (initially conceived as a defensive play against Microsoft, but ended up getting Google Search in front of hundreds of millions of new users - this, BTW, was Sundar Pichai's first big win on the way to CEO); Google Chrome (ditto, with the side effect of becoming the dominant browser); GMail (initially an internal tool to improve productivity, then became a major consumer product); and Google Fiber (worst case, force Internet speeds up through competition, best case, new ISP). It's likely that Sundar & Larry's thinking of Fuchsia is that worst-case, it keeps 100 talented engineers at the company, and best-case, it's a dominant new OS that drives computing forwards. Either one is worth the $50M or so, so they do it.
At some point the difference between "engineer retention project" and "risky venture that probably won't pan out but could win big" ceases to matter. Larry Page is exceptionally good at "Heads I win, tails I win even more" gambits - historically, these included Google Toolbar (initially conceived as a defensive play against Microsoft, but ended up getting Google Search in front of hundreds of millions of new users - this, BTW, was Sundar Pichai's first big win on the way to CEO); Google Chrome (ditto, with the side effect of becoming the dominant browser); GMail (initially an internal tool to improve productivity, then became a major consumer product); and Google Fiber (worst case, force Internet speeds up through competition, best case, new ISP). It's likely that Sundar & Larry's thinking of Fuchsia is that worst-case, it keeps 100 talented engineers at the company, and best-case, it's a dominant new OS that drives computing forwards. Either one is worth the $50M or so, so they do it.
> Wave and Hello.com each had over 50 engineers, and Andy Rubin spent several hundred million (perhaps billions) on robotics acquisitions, all for projects that ended up getting canceled.
And they all got canceled once their business case became void.
None of these were bogus projects. They all initially had a business case, and were run by engineers who proved themselves before. When that business case fail to pan out - they were canceled.
> At some point the difference between "engineer retention project" and "risky venture that probably won't pan out but could win big" ceases to matter.
Maybe to you as an employee. Not to Google as a business, nor its shareholders.
If I'm a Google shareholder, and you're wasting hundreds of millions of dollars of my money with nothing to show for it but some vague fears that "my engineers will go to competitors", then I'm going to be unhappy. Beyond a certain point, you're opening yourself up to lawsuits and even criminal charges (Google is a public company).
All of your examples are projects that were interesting and had some passionate senior engineers pushing them forward, but also had a business case. When the business case went bust, so did the project.
To support OP's assertion that Fuchsia is just a retention project with no future, you'd have to show a project of its size (or any size, really) run for the sole purpose of retention with no plausible business case.
I don't think such a thing exists, and it's not in any of your examples.
I have some personal experience with Wave. It had a plausible business case and Google was promoting it heavily. It wasn't bogus. I'm sure the same is true for the others.
And they all got canceled once their business case became void.
None of these were bogus projects. They all initially had a business case, and were run by engineers who proved themselves before. When that business case fail to pan out - they were canceled.
> At some point the difference between "engineer retention project" and "risky venture that probably won't pan out but could win big" ceases to matter.
Maybe to you as an employee. Not to Google as a business, nor its shareholders.
If I'm a Google shareholder, and you're wasting hundreds of millions of dollars of my money with nothing to show for it but some vague fears that "my engineers will go to competitors", then I'm going to be unhappy. Beyond a certain point, you're opening yourself up to lawsuits and even criminal charges (Google is a public company).
All of your examples are projects that were interesting and had some passionate senior engineers pushing them forward, but also had a business case. When the business case went bust, so did the project.
To support OP's assertion that Fuchsia is just a retention project with no future, you'd have to show a project of its size (or any size, really) run for the sole purpose of retention with no plausible business case.
I don't think such a thing exists, and it's not in any of your examples.
I have some personal experience with Wave. It had a plausible business case and Google was promoting it heavily. It wasn't bogus. I'm sure the same is true for the others.
The final risk factor listed on Google's 10-K [1] is:
"We rely on highly skilled personnel and, if we are unable to retain or motivate key personnel, hire qualified personnel, or maintain our corporate culture, we may not be able to grow effectively."
Acquiring and retaining key people is in the interests of shareholders, and Google invests significantly in this activity. I started this subthread with a comment about $50M acquihires where they shut down the product immediately afterwards. That's just one example - others include funding STEM education for children, the Google Summer of Code, multi-million-$ retention bonuses, and constant recruiting efforts.
This is all disclosed on the prospectus and annual reports. If you don't understand why this is important for a tech company, you should probably not be investing in tech, but I will be happy to buy your shares from you.
[1] https://www.sec.gov/Archives/edgar/data/1288776/000165204416...
"We rely on highly skilled personnel and, if we are unable to retain or motivate key personnel, hire qualified personnel, or maintain our corporate culture, we may not be able to grow effectively."
Acquiring and retaining key people is in the interests of shareholders, and Google invests significantly in this activity. I started this subthread with a comment about $50M acquihires where they shut down the product immediately afterwards. That's just one example - others include funding STEM education for children, the Google Summer of Code, multi-million-$ retention bonuses, and constant recruiting efforts.
This is all disclosed on the prospectus and annual reports. If you don't understand why this is important for a tech company, you should probably not be investing in tech, but I will be happy to buy your shares from you.
[1] https://www.sec.gov/Archives/edgar/data/1288776/000165204416...
> If I'm a Google shareholder, ... then I'm going to be unhappy.
Are you a voting shareholder (class A or B)? If you have class C (no vote), they don't have to care. If you have class A (voting public) shares, which get 1/10 the vote of the class B (management) shares, your influence is incidental at best.
Are you a voting shareholder (class A or B)? If you have class C (no vote), they don't have to care. If you have class A (voting public) shares, which get 1/10 the vote of the class B (management) shares, your influence is incidental at best.
I would not characterize fiber as having any notable impact on the country at large's internet speeds/caps.
It worked for Kansas City, Provo, and Austin, and basically failed everywhere else.
I think Fiber was a bit of a miscalculation in that they misjudged where the bottleneck would be. In the early days of Fiber (I worked on it, briefly), the assumption was that key risk factors would be that incumbent ISPs would raise their speeds to match, or that marketing would fail to sign up enough customers to make the build-out economical. These turned out to not be major problems, but the incumbent ISPs blocked expansion to new municipalities through permitting & right-of-way restrictions. The assumption when I was working on it was that if Kansas City could demonstrate a successful deployment, other cities would be lining up to clear roadblocks and bring Google Fiber to their citizens; this didn't happen.
I think Fiber was a bit of a miscalculation in that they misjudged where the bottleneck would be. In the early days of Fiber (I worked on it, briefly), the assumption was that key risk factors would be that incumbent ISPs would raise their speeds to match, or that marketing would fail to sign up enough customers to make the build-out economical. These turned out to not be major problems, but the incumbent ISPs blocked expansion to new municipalities through permitting & right-of-way restrictions. The assumption when I was working on it was that if Kansas City could demonstrate a successful deployment, other cities would be lining up to clear roadblocks and bring Google Fiber to their citizens; this didn't happen.
Would you say that most major cable providers now having gigabit offerings now wasn't at least partially pushed by the threat of Google Fiber? I mean, in an area Fiber never launched in now, two of the three ISPs here provide gigabit via coax now (Comcast and WOW), and I'm hard pressed to believe they would've jumped from ~150 Mbps service to gigabit service at about the same price if someone else wasn't threatening to do it first.
Sure, it took a while after Google Fiber launched, but there was a lot of infrastructure to deploy. I'd argue Google had a hand in this.
Sure, it took a while after Google Fiber launched, but there was a lot of infrastructure to deploy. I'd argue Google had a hand in this.
> It's very different from "a bogus project for the sole purpose of retaining some engineers" that OP theorized.
I mean, it's not like Google is inventing bogus projects in a top-down sense, with some middle-manager somewhere coming up with "private works projects" and staffing them with engineers Google wants to keep. Nobody is claiming that.
No, what the GP was proposing is that the projects are bogus in a bottom-up sense: they're projects that are entirely useless to Google's shareholders in both a short-term and long-term sense, but which the engineers really want to work on, and which at least aren't actively harming Google (or perhaps they are, but not as much as Google would be harmed if the same project were developed in the wild.) This is very different from "basic research" (Google X et al), which is useless in a short-term sense, but may yield large positive returns later on. These projects are bogus because the best-case scenario for them is no net effect on Google as a business. (They might have quite an effect on the the world, but if there's no way for Google to convert that effect into shareholder value: bogus.)
Fuchsia is a perfect case: at best, it replaces Android, for no net benefit to Google (since they already dominate the mobile ecosystem with Android.) But if the engineers working on Fuchsia couldn't work on it at Google, they'd have started a similar project outside Google... and then Google would be in the position of a non-Google-owned OS displacing Android's share of the mobile-OS market.
Much better that these engineers do something useless [from a business perspective] that merely keeps stable Google's share of a market, than that they do something that actively lowers Google's share of a market.
I mean, it's not like Google is inventing bogus projects in a top-down sense, with some middle-manager somewhere coming up with "private works projects" and staffing them with engineers Google wants to keep. Nobody is claiming that.
No, what the GP was proposing is that the projects are bogus in a bottom-up sense: they're projects that are entirely useless to Google's shareholders in both a short-term and long-term sense, but which the engineers really want to work on, and which at least aren't actively harming Google (or perhaps they are, but not as much as Google would be harmed if the same project were developed in the wild.) This is very different from "basic research" (Google X et al), which is useless in a short-term sense, but may yield large positive returns later on. These projects are bogus because the best-case scenario for them is no net effect on Google as a business. (They might have quite an effect on the the world, but if there's no way for Google to convert that effect into shareholder value: bogus.)
Fuchsia is a perfect case: at best, it replaces Android, for no net benefit to Google (since they already dominate the mobile ecosystem with Android.) But if the engineers working on Fuchsia couldn't work on it at Google, they'd have started a similar project outside Google... and then Google would be in the position of a non-Google-owned OS displacing Android's share of the mobile-OS market.
Much better that these engineers do something useless [from a business perspective] that merely keeps stable Google's share of a market, than that they do something that actively lowers Google's share of a market.
Or more that they're likely useless from a shareholder perspective, but have a small chance of paying off in a large way, and worst-case keep the engineers occupied & employed at the company.
Google doesn't generally allow projects that everyone knows have zero chance of being useful in a bottom-line sense; you can't, for example, build a D&D campaign index on company time even if you're T9. (There was a big debate over this near the tail end of the Eric Schmidt years, when you actually could, and this was one reason for Larry's "More wood behind fewer arrows" campaign.)
But for something with a small chance of having a large impact, like a new OS or programming language or attempt to speed up scientific progress? Google can totally get behind that, because worst-case, you keep the engineers employed and available for future use, while best-case, you've got a computer science breakthrough. Fuchsia fits right into this case, as does Dart and Go and Unladen Swallow and several other projects.
Google doesn't generally allow projects that everyone knows have zero chance of being useful in a bottom-line sense; you can't, for example, build a D&D campaign index on company time even if you're T9. (There was a big debate over this near the tail end of the Eric Schmidt years, when you actually could, and this was one reason for Larry's "More wood behind fewer arrows" campaign.)
But for something with a small chance of having a large impact, like a new OS or programming language or attempt to speed up scientific progress? Google can totally get behind that, because worst-case, you keep the engineers employed and available for future use, while best-case, you've got a computer science breakthrough. Fuchsia fits right into this case, as does Dart and Go and Unladen Swallow and several other projects.
Your comments have been enlightening. Thanks for confirming what I always suspected [1].
[1] https://news.ycombinator.com/item?id=12410662
[1] https://news.ycombinator.com/item?id=12410662
Funny how you only took into account the post that confirms your preset bias.
This makes sense to me. I wonder how much the secret sauce comes into play. For example blowing a good/great engineer is one thing. But worse if they can apply some of the seemingly unique techniques google used to do engineering.
I’m thinking of things like the build system, mono repo & the borg etc
I’m thinking of things like the build system, mono repo & the borg etc
> If an engineer isn't producing something worthwhile, he's not a good engineer, certainly not "one of my best engineers".
Not my experience. I've seen amazing engineers happily convince themselves whatever they are working on is important regardless of what it is. In fact its pretty common for really good engineers to simply fall in love with the code - or be convinced if they only finished this refactor it would be beautiful. I almost never hear them talk of business value.
The ones that do have this insight end up going on to be great managers - as they can bridge the divide.
Not my experience. I've seen amazing engineers happily convince themselves whatever they are working on is important regardless of what it is. In fact its pretty common for really good engineers to simply fall in love with the code - or be convinced if they only finished this refactor it would be beautiful. I almost never hear them talk of business value.
The ones that do have this insight end up going on to be great managers - as they can bridge the divide.
For a functional employer, the definition of "a good engineer" is "someone who produces valuable engineering solutions for me".
An engineer who isn't doing that is either mismanaged, misplaced, or is no good. In the first two cases, I can possibly make use of them. But if the engineer is a diva who would only work on some made-up fancy project, then he is not a good engineer for me.
Maybe he will be able to do good work elsewhere, but that's not really relevant for me, my business, or my shareholders. Not anymore than the fact he may be a great painter or musician. Good for him, but sadly irrelevant for my business.
An engineer who isn't doing that is either mismanaged, misplaced, or is no good. In the first two cases, I can possibly make use of them. But if the engineer is a diva who would only work on some made-up fancy project, then he is not a good engineer for me.
Maybe he will be able to do good work elsewhere, but that's not really relevant for me, my business, or my shareholders. Not anymore than the fact he may be a great painter or musician. Good for him, but sadly irrelevant for my business.
Generally its the managers responsibility to ensure they are working on what is important. That's literally their entire job. An employee capable of convincing themselves whatever they work on is important is a net benefit to the manager - they are more malleable and can be convinced to work on the important but "boring" parts.
An employee refusing to work on something because in their opinion its not worthwhile is a tough place for both the employee and the manager.
An employee refusing to work on something because in their opinion its not worthwhile is a tough place for both the employee and the manager.
Who said Fuchsia was some bogus project and a waste of talent and resources? My original comment was that Google was willing to let its enginners work on duplicate project so they remain at Google instead of leaving to work elsewhere. If Fuchsia turns out great, that will be a win for Google. It's not like these enginneers are just being paid to kill time.
Google bought Android, then also created Chrome OS and is now making a tthird OS named Fuchsia.
They had Gchat that they scrapped for Hangouts, which they pivoted into a business chat (Meet), but the Hangouts client is still available for the general public. They also made Allo, which eventually went nowhere, so now they're pushing for the adoption of RCS (Android Messages).
Gchat, Hangouts, Meet, Allo, RCS. That's 5 messaging apps right there.
Google bought Android, then also created Chrome OS and is now making a tthird OS named Fuchsia.
They had Gchat that they scrapped for Hangouts, which they pivoted into a business chat (Meet), but the Hangouts client is still available for the general public. They also made Allo, which eventually went nowhere, so now they're pushing for the adoption of RCS (Android Messages).
Gchat, Hangouts, Meet, Allo, RCS. That's 5 messaging apps right there.
You talk tough but I don't think your understanding of the problem space warrants that tone. Doing research & development is not something that involves lying to investors. Investors love new products. That is how they make money by investing.
Consider the project mentioned in the article. Sure, it will cost millions of dollars to develop. But OSes are in high demand, existing OSes have quite a few sore points, and plenty of people have made money selling operating systems or devices that need a custom operating system (MS/DOS, Windows, iOS, etc.) So it is not categorically insane from a business or engineering perspective to say "hey, we're going to invest in the development of a new operating system that will change the world."
On the other hand, maybe all the OS world needs are some patches on top of Linux to smooth over the rough spots.
People that see the project the first way will say they're working on a "moonshot". People that see the project the second way will say they're working on a "senior engineer retention project."
Any big company will likely want to hedge its bets, and indeed... apparently Google has people working on a new OS, and they obviously have people patching the Linux kernel (Android). No matter which approach ends up being correct, Google makes money. I don't think the investors are going to be filing many criminal charges against the board.
Back to the retention aspect, remember what the downside is in this scenario. The people that want to build their own OS to change the world or whatever just leave and go do it. They have money and can probably rope in some investors. If they end up being right about the approach... there is no more Android and that means no more Google ads on mobile phones, no more location history, no more searches... etc. That is quite a downside for Google. So even though the project is "this seems crazy, but we don't want these people to quit", it's 100% the right financial decision.
I think the shareholders can appreciate that.
That said, as an employee... this was all a little too much for me when I was at Google. No matter what you worked on, there was always a competing project with twice as much headcount and 1/10th the users. You would have a meeting with them along the lines of "hey, this thing you're assembling a 30 person team for... my team already made and it's in production and working." They would be like "nah, our use case is slightly different and rather than editing 1 line of code and getting no promotion, I'd like to build a HUGE team and put an EZ promotion packet together." Not for me.
Consider the project mentioned in the article. Sure, it will cost millions of dollars to develop. But OSes are in high demand, existing OSes have quite a few sore points, and plenty of people have made money selling operating systems or devices that need a custom operating system (MS/DOS, Windows, iOS, etc.) So it is not categorically insane from a business or engineering perspective to say "hey, we're going to invest in the development of a new operating system that will change the world."
On the other hand, maybe all the OS world needs are some patches on top of Linux to smooth over the rough spots.
People that see the project the first way will say they're working on a "moonshot". People that see the project the second way will say they're working on a "senior engineer retention project."
Any big company will likely want to hedge its bets, and indeed... apparently Google has people working on a new OS, and they obviously have people patching the Linux kernel (Android). No matter which approach ends up being correct, Google makes money. I don't think the investors are going to be filing many criminal charges against the board.
Back to the retention aspect, remember what the downside is in this scenario. The people that want to build their own OS to change the world or whatever just leave and go do it. They have money and can probably rope in some investors. If they end up being right about the approach... there is no more Android and that means no more Google ads on mobile phones, no more location history, no more searches... etc. That is quite a downside for Google. So even though the project is "this seems crazy, but we don't want these people to quit", it's 100% the right financial decision.
I think the shareholders can appreciate that.
That said, as an employee... this was all a little too much for me when I was at Google. No matter what you worked on, there was always a competing project with twice as much headcount and 1/10th the users. You would have a meeting with them along the lines of "hey, this thing you're assembling a 30 person team for... my team already made and it's in production and working." They would be like "nah, our use case is slightly different and rather than editing 1 line of code and getting no promotion, I'd like to build a HUGE team and put an EZ promotion packet together." Not for me.
> $50M is tiny compared to the opportunity cost of having 100 of your best engineers jump ship to a competitor or found a new one.
One of the following must be true:
- Fuchsia has perceived product value, and it's an investment
- Google doesn't have enough interesting work right now, the amount of interesting fluctuates up & down, and retaining expensive employees by having them work on "Fun Fuchsia" during the current down cycle is more efficient than hiring expensive employee attrition+recruitment
- Fuchsia has no product value, and Google has too many expensive engineers
One of the following must be true:
- Fuchsia has perceived product value, and it's an investment
- Google doesn't have enough interesting work right now, the amount of interesting fluctuates up & down, and retaining expensive employees by having them work on "Fun Fuchsia" during the current down cycle is more efficient than hiring expensive employee attrition+recruitment
- Fuchsia has no product value, and Google has too many expensive engineers
> the cost of keeping them must be at least 50 million per year.
There's a high likelihood that at least some of their work will be of value to the company—or, if everything pans out, they get a fancy new platform. The real motivation is probably somewhere in the middle (retention, product development).
This is a solid bet to make, especially when you are effectively not worried about the cost (thanks, ads!).
A lot of Google is heavily research focused like this: let engineers (mostly) freely explore complicated problem spaces. If it's a product—awesome!—see if there's market fit, and then grow it. If not, no problem; see where it, or parts thereof, can be applied elsewhere within Google.
Source: I worked there.
There's a high likelihood that at least some of their work will be of value to the company—or, if everything pans out, they get a fancy new platform. The real motivation is probably somewhere in the middle (retention, product development).
This is a solid bet to make, especially when you are effectively not worried about the cost (thanks, ads!).
A lot of Google is heavily research focused like this: let engineers (mostly) freely explore complicated problem spaces. If it's a product—awesome!—see if there's market fit, and then grow it. If not, no problem; see where it, or parts thereof, can be applied elsewhere within Google.
Source: I worked there.
Sure, that's more reasonable. You're describing a match between business needs (the potential Android successor - quite an important business target) and a critical mass of senior engineers eager to work on the product.
I'm sure Google is aware that more interesting and ambitious projects do tend to capture and hold the interest of the most talented engineers, and that figures into their business decisions.
What I strongly dispute is this notion that such a project would be subsidized solely for retention. Everyone knows about big Google projects that were shut down when their business case lost its appeal. I've also seen much smaller projects shut down when their value proposition was no longer deemed sufficient, even when their members were talented, passionate, and at real risk of leaving once their project shut down.
I'm sure Google is aware that more interesting and ambitious projects do tend to capture and hold the interest of the most talented engineers, and that figures into their business decisions.
What I strongly dispute is this notion that such a project would be subsidized solely for retention. Everyone knows about big Google projects that were shut down when their business case lost its appeal. I've also seen much smaller projects shut down when their value proposition was no longer deemed sufficient, even when their members were talented, passionate, and at real risk of leaving once their project shut down.
> It just doesn't make any sense to retain someone indefinitely if they're not going to produce anything of value
They likely will. Whenever a new projects starts, engineers can be recruited for it from the pre-vetted internal pool. Hiring and the ramp-up time for new hires would cost more. Yeah, if you're an ossified compnay rarely starting new projects it doesn't make sense. But if your Google this is not the case...
They likely will. Whenever a new projects starts, engineers can be recruited for it from the pre-vetted internal pool. Hiring and the ramp-up time for new hires would cost more. Yeah, if you're an ossified compnay rarely starting new projects it doesn't make sense. But if your Google this is not the case...
This sounds good in theory, but in practice what you're describing will not be stable, sustainable, or at all practical.
You can't really run this sort of revolving-door "talent pool" project for long, certainly not a massive project of 100+ engineers. If every time a new project opens up, its hiring managers get to unreservedly raid the "talent pool" project for star performers, then pretty soon this project will be known internally as a joke, that is at priority zero, and any but its most dysfunctional engineers will be rushing to other projects, either internally within Google or (more likely) outside it.
You'll end up with all the best people quickly leaving for real projects where they can do real work on real products for real pay (bonuses for revenue-yielding projects are much, much higher than for anything else). The project itself will be a dysfunctional joke since you can't run it with the best talent routinely recruited away. The only people who will work on it will be dead weight who don't care to work on real products or even make any progress on a bogus one, which is the definition of the sort of people you should immediately fire.
In fact, the whole initial "pool" of candidates sounds toxic, if the only reason they were given this project is that any other _real_ work would cause them to leave. As a hiring manager, I'd be very skeptical of anyone who seemed to be this sort of indifferent diva, and would not be looking to hire them.
To sum up, it's a fun little theory, but extremely unlikely to work in practice, and I've never seen anything like it. The simple explanation that Fuchsia is an Android successor is much more likely, and there's zero evidence for the far-fetched "talent pool" explanation other than an unsupported comment by some anonymous "one person who has spoken to Fuchsia staff". It's ridiculous.
You can't really run this sort of revolving-door "talent pool" project for long, certainly not a massive project of 100+ engineers. If every time a new project opens up, its hiring managers get to unreservedly raid the "talent pool" project for star performers, then pretty soon this project will be known internally as a joke, that is at priority zero, and any but its most dysfunctional engineers will be rushing to other projects, either internally within Google or (more likely) outside it.
You'll end up with all the best people quickly leaving for real projects where they can do real work on real products for real pay (bonuses for revenue-yielding projects are much, much higher than for anything else). The project itself will be a dysfunctional joke since you can't run it with the best talent routinely recruited away. The only people who will work on it will be dead weight who don't care to work on real products or even make any progress on a bogus one, which is the definition of the sort of people you should immediately fire.
In fact, the whole initial "pool" of candidates sounds toxic, if the only reason they were given this project is that any other _real_ work would cause them to leave. As a hiring manager, I'd be very skeptical of anyone who seemed to be this sort of indifferent diva, and would not be looking to hire them.
To sum up, it's a fun little theory, but extremely unlikely to work in practice, and I've never seen anything like it. The simple explanation that Fuchsia is an Android successor is much more likely, and there's zero evidence for the far-fetched "talent pool" explanation other than an unsupported comment by some anonymous "one person who has spoken to Fuchsia staff". It's ridiculous.
> That's a lot of money to pay just for retention of people who are not producing anything of value, consuming many other resources (office space, network, hardware, perks), and deeply committed to a project that supposedly will never benefit their employer.
I think Google figure it out its real bussiness like MacDonalds did: Not burgers, but real state bussiness. I think Google understood they are not in the make "valuable useful tech" bussiness as one is inclined to think, they are in the "tech talent retention bussiness".
Even if they dont use the talent, if they are able to lock the talent inside Google as a kid in a Circus, their competitors wont have access to the talent pool they need, and this will make a big monopoly on Google.
Of course, this is only possible if you have the ammount of cash and credentials Google have to attract tech people like Disney do to kids.
I think this is their real primary mission; attract human talent, retain and ultimately lock it from the competition.
Do you ever wonder why the startup scene is so dry lately, even with so many enginners and tech focused people no short of ideas? The titans are just sucking all the oxigene in the room making everyone else choke.
I think Google figure it out its real bussiness like MacDonalds did: Not burgers, but real state bussiness. I think Google understood they are not in the make "valuable useful tech" bussiness as one is inclined to think, they are in the "tech talent retention bussiness".
Even if they dont use the talent, if they are able to lock the talent inside Google as a kid in a Circus, their competitors wont have access to the talent pool they need, and this will make a big monopoly on Google.
Of course, this is only possible if you have the ammount of cash and credentials Google have to attract tech people like Disney do to kids.
I think this is their real primary mission; attract human talent, retain and ultimately lock it from the competition.
Do you ever wonder why the startup scene is so dry lately, even with so many enginners and tech focused people no short of ideas? The titans are just sucking all the oxigene in the room making everyone else choke.
> If these are all "senior engineers" that "Google is trying to retain", the cost of keeping them must be at least 50 million per year.
Wait uh... are you saying seniors at Google make an average of $500k?
Wait uh... are you saying seniors at Google make an average of $500k?
That seems like a low estimate of the cost of a senior SWE at Google. They probably earn at least 400k in cash + bonus + stock, and there are employer costs beyond that (office space, benefits, payroll taxes).
Glassdoor has avg total comp for senior swes at google at 193k...
I am very surprised if that's the case.
For what it's worth, I just started at Google as a Senior SWE this summer. My base is in the 180s. With an average annual bonus, my moving/starting bonus, and stock grant (ignoring stock price movements), my first four years should be 400ish...very high 300s really.
BTW, https://www.levels.fyi/ is another source of data which might prove useful
190 total comp is more in line with what I expect for an early career person. Welcome to 2018 tech company salaries.
For what it's worth, I just started at Google as a Senior SWE this summer. My base is in the 180s. With an average annual bonus, my moving/starting bonus, and stock grant (ignoring stock price movements), my first four years should be 400ish...very high 300s really.
BTW, https://www.levels.fyi/ is another source of data which might prove useful
190 total comp is more in line with what I expect for an early career person. Welcome to 2018 tech company salaries.
That's a pretty great package... brb applying to work at Google.
That is definitely not correct.
Senior engineer can either mean "an engineer with a significant amount of experience" or "a title for a specific position at a specific company".
Either way based on my experience as a manager at Google, the answer to your question is yes.
Either way based on my experience as a manager at Google, the answer to your question is yes.
Yes -- https://danluu.com/startup-tradeoffs/ cites $250k as a "conservative" (low) estimate for a senior SWE there, and was written in 2015.
Salary is usually only 2/3 of the cost of an employee. Benefits and overhead are a big part.
Must be the first law of HN: Every thread devolves into a discussion of $1mn+ engineer salaries ;)
Some do. If you add bonuses and stock grands it can get to at least half a million per year
> they often merge to a single deliverable that is better than any of the projects could produce individually.
Do you have an example of this?
Do you have an example of this?
I think Google's self-competition is something they are doing strategically.
If you look at the industry as a whole products wax and wane based on market trends. Market leading products often struggle to innovate under the weight of their own success and are eventually replaced by a new innovator that's doing something right.
Google, by virtue of creating many different types of products in one category somewhat insulates themselves from this effect. They have effectively infinite money, so from their perspective they can somewhat emulate the greater market internally. They can let "startup" style teams form internally so if someone supplants one of Google's products, it's likely to be a Google team.
There are significant downsides to this (eroding consumer trust) which may take their toll on Google with time.
If you look at the industry as a whole products wax and wane based on market trends. Market leading products often struggle to innovate under the weight of their own success and are eventually replaced by a new innovator that's doing something right.
Google, by virtue of creating many different types of products in one category somewhat insulates themselves from this effect. They have effectively infinite money, so from their perspective they can somewhat emulate the greater market internally. They can let "startup" style teams form internally so if someone supplants one of Google's products, it's likely to be a Google team.
There are significant downsides to this (eroding consumer trust) which may take their toll on Google with time.
Having multiple competing projects is not unheard of in the business world in general, and in high-achieving technology businesses in particular. Often, those outside the organization are only aware of the winning project, and the others are quietly discontinued, with many / most / all members moving to the winning team.
I know of several other prominent examples, but can't mention by name because I'd be breaking an NDA.
Also, Fuchsia is a successor, not a competing project, strictly speaking. It would be the "gauntlet" scenario if Google was running multiple ongoing projects all competing to "inherit" Android (which quite possible it does...)
I know of several other prominent examples, but can't mention by name because I'd be breaking an NDA.
Also, Fuchsia is a successor, not a competing project, strictly speaking. It would be the "gauntlet" scenario if Google was running multiple ongoing projects all competing to "inherit" Android (which quite possible it does...)
I've heard that Intel used to do this. They would have separate teams working on next gen chips. Eventually they'd have a bake off and pick a winner and the rest would get written off as R&D. I'm guessing they at least pick up some learnings from the dead projects.
This is often called the NASA approach since they've hired multiple companies to provide the same component many times. Then they use the best one.
If we still look at the messaging example, I honestly think this theory (if that really is what Google is doing) is backfiring spectacularly - the fragmented messaging standards mean that most Android users communicate using SMS, which is a laughably bad protocol in 2018. iMessage - boring old non-developed by a "startup" style-team iMessage - is so much better that I've often contemplated switching to iOS for that reason only.
The funny part is that they might be actually emulating an entire marketplace entirely within one company, but it often seems like it's a marketplace where a large entrenched lowest common denominator is the option that everyone uses and dislikes.
The funny part is that they might be actually emulating an entire marketplace entirely within one company, but it often seems like it's a marketplace where a large entrenched lowest common denominator is the option that everyone uses and dislikes.
I wonder if you look at the stats whether or not SMS is actually the most popular form of communication on Android. I live in the US, where I use iMessage and SMS is the most popular, but I hear all the time on Reddit that no one uses SMS outside stupid America and everyone uses WhatsApp/Signal/(Chinese one I'm forgetting).
Google needs to pick one, no doubt, but I wonder how relevant it is that they do (Android has much of its market share outside the US).
Google needs to pick one, no doubt, but I wonder how relevant it is that they do (Android has much of its market share outside the US).
This is a fair point, and I wouldn't be surprised if what you are saying is correct.
That said, saying "Google's startups-within-a-big-company strategy has driven most users outside of Google's chat ecosystem entirely" isn't a whole lot better.
That said, saying "Google's startups-within-a-big-company strategy has driven most users outside of Google's chat ecosystem entirely" isn't a whole lot better.
It depends on the country. Some places you have to pay per SMS, some places it's free. SMS cannot be sent across borders, a big problem when traveling or living abroad.
WhatsApp is free SMS, from and to anywhere. It's an attractive offer for most of the world.
WhatsApp is free SMS, from and to anywhere. It's an attractive offer for most of the world.
SMS can be sent across borders in most of the world.
And you'll be charged as much as $1 per SMS for doing that.
Can confirm, in Germany, where Android is >75%, everybody uses WhatsApp (iOS users, too).
All major OS have gone kernel changes over time. Windows,MacOS,now Android. Simple. Of course, lots of other factors as well like Oracle lawsuit.
Taken from reddit: I don't think it will be "starting over," just a major platform change. Imagine Fuchsia being Android 13.0. Every OS maker does a major platform rewrite along these lines eventually.
Windows moved from DOS to the NT kernel.
Apple moved from the classic Mac OS nanokernel (is this the right name?) to the Unix-like XNU kernel with OS X.
Google could trade Linux for Fuchsia's kernel.
These projects are always codenamed something else at first. They always come with big compatibility problems that are overcome with time or emulation layers. Sometimes there are major UI changes, sometimes the UI is built to closely replicate the old OS, but everyone does a huge "reboot" transition like this eventually.
Taken from reddit: I don't think it will be "starting over," just a major platform change. Imagine Fuchsia being Android 13.0. Every OS maker does a major platform rewrite along these lines eventually.
Windows moved from DOS to the NT kernel.
Apple moved from the classic Mac OS nanokernel (is this the right name?) to the Unix-like XNU kernel with OS X.
Google could trade Linux for Fuchsia's kernel.
These projects are always codenamed something else at first. They always come with big compatibility problems that are overcome with time or emulation layers. Sometimes there are major UI changes, sometimes the UI is built to closely replicate the old OS, but everyone does a huge "reboot" transition like this eventually.
Different sources will have different spins. Surely the Fuchsia team wouldn't think they're in glorified daycare, it's unlikely their superiors would tell journalists they are.
Yup and if it turns out there are advantages to transition it into a real project.
"It’s a senior-engineer retention project."
First time I've ever heard this phrase. It's funny because it's true.
First time I've ever heard this phrase. It's funny because it's true.
HP, Xerox, and AT&T figured that out decades ago.
> "The company must also settle some internal feuds. Some of the principles that Fuchsia creators are pursuing have already run up against Google’s business model. Google’s ads business relies on an ability to target users based on their location and activity, and Fuchsia’s nascent privacy features would, if implemented, hamstring this important business. There’s already been at least one clash between advertising and engineering over security and privacy features of the fledgling operating system, according to a person familiar with the matter. The ad team prevailed, this person said."
> The ad team prevailed, this person said.
Of course they did.
A controversial idea, but you know how much easier this would be for everyone if Google offered an option for users to be paid for volunteering your information to them? It's a precedent most fledgling ad companies wouldn't be able to match... even if it's just a few dollars a month, or maybe 30ish bucks a year. It'd cut into Google's bottom line, but it would eradicate the competition.
And then on top of that, you've got the security and privacy wins by baking the product to be secure by default but allowing consumers to accept a paycheck to disable some of it for Google. That risk calculus works for plenty of people (if not for myself).
Google's wins:
• Security and Privacy by default
• Dismantling start-up competition who can't afford to pay for the data they harvest
• Growing marketshare.
Drawbacks:
• Immediate hit to Google's revenue stream
• Permanent assignment of value to data in the perception of consumers
The only big outstanding risk would be posed by rivals with large warchests able to subsidize a similar payment scheme, but honestly once that's done, the winner is a public which now has the ability to monetize their data.
Of course they did.
A controversial idea, but you know how much easier this would be for everyone if Google offered an option for users to be paid for volunteering your information to them? It's a precedent most fledgling ad companies wouldn't be able to match... even if it's just a few dollars a month, or maybe 30ish bucks a year. It'd cut into Google's bottom line, but it would eradicate the competition.
And then on top of that, you've got the security and privacy wins by baking the product to be secure by default but allowing consumers to accept a paycheck to disable some of it for Google. That risk calculus works for plenty of people (if not for myself).
Google's wins:
• Security and Privacy by default
• Dismantling start-up competition who can't afford to pay for the data they harvest
• Growing marketshare.
Drawbacks:
• Immediate hit to Google's revenue stream
• Permanent assignment of value to data in the perception of consumers
The only big outstanding risk would be posed by rivals with large warchests able to subsidize a similar payment scheme, but honestly once that's done, the winner is a public which now has the ability to monetize their data.
What would be better is the ability to pay for Google not to sell your data. However, the new problem would be making sure they aren't selling your data, anyway.
Google Contributor: https://contributor.google.com/v/marketing
'allow us to track you across the web, so we can stop showing you ads on publishers that are in our network, once you pay for this privilege'
That does not include Google's services and only includes a handful of sites.
I also see nothing about not still collecting information about you. It appears to just remove showing you some ads.
I also see nothing about not still collecting information about you. It appears to just remove showing you some ads.
Google doesn't sell your data. Advertisers pay Google to deliver their ads to the demographic they want to target.
Right. They don’t sell our data, they rent us out to the highest bidder.
Much better.
Much better.
It is much better, considering there are companies that do actually sell our data.
"rent us out to the highest bidder" is the perfect description of Google and FB's business model. It's hard to imagine how either company could change course at this point, even if they wanted to.
"rent us out to the highest bidder" is the perfect description of Google and FB's business model. It's hard to imagine how either company could change course at this point, even if they wanted to.
Exactly, people lovw to give a negative spin to 'rent','bid'. I see it as an exchange of value. Data, money both serve same purpose: we give them vakue,they give back. My data helps them improve their systems, make recommendation engine etc. and they give me services in return. Making sense of vast troves of data is their main competency or of any internet service. Would YouTube be relevant without recommendations? Just open incognito mode in YouTube and find out! One thing they could do in future is maybe allow users to store their data somewhere locally,and which gets updated with new recommendations,profilinf info; but that'll involve losts of code changes, engineering challenges i suppose.
I think part of the issue is inequity. I don't have the requisite skills to even begin to do the calculations, but I expect that Google is getting way more (monetary) value out of me than I am getting out of their recommendations. Especially when their recommendations have often been for videos that they know I've already recently watched.
Even if there is nothing wrong with the business model, the "prices" can still be unfair. A lot of the values of these things are inherently difficult, if not impossible, to calculate (at least seemingly).
Even if there is nothing wrong with the business model, the "prices" can still be unfair. A lot of the values of these things are inherently difficult, if not impossible, to calculate (at least seemingly).
How is that not better?
Well, at least they don't let governments have free unfettered access to their users data.
Isn't the competition already mostly eradicated, except for Facebook? The other ad companies are orders of magnitude smaller.
It would be too expensive. Google is making $40 every time someone clicks on many categories of ads. They probably have users generating them thousands of dollars a year.
I’ve got a better idea. Google could always ship a product that people are willing to pay enough for where it is a sustainable business without being as supported.
Google is a consumer software company. Consumers aren't willing to pay for software.
The article is not about standalone software. It is about an operating system that will be used to sell hardware. Apple is proof that consumers are willing to pay enough for hardware to keep a company profitable.
They could and it would make them a few million dollars, not billions of dollars.
Selling hardware products that people want without advertising or collecting user data unnecessarily seems to be making Apple slightly more than a “few million”.....
> I’ve got a better idea.
Except that is an awful idea.
Except that is an awful idea.
Since when was it an awful idea to sell something that the market valued enough for a company to make a profit without subsidizing the product with ads?
There are many such companies you can go to. For instance, go here: www.microsoft.com, but also www.apple.com, and so on.
Attempting to out-compete those companies has not historically been a very successful tactic. I think that's what's meant.
Attempting to out-compete those companies has not historically been a very successful tactic. I think that's what's meant.
We aren’t talking about a little unknown poorly funded startup. We are talking about Google.
Even on the other end of the scale,I subscribe to Backblaze and Evernote.
Even on the other end of the scale,I subscribe to Backblaze and Evernote.
>but you know how much easier this would be for everyone if Google offered an option for users to be paid for volunteering your information to them?
Have you not seen their Opinion Rewards app for Android? They do precisely that.
Have you not seen their Opinion Rewards app for Android? They do precisely that.
That's a wholly different context. In that context, you're not selling usage data, you're selling conscious opinions/preferences. More than anything, all that does is confirm the assumptions Google is already making about your tastes based on your usage.
This is about valuing the usage data itself that's passively collected on the Android platform.
This is about valuing the usage data itself that's passively collected on the Android platform.
Is it ? Google provides free functionality, like a (pretty nice) mail client in the cloud in trade for mail usage data.
Those things go, outside of Google, for 2$/month minimum, and more often 10$ per month ...
Similar things go for Google's index of the web, phone operating system, ...
Those things go, outside of Google, for 2$/month minimum, and more often 10$ per month ...
Similar things go for Google's index of the web, phone operating system, ...
The real indicator of how outsized the value is compared to the perception of such is the revenue inflow.
There's no reason for the suppliers of raw materials here not to raise their prices (from zero). If anyone wants to provide it for less, so be it, but given that Google wants insight into everyone marketable, there's no reason for people not to raise their own prices for the data they supply.
There's no reason for the suppliers of raw materials here not to raise their prices (from zero). If anyone wants to provide it for less, so be it, but given that Google wants insight into everyone marketable, there's no reason for people not to raise their own prices for the data they supply.
They already do this-it's called Google Opinion Rewards and it's how I feed my Clash Royale habit.
> Immediate hit to Google's revenue stream
but maybe only a temporary one. after knifing the babies (i mean honestly outcompeting the startups), Google could discontinue that option and stop all the payments.
at least for a while, until a fresh crop of foolhardy competitors boldly entered that market again.
but maybe only a temporary one. after knifing the babies (i mean honestly outcompeting the startups), Google could discontinue that option and stop all the payments.
at least for a while, until a fresh crop of foolhardy competitors boldly entered that market again.
The main reason why this won't work is that majority of public simply prefers free ad-infested services over paid ad-free ones. Case in point - YouTube Red and it's abysmal adoption rate.
One might reasonable argue that YT Red just removes ads, but doesn't do anything for privacy / data collection. But I have two questions for them: 1. what makes you think people would gladly pay for privacy (any glaring example)? , 2. even if Google were to offer such an option, would you trust it?
One might reasonable argue that YT Red just removes ads, but doesn't do anything for privacy / data collection. But I have two questions for them: 1. what makes you think people would gladly pay for privacy (any glaring example)? , 2. even if Google were to offer such an option, would you trust it?
> The main reason why this won't work is that majority of public simply prefers free ad-infested services over paid ad-free ones.
Counterpoint: Apple, one of the most profitable companies.
People have been giving their money to Apple before they even flaunted a strong pro-privacy stance, and I have yet to see an ad from Apple that I did not opt in for (although their recent Apple Pay emails have been slightly annoying, given that I'm in a country where I cannot use Apple Pay but there's no option to opt-out from only Apple Pay related emails while still receiving offers for other Apple services.)
Counterpoint: Apple, one of the most profitable companies.
People have been giving their money to Apple before they even flaunted a strong pro-privacy stance, and I have yet to see an ad from Apple that I did not opt in for (although their recent Apple Pay emails have been slightly annoying, given that I'm in a country where I cannot use Apple Pay but there's no option to opt-out from only Apple Pay related emails while still receiving offers for other Apple services.)
Hence the phrase: "majority of public"
Rich people with lots of disposable income would, not surprisingly, prefer quality for a higher price. But that is not the business model of Google, nor is it applicable for everyone.
Rich people with lots of disposable income would, not surprisingly, prefer quality for a higher price. But that is not the business model of Google, nor is it applicable for everyone.
Please, people don’t buy apple stuff because apple cares for privacy. People buy apple because its products are top notch quality wise.
I don’t buy Apple products because of privacy. I buy Apple products because the alternative in the consumer market -Windows and Android feel like a flea market where Im constantly being advertise to. I like Apple’s business model. I give them money and they give me stuff. Too many other companies sell hardware subsidized by ad sales. For instance, I would gladly pay more for my Roku devices to avoid advertising on the home screen and paid for placement on the remote. I have three Roku TVs but I still use my attached AppleTV devices more often than the Roku apps for just that reason.
People willing to accept money for their data are useless as advertising targets, because they have already proven that something is wrong about them, and that they have less money than others.
Would be nice if there were a competitor mobile platform to iOS that wasn't built from the ground up to sell you advertising based on personal data. I guess Blackberry was the last mobile OS that didn't need to know every detail of my pissing habits.
Sure, but Blackberry - specifically, the BBM service - had no qualms about setting up intercepting proxies with governments when pressured.
Blackberry gave the RCMP a global decryption key[0], then defended the practice[1]. Given the chance, they probably would have sold out their users as well.
[0] https://news.vice.com/article/exclusive-canada-police-obtain...
[1] http://blogs.blackberry.com/2016/04/lawful-access-corporate-...
[0] https://news.vice.com/article/exclusive-canada-police-obtain...
[1] http://blogs.blackberry.com/2016/04/lawful-access-corporate-...
I take it you have a different problem with iOS? It seems to be pretty good on privacy, at least.
Nope, I like competition, and until I see some I'll stick with iOS. They're way better on privacy than others.
When we are in our nursing homes later in life we will get to hear some interesting stories about the creation of these world changing technologies in a middle of the afternoon radio show.
I often wonder what kind of amazing company Google could be if only their cash cow was not from advertising, but something neutral and profitable like AT&T was to foster Bell Labs.
> The ad team prevailed, this person said.
Sure, don't they make >95% of all google profits.
Sure, don't they make >95% of all google profits.
> "Switching away from Android could provide Google the opportunity to hit the reset button on any mistakes they believe they made a decade ago,". "They might be able to regain some power that they’ve ceded to device manufacturers and telecom carriers."
How making a new OS achive this? What kind of problems Fuchsia could solve when Linux can’t solve?
I personally hope Fuchsia would remain as an experimental project. A new non-GPL OS by a big player like Google is a bad news for hardware dev and enthusiasts from XDA. This will make hardware driver developments more fragmented and closed-source.
Smartphone manufacturers are trying to hide their kernel and device drivers, even they are using Linux. Imagine there are no legal restrictions to hide those.
How making a new OS achive this? What kind of problems Fuchsia could solve when Linux can’t solve?
I personally hope Fuchsia would remain as an experimental project. A new non-GPL OS by a big player like Google is a bad news for hardware dev and enthusiasts from XDA. This will make hardware driver developments more fragmented and closed-source.
Smartphone manufacturers are trying to hide their kernel and device drivers, even they are using Linux. Imagine there are no legal restrictions to hide those.
One of Android's major headaches is that Linux does not have a stable driver interface. Interfaces within linux change regularly, but only drivers that are checked into the main tree are updated. If you maintain a driver outside of that tree, you will experience pain. That's how Android operated and why it's linux kernel rarely changed (and why doing OS updates for phones was so hard).
Android has been trying to fix this with treble[0], which will make many more phones get OS updates going forward. So Android has attempted to work around one of linux major problems.
Another large problem is that Linux was designed for desktop architectures. It's design and focus continues to go that way. This has impact across an entire range of functionality that an OS is supposed to bring.
Fuschia seems to be a research project with a focus on mobile/laptop type devices. It could care less about server type environments, which lets it make different tradeoffs in design.
[0] https://source.android.com/devices/architecture/
Android has been trying to fix this with treble[0], which will make many more phones get OS updates going forward. So Android has attempted to work around one of linux major problems.
Another large problem is that Linux was designed for desktop architectures. It's design and focus continues to go that way. This has impact across an entire range of functionality that an OS is supposed to bring.
Fuschia seems to be a research project with a focus on mobile/laptop type devices. It could care less about server type environments, which lets it make different tradeoffs in design.
[0] https://source.android.com/devices/architecture/
"That's how Android operated and why it's linux kernel rarely changed "
Android changed Linux kernels with every single release, from 2.6.27 to 4.10 by core release, and vendors often update kernels incrementally in between. Any driver issues are trivial to change presuming they didn't come in a binary blob and the source refused any further changes, which is supposedly the case with Qualcomm hardware in the Nexus 6, for instance.
"Android has been trying to fix this with treble[0]"
Treble is about the intra-Android interfaces, not Linux device interfaces. This is about Google doing large scale, breaking changes that made vendors just throw up their hands.
"Another large problem is that Linux was designed for desktop architectures"
Nope.
The reality is that everyone always thinks they can rebuild it better. Second (Third, Fourth, etc) system effect. It the very basis of NIH syndrome. So some small group at Google wants to research OS'. Whatever. The likelihood that this replaces Android, or that it is in anyone's imaginations that it actually will besides content writers outside of Google, seems very low.
Android changed Linux kernels with every single release, from 2.6.27 to 4.10 by core release, and vendors often update kernels incrementally in between. Any driver issues are trivial to change presuming they didn't come in a binary blob and the source refused any further changes, which is supposedly the case with Qualcomm hardware in the Nexus 6, for instance.
"Android has been trying to fix this with treble[0]"
Treble is about the intra-Android interfaces, not Linux device interfaces. This is about Google doing large scale, breaking changes that made vendors just throw up their hands.
"Another large problem is that Linux was designed for desktop architectures"
Nope.
The reality is that everyone always thinks they can rebuild it better. Second (Third, Fourth, etc) system effect. It the very basis of NIH syndrome. So some small group at Google wants to research OS'. Whatever. The likelihood that this replaces Android, or that it is in anyone's imaginations that it actually will besides content writers outside of Google, seems very low.
> Interfaces within linux change regularly, but only drivers that are checked into the main tree are updated.
This is why all of the Google's code sits in one big repo (reportedly). It allows them to refactor all dependent code at once when changing interfaces.
This is why all of the Google's code sits in one big repo (reportedly). It allows them to refactor all dependent code at once when changing interfaces.
> How making a new OS achive this? What kind of problems Fuchsia could solve when Linux can’t solve?
The problems they are likely trying to solve are business and legal, not technical. Pesky things like not having to release keys bits of code under a 'free' license (i.e. they have no choice but to release any changes to the Linux kernel under GPL as that's what it requires.) Sure, they'll probably still release large chunks of source code (possibly under MIT/BSD, possibly under a less liberal license) but keep strategic bits closed source. Right now they have to do this via the clunky and somewhat obvious Google Play services layer. And then there's the constant potential exposure to lawsuits. etc.
By being able to decide on what pieces would be released under what licenses, it would allow them to prevent competitors from following in their footsteps as Amazon and various Chinese companies have done with Android. Things like this are the reason Samsung (one of Google's largest problems) keep pushing forward with their Tizen platform so that when the shift comes they have the ability to sidestep it if they want to.
The problems they are likely trying to solve are business and legal, not technical. Pesky things like not having to release keys bits of code under a 'free' license (i.e. they have no choice but to release any changes to the Linux kernel under GPL as that's what it requires.) Sure, they'll probably still release large chunks of source code (possibly under MIT/BSD, possibly under a less liberal license) but keep strategic bits closed source. Right now they have to do this via the clunky and somewhat obvious Google Play services layer. And then there's the constant potential exposure to lawsuits. etc.
By being able to decide on what pieces would be released under what licenses, it would allow them to prevent competitors from following in their footsteps as Amazon and various Chinese companies have done with Android. Things like this are the reason Samsung (one of Google's largest problems) keep pushing forward with their Tizen platform so that when the shift comes they have the ability to sidestep it if they want to.
I'm really suprised the article didn't mention anything about Tizen. For Google, Tizen looks like a big issue. At some point in the future, their biggest hardware seller, Samsung, will start switching all of their devices to running on Tizen and other partners in the Tizen Association (from wikipedia) are Fujitsu, Huawei, Intel, KT, NEC Casio, NTT DoCoMo, Orange, Panasonic, Samsung, SK Telecom, Sprint. Google's going to have to get very aggressive with Fuchsia to compete with Tizen.
Tizen has been 6 years now and there is almost zero percentage of smartphone market and it has become only for Samsung products (look at the association list. Huawei is the only big consumer device company). This would never threat Google.
no stable driver interface, they are still learning how to cope with this.
There is a ton of cruft in the APIs, like any large project would have.
One of the engineer in the Android framework team described creating APIs as generating future regrets.
Some of the mistakes are pretty small. Like internally the system reuse drawable instances in order to save memory, but instead of making this process entirely automatic, before calling let's say `setTint(color)`, you need to call `mutate()` so the UI framework spins a copy of the drawable for you. it would have been easy to integrate this behavior by default without having you know about mutate but since it was done differently, this behavior has been preserved in order to do not break retrocompatibility.
There are many small API issues like this. Big issues of course are corrected but often preserve the old behavior in case you are targetting an old version of the OS.
The View system is incredibly complex. Some of it is due to the inherent complexity of the problem, but some of it is due to the constraints of the time and some decisions that could have been better.
So there are many things you can improve by restarting from scratch and it is often easier than having to deal with the legacy APIs too.
There is a ton of cruft in the APIs, like any large project would have.
One of the engineer in the Android framework team described creating APIs as generating future regrets.
Some of the mistakes are pretty small. Like internally the system reuse drawable instances in order to save memory, but instead of making this process entirely automatic, before calling let's say `setTint(color)`, you need to call `mutate()` so the UI framework spins a copy of the drawable for you. it would have been easy to integrate this behavior by default without having you know about mutate but since it was done differently, this behavior has been preserved in order to do not break retrocompatibility.
There are many small API issues like this. Big issues of course are corrected but often preserve the old behavior in case you are targetting an old version of the OS.
The View system is incredibly complex. Some of it is due to the inherent complexity of the problem, but some of it is due to the constraints of the time and some decisions that could have been better.
So there are many things you can improve by restarting from scratch and it is often easier than having to deal with the legacy APIs too.
Then, of course, there's this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I would argue there's a difference between "rewriting the project" and "building something new based on additional decades of experience in the domain". Taken too literally, your comment suggests we should never e.g. write a new filesystem. Should Apple have taken Joel's advice and stuck with HFS+ forever? Sometimes the world changes enough that you can't keep grafting onto the old system, and need a new one.
I don't know if Linux/Fuchsia meets those criteria, but given that there are extremely smart people at Google working on it, I would think that it's at least plausible.
I don't know if Linux/Fuchsia meets those criteria, but given that there are extremely smart people at Google working on it, I would think that it's at least plausible.
So much this.
IF you consider that there are some fundamental flaws in the Android Framework at the surface level, either oversights or just based on what the landscape looked like 10 years ago, then we have to reach a tipping point where it makes more sense to do a full rewrite than to continue building on this codebase.
FWIW, there are major incremental improvements made at each release, most of them with very few changes to the high level APIs.
The VM itself evolves at each release and has even been completely replaced from Dalvik to ART. The permission system has moved from install time (designed by engineers .. ) to iOS-like incremental runtime permissions.
Not everything can be updated that way though. So it might be worth redesigning the OS with better assumption about its usage and by totally rewriting the APIs from scratch in order to avoid the mistakes made by Android (of course Fuchsia will also make some mistakes in its APIs .. all immense projects do, it does not mean that it can't improve on Android)
And I don't think the OP article applies very neatly here. Android is still being worked on and is constantly improved. We are not in a situation where Android's development is going to freeze for 5 years while Fuchsia is being worked on. Completely different teams work on the 2 projects.
If anything, Fuchsia has a lot of pressure in order to catch up with Android. And it might want to start supporting kotlin so that the dev experience gap is not too wide and to add an Android VM for retrocompat before starting to consider competing with Android.
IF you consider that there are some fundamental flaws in the Android Framework at the surface level, either oversights or just based on what the landscape looked like 10 years ago, then we have to reach a tipping point where it makes more sense to do a full rewrite than to continue building on this codebase.
FWIW, there are major incremental improvements made at each release, most of them with very few changes to the high level APIs.
The VM itself evolves at each release and has even been completely replaced from Dalvik to ART. The permission system has moved from install time (designed by engineers .. ) to iOS-like incremental runtime permissions.
Not everything can be updated that way though. So it might be worth redesigning the OS with better assumption about its usage and by totally rewriting the APIs from scratch in order to avoid the mistakes made by Android (of course Fuchsia will also make some mistakes in its APIs .. all immense projects do, it does not mean that it can't improve on Android)
And I don't think the OP article applies very neatly here. Android is still being worked on and is constantly improved. We are not in a situation where Android's development is going to freeze for 5 years while Fuchsia is being worked on. Completely different teams work on the 2 projects.
If anything, Fuchsia has a lot of pressure in order to catch up with Android. And it might want to start supporting kotlin so that the dev experience gap is not too wide and to add an Android VM for retrocompat before starting to consider competing with Android.
>What kind of problems Fuchsia could solve when Linux can’t solve?
I doubt this is really a big deal for Google, but a capabilities based OS lends itself a bit better to the mobile OS security model.
I doubt this is really a big deal for Google, but a capabilities based OS lends itself a bit better to the mobile OS security model.
https://spectrum.ieee.org/tech-talk/computing/software/a-mod...
There's basically nothing new in the Bloomberg article.
There's basically nothing new in the Bloomberg article.
This Bloomberg article has several shortcomings.
1. "Android and Chrome OS are built on Linux, a widely used open-source programming language."
Here they mix up the Linux kernel with the Java programming language.
2. "Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is owned by Oracle Corp., is at the center of a lengthy, bitter lawsuit between the two companies. Shifting away from using Linux would help Google’s legal case that its software isn’t reliant on Oracle."
While here they mix up the Java programming language with the Linux kernel.
1. "Android and Chrome OS are built on Linux, a widely used open-source programming language."
Here they mix up the Linux kernel with the Java programming language.
2. "Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is owned by Oracle Corp., is at the center of a lengthy, bitter lawsuit between the two companies. Shifting away from using Linux would help Google’s legal case that its software isn’t reliant on Oracle."
While here they mix up the Java programming language with the Linux kernel.
I agree. Some other snippets
> In the code pages, the Googlers working on Fuchsia specify that the software is not finalized.
Really, that needed to be said? An operating system with no practical use or implementation isnt finished? None of the ones in mass use right now are "finished."
>This means Google’s latest services only reach a fraction of Android users.
Google Play Services were split out from the OS back in 2013. https://arstechnica.com/gadgets/2013/09/balky-carriers-and-s... The author repeatedly tries to paint Android as a monolith held back by hardware manufacturers, and google, for the most part has split what we know as Android into two layers, and has fullll control of one of those two.
>"Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is distributed by Oracle Corp., is at the center of a lengthy, bitter lawsuit between the two companies. Android was also built using Java software technology, which Oracle owns and has claimed Google stole to shore up its mobile business."
Even after a correction, the article still claims Oracle has sued Google over Linux! (Not sure if your copy/paste is from after the correction.) The author demonstrates no understanding of the difference between the Linux Kernel, Common Libraries, Android Runtime, Android Application Framework, and Google Services. Moving from Linux doesnt mean replacing the Runtime or Services. Completely separate layers. Oracles disupte is over the Runtime not Linux.
> In the code pages, the Googlers working on Fuchsia specify that the software is not finalized.
Really, that needed to be said? An operating system with no practical use or implementation isnt finished? None of the ones in mass use right now are "finished."
>This means Google’s latest services only reach a fraction of Android users.
Google Play Services were split out from the OS back in 2013. https://arstechnica.com/gadgets/2013/09/balky-carriers-and-s... The author repeatedly tries to paint Android as a monolith held back by hardware manufacturers, and google, for the most part has split what we know as Android into two layers, and has fullll control of one of those two.
>"Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is distributed by Oracle Corp., is at the center of a lengthy, bitter lawsuit between the two companies. Android was also built using Java software technology, which Oracle owns and has claimed Google stole to shore up its mobile business."
Even after a correction, the article still claims Oracle has sued Google over Linux! (Not sure if your copy/paste is from after the correction.) The author demonstrates no understanding of the difference between the Linux Kernel, Common Libraries, Android Runtime, Android Application Framework, and Google Services. Moving from Linux doesnt mean replacing the Runtime or Services. Completely separate layers. Oracles disupte is over the Runtime not Linux.
> Here they mix up the Linux kernel with the Java programming language.
I parsed that comma as an "and".
> While here they mix up the Java programming language with the Linux kernel.
Did they? It might be implied that Google is dropping Java as well. Indeed other sources seem to suggest this is their strategy[1], [2], [3], [4]
My experiences with Bloomberg writers is that they're not lazy, but they elide a great deal of specificity to focus on the business effects and brands instead of technical bits and bobs.
[1]: https://www.theregister.co.uk/2017/11/21/android_the_next_10...
[2]: https://www.quora.com/Is-Google-implictly-going-to-drop-Java...
[3]: https://rethinkresearch.biz/articles/google-reveals-more-fuc...
[4]: https://www.androidauthority.com/we-compiled-fuchsia-os-7104...
I parsed that comma as an "and".
> While here they mix up the Java programming language with the Linux kernel.
Did they? It might be implied that Google is dropping Java as well. Indeed other sources seem to suggest this is their strategy[1], [2], [3], [4]
My experiences with Bloomberg writers is that they're not lazy, but they elide a great deal of specificity to focus on the business effects and brands instead of technical bits and bobs.
[1]: https://www.theregister.co.uk/2017/11/21/android_the_next_10...
[2]: https://www.quora.com/Is-Google-implictly-going-to-drop-Java...
[3]: https://rethinkresearch.biz/articles/google-reveals-more-fuc...
[4]: https://www.androidauthority.com/we-compiled-fuchsia-os-7104...
1. No they didn't. They incorrectly used the word language instead of Kernel. Chrome Os is not built with Java.
2. Correct
2. Correct
Imagine the horrors if Oracle "owned" Linux...
Then I’m sure Unix or FreeBSD would be more prevalent for servers.
Well, they did their share of contributions
http://www.oracle.com/technetwork/server-storage/linux/techn...
As for Java, if Google actually cared to get away with their actions, they could have bought Sun.
Surely it would have been cheaper than what they already paied their lawyers.
http://www.oracle.com/technetwork/server-storage/linux/techn...
As for Java, if Google actually cared to get away with their actions, they could have bought Sun.
Surely it would have been cheaper than what they already paied their lawyers.
Well, SCO certainly tried to make that claim.
Well, they did build JavaOS.
https://en.wikipedia.org/wiki/JavaOS
https://en.wikipedia.org/wiki/JavaOS
That first mistake isn't in the article anymore, but the second is.
For those of you who want more information, and especially more accurate information, check out Fuchsia Fridays: https://9to5google.com/guides/fuchsia-friday/
Thanks for your support.
Apparently it uses a micro kernel, zircon.
I'm curious about this kernel, honestly making something new from the ground up doesn't seem like a good idea.
I wonder how much of an advantage it was for android to use linux as a kernel, but I guess it was a gigantic advantage, which let them focus on what mattered in the development of android.
Other question: any kernel/OS developer here to explain if a micro kernel makes his job easier or harder? Having the flexibility of a micro kernel seems good, but I'm not sure it's that much important.
I'm curious about this kernel, honestly making something new from the ground up doesn't seem like a good idea.
I wonder how much of an advantage it was for android to use linux as a kernel, but I guess it was a gigantic advantage, which let them focus on what mattered in the development of android.
Other question: any kernel/OS developer here to explain if a micro kernel makes his job easier or harder? Having the flexibility of a micro kernel seems good, but I'm not sure it's that much important.
> making something new from the ground up doesn't seem like a good idea.
It isn't actually terribly difficult, the most difficult part being driver support. By using Linux as a base, Google gained a lot of driver support by default, among other things like a well-known base environment.
> explain if a micro kernel makes his job easier or harder
Well, a microkernel usually has well-defined interfaces that allow drivers to communicate with the kernel, instead of these interfaces being decided by the compiler at compile-time. This in turn offers the guarantees of "ABI/API stability" that the Linux kernel usually offers to userspace programs: drivers don't need to be recompiled to work with a new kernel, so you can actually have binary drivers that continue to "work" long after the vendor stopped working on them. This also offers more room for stability guarantees (a driver that crashes can be restarted, as it's not the kernel panicking), and security (drivers don't have access to each other's data).
On the other hand, you trade a bit of performance and flexibility (from the developer's perspective) for this, by committing not to break compatibility. By now, advantages and inconvenient of microkernels vs monolithic ones are well understood and documented.
What's in for Google is mostly licensing-related: since they're making it; they are free to pick their favourite license. And I am pretty sure Google has been uncomfortable with the GPL for a while now. The same could be said about its hardware partners, and manufacturers that have to provide the source code for their drivers (when they comply at all).
Since a GPL kernel is one of the best things that happened to Android so far (allowing custom roms, open source projects, more transparency), I am extremely weary of fuschia, and looking forward to postmarketos as an alternative to android.
It isn't actually terribly difficult, the most difficult part being driver support. By using Linux as a base, Google gained a lot of driver support by default, among other things like a well-known base environment.
> explain if a micro kernel makes his job easier or harder
Well, a microkernel usually has well-defined interfaces that allow drivers to communicate with the kernel, instead of these interfaces being decided by the compiler at compile-time. This in turn offers the guarantees of "ABI/API stability" that the Linux kernel usually offers to userspace programs: drivers don't need to be recompiled to work with a new kernel, so you can actually have binary drivers that continue to "work" long after the vendor stopped working on them. This also offers more room for stability guarantees (a driver that crashes can be restarted, as it's not the kernel panicking), and security (drivers don't have access to each other's data).
On the other hand, you trade a bit of performance and flexibility (from the developer's perspective) for this, by committing not to break compatibility. By now, advantages and inconvenient of microkernels vs monolithic ones are well understood and documented.
What's in for Google is mostly licensing-related: since they're making it; they are free to pick their favourite license. And I am pretty sure Google has been uncomfortable with the GPL for a while now. The same could be said about its hardware partners, and manufacturers that have to provide the source code for their drivers (when they comply at all).
Since a GPL kernel is one of the best things that happened to Android so far (allowing custom roms, open source projects, more transparency), I am extremely weary of fuschia, and looking forward to postmarketos as an alternative to android.
There's also Eelo: https://www.notebookcheck.net/Eelo-the-Google-less-Android-O...
I'd like to know how Zircon compares to L4 (implementations).
When I asked Tanenbaum at FOSDEM why he didn't pick L4 for Minix 3, he just got annoyed and seemed to think I was asking why he didn't just use the L4 OS (which doesn't exist) instead of creating Minix 3 - or something. In any case I didn't get a good answer. He could have created his own implementation if he wanted, L4 is just a specification with a few existing high quality implementations that prove the concept...
When I asked Tanenbaum at FOSDEM why he didn't pick L4 for Minix 3, he just got annoyed and seemed to think I was asking why he didn't just use the L4 OS (which doesn't exist) instead of creating Minix 3 - or something. In any case I didn't get a good answer. He could have created his own implementation if he wanted, L4 is just a specification with a few existing high quality implementations that prove the concept...
Note: I think he thought I thought L4 was an OS, I'm pretty sure he knows what L4 is.
Eventually it turned into a disadvantage for them, as chip vendors nowadays ship extremely outdated and insecure versions of Linux and the driver model doesn't allow for frequent updates.
They made a step in the right direction with Project Treble though.
They made a step in the right direction with Project Treble though.
There's a set of docs on Fuchsia that you can read about if you'd like (https://fuchsia.googlesource.com/docs/+/master/the-book/)
There's some discussion of it already on HN: https://news.ycombinator.com/item?id=16813796
Some advantages of the Fuchsia architecture over Linux for Android:
* Capability based system; applications only get access to objects, including files, directories, other processes, etc via capabilities, so they can only affect those objects they have been given access to directly. This is much better for security and isolation of applications.
* Userspace drivers with a stable ABI, or with the possibility of versioned ABIs. This could allow them to ship updates to the underlying system without waiting for vendors, reducing fragmentation.
There's some discussion of it already on HN: https://news.ycombinator.com/item?id=16813796
Some advantages of the Fuchsia architecture over Linux for Android:
* Capability based system; applications only get access to objects, including files, directories, other processes, etc via capabilities, so they can only affect those objects they have been given access to directly. This is much better for security and isolation of applications.
* Userspace drivers with a stable ABI, or with the possibility of versioned ABIs. This could allow them to ship updates to the underlying system without waiting for vendors, reducing fragmentation.
I think the idea is to let phone developers create drivers and then ignore them while Google is still able to update the rest of the OS around them.
I wrote a small Flutter app recently and rather enjoyed the experience. I'm reluctant to spend more time on the technology, though, since it seems like it has a high chance of dying out. But as I understand it, Fuchsia would have native apps written using Flutter as well, which would be great, so I really hope it does take off.
Why do you think it has a high chance of dying?
It's based on Dart, a language that already failed to take off in browsers? Just a guess.
I think it's more of an issue with it coming from and being maintained by Google. I think aversion to Dart is overrated; it's a boringly stable and straightforward language, and I'm puzzled that mobile developers aren't more open to learning it, given how Objective-C/Swift/Kotlin were languages that most had to learn for developing on their respective smartphone.
Here's a more thorough and technical overview:
https://arstechnica.com/gadgets/2018/01/googles-fuchsia-os-o...
https://arstechnica.com/gadgets/2018/01/googles-fuchsia-os-o...
This has been percolating along for a few years, no? I remember hearing vague announcements about a Fuchsia project for a while.
I don't think there's been much in the way of announcements, but yes, this has been in progress for a few years. It's being developed in the open, with a public github repo.
The source code in the open is one thing. However there are not a lot of design documents or discussions visible for the public. Therefore it's hard to follow the development and really getting an idea where the project is heading.
This was actually the main point of The Cathedral and the Bazaar; GNU was the Cathedral...
I've been wondering why so many Bloomberg articles have been on the front page recently, maybe in the last 3-6 months. This OP seems like a good example because there has been coverage of Fuchsia from more technical sources for awhile and I doubt the Bloomberg article adds much. Or is the change in frequency of Bloomberg posts just a misperception on my part? I don't have any data.
Due to Mark Gurmans track record a Bloomberg rumor on a tech companies future plans for a product are almost as trustworthy as official PR from the company. More leaks = more representation on HN.
Fuschia is well-known (in tech circles); he's not breaking a new story.
It’s possible it’s because of Gurman (the author). Mark Gurman was a big Apple journo and has great sources. Bloomberg scooped him up and he’s been at the front of big Apple rumors and Bloomberg has risen because of them. Especially after Marzipan was confirmed in macOS Mojave source code.
I also have the feeling that the amount of links to Bloomberg articles on HN significantly increased in the past months. I'm not a fan of that though, because Bloomberg articles seldomly cover really new topics or add in-depth information. Which is fine, as Bloomberg's audience is a different one than HN's, isn't it?
Well, at least they're quoting and Google source with specifics instead of just relying on source code, docs and speculation.
No matter what, We must need a new OS, encompassing big screen devices as well as small IOT devices. No more JAVA and JVM. I had loved it for 15 years but now I hate it most;
I am sick and tired of developing Android because of the huge fragmentation and poor compatibility of different screen sizes. Now is a little bit better than before in terms of that but the fundamental issue cannot be fixed from the root core unless the kernel and android jvm are replaced. Some Googler said "Android system was wrong from the beginning".
I would love to see Fuchsia in real as soon as possible. I've recently learnt Flutter, which is going to become the primary User interface SDK/framework of Fuchsia. I recommend you guys to learn Dart and Flutter if you are a UI developer. Be leaders of them. In a nutshell, Fu[lutter/chsia] is the future for mobile/embedded developers over the next 30 years in this AI/IoT era.
I can already hear professor Tanenbaum's evil laughter, followed by "I told you so" :)
Although for the life of me, I cannot figure out why Google suffers so hard from NIH syndrome and didn't go with something like seL4/Genode. Do they just want control of absolutely everything they touch?
Although for the life of me, I cannot figure out why Google suffers so hard from NIH syndrome and didn't go with something like seL4/Genode. Do they just want control of absolutely everything they touch?
I thought they started from an existing microkernel actually.
Oh so that's what the rust crates fuchsia-zircon and fuchsia-zircon-sys are for. They are dependencies of the mio and rand crates.
Cargo.toml links to https://fuchsia.googlesource.com/garnet/
Cargo.toml links to https://fuchsia.googlesource.com/garnet/
Someone please answer this... I want to learn this.
Fuschia is getting swift support Flutter runs on fuschia Flutter uses dart
Do I learn dart or swift, personally I want to learn swift. Flutter only supports dart??? Fuschia supports swift
Is flutter going to support swift
Fuschia is getting swift support Flutter runs on fuschia Flutter uses dart
Do I learn dart or swift, personally I want to learn swift. Flutter only supports dart??? Fuschia supports swift
Is flutter going to support swift
You can write software for Fuchsia without using Flutter, but Flutter is the most friendly way at present.
In a basic sense, Flutter is based in Dart, but if you want to call into another language like Swift, there is a way to do so, called FIDL. I'm not sure if Swift has FIDL bindings yet, but I'm sure that it and many other languages will, in time.
Even today Flutter has support for Swift code on iOS the same way it supports ObjC, via MethodChannels. (This is also true for Java and Kotlin code on Android.)
In a basic sense, Flutter is based in Dart, but if you want to call into another language like Swift, there is a way to do so, called FIDL. I'm not sure if Swift has FIDL bindings yet, but I'm sure that it and many other languages will, in time.
Even today Flutter has support for Swift code on iOS the same way it supports ObjC, via MethodChannels. (This is also true for Java and Kotlin code on Android.)
Have you encountered Julia, and if so, what did you think of it?
Can't say as I have. My expertise centers around Flutter and Fuchsia, for now.
> Do I learn dart or swift
I'm not terribly familiar with the landscape, but my suggestion is broadly applicable: learn both.
A developer shouldn't be constrained to a single language. Pick the one that's suitable for the project you want to work on. For the next project, do the same. In my experience you'll find it progressively easier to pick up new languages (and stacks, and paradigms, etc.) each time you do it.
IMO, a developer's goal should be to understand and implement design patterns, not individual languages.
... and for the record, I say this as someone who prefers a single language (Python) to all others I've encountered.
I'm not terribly familiar with the landscape, but my suggestion is broadly applicable: learn both.
A developer shouldn't be constrained to a single language. Pick the one that's suitable for the project you want to work on. For the next project, do the same. In my experience you'll find it progressively easier to pick up new languages (and stacks, and paradigms, etc.) each time you do it.
IMO, a developer's goal should be to understand and implement design patterns, not individual languages.
... and for the record, I say this as someone who prefers a single language (Python) to all others I've encountered.
Learn dart instead of swift.
Surely Google are setting themselves up for another $5G EU antitrust fine?
I thought one of the core reasons for the fine was the restriction in the Mobile Applications Distribution Agreement that a company couldn't develop a competing OS...
Yet Google is?
Alternatively they will use it as the core for a new "Nexus" line to compete with Apple, and not licence Fuscia as a platform (avoiding dominance of the mobile "Platform Market" by doing what Apple are doing).
I thought one of the core reasons for the fine was the restriction in the Mobile Applications Distribution Agreement that a company couldn't develop a competing OS...
Yet Google is?
Alternatively they will use it as the core for a new "Nexus" line to compete with Apple, and not licence Fuscia as a platform (avoiding dominance of the mobile "Platform Market" by doing what Apple are doing).
There was no absolute restriction on developing a competing OS (Samsung does it with Tizen for example). My understanding is that the restriction was on forking the Android codebase and shipping an OS based on that without the Play Store (you would then lose your Play Store license on all devices). Even then I'm not sure whether it's as strict as that, considering Xiaomi and others do it.
It sounds very unlikely Fuchsia will replace Android or Chrome OS. They list a bunch of Android issues, but which of these can’t be addressed more incrementally through Android?
Google probably needs fewer OSs, not more.
The idea that this is a senior engineer retention project is what actually makes sense. I think it will probably yield some useful results that can be harvested for their other systems, or perhaps it can fill a niche not already well fillled.
Google probably needs fewer OSs, not more.
The idea that this is a senior engineer retention project is what actually makes sense. I think it will probably yield some useful results that can be harvested for their other systems, or perhaps it can fill a niche not already well fillled.
Is it fair to describe this as a rewrite from scratch kind of project?
no. it's not a rewrite of android, or (at this point) android-compatible in any way.
it's a brand new operating system that google is experimenting with.
it's a brand new operating system that google is experimenting with.
It will need some form of compatibility to get a foothold in the market, though.
From what I can tell, the compatibility plan is to market flutter/dart as a cross-platform development toolkit for Android and iOS.
Fuchsia won't run android apps, but fuchsia apps will run on Android and iOS.
Fuchsia won't run android apps, but fuchsia apps will run on Android and iOS.
If you check the Zircon repo, you will see that they are backing in a linux virtualization layer in the kernel, so i imagine they will use that to bootstrap android linux apps in Fuchsia as a staging process, until android apps are completely native in a second phase.
Chrome OS already runs Android, so it would be a matter of stitching the Chrome os shell into Fuchsia to have both running in Fuchsia. First with virtualization of Linux, and later without it.
Chrome OS already runs Android, so it would be a matter of stitching the Chrome os shell into Fuchsia to have both running in Fuchsia. First with virtualization of Linux, and later without it.
There is some signal[1] that maybe Fuchsia as an OS will support Android apps out of the box. As I'm sure we both know though, ANYTHING can happen between now and the ship date.
[1] https://9to5google.com/2018/04/26/fuchsia-android-runtime-ap...
[1] https://9to5google.com/2018/04/26/fuchsia-android-runtime-ap...
PR piece = "quietly"
I am really surprised Microsoft isn't doing something like this. They are losing the OS war.
They are. The fact that HN doesn't follow it just speaks to the anti-Microsoft bias here. They've had the OneCore project back in 2015-2016 to unify the kernel and core OS pieces, which was a success and is now powering every Windows device out there from Xbox to the PC. They have the UWP, their unified app framework.
They are also working on CShell, which is a unified UI/windowing/compositing system that will work across PC, Xbox, Mobile, etc.
CShell + OneCore + UWP are essentially becoming part of a "brand new" OS they're calling Core OS, which will strip the Win32 backward compatibility requirements and just work with UWP apps, primarily targeted at devices like phones and low power tablets.
You can search Project Polaris for more information
They are also working on CShell, which is a unified UI/windowing/compositing system that will work across PC, Xbox, Mobile, etc.
CShell + OneCore + UWP are essentially becoming part of a "brand new" OS they're calling Core OS, which will strip the Win32 backward compatibility requirements and just work with UWP apps, primarily targeted at devices like phones and low power tablets.
You can search Project Polaris for more information
They're taking a different approach. They're positioning .NET to be the Platform regardless of the underlying Hardware/OS.
They tried to rewrite the OS in a C# derivative and could never meet the perf needed while still fighting backwards compatibility issues[0].
At this point mobile OS's are a lost cause, but the PC market is stable. Windows server has never been as big as Linux, but all of Azure runs the Windows hypervisor. I'm not sure they're losing at all actually.
[0]: https://en.wikipedia.org/wiki/Midori_(operating_system)
Hyper V is a type 1 hypervisor. It’s not a Windows hypervisor in any sense except that the license is bundled with Windows.
Not really, they are winning the desktop and tablets (2-1) war.
Desktops aren't going away, and Macs are pretty much an US phenomenon, alongside a couple of other countries.
Likewise, Android tablets aren't that good, with most of the apps being phone apps. Google now is playing with ChromeOS for tablets, which also remains to be seen where it goes.
So, most consumer shops around here are now mostly selling iPads and Windows 10 tablets.
Desktops aren't going away, and Macs are pretty much an US phenomenon, alongside a couple of other countries.
Likewise, Android tablets aren't that good, with most of the apps being phone apps. Google now is playing with ChromeOS for tablets, which also remains to be seen where it goes.
So, most consumer shops around here are now mostly selling iPads and Windows 10 tablets.
>Not really, they are winning the desktop and tablets (2-1) war.
According to tablet market share stats they are clearly not winning that war and not even a serious competitor.
>Likewise, Android tablets aren't that good, with most of the apps being phone apps.
Most of the Android apps I use on tablets all resize fine to use the extra space. I consider trying to use desktop apps that are not optimized for a touch interface a much worse experience.
According to tablet market share stats they are clearly not winning that war and not even a serious competitor.
>Likewise, Android tablets aren't that good, with most of the apps being phone apps.
Most of the Android apps I use on tablets all resize fine to use the extra space. I consider trying to use desktop apps that are not optimized for a touch interface a much worse experience.
We would appreciate to see the worldwide numbers of those stats.
Well, that wasn't the message being discussed at Google IO, specially at the ChromeOS sessions regarding usability.
Well, that wasn't the message being discussed at Google IO, specially at the ChromeOS sessions regarding usability.
Global tablet market share held by tablet vendors from 2nd quarter 2011 to 1st quarter 2018. Microsoft is no where to be found.
https://www.statista.com/statistics/276635/market-share-held...
https://www.statista.com/statistics/276635/market-share-held...
That marketshare is by brand, not OS.
From what I see here there are lots of Windows tablets to be had, from various vendors.
http://www.mediamarkt.de/de/category/_2in1-convertibles-5420...
https://www.saturn.de/de/category/_2-in-1-convertibles-46890...
Which are the ones actually on display when I go to those shops.
From what I see here there are lots of Windows tablets to be had, from various vendors.
http://www.mediamarkt.de/de/category/_2in1-convertibles-5420...
https://www.saturn.de/de/category/_2-in-1-convertibles-46890...
Which are the ones actually on display when I go to those shops.
StatCounter also indicates that Windows tablets have nearly no marketshare.
http://gs.statcounter.com/os-market-share/tablet/worldwide
http://gs.statcounter.com/os-market-share/tablet/worldwide
Faire enough, it just looks quite different when going into local consumer shops and what is available to buy on premises.
So I wonder where they are being bought from, is everyone getting them from Amazon?!
So I wonder where they are being bought from, is everyone getting them from Amazon?!
Microsoft and their partners do sell millions of tablets per year, it's just that their unit sales pale in comparison to Android and iOS tablets. I'm also not even sure if Microsoft calls their Surface line tablets anymore. Their product page now calls them laptops which is odd considering you sort of need the optional keyboard to be a laptop.
>So I wonder where they are being bought from, is everyone getting them from Amazon?!
Amazon accounts for good percentage of tablets sold. I bought an Amazon Fire 8 HD for $49 during Prime Day. At that price it's an instant purchase.
>So I wonder where they are being bought from, is everyone getting them from Amazon?!
Amazon accounts for good percentage of tablets sold. I bought an Amazon Fire 8 HD for $49 during Prime Day. At that price it's an instant purchase.
They've already tried. There's no interest currently for a 3rd also-ran OS, especially from a vendor that would be changing up the toolkit yet again.
They're on like their fourth attempt, aren't they? They tried Pen Windows, then Windows CE and its derivatives, then there was the ARM version of Windows 8, and now they're hoping Intel tablets running Windows 10 can become a thing.
I would have agreed with you a year or so ago. I've been on MBP for about 4 years, my next laptop is going to be a PC again.
Linux and Windows runs on personal computers
If Fushia/Flutter gets adopted, it would be a better outcome than MS botched effort with universal desktop/mobile apps. The fragmented tooling and support was like it was made by sales/marketing types rather than engineers.
Has anyone here had a good experience making a single UWP app for both mobile and desktop?
Bwauhahahaha.
Did anyone think maybe using a pinkish shade for a Second System codename is asking for it to fail?
Apple had a Project Pink back in '88 to be the successor to System Software 6. They hoped to release it in 1993, instead buying NeXT in 1997 and launching OS X in 2001: https://en.wikipedia.org/wiki/Copland_(operating_system)#Pin...
Microsoft's Project Pink was the result of their Danger acquisition. It didn't fare well either: https://en.wikipedia.org/wiki/Microsoft_Kin
I wish Google the best of luck.
Apple had a Project Pink back in '88 to be the successor to System Software 6. They hoped to release it in 1993, instead buying NeXT in 1997 and launching OS X in 2001: https://en.wikipedia.org/wiki/Copland_(operating_system)#Pin...
Microsoft's Project Pink was the result of their Danger acquisition. It didn't fare well either: https://en.wikipedia.org/wiki/Microsoft_Kin
I wish Google the best of luck.
The Fuchsia name is derived from projects the primary Fuchsia OS developers previously worked on at Apple - Project Pink and Project Purple. Pink + Purple = Fuchsia.
This article seems to have gone through multiple edits to correct all of the incorrect technical facts, but it looks like they still have work to do.
Shifting away from using Linux would help Google’s legal case that its software isn’t reliant on Oracle.
Shifting away from using Linux would help Google’s legal case that its software isn’t reliant on Oracle.
Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is distributed by Oracle Corp.
Yeah this is totally wrong.
Yeah this is totally wrong.
This has been my therory for a while. You see all these different projects competing against each other (multiple messaging apps are a good example) and you think: why is Google so unfocused? But what Google basically wants to do is hoard engineers so they don't leave and go work for competitors and make them stronger (or start their own companies that could compete against Google).
So Google's management figured out that if they give these enginners some cool stuff to work on, they'll stay at the company, even if the stuff they work on is a duplicate of something else the company has already done.