I don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble.
Google were so convinced of the value of open source that they didn't anticipate that almost all OEM's would rather ship their Android forks than to stay close to upstream. If they hadn't intervened, Android as a platform would be useless by now and app developers would need to implement various ways of handling notifications, storage access, etc just to ship their apps to a broad audience of device owners, Samsung would've never upped their update game and there wouldn't be 2-3 versions of Android on the majority of devices, but more like 5-10, depending on how many manufacturers would've survived in the market.
Android still allows for easy side loading of applications, there are still major independent after market Android versions out there, you can develop for Android in various languages, using a huge selection of IDEs and there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against. Google didn't even manage to gain any relevant market share with their Pixel line of devices, of which most run Android. They could've done a lot of nefarious things by keeping newer Android versions Pixel exclusive until they publish the source code to OEMs, for example. Instead, they are making it easier to quickly move an existing Android code base to the latest version by abstracting away a lot of the complexity (project treble).
Is Google still primarily am advertising company that tracks its users? Of course. Do they have their own motives to keep Android at the top of the mobile OS market? Of course. But a lot of the comments see evil scheming where Google probably had to act quickly to ensure that Android has a future and that developers didn't lose interest in the platform in favor of iOS.
> there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against
AFAIK these are reverse-engineered. Do you sincerely believe that developers' time is best spent reverse engineering and maintaining play services alts to undo a blockade that Google put in, just to be able to get full freedom over their android derivative? Wouldn't it be better spent in playing with cool new tech (as Google engineers seem to be doing)?
yeah there are many options but if 99.99% uses gms on android. Its majority rule as a app developer i would push other services way back down in priority.
It's not about what is possible, it's about what developers eventually pick. While some privacy-focused companies seem to use more open alternatives or even implement the system themselves, most of developers simply stick with Play Services, which makes use of many (even FOSS) apps cumbersome without them.
You can easily sideload an app, sure. But recent version of Android restricted background running of the apps, making developers dependent on push notifications, and FCM notifications won't work without Google services.
It takes about 15 seconds of googling to find out that yes, the user can decide what apps are allowed to run in the background. It's just that now, it's not "every app by default" and instead "what apps a user selects".
If instead of googling for 15 seconds you had any real experience about developing apps that need to run in the background (like I do), you would know that this 'background running' is a joke.
The only way to run an app non-stop is to have a persistent notification. And even then, apps are killed off left and right by the likes of Samsung. See https://dontkillmyapp.com for more details
It depends on the phone. Lots of problems with eg the COVID-19 exposure notification apps where firmware updates from Android OEMs were needed to whitelist the apps, the user accessible background settings weren't enough to keep them working.
> that developers didn't lose interest in the platform in favor of iOS.
Developers go where users are. Some developers sell their apps on the store, others get hired to build apps that are distributed for free to make people use services they buy outside the store. Banking, business apps, etc. It's impossible to lose interest in Android. It's too big. Compare it with Windows phone which died for lack of users.
I'm losing interest in it, for actually some of the reasons sited. Chinese manufacturers are slowing increasing market share, and their version of Android is completely broken, to the point where if you are not a major whitelisted app, you simply can't do anything unless the app is in the foreground. It's maddening.
Project Treble didn't fix anything (I'm very happy with Project Treble, because it lets me hack stuff I couldn't begin to imagine with 4 yrs ago, but that's just hack). It didn't even fix Nexus/Pixels that still have the same upgrade track record as a Samsung 100$ device. (Pixel 1 and Pixel 2 users, feel free to come and use my Generic System Image, I'll keep upgrading you as long as I can with my bare hands!)
ATM OEMs are NOT allowed to use Project Treble. There is only one OEM in the whole world that did an upgrade using Project Treble. What does this OEM have special? Well it's Meizu, they ship only in China, and doesn't care about Google certification. The certification that you say helped prevent Android from being fragmented. Turns out it actually helps fragmentation.
Meizu, Amazon, and Huawei are not Google certified. I have yet to hear developers say they are specifically worse than other Android devices. Last time I had an Android device with stupidly broken video aspect ratio (I'm a multimedia developer amongst other things), it wasn't a Meizu, Amazon or Huawei device. It was a properly certified Philips TV.
Project Treble is sincerely a superb engineering project. But the truth severely lags behind.
If you don't care about Google certification, you can upgrade an Android 8 device to Android 11 finger in the nose, keeping Android 8. It's bootable in a day, usable in a week, production ready in a month. If you care about Google certification? Well, you need to upgrades your drivers to Android 11 base, which is a non-sense when mentioning Project Treble.
How to upgrade drivers? Well it depends. Usually the first step is to upgrade your build scripts. Because well of course, every two major upgrades Android build system is "upgraded". Well, OEM got the trick, now they are building their drivers out of Android, and their build system is a giant shell script. Way to go! Makes upgrading to newer Android version much better!
Now you've managed to build your Oreo drivers into Android 11, congrats! Now let's start them! Oh, new "security" features have appeared, and now half of your code no longer works. (fdsan I believe is way more annoying that it is meant to be)
Let's not forget about Android 9 Go mess as well. (Hint: The only post-Oreo Samsung devices that didn't get their 2 upgrades are Android Go devices) Basically Google cares about RAM consumption two weeks every 2 year, so only this exact release is usable on low-end devices.
Is Google evil? I don't believe it is. Hell I believe that every Google engineers believe they are working towards a better future. However I do believe that even within Android itself, there are many units, that are (mostly unwillingly) shooting at each other's foot. So yes having AOSP is awesome, Project Treble is beyond any hope I had back then. Still, overall the improvement is far from what has been advertised.
To come back to Fuchsia, I believe it is going to be pushed to Android devices in two years (so Android T). OEMs won't have a word to say in this: Google gave a try at such a big change through GKI, and OEMs have been complying nicely, so going to Fuchsia should be pretty easy too. I'm expecting some Android features to be offloaded to Fuchsia for "security" reasons, like Window Manager, which will constraint OEMs even further down as to what they can change, because the Fuchsia "core" image will be like Google Services, mandatory Google-signed. (There'll be Fuchsia app images as well, which people will be able to do whatever they want with, but that's something else) I hope I'm wrong.
For more context, if I recall correctly, phh is the first person outside of Google to figure out this Generic System Image thing, and has been tinkering around Project Treble ever since.
(And I just learned about the GSI image for Pixel 1/2, thanks for that!)
GSI isn't specifically for Pixel 1 and 2, but they can use those, just like every other device whose OEM have abandonned them, since it is a generic image.
And not just that, Android also severely lags behind upgrading its mainline kernels, so you can't even avoid the issues by upstreaming your drivers. You have to fork them. People get mad at vendors that they don't upstream their drivers but there is currently zero benefit in that. Google should reward vendors for that, and maybe we'll start seeing more drivers upstream.
That is just Google reinventing a stable kernel API for certain drivers. It will be Android specific and will never be mainlined. Drivers that use this will probably not be part of mainline either. It is just Google splitting of from vanilla Linux and going their own way, what they want is to be able to use 5 year old drivers on new kernels.
Ah, then nothing's changed (re the messiness) since Android 2/4/5. Sounds like they're still moving toward locking down everyone's hardware to ensure their ad platform revenue.
The couple of devices I've broken down a release for and rebuilt just to clean out Trojans included in the firmware were devilishly difficult. And does it ever piss me off that there's nothing generic and updated to run on them.
As a hacker, Android feel much more free than before.
Because I can flash whichever ROM on pretty much whichever device I want. (assuming OEM didn't lock down bootloader unlock, which is pretty rare those days) I have my own ROM on small device (kTouch i9), long device (Qin 2 Pro), keyboard device (Unihertz Titan), device with a FLIR and endoscope (Ulefone Armor 9), assistant/speaker (Archos Hello 7), comfortable in hand device (Pixel 5), premium device (ROG Phone 3). Those devices (except those last two) wouldn't ever have seen custom ROM. But here we are, thanks to Project Treble, the same ROM works on all of them without breaking a sweat. Nowadays when I buy a device to hack with, the only question I have to ask is "can the bootloader be unlocked?" (small photo to make my case https://twitter.com/phhusson/status/1308299188153643008/phot... )
As a user, however, it is severely locked down. Installing apps from 3rd party app store was okay-ish years ago. Nowadays, Android just frightens you as much as possible so that you don't install 3rd party apps. The battery thing that has already been mentioned is an issue as well. Nowadays you can't even use an alternate Camera app, you have to stick to whatever OEM gave you.
Jeez. Remind me not to express an opinion on here.
Thank you for the clarification! I haven't had the extra time to tinker with the latest devices since it's a bit outside my day to day. That's a bit more nuanced and it's good to hear from someone who develops on the platform regularly.
"Is Google still primarily an advertising company that tracks its users? Of course."
A primary reason why I would choose open over closed source is the ability to avoid ads and tracking. Can the user remove all the phone home nonsense from Fuschia. Of course not. This defeats the purpose of open source for me -- control. With this, I have to share control over the computer with Google.
generate_204 is used to check if a network has internet connection or need to login at captive portal, not sure about Fuchsia but on Android if you don't want to use google server for that, you can disable the feature or change it to use a different url
https://android.stackexchange.com/questions/186993/captive-p...
Apple and Microsoft both have something similar but with their own website, and AFAIK there's no way to change the url on iOS.
But this is not always a fair label to apply. If I release a device running Android that prevents you from using your own Android, that's a problem with me and the device I released, not with Android. This seems to be conflating hardware and software -- which is understandable in the context of operating systems -- but we should be clear about the cause of the problem, which has nothing to do with the openness of the code.
What's the generate_204 thing? Low effort web searching revealed something about a default path on google services for clients to check network status. Is it more nefarious than that?
I believe they should have closed source the OS, Android being open-source is the number one reason for its fragmentation. What i dont understand is the "security" logic given by fuchsia. How is Linux less secure ? I dont think anyone starting a new kernel now can guarantee its security to be superior to Linux, because Linux had 25 yrs of evolution to where it is now. That logic is pure garbage, the real reason probably is NIH. And if Google ever actually hopes to compete with iOS technologically it better choose a superior stack and fuchsia is far from it.
I do believe building a new OS from scratch - taking the learnings of the past 25+ years into consideration - will lead to a better and safer OS. I mean for Linux they had to invent a lot of new concepts, replace a ton of things for security reasons, etc. It's secure NOW, and it was secure enough since its inception (I presume?), but it's the cumulative effect of years of polishing.
I mean search the kernel for references to use-after-free or null pointer dereference.
Since then, there's been big improvements in development practices, tooling, and languages to prevent security issues from occurring in the first place.
I think this assumes that all OS designs have equivalent levels of security, but if this is true then why are there security-focused operating systems like seL4? Also I think that without the backwards compatibility requirements of Linux, one could probably have features that improve security (eg sandboxing of some kind)
I am a Linux kernel contributor and former golang and chromium contributor and to be honest the latter experiences makes me leary about contributing to another Google project.
There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors.
The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible. Not so different with chromium.
The cathedral model is fine but be honest about it.
With the Linux kernel if you have a good idea and can defend it you have a genuine chance of contributing. So I know my limited spare time efforts aren't wasted. With fuchsia I couldn't be so sure.
I hope I am wrong but the fact they are only now taking potential contributions suggests otherwise.
> those working for the company get considerably more say and control than outside contributors
As someone who knows little about open source politics, I'm genuinely curious about how people expect this should work. What are the large open source projects that have the gold standard for this that I can learn about?
My initial reaction is that if a company contributes considerably more to a project, shouldn't they have considerable more say? For example if they have 20 full time engineers working on it and have contributed 95% of the code, then if I come along and make a few changes should I have equal say and control over the project?
I think the problem is that Google doesn’t really want or need outside collaboration in their open source projects. They have project managers that steer the ship and more than enough smart people to write code. What do they need you for?
I think that’s often the (subconscious?) attitude Google has towards its open source projects at least. Which would be fine if they didn’t try to make it seem like their OS projects are a welcome place where anyone can contribute ideas and code and move the project forward.
As an example: Angular is open source but it’s very much a Google project. Rails is also open source but it’s a broad collaboration, certainly not a “37signals project”. Most people would rather spend their time contributing to the second kind of project.
Without intending to either minimize or represent OP's opinion, my thought is the cases people get frustrated about are really unfortunate. In these cases, community opinions have been solicited -- sometimes committees are even formed -- and folks put in significant effort.
The oft-cited case with Go (and I'm paraphrasing heavily, so this account is likely unfair to everyone involved) was when Peter Bourgon formed a committee to design a Go packaging system, there were a bunch of meetings held that included core team members, and Russ apparently surprisingly came out with the Go modules proposal. The core team decided to adopt Russ' work. The team's perspective is it solved their problems simply and cleanly, and it came with an implementation. The community perspective was that the core team was now a sort of cabal.
I think the issue here isn't that the community's project was rejected, it's that there is a perception that folks were let to waste their time. It seems that sometimes people want this idealized model where an open project has a community that is on equal footing with the project owners, but I rarely see this to be the case in practice. Ultimately some individual or group holds a "voting share" that outweighs the community.
We have a documented process for system changes in Fuchsia that we have already been following internally. I've seen various proposals rejected; I've had proposals of my own rejected. It's always disappointing to have work rejected, because no matter what, it takes effort to come up, submit, and socialize work proposals. It's easy to feel slighted, especially when you're contributing for free while the folks making the decisions... well, it's their job.
I think I can say that it is nobody's goal on Fuchsia to waste folks' time. But I think it would be naive to think this kind situation couldn't or won't occur in the future. I just hope our transparency about our process and our availability to communicate with the community through lists will help mitigate negative feelings when a proposal representing a non-trivial effort is rejected.
These kind of projects are just “open washing” at that point. The source is available, but outsiders can’t meaningfully contribute stuff outside of the preordained roadmap nor is the project beholden to community consensus.
As an open source contributor, it’s very unfulfilling and disappointing to find out you’re essentially an unpaid contributor to a company project.
I'm playing Devil's Advocate here because I sympathize with your point, but isn't there a way you can squint and look at this weird that it's true of pretty much everything else? IBM makes tons of money off of Linux, for example. iXsystems profits off of FreeBSD. Facebook profits off of their wildly popular C++ libraries.
I think we really need to divorce "profit" from "open source". OSS is great because we can contribute our own ideas to it, because we can learn from it, because we can form communities around it. It's also useful because it's a vector for entrepreneurship. Edit: why should these be mutually exclusive properties?
It's fair to point out that it can be a vector for exploiting unpaid labor. But that's an accessibility issue that exists already. For example, it's easy to tell folks interested in the field to "do open source work" if they want to get a job in the field. If you're a low-income single parent, this doesn't make CS more accessible, it's a sick joke. Even without profit, open source isn't this bastion of opportunity that we sometimes like to think it is.
You make an excellent point that it's hard to learn large new systems. But it's not impossible. Indeed, it's possible to make super meaningful contributions to the system in "limited time", starting with net zero knowledge: https://blog.quarkslab.com/playing-around-with-the-fuchsia-o.... To that end, I have to disagree that we're the kind of project that outsiders can't meaningfully contribute to.
I've addressed the point of community consensus elsewhere. All I can say here is that I personally owe my career to open source, and I'm therefore committed to helping others do the same. We opened the project to communicate with people. My personal goal is to do this and help as many people as possible succeed professionally through this vector.
> IBM makes tons of money off of Linux, for example.
Personally I would rather contribute to a GPL licensed project, because if big companies try to profit of it, they will also have to release their changes. Those could improve the project, and now the community does no longer have to do themselves -> Community devs get payed back in development time that they would have to spend themselves.
With permissively licensed projects (or commercially dual-licensed), where big companies are allowed to just take and improve it internally without giving anything back to the community, a community dev would pretty much be an unpaid developer for those companies.
Strictly speaking, they only have to release their changes to people they distribute their product to. It's convenient to keep it entirely open, but not a requirement.
I agree that folks should contribute code to places they feel comfortable in any case. As I mentioned in GP, if you separate out pay, there are other reasons to work on OSS, and these motivations can coexist.
For one,they provide a major advantage to people who have enough money to be able to afford to go unpaid. And really, if a company can't or won't pay you even minimum wage (something like $500/week on the high end in the US), that should be a huge red flag.
I feel you've picked that one paragraph to focus on and ignored OP's point. Namely:
> The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible.
> The cathedral model is fine but be honest about it.
It's kind of unfortunate because existing developers have the privilege of experience with the systems and where they're going that external contributors simply don't have, and it will take a non-trivial amount time for interested parties to develop that knowledge.
At the same time, it is an active project with active development that are informed by goals and processes not all of which are open. And really, while the development has been "in the open", it hasn't engaged the public until now. To that end, it's not possible to engage in a "bazaar" approach off the bat, whether or not that's a goal of the project.
Having been active in Go development and seeing some of the issues there, I understand what you mean. I don't think we state anywhere "this is clearly a cathedral model of development", but I think we're pretty clear on it:
* We have a section of documentation detailing different kinds of contributors, acknowledging that there are kinds of contributors with special powers, and also reserving the right to revoke contribution privileges in some cases: https://fuchsia.dev/fuchsia-src/contribute/community/contrib...
To the extent that you can look at these as a set of policies, follow all the policies, submit a change, and have that change rejected, I think that is unfortunate. I think this is much less likely if you first engage with the stakeholders, and having opened up mailing lists, we've made it simpler to do that.
However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion. I can fork the repo, but that's also already the case with Fuchsia.
> the fact they are only now taking potential contributions
We were honest about this too, and our documentation used to explicitly say that we did not accept external contributions.
The real question is, moving forward, if somebody submits a proposal, properly tested, described and discussed with the community that makes a fundamental or deeper change whether that is likely to be accepted or not.
The bazaar certainly exists for the Linux kernel insomuch that this can and does happen (partly as a result of the fact many companies contribute but none control it). For go it does not, for chromium it does not seem to either.
It is tough for a company with internal aims and pressure to adhere to that kind of model for sure.
And it is good you have been honest about your approach prior to this in that no contributions were taken but now it is a matter of whether or not a non Googler has the opportunity to make such a change, in accordance with your policies.
But obviously as a hobbyist with limited free time I am understandably cautious as to where I put my effort.
Honestly on a personal level it is probably no loss on fuschia's part, I am a minor contributor at best, but the general point stands.
I understand the concern. I spent the vast majority of my career not at Google while also involved in open source communities, and I can empathize with this. I think one place we have a leg up here is that we do have documented processes for performing this type of work. It's certainly possible that the outcome of a proposal is rejection, but the hope would be the process does that quickly. We're all human and we don't want to waste anyone's time.
One of the cases that people cite for Go rejecting the community outright is the modules work. My perspective is that could've been handled better, but I didn't have a stake in that. But then I look at the error handling proposals, all rejected, including the ones originating from Googlers. And the iteration on generics, which has been reworked several times due to dissatisfaction expressed by community members of all experience levels. I think it's fair to say that even though there are deciders of what happens, they hold themselves to the same standard.
I hope you'll consider at least taking a look as a hobbyist. It's a large system, so both lots of opportunity for contribution and lots to learn. I think many of us are very eager to work with people outside the team, especially as many strive for more social interaction in general, and I know many of us are individually looking forward to welcoming external contributions. Certainly we can never find out if the process works if no one tries.
I think the important part will not be what gets rejected, but what gets accepted. Nobody will ever remember the rejected error handling or genetics proposals; but people will definitely take notice if the eventually accepted one come attached with Google names.
It's hard for an open source project started (or dominated) by a single company to shake the appearance of being insular. At this point I believe Kubernetes has major contributors from various companies, but I still mentally think of it as Google because, among other things, a bunch of the infrastructure is still Google so it feels very much like Google has dominant control. The dominant company will need to actively drum up interest and try to convince external contributors to take up the work to make it look less lop-sided.
I don't mean this as an attack on Google — getting good community governance is hard; I've also been on the dominant company side on other projects (generally not great at fostering a good external community). I believe it takes extra concerted effort.
> Nobody will ever remember the rejected error handling or genetics proposals; but people will definitely take notice if the eventually accepted one come attached with Google names.
I guess, but my point is that many of the rejected ones are attached with Google names. Also it's unclear to me that the reason for not remembering is due to who proposes and implements the things -- it seems more likely that this is due to a huge volume of proposals over a long span of time. WRT generics, it's also very clear that community feedback is being incorporated.
So this is why I think the issue is really rejection. Nobody's really upset about how error reporting or generics are being handled because it's clear that community feedback is being honored, and it's clear that the core team is holding themselves to the same standard the community is being held to. Those two properties aren't as clear in the packaging situation.
That's why I think Fuchsia having a documented community process and also having been working within that process for some time is important. We're already holding ourselves to the standard we're asking of the community.
> I believe it takes extra concerted effort.
This is absolutely true, and it's why I'm here trying to make sure that folks know there are people involved in the project who care greatly about its open nature.
Many people have pointed out that the existence of open source doesn't necessarily make the project accessible for contribution, and that's I think the more difficult problem to solve in the short-to-medium-term.
> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion.
I am aware of one, but an important one: ZeroMQ. Thanks to the late Pieter Hintjens, this project has C4 model. I have not seen any other project where I submitted a PR and maintainer accepted it less than half-hour later, no questions asked. And it works wonderfully; ZeroMQ is live and well.
>16. Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion
The word "bazaar" alone should imply discussions, including some haggling and shouting. If no discussions were expected, it should've been called supermarket or something like that.
> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion.
Bazaar is not a myth at all. The distinction was never 'are patches always merged' but is the development done in public. The issue with Google projects is more about in-group and out-group and if you're not in Google, it's hard to be considered 'in-group.
But even if the complaint was that all projects had this issue; it's just wrong. I've made and received plenty of drive by contributions with no discussion before the PR was made. You can't expect it to be merged any more than you can expect a romantic interest to agree to a date. But that's just interacting with people.
But it comes from observing what the Linux community did and giving it a name. It wasn't an ivory tower meditation but a field observation. I don't know how one can then turn around and say that it is not how the model works. Was the original observation incorrect?
It might sound like I'm being pernicious but I think fuchsia is great tech and I want it to succeed. I feel compelled to cheer you on in seeing the bazaar model as very real and good thing to pursue.
On the topic of more community engagement... despite Zircon not being an outright microkernel, maybe it's still appropriate for someone in the Fuchsia community to submit a talk to the FOSDEM 21 Microkernel devroom
Sorry, I am doing a poor job communicating. I agree with your assessment of how the bazaar model works.
When I said "in this regard", the intent was to signal that "bazaar" explicitly doesn't mean an anarchic situation where all change is accepted. It's maybe more anarchic than the cathedral model, but it's controlled anarchy.
The reality is that most projects fall somewhere between the two models. The people most heavily invested in the projects tend to drive change, and this is sometimes at the behest of the community. That doesn't automatically make the project a cathedral.
Similarly, while Google controls the direction and funds the development of Fuchsia, our development process (which we publish on fuchsia.dev in the Governance section) is very much bazaar-like. This is difficult to see because we haven't been open about our processes, and we haven't engaged externally with developers. To that extent, we've been very much "cathedral". This expanded model is us inviting folks to join us in the bazaar.
Google has a forking mindset and they prefer having more say than letting other rule the roost. Look at Webkit, Google forked it and derived chrome so they can have more say. Android Kernel Team didnt back port their changes to Linux kernel for yrs. This has more to do with politics and less to do with development. My guess is Fuchsia may have reached a point of internal abandonment like most google projects which is when they thought of the last effort to salvage it before ditching it completely.
I'm a longtime Go watcher, and sometime Go contributor and I agree with this, 100%. Go has benefitted from having a BDFL employed by Google. But outsiders will always be outsiders.
While I think Russ is brilliant and deeply qualified for that role, his BDFL position differs considerably from that of e.g. Guido (well pre resignation) or Linus in that he is considerably more 'D' than either of them.
And probably that works well for go and keeps a very clear philosophy and style for the language. It is just the fact they very blatantly misled the community on the scope of possible contributions that frustrates me.
Fuschia does, in all fairness, appear to be considerably more honest on these issues.
There's nothing wrong with an open source being controlled by a company or even existing only to privilege a specific company, but it's important not to mislead open source developers into thinking that a project has different objectives than what it has.
Congrats on the promo! It didn't quite retain me either, but I was a lowly staff software engineer. I am returning to Google though (back to the Google Fonts team), and it's entirely possible we'll get a chance to work together again.
Congrats on the promo! It didn't retain me (though I didn't get promoted to Principal, so maybe I don't count) but I did enjoy working on Fuchsia. Nice to see much of the syscall design seems to have survived.
I'm sorry, but I'm not sure what you mean by "this manifest." The blog post linked above was written by Wayne Piekarski, who is a Developer Advocate for Fuchsia. My role in the project is as a software engineer.
Since you're here, "abarth", it took me several clicks to get to the OWNERS file and all I saw was a list of email addresses. Calling that "governance" is... could we at least get some names and maybe brief bios on these people?
It's not meant to be a place for developer bios. If for no other reason than one developer could appear in many OWNERS files scattered throughout a repo, or in multiple repos, and keeping the bio current across all of them would be a nightmare.
Let me add some context. I was looking at the governance links on the site and found https://fuchsia.dev/fuchsia-src/contribute/governance/eng_co... which at the bottom simply says "The current members of the Fuchsia Eng Council are listed in this OWNERS file." I think it would improve the transparency/accountability of the project to have more than a list of email addresses here.
I understand where you're coming from, but that ends up being an inclusion issue in the project. I'm comfortable having my name and bio "out there" on the Internet, but I recognize that's a privilege. Not everyone who contributes to the project will be comfortable doing that.
> I've heard Fuchsia referred to as a "principal engineer retention project" at Google.
No rational company is going to create useless projects just to retain expensive engineers. What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?
> No rational company is going to create useless projects just to retain expensive engineers. What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?
(Short) story time!
Windows on ARM was a solo pet project of a high level engineer at Microsoft!
There are some engineers who are so valuable that letting them spend non-trivial amounts of time on whatever they want is a very good use of company resources.
Sometimes just not letting the competition have them is valuable!
I've worked with a few 10x-20x engineers, if someone is that productive, they can spend 2 years off on another non-ROI project, come back, and spend 2 years on a project with ROI, and the company still comes out ahead.
Most company's aren't smart enough to figure this out, then again determining who these people are is also a problem. That latter part is funny (ironic?), because on the ground floor everyone who encounters a world class engineer is pretty darn sure of it.
I don't think it's fair to call Windows on ARM an "engineer retention project". They actually released Windows RT and tried very hard to make it work. They still have it going with the Surface Pro X, and they just announced an emulation layer to get x64 applications working on ARM, which if it works well would solve RT's biggest problem, a lack of legacy applications: https://www.neowin.net/news/it039s-official-x64-emulation-is...
That is correct. It was a one man show for a long time (I don't think it was his only job, just a side project), then when tablets happened a full team was ramped up behind it.
> What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?
I'm not claiming that Google or other companies often do this, but just to play Devil's advocate, here are reasons why they might:
* Prevents them from going to the competition.
* Uses their prestige to attract or retain other developers.
* Keeps them "on retainer" in case a hard problem that needs their rare skills appears in the future.
When I worked at EA, we had a star engineer that spent, like, 75% of his time totally dicking around on whatever he felt like. But when say, it was a month away from FIFA's ship date and they couldn't get the game to run faster than 5 FPS, they would call him in. He would work some magic, the game would ship on time and with adequate perf, and he'd return to goofing off. Well worth EA's money to keep him on salary.
The rationale behind decisions in a BigCorp with very large Other Revenue Sources is entirely different from that of a small company that could be crushed by market forces on a moments notice.
As others have pointed out, the ROI can be something entirely different than $$ in the accounting ledger.
9 years into my BigCorp career and I still find it flabbergasting.
Since I was got into programming in middle school, I was obsessed with OS design (yeah, reading the source code for L4 in high school). As I went further in my education, I felt the landscape was pretty stagnate at this point and went into other areas (initially driver development and now developer tooling).
While I've not had a chance to jump over to Fuschia to participate, it warms my heart to see the development going on.
When looking more closely on Fuchsia architecture you might well be back into OS design obsession. As the kernel is, IMHO strongly based on a microkernel design, the OS APIs presents itself as userspace APIs. They are in fact, defined by what the userspace implements. And there is a lot of freedom on how to implement this API.
The majority of microkernel based OSes just implement these APIs to emulate UNIX APIs and that IMHO is a waste of potential but understandable in order to be backward compatible and not have to develop whole new userspace applications from scratch.
But I really like Fuchsia's take on the design of this userspace and the way the 'capability security model' is integrated into it. The amount of APIs built into the base 'Fuchsia platform' really blurs the line between and OS and a stack with OS plus essential services. Today, IMHO, things like automatic updates, software distribution, crash reports, and other low level application centric facilities should really be provided by the OS and that is done in the base Fuchsia platform.
AOSP is an open source project, which is impractical for any business to run because of apps' reliance on proprietary google play services.
Chromium is an open source project, but proprietary chrome has the largest browser market share and they like to abuse their position to not play well with standards bodies.
Google can develop Fuchsia. It'll even be cool piece of tech, but I do not for a second believe that contributing to the project would benefit anyone but Google.
To elaborate, the following distributions of Chromium are violating the Google API terms of service [1] [2] by publishing the API secret key publicly in the build source code responsible for building Chromium:
[1] https://developers.google.com/terms (specifically: "You will only access (or attempt to access) an API by the means described in the documentation of that API. If Google assigns you developer credentials (e.g. client IDs), you must use them with the applicable APIs. You will not misrepresent or mask either your identity or your API Client's identity when using the APIs or developer accounts." and "Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.")
If I fork one of the aforementioned Chromium packages, is my fork covered under that agreement? Is my right to build and produce my own binaries from the original unmodified source still intact?
There's a fuzziness to the concept of monopoly. It doesn't have to mean the absolute version where no alternatives exist at all. It can (and legally does) mean that a business is so dominant that it can effectively dictate the terms of the market.
Google has a search monopoly effective enough that they can solely make or break anyone who relies on search. They have enough dominance in the market that if they were to choose to delete something from search results, it could utterly devastate all sorts of players in the market who cannot at all get by on the tiny fraction of traffic they get from other sources.
This is not the case for all areas of search, but it's the case for enough of them that the concerns about Google's monopoly are valid.
As a simple example of this, let us imagine for a minute that Amazon and Google go to war. Google drops all search results that point to Amazon products or products in the Amazon marketplace and direct those searches to competitors and competing marketplaces. Google also changes Chrome so that entries into the url bar that are not explicitly for amazon domains do not match or return any amazon domain or product.
Since "Google is not a monopoly" I am sure no one would have a problem with this behavior... :)
That's not a simple example, that's an exceptional poor example. That's like talking about a world with a railroad monopoly and a steel monopoly and discussing what happens if they have a war at their intersection. That's not the point at all.
Google does NOT have a monopoly on searching for the sorts of products you buy on Amazon. In that particular exceptional case, a lot of people do go straight to Amazon for the search.
I use DuckDuckGo myself. The issue isn't that no alternatives exist (if that were the case, it would be much clearer that Google had a plain and simple monopoly). The issue is that Google can unilaterally kill or make other businesses through their search. For example, they can use their search dominance to push everyone into Chrome in order to kill Firefox (even as they pay Mozilla and Apple to keep Google as default search).
Google's search dominance is under threat from competition, but they do enough anti-competitive stuff to keep their dominance that it's an issue.
Maybe a big step would be just to block Google from paying Apple and others to make Google the default. I don't know. Probably the more impactful would be to separate the Google search business from the Android stuff. The benefit Google has from tying those two together makes it really so much harder for competition to gain ground.
If you want a pretty neutral balanced view of the issues of anti-trust, Planet Money did a good little series on how overreach in the past led to excessive caution and underreaction now.
> The issue is that Google can unilaterally kill or make other businesses through their search.
I don't see how this answers my statement. Of course they can, it's their platform. I'm sure MS pushes their new browser on bing. There's another thread open today where people have listed a ton of alternates so one can de-google. I did it 2 years ago, it's been fine. Apple Maps is much better than it used to be, bing is better than it used to be. Lots of email options.
I'm not saying it's a clear conclusion that Google has a monopoly that must be regulated/broken-up. I'm saying that it's not conclusive. The case is strong enough to seriously consider and to evaluate. I think the duopoly of iOS/Android is probably the most serious issue, even more than search. But none of this is simple cut-and-dry.
So for search they are not a monopoly, not even close.
For iOS/Android, I'm not seeing a problem just because they are popular. Is there some specific legislation you would like passed which would interfere and most likely overreach into their companies?
Like you said, it's not cut and dry because there isn't a monopoly. If an upstart company came along and wanted to make a new mobileOS, I wish them well. If Google or Apple did something wrong to interfere with their success, bring a suit at that time with specific claims.
Looks like you still cannot contribute without granting copyright ownership to Google. In turn, GOOG licenses it out under a BSD (or BSD-like) license.
This is a big difference relative to Linux, and its part of why Linux works so well as a collaboration between competitors. The GPL's copyleft acts as a joint development agreement between equals.
IMO, Fuchsia's model only works well for integration partners that are willing to act as sharecroppers in the ecosystem. That certainly does work for some device manufacturers, but it cannot serve as the foundation of a new Free operating system.
There's a big difference between licensing code to the world under the terms of Apache 2.0, and licensing code to Google under whatever terms they feel like now or at any time in the future.
I don't think it's an important difference. If you're doing open source at all, you're losing control over what's done with your code, including allowing it to be used by competitors and "bad guys" however you define that.
See (5) and (6) in the open source definition: no discrimination against persons or groups, and no discrimination against fields of endeavor.
If you're unwilling to relinquish control, no open source license is going to be good enough. At best you might scare some risk-adverse companies away from using it, but there are still going to be a lot of people you dislike who can use your software to nefarious ends.
You used to not be able to contribute to most GNU projects (maybe you still can't) without assigning copyright ownership to the FSF.
I don't see what practical difference the assignment to Google will make. Without using the words "equality", "between equals" and "sharecropper", can you give an example of something you or I will not be able to do with the code that you or I would have been able to do if the copyright had remained with the contributors?
If I want to distribute derivative works of the Linux kernel, I need to release those works to all. My competitors can take advantage of this, but in the end they are bound by similar rules. This produces a feedback loop in which contributions back may be used by everyone under pretty much equal terms.
If you assign your copyright to Google, they may make use of those changes and integrate them into further development and then _not_ release those changes or release those changes under another license. Do you see the practical difference now?
> If I want to distribute derivative works of the Linux kernel, I need to release those works to all.
This is false. The GPL does not require you to make source code available to anybody who asks, only those you distribute the software too (in source or binary form).
If you modify a GPL'ed application and then distribute that to 3 friends, those friends have the right to ask for the (modified) source code. Nobody else does.
I'm sorry I was unclear. You are correct I didn't intend to imply otherwise. My point was more specific to the case at hand. If Google distributes the code to say an end-consumer, they need to be prepared to distribute the source as well. That consumer can then provide that source to any of Google's competitors and they can make use of it in their own products. In most of these cases a company like Google would probably stop wasting time and simply make the source for any consumer products easily accessible by all.
However, Google need not provide the source to people that they do not distribute the code to (well obviously there are differences between e.g. GPLv2 and GPLv3, but whatever this isn't a legal analysis). For example, if Google uses it internally they may not need to release the source to anyone at all. They're all important points that more people need to understand, but they aren't really the ones that I was making in this thread and none of them are really specific to Google vs. other companies.
Incorrect, under GPLv3 if you do not distribute the source with the object, anyone with a copy of the object code is entitled to request the source code if you do not distribute the object code with the source code. I.e. if those friends give it to someone else your obligation to provide source follows the object to someone else. (This is a short and incomplete summary of section 6).
GPLv2 is even more stringent, if you do not accompany the source with the object than any third party with or without access to the object is entitled to request the source code. (This is a short and incomplete summary of section 3).
I was not commenting on GPLv3. But even so, your first paragraph does not contradict what I wrote. You're also incorrect: there is no transitivity to providing source. Section 6 makes clear that if your offer of source relies on someone else's server (i.e. you are redistributing the work but do not control the location where the source is available): "Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements". These clauses in the GPL cover you the person distributing a copy of the work, not "them" (the people who gave you a copy of the work).
You're incorrect about GPLv2. Section 3 states that if you distribute the work "in object code or executable form", you have to do one of 3 possible things:
1. accompany the object/executable with machine readable code
2. accompany the object/executable with a written offer of access to machine readable code
3. accompany the object/executable with the same information you received with the object/executable. (This option is only available for non-commercial distribution)
So we agree we're talking about the second option in GPLv2 then right? Here is the relevant text with the relevant portion emphasized (in italics since hn doesn't have bold).
> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
GPLv3 has transitivity not GPLv2, but GPLv2 doesn't need it because it already specified any 3rd party.
Edit: Reread what you wrote, GPLv3 b (i.e. written offers) has transitivity, I do think that GPLv3 d does not (but does distribute the source simultaneously with the binary in some sense).
Yes, if you exercise the seond option, the offer would be open to any 3rd party (i.e. it's a public server / URL).
But you only have to give the offer to whomever you give the object/executable to. So you tell them "you can get the source from foo://bar.baz/phaf" ... this just has to be a publically accessible address with no additional authentication or authorization. You are not required to announce this in any way other than in the written offer which accompanies the object/executable.
So, although in theory any third party has access to the source code, you are not being required to put it in a publically visible location, merely a publically accessible one.
[EDIT: I was saying that GPLv3 also does not have transitivity,so we agree about that ]
[EDIT: I admit that I am misleading in my final sentence ... yes, any third party has the right to access the source code, but you are not required to notify "any third party" of this fact, only those you gave the object/executable to. ]
You are describing the difference between the GPL and BSD-like licenses.
You have not said anything about the difference between a BSD-like license with copyright remaining with the contributors versus BSD-like license with copyright assigned to Google.
Well if I have the copyright I can straight up sell software based upon it without telling people you made it. Or I can release your code or derivatives of it under a different license while privately selling it under other licenses for profit. If these things don't bother you, then feel free to contribute.
In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place?
edit: If this ( https://cla.developers.google.com/about/google-individual ) is the CLA in question, then you additionally agree on a patent grant to Google and those those Google distributes it to. So if Samsung takes the code and distributes it to other customers those customers and Samsung are not covered by the same grant? Why is this all centered on Google? Why is not simply a general patent grant as part of the submission to anyone receiving the code?
> In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place?
The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from all owning parties.
This came up a lot when GPLv3 was introduced — many projects wanted to migrate from GPLv2 to GPLv3, but couldn't, because they never acquired legal ownership of contributed code, and so didn't have the right to re-license the contributors' code.
> The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from all owning parties.
Yeah I understand this. Hence there _is_ a difference and maybe one I don't prefer. I understand why Google would want this, but maybe I view Google's inability to relicense my code as a feature and not a bug.
In any case, I think the people involved in this back and forth essentially understand the state of things. I only seems some of us disagree on whether we should care. If people want to sign CLA's with Google that's their prerogative. If they understand what they're doing, more power to them. I don't like that Google has special preference over other actors, but that's just me.
edit:
> This came up a lot when GPLv3 was introduced — many projects wanted to migrate from GPLv2 to GPLv3, but couldn't, because they never acquired legal ownership of contributed code, and so didn't have the right to re-license the contributors' code.
Sure there are a lot of people who didn't like that, but maybe those who contributed their code under the GPLv2 never would have done so if they knew it would change to GPLv3 (not that he's more important than others, but Torvalds seems to fall in this camp)? Their wishes should be respected. Besides in those specific cases the projects could have avoided it by only accepting code licensed as "GPLv2 or later" so a CLA wasn't really required in that case anyway (though obviously that only applies to this specific GPLv2 -> GPLv3 case and not more generally).
IIRC in most cases it wasn’t so much that anyone actively disagreed with the licensing change, as that it was infeasible to even get in contact with the literally thousands of contributors — especially since many of them have left no contact details that could be used for legal correspondence.
Imagine a country with direct democracy, where a 100% consensus of all citizens is required for any law to be passed. Now imagine that a single citizen of that country decides to go live in the mountains, out of contact with the rest of the country, but still legally alive and legally a citizen, and therefore legally a "required" vote. The legislative process grinds to a halt!
This is, of course, why no government is run that way. And it's equally silly to run a FOSS project that way. Even if literally everybody likes some change, just one contributor failing to get in contact means you're stuck without the ability to make the change.
> IIRC in most cases it wasn’t so much that anyone actively disagreed with the licensing change, as that it was infeasible to even get in contact with the literally thousands of contributors — especially since many of them have left no contact details that could be used for legal correspondence.
Maybe yes and maybe no.
> ...The legislative process grinds to a halt!
You're being a bit overly dramatic. The software development process can continue just as it did before, they just can't retroactively change the license on code they do not own. It is true that maybe the project might die partially due to a lack of adoption due to people not liking the license, but he project may die for many other reasons as well. Also the project isn't gone anyway. It continues just as before.
> This is, of course, why no government is run that way. And it's equally silly to run a FOSS project that way. Even if literally everybody likes some change, just one contributor failing to get in contact means you're stuck without the ability to make the change.
There is one government, but there are many competing software projects. If one goes into decline it's not the end of the world. Besides the software project is not gone, it's still there. The fact that there are so many popular projects without the ability to change their licenses shows that the model can work just fine.
Look if you want to start a project and require a CLA be my guest. If you want to join a project with a CLA, go ahead. Just be aware that CLA's will deter some contributors. Weigh these trade-offs however you wish.
Well, sure. Because people who want to develop products on some platform also want some kind of warranty, which is explicitly not provided.
Google establishes with the public a warranty- and guarantee-free use license. If someone feels they've been harmed by the software, they're prevented by the open source license from suing Google, but they're (more importantly) also giving up their right to sue the individual contributors.
At the same time, vendors want to be able to hold suppliers accountable for support and warranty on products that are supplied. Permitting sublicensing allows Google to sell the software to OEMs and vendors with support agreements that allow those vendors to hold Google responsible for that support (rather than the individual contributors).
There's a lot of complaint about the sublicensing going on, but I think most vendors aren't going to build systems where they can't get support, and I don't think contributors actually want to be liable under tort law for the code they provided for free.
Then again, maybe the objection is to giving code to Google that Google can profit from. I guess that's fair, but you don't _have_ to contribute code and you're also not prevented from sublicensing and trying to turn a profit yourself.
Linux itself has never been a GNU project and has never required copyright assignment. It is the combination of features (retain ownership and GPL) together that has enabled collaboration in Linux.
Are you saying that collaboration on Gnu Compiler Collection, binutils, bash, bison, CLISP, coreutils, etc, has been inhibited by the requirement for copyright assignment to the FSF?
There's a big difference between GNU and Linux in terms of their collaboration. With the exception of GCC, most of the utilities you named have been maintained by a very small group of people.
GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.
As far as I am aware, the only times contributions were not incorporated were because the work was done by under the terms of an employment contract with the result that the employer ended up owning the copyright, then the employer decided not to sign the CLA.
Can you think of a single instance in which code written by an individual contributor not bound by an employment contract was prevented from being incorporated into a project that required copyright be assigned to a central entity?
I have read multiple accounts of open-source contributors who have successfully negotiated when being hired that copyright to any code written on their own time on the own hardware will remain with them (so as not to complicate their contributions to open-source projects).
I'm not sure what your point is. The exceeding majority of the work done on these foundational projects has been done as works for hire. The issue isn't the relationship between Google and Coder Jane. Its between Google and Red Hat. Its between Google and Samsung.
Intel and ARM both collaborate on GCC and Linux all the time while being fierce competitors. Google, Canonical, Red Hat, etc all contribute to Linux while being fierce competitors.
But the only companies that contribute to Android and ChromeOS are device partners, and the partner contributions are far more limited in scope.
Sure, but no open-source project wants contributions by contributors who do not legally own the code because in that case the actual owner of the code can petition the court to issue an injuction on the project preventing further distribution of the code till the offending code is removed from the project. (They can also sue any user of the project for damages.)
Wikipedia has to worry about the same thing, BTW: contributors who upload text whose copyright is owned by some entity who never consented to the upload, and they have policies in procedures in place to correct it when it happens.
It's not like CLA's are the only obstacle to employees contributing to the open-source projects. In fact, you might say that the main purpose of a CLA is to surface copyright-ownership problems early, when the cost of correcting them is lower.
I agree that no project wants that situation. But many projects are willing to accept the risk of it happening, and instead have reduced friction with no CLA.
Only one datapoint, but I have refrained from contributing to GNU partly[1] because of the copyright assignment requirement, while having committed to many other open-source projects I use.
1: TBH it's hard to tease apart the cultural aspects from the legal. Most GNU projects were roughly "We'll post a tarball once in a while and not have public CVS" when I first started getting involved in OSS; projects with public CVS it was a lot easier to tell if someone was already was working on something, particularly for people as shy as I was back then; I got the impression that the "proper" thing to do would be to introduce yourself on the mailing list, propose the idea, &c. and then start working on a patch.
My particular combination of low-confidence and misanthropy steered me away from such projects.
I'm sure it has. It's an additional hurdle that developers have to clear before they get their code included upstream -- it would be extremely surprising if there weren't some number of developers who gave up at that point.
(It doesn't help that the FSF's processes for copyright assignment are incredibly clunky. It was a big deal when they started accepting scanned papers in 2012, for example.)
The FSF is not Google. Their organizational goals are different enough that the repercussions of copyright assignment are different in each of those cases.
Basically I trust the FSF to stand by the spirit of open source. I don't trust that out of Google.
Sure. I don't contribute to projects that require copyright assignment to the FSF. For one thing, it's a major hassle for new contributors. For another, I don't particularly like or trust the FSF.
With BSD-style licenses there's still a strong incentive to share code. That's why permissively-licensed projects, from Node, to PostgreSQL, to FreeBSD, work.
With GPL-style licenses, there's an incentive to avoid putting effort into development, and instead undercut other parties who did invest, and then had to share their code.
I'm still not clear on what fuchsia is trying to be - or more specifically, why is Google developing it. What is the end goal here, from a business perspective?
>An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult.
I don’t think these claims hold. It is still written in a memory unsafe language, so exploitation is totally possible. As well, for malicious software you’re just looking for a process handing out high privilege handles.
> for malicious software you’re just looking for a process handing out high privilege handles
In the end, that is true.
But the thing is the way Fuchsia's implementation of the 'capability security model' is done. The capabilities a process (or, a 'component' in Fuchsia's model) use/consume are explicitly given to it. And this scheme is implemented in a way that is easy to see and account for where/from these capabilities are going to/from. An process can do nothing that is not provided by the capabilities it got during creation.
Of course, components might be buggy/malicious and leak capabilities. But the security holes bottleneck in this capability routing scheme, so even with buggy/malicious components, it's much easier to audit and fix. And from an attacker perspective, it's much harder to reach a component given the routing path of capabilities that it's received.
I expect it will be very much the same as drivers we have today, where you have some game anti-cheat rootkit that has a bug in it.
In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them.
It will be cool to see a full system audit of capabilities, but I don't think that analysis exists yet.
> In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them
Yes, and then you would have to own a component in some route that received the driver exposed capability. Either way, the tight sandoxing and compartmentalization of functionality make things difficult.
Absolutely agree. The other thing I guess I was implying is that Fuchsia uses a number of tools to reduce attack surface that work regardless of language.
I remember reading a couple years ago that the goal is IoT devices. It runs on the Zircon kernel, which is a true microkernel (as I remember, haven't been paying attention recently). This is pretty ideal for IoT, since manufacturers should be able to spin up only as much OS as they need on top of the Zircon kernel.
Fuchsia specifically is looking to be a full-fledged OS, I think, for devices like Chromebooks or similar. I think they expect to get Fuchsia to a place where it can run Android apps natively, then put out an OS that can run native apps, Android apps, etc, all while being tied in to Google's services.
This is definitely some speculation, but that's what I'm seeing so far.
It gives google the ability to thwart a major security problem that android has. That is, manufacturers choosing to drop support for a device.
Because the important parts of Fuchsia are all controlled by google, it means they can theoretically keep devices running and up to date indefinitely. They can control the majority of the software while manufactures only need to supply their drivers.
Manufacturers dropping driver support, while bad, isn't the end of the world. It's a much smaller attack vector than the whole kernel never getting updates.
the goal is to be a foundation for future embedded devices that doesn't have the many challenges associated with linux-based systems, specifically around security, isolation, and firmware updates while also defining a simple and straightfoward presentation model to app developers.
If contributing to your project requires much more than git commit --signoff — in Fuchsia's case, a full-on Google Account! — this will exclude many pseudonymous developers who conceive of things such as privacy in terms of capabilities (not pinky promises). Which seems relevant for a security-focused OS.
I'm guessing that most of these pseudonymous developers—of which there can't possibly be too many—would distrust Google enough not to contribute even if it were easier to do so without a Google Account.
As a pseudonymous developer, I fail to see any harm in contributing to projects run by Google in general. Fuchsia is not a monopolist way to exert control over the market (not today at least), it doesn't seem to be explicitly made for evil, and can be forked to let the community steer it.
I would not be surprised if Google account ToS has some point that complicates things for contributors or people forking the code.
I haven't read Google ToS lately so I can't say there is something like this but that document is huge and keeps changing all the time.
If I was a pseudonymous developer, I would probably not go through that.
As of today, there are no phones running Fuchsia, so it's hard to evaluate if it's going to be useful for any kind of control. Does it have feature parity with Linux?
Forking can be practical without competing for the same use case.
Both of these are true, and it is indeed possible that Fuschia is intended to be genuinely open.
However that seek unlikely given that there are many actors who would like to exclude Google services from their devices and Google is at the same existential risk if that happens as they were when they introduced Android.
And yes forking can be practical, but it very often isn’t, partially in the case of a very large corporately sponsored codebase. So ‘we can just fork it’ doesn’t mitigate the concerns.
I'd just like to interject for moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but
sure you can contribute to the Linux kernel pseudonymously. Think of a plausible name, "git commit --signoff", and you're good to go. There's no enforcement of slave names for kernel contributions, it's all just a minimally viable legal fiction.
You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted". (https://www.kernel.org/doc/html/latest/process/1.Intro.html)
And since you mentioned GNU, would you be able to pull the same trick on a GNU project? Don't they require you to sign away your copyright, with paperwork? So you wouldn't be able to contribute to (some portions of) GNU/Linux pseudonymously.
It's a common way that pseudonym aficionados refer to their civil names. Gallows humor.
> You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted"
And yet it won't be rejected or removed. The preceding sentence is "It is imperative that all code contributed to the kernel be legitimately free software." If you don't betray the project, nobody will make it a problem.
I'm a little sad that there aren't any comments describing what is technically novel around Fuchsia and why it is/why it isn't interesting from an OS design standpoint.
I get the sense that its advances are probably too low-level for most app developers to care, but that's kind of precisely why I'd love a comment elucidating them a bit.
Edit: For example, the Fuchsia docs list the primary talking points as secure, updatable, inclusive, and pragmatic. How well does it live up to those principles? Will they bring practical benefits? What's exciting/new about what's being done here?
> Fuchsia is a long-term project to create a general-purpose, open source operating system
Why do we need this? We have Linux. It works. It is open-source, general purpose. It needs more support to become more mainstream (like what Valve has done with Proton).
Don't like Linux? Start with one of the BSDs. Heck, start with Haiku. Any of these projects are lightyears ahead of anything that's just starting.
The most likely explanation is that _we_ don't need this, but Google does, for some strategic purpose. It must be for some pretty compelling use-case, because we know how happy they are to kill projects.
Because every once in a while, it‘s easier to free yourself from the shackles of architectural decisions that were made because of the hardware and constraints of their time that are obsolete now but are supported for legacy reasons.
A security model that is designed from scratch into such a deep OS concern as with Fuchsia is one of the aspects that would be next to impossible to bolt onto such a conplex project such as Linux or BSD.
I‘m not saying it will play out, but it certainly brings a wave of fresh and radical new ideas into open source operating systems I haven‘t seen since the times of BeOS and Plan 9.
There is definitely room to innovate more fundamentally in operating system design. POSIX is effectively a 50-year old API, and there are definitely places where the API it provides is far from optimal.
For something that interests me personally, the POSIX idea of ptrace and signals for debugging is a fundamentally broken and obtuse API that just don't work very well with how modern software is designed, and requires a decent amount of hacks to do anything rational with hardware traps. I did think a little bit about what kind of API I wanted if I were designing de novo, and happened to pop through Fuchsia's API at a glance to see what it decided... and it was exactly the kind of way I'd have thought about this space.
POSIX doesn't say anything about ptrace. And yeah, ptrace is somewhat horrible, but there's no reason you couldn't implement something better in existing systems; it's just that the amount of work necessary is so huge it's probably not worth it, but the same amount of work would be needed to write it from scratch.
None of these are microkernels with a strict capabilities model. Open source isn’t the only desirable property of a kernel, and Unix is probably not the last word in advancements of general purpose OS APIs.
One application they’re probably interested in is a sandbox/containerization system with a drastically smaller surface area than the Linux primitives. That’s what excites me, we may get to the point where things like Firecracker VM and gVisor are no longer needed for robust isolation.
SeL4 currently doesn’t have shared memory concurrency, and is only the kernel part. It’s focused heavily on formal verification, and makes a number of other sacrifices (in particular to performance) to achieve that. I’m a big fan of formal verification, but seL4 levels of assurance are still too unwieldy with current tools for an application that doesn’t place a massive premium on it.
It’s also worth noting that the Fuchsia equivalent would be Zircon, which is a relatively small part of the Fuchsia project (and will only get smaller in proportion).
About the biggest piece I can see which benefits the outside world is the fact that Fuchsia's drivers are independent of kernel version. This is one of the biggest pain points for Android upgrades.
A Fuchsia based kernel upgrade won't be held hostage by lack of Qualcomm/ Nvidia/ Mediatec binary drivers.
But mostly, I suspect Google just wants an OS that isn't burdened by GPL.
Because Linux isn't perfect. It can be improved upon.
* All code in the kernel including all drivers is 100% trusted. This is very bad for security.
* No stable driver ABI, so writing out-of-tree device drivers is very difficult.
* GUI is an afterthought, which means it is very difficult to do things like graphical secure attention keys, and frankly graphics/display support on Linux is very janky as a result.
* Many of its features are firmly stuck in the 80s.
Linux considers stable driver API as a nonsense. SoC manufacturers don't want to open source their drivers, they prefer to ship blobs and they prefer not to support those blobs for a future kernel updates. Those facts means that you can't upgrade your kernel. When you can't upgrade your kernel, you can't upgrade your userspace which depends on new kernel features. So basically your software is stuck and eventually obsolete.
There are two ways out of this situation. You can either replace Linux with another kernel with stable driver API or you can replace SoC manufacturers with those willing to upstream their drivers. Probably it's easier to go to the first route.
Surely we've learned a few things about designing systems since 1991 (and the hardware landscape has changed just a little bit in that time too). A new, from-scratch OS should be able to make some huge leaps with all of that new hindsight, and without all of that legacy baggage. It's an enormous task, of course, but if anybody has the research-cash to throw at it, Google does.
Of course from a business perspective it's definitely a power-grab, just like Chrome was. But from a technical perspective I think it makes a ton of sense.
We don't need it, we don't need anything at all really. But when* google turns it into reality everyone is either going to embrace it or it will fail like MS's arm attempt. If it succeeds, we'd all be like - "This is exactly what we needed!" But then we will realize it's just different bone structure under the same skin. Skin being metaphor for a highly locked down and centrally controlled ad delivery platform that doesn't let users truly own their paid for devices.
* - considering google's software mortality rate, i am skeptical of anything new and daring getting enough time to mature. It will be google plus'd.
Chrome -> Make chromium opensource but add spyware that phones home on every second and with new manifest v3 make sure extensions like ublock origin don't work
Andriod -> Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it. And make sure there is no way to block ads on youtube for andriod.
Fuchsia -> Initial Stage make people think they are open they are helping community for first 5-10 years. After that implant spyware etc.
Same strategy different form === Modern Polymorphism by Modern Liars.
I don't know, I think there's a couple examples of these open source projects gaining non-Google traction:
- The new Edge, Opera, and Brave are based on Chromium
- China has a huge ecosystem of non-Google Android devices
Google does exert strong control of their open source code, and Google is clearly the prime beneficiary of them, but the external world has still leveraged these projects nonetheless
And the Android in China example doesn't really say much because because the only way that was possible was through the forceful intervention of the Chinese government.
Nowhere else in the world is there a market where Android is free from Google's iron grip, outside of tech enthusiast/hacker circles.
Those aren't phones or general purpose computing devices (except maybe the tablets)
You could count those, but I don't consider them relevant the same way I don't consider those cheap chinese TV boxes, smart watches, fridges, and other appliances to be relevant here (they could just as well be using Windows 98)
I think we should still give them credit for being the most open among their peers. MacOS, iOS, Safari and Windows are not open source at all. Edge is of course just another Chromium based browser.
WebKit is open source but Safari isn't meanwhile Chromium is. WebKit is sometimes a bit closed until it reaches embargo that Apple sets. But anyway Safari is good to web diversity.
What I did say is that Chromium was based on WebKit and then a fork of WebKit, blink.
Let’s not credit Google for Chromium without recognizing that it was Apple’s open source work that made it possible.
To suggest that WebKit isn’t open makes no sense at all. It may not have a governance model or development processes people like, but the fact that the source is open and has been used to build competitor products and has been forked means that it is unquestionably open source.
> Make chromium opensource but add spyware that phones home on every second
Chromium homes every second? That seems interesting. It has been a long time since I last used Chromium. Does it also come with Google auth now?
> Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it.
If they add Google specific services into core Android is it not worse? Companies like Amazon and a lot of Chinese companies seem to be fine with using just the core Android.
> If they add Google specific services into core Android is it not worse?
Not necessarily. Take for example push notifications - the push notification client could be part of the OS, with build configurations to specify a server or disable this altogether.
Or, given OS update issues, Google Play Services could be a separate open source project with the Google URLs and keys supplied as build configs.
I find it kind of hilarious how large a proportion of the roadmap is just migrations of various kinds. If the goal here was to encourage external contributions, I can't imagine a much worse sales pitch.
I see it as better way of developing a product. Or actually, a foundational system, if Fuchsia really ends up becoming something like that. You see, lots of things that today are fundamental were just "developed organically", and that is OK because people never tought that it would end up being what it is.
Besides, a greater part of the cruft we have today is rooted in the development model companies adopt that is "develop it, make it work, and ship so not to delay the schedule/budget so much". And that is OK too given that companies just want to develop a product and don't have lots of time, budget and resources... But, as things are in software engineering, that model doesn't produce as good a piece of software as it would with more iterations and refactoring seeking the best software model and implementation. In the end, that results in greater issues issues than what was really needed and the backward compatibility hinders an actual solution. But Fuchsia being meant as a foundation, cannot be developed like that. Like a product that "just works". It would end up being just another bad designed (and chances are, bad implemented too) system based on concepts of the beginnings of computer industry that doesn't necessarily apply for today's systems.
As I've loosely accompanied Fuchsia's development, they've done a lot of early bring up work just so that other parts of the system could be developed. And that is expected because they developed arguably almost everything from scratch. You cant expect ending up with really great system design and implementation just from these first iterations. Then, with the experiences from that, they've done lots of refactorings that refined system's abstractions, APIs and implementation. And, if they are serious about Fuchsia being a good foundational system, they have to solve these left over from the early development.
I think this is the greater challenge now for Google. A system being very well designed and implemented only attracts enthusiasts and people like that with free time. Even the 'better security' aspect doesn't convince the majority of developers. For general usage in IoT and primarily in smartphone/tablet devices, Google would have to:
1. Port ART together with all of Android's public facing APIs to Fuchsia. Evidence says they are doing it, at least for Android ART. As people say, "there's no way without Android app compatibility"...
2. Convince OEMs to switch to Fuchsia platform instead of Linux. That I believe is under way with project Treble, or at least has a path for a possible solution. And Fuchsia's architecture solving Linux big pain points would be a strong argument in convincing OEMs to switch. Woundn't be easy though as drivers would have to be (re)developed or some bridge would have to be built.
With above done, developers would have a push to develop targeting Fuchsia natively. Then Fuchsia's better system architecture together with security advantages would be more strongly perceived by end developers.
If Google managed to develop some new fancy end product on top of Fuchsia that got traction, then that process would be a lot easier for them...
The classical chicken and egg problem every platform has but in this case even more obvious because there are no consumers yet so the number of producers is also small.
Fuchsia will e to Android and ChromeOS what Servo is/was to Firefox. Eventually the guts of Android and ChromeOS will be replaced with Fuchsia while end users won't see a radical change. It might feel like moving from XP to Vista or OS 9 to OS X.
OT: Just a second ago, I was setting up unattended-upgrades for security updates
for a new Ubuntu box and I am once again puzzled why the largest Linux distribution has such an underwhelming UX for an crucial feature. Long story short, I welcome any new contender in the OS space.
> I am once again puzzled why the largest Linux distribution has such an underwhelming UX for an crucial feature
Are we talking about Ubuntu, or Android? Because honestly in either case... what would you improve? Ubuntu has updates rolled into GNOME's package management frontend and it's seemed to work well, and Android has decent UX around updates (especially with A/B system partitions) although of course it suffers from vendors not actually releasing updates.
You have to touch two config files. One is easy but the other one needs a bit of googling, nothing major but yeah why at all this? Auto-updating security updates should be the default if you run servers in the wild.
Not if you just want automatic security updates? The package is part of the server task, and defaults to installing security updates. It does not install other updates, and does not automatically reboot.
> Auto-updating security updates should be the default if you run servers in the wild.
OT indeed, this is about a kernel and you're asking for a userspace feature.
Also, there are large number of "contenders" in the Linux based OS space which may have the UX you want, and if there isn't one this sort of thing tends to be pretty easy to tweak and suggest changes for (unlike in most of Google's OSes.)
So maybe open source, [mostly] closed ecosystem? Add a bunch of Spyware from Google and get every app maker to add a dependency to Google services and they are golden for the collection of data on all your "smart" things
Sorry/not sorry for the cynicism; I feel it is warranted given what "open source" means on Android. Google talking like they have noble open source ambitions means nothing. They have a lot of amends to make before they begin to seem like a win for society and the industry and they seem to be going in the opposite direction.
Sorry, not familiar with Android core. For your example, how would it work without proprietary technologies? AFAIK, Android uses GCM for notifications. Adding integrations for it don't seem to make much sense in core open source Android as that will make you tied to Google's ecosystem.
Both are serving the same purpose, for different apps. Even before we get to network connections and servers (the things that might make sense to be proprietary), without Google's ecosystem the local side has a bad UX and requires hacks.
That is just because they are not using something like https://bubu1.eu/openpush/ and instead implementing their own push services. This is not a problem with Android but with the apps.
I was speaking about _local_ notifications, not push: some clock / reminder apps never fire notifications or way too late. I think it's because the OS aggressively shutdown apps running in background.
It doesn’t have to do anything, but if it doesn’t support what are considered standard features of a phone today in an open manner, it’s hard to take AOSP seriously as an open platform.
Also worth noting that when someone does build on top of AOSP, they are at the mercy of Google’s roadmap for the closed versions of Android.
The fact that this is possible is something I have commented about on this very forum for years. It is trivial for the Amazons and Huaweis of the world to build an API like this that supports Google's FCM, Amazon's ADM, etc. and provide a library for developers to use that will let them easily deploy push-enabled apps on devices across all ecosystems.
It is already usable. Nobody would claim that a Linux distro isn't open just because it doesn't have a built-in push API. You can build one on top for other apps to use, and you can do the same on Android. This is notably different from iOS.
You're essentially suggesting that Android should have Tor built in. The point is that it's possible to use other push services on Android and has been done, just like it is possible to use Tor on Android. There is no reason that AOSP itself needs to implement Tor any more than Windows or AOSP needs to provide a push API. Both are possible to implement on top of the platform and have been implemented on top of the platform.
This is unlike iOS, which is the real broken platform.
Push messaging is a service, just like anonymous proxies are a service. It doesn't make sense to put them into a platform if they can be built on top of the platform. It would make sense to put something like this into iOS because it can't be built on iOS. It doesn't make sense to put it into AOSP.
Earlier you said AOSP had a framework for push notifications, a statement found to be false when checking the links you provided.
Now you say it doesn’t make even sense to put this feature in the platform, confirming that you were lying when you said it already was part of the platform.
AOSP has a framework to support multiple backends. It's called the Service framework. With it, you can build a library to simplify dealing with backends, and I pointed you to one such library.
> Now you say it doesn’t make even sense to put this feature in the platform
Of course it doesn't make sense to build that library into the platform.
> Why are you talking about iOS?
iOS doesn't provide the ability to make this possible, which is probably why you are so confused.
Do you still claim it’s already usable? If not, why did you say it is?
You say: “Of course it doesn't make sense to build that library into the platform.”
I agree, but nobody is talking about building that library into the platform. The comment you are replying to is talking about the feature, not that library:
“Now you say it doesn’t make even sense to put this feature in the platform”
Do you think it makes sense to put this feature into the platform?
> Do you think it makes sense to put this feature into the platform?
How many times do I have to tell you that it doesn't?
Do you think AOSP should have a framework specifically for uploading photos to a photo sharing service in the background? That is another standard feature for smartphones. Of course not, it just needs the ability to support uploading photos to multiple services, and people can build libraries on top of the platform to make it easier. This is notably another thing that is not possible on iOS.
> You pointed me to an abandoned codebase.
And another one that isn't abandoned.
> Do you still claim it’s already usable? If not, why did you say it is?
No. I assumed it was because they had already announced it. Any developer who would like it can simply finish the library themselves.
We seem to be in agreement except for your wacky ideas of how much should be in the platform vs. how much should be built on top of the platform.
Can you give extra context? It's unclear to me how Zephyr relates other than being an operating system. It doesn't on initial look seem to be designed with the same goals as Fuchsia.
This is an OS which can be used to create IOT devices - it works on many devices and architectures without binary blobs other than some firmware for stuff like BLE or WiFi.
"Fuchsia is an open source effort to create a production-grade operating system that prioritizes security, updatability, and performance. Fuchsia is a foundation for developers to create long-lasting products and experiences across a broad range of devices."
"The Zephyr ProjectTM strives to deliver the best-in-class RTOS for connected resource-constrained devices, built to be secure and safe."
This sounds a lot like the same to me - Fuchsia is perhaps more a general OS, but I would think that Zephyr can solve the same problems as Fuchsia.
What I like about Zephyr is that it is developed in the open and not in some google lab.
Fuchsia is an OS. Genode's a framework for creating operating systems. It's not comparable.
What's interesting imho is to compare seL4 with zircon. The former is a third generation microkernel. The latter is still a first generation microkernel or, according to google, not a microkernel at all.
It's thus not very interesting from a computer science perspective. In practical terms, I'm sure it'll be better than Linux and IOS/OSX, but that's a very low bar to meet.
How about an OS using the Genode framework, Sculpt OS https://genode.org/download/sculpt IIUC, compared to Fuchsia? Apart from their kernels, which you've addressed.
Also, I guess the adoption of Fuchsia will be a litmus test of the GPL. Will its possibly technical merits outweight the strength of GPL to avoid fragmentation? I suspect the GPL has served Linux very well in this regard.
Given Google's muscles it will most likely have an impact in the mobile world, but whether it will reach beyond into the area of general computing is less certain.
There is not a RPi port, and that's non-trivial for reasons I vaguely recall to be related to display driver weirdness. The system does run on arm64le.
Anyone else bothered by the black banner saying "Google is committed to advancing racial equity for Black communities" in technical documentation (https://fuchsia.dev/fuchsia-src/contribute/roadmap) ?
This is simply an advertisement for Google, and just like any other advertisement it has nothing to do in technical documentation, especially in a project where they want other companies to contribute.
The one singular nice thing about android was that the kernel was GPL. This put a (rather high) limit on the stupidity that could go on. Fuchsia changes that.
I believe he's referring to how Android phones have slowly become more and more dependent on the closed-source Google Play Services to provide essential functionality. Despite Android itself being "open source", many Android devices and apps are useless without Google's proprietary services.
> many Android devices and apps are useless without Google's proprietary services.
And not, in fact, open source. Due to the non-GPL license, every single Android device out there is effectively running a closed-source fork of AOSP.
I had an old Samsung device automatically install TikTok when I powered it on after sitting in a drawer for years. TikTok didn't even exist when I bought the phone, yet someone with more control over my device than me sold the remote access (they gave themselves, without my consent) to TikTok.
Of course this is not a new development, but the proprietary BS and Google's increasingly evil actions over the past decade really highlight how much of a problem that is. Trusting Fuchsia is just repeating that mistake.
Android too was advertised as a nearly "community driven" OS.
Few years down the line, and good sales, and they turn Android into a locked down hell, start to stonewall communications with contributors, throw musings about community governance out of the windows, and break pledge to never block the adblock, nor introduce political censorship on the Android Store.
That is the most hideous source control system ever.
Do they really need to be developer hostile just because Github is owned by Microsoft? I mean seriously, who has time to commit to a project with a random set of tooling.
I've never worked at Google, but I've used Gerrit not infrequently at jobs and on projects--it isn't "random" even if you've never run into it before. Gitiles is just a hat on top of it; it's not pretty but it is fast.
It's not "developer hostile" to not use Github. Git works everywhere. It might mean that to contribute to an operating system a developer may have to learn how to use something that isn't Github, but honestly if that's a bar to contribution for somebody they probably weren't gonna anyway.
Google uses GitHub for a bunch of things, I suspect it is more that the people working on it want to use Google's internal tooling as much as possible, and public user experience is considered less important than that.
That may be true for Google in general, and internal code in particular, but that's definitely not the case for Fuchsia. We use the tools and interfaces available to the public to work on the code base: code search to browse the code, gerrit for reviews and monorail for tracking bugs.
Welcome to the world of Building Large Google Projects. This is somewhat painful in the Android and Dart/Flutter world. I haven't tried building Chromium yet but I'm sure it's just as complex.
Yeah, I've tried building Chromium on my own before. Chromium's build process is so inscrutable and changes so often that several Googlers I've talked to have said you can't really do it without handholding from another Googler in-the-know.
fetch --nohooks chromium && cd src
./build/install-build-deps.sh
gclient runhooks
gn gen out/Default
autoninja -C out/Default chrome
Congrats, you just built Chromium. Is it a different build process? Sure. But it sure isn't inscrutable, and they've been using this system for a while now.
Google were so convinced of the value of open source that they didn't anticipate that almost all OEM's would rather ship their Android forks than to stay close to upstream. If they hadn't intervened, Android as a platform would be useless by now and app developers would need to implement various ways of handling notifications, storage access, etc just to ship their apps to a broad audience of device owners, Samsung would've never upped their update game and there wouldn't be 2-3 versions of Android on the majority of devices, but more like 5-10, depending on how many manufacturers would've survived in the market.
Android still allows for easy side loading of applications, there are still major independent after market Android versions out there, you can develop for Android in various languages, using a huge selection of IDEs and there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against. Google didn't even manage to gain any relevant market share with their Pixel line of devices, of which most run Android. They could've done a lot of nefarious things by keeping newer Android versions Pixel exclusive until they publish the source code to OEMs, for example. Instead, they are making it easier to quickly move an existing Android code base to the latest version by abstracting away a lot of the complexity (project treble).
Is Google still primarily am advertising company that tracks its users? Of course. Do they have their own motives to keep Android at the top of the mobile OS market? Of course. But a lot of the comments see evil scheming where Google probably had to act quickly to ensure that Android has a future and that developers didn't lose interest in the platform in favor of iOS.