Having used several Google OSS projects I would NEVER consider using an OS from Google.
The documentation structure is often atrocious, the are always dozens of recognized but unresolved bugs, those bugs often remain for years, the documentation often is not updated to reflect the state of open bugs so code samples and tutorials are often broken, the bugs are resolved slowly, non-Google pull requests are often left to die on the vine[0], no road maps, the Google employees use an internal build system and the external packages are often broken, and these three words: "Not. A. Priority." If your bug is not an internal Google priority you are basically out of luck. Hope you like maintaining your own patches, for years.
I'm not saying that OSS projects from other large projects don't have similar problems, I'm saying that every Google project I've depended on has had all of these problems.
The idea of my OS being run like this? Absurd.
This just is a guess, but, I'd wager that most Google OSS developers just wanted a fancy corporate job and got stuck interfacing with the public on an OSS project. I don't think that most of them aspired to be OSS developers and it shouldn't be a requirement.
[0]: Just today a two year old bug that I've been watching was closed by merging a pull request that was first opened in early-2020, closed as stale in mid-2021, and re-submitted/merged this week.
Isn't Android run like this? Is the community participation in Fuchsia different from that of Android i.e. Build inside Google and publish the code to AOSP?
Regardless of how 'open-source' android is, I'm grateful for its 'openness'. Cannot imagine mobile compute held solely by walled-gardens and carriers.
Anyways Brian Swetland is the person to thank for those who appreciate the openness of android[1].
> “Peter mentioned something about exclusivity for our first device, which Brian overheard. By the time we got back to our hotel room, Swetland had threatened to resign because ‘I didn’t join Android to become another Danger.’ I was concerned because Brian was so critical to our success, but when I saw him the next day everything was fine.”
> He was strongly in favor of Android’s vision for an open and independent platform. He threatened to resign several times during his time on the Android team over decisions that would have resulted in a closed platform.
Not so fast, in areas where the bug can be phrased as basic compatibility with a recognized standard it is often easier to get Google (or Apple, or ..) to flinch than areas with a mixed standard/implementation they think they own.
> Not so fast, in areas where the bug can be phrased as basic compatibility with a recognized standard it is often easier to get Google (or Apple, or ..) to flinch
Unfortunately, Like the parent I've been following couple of bugs for years which Google didn't 'flinch' yet; 'Chromium on Linux not respecting prefers-color-scheme when dark GTK theme is set'[1] is one such bug.
It looks to me like they tried to flinch or at least didn't close it like almost everything UX I've seen on the chromium bug site. Pretty impressive given that while gnome is external its not an actual standard of the sort the Posix or RFC networking gangs kick each other in the crotch over. If they aren't publishing formal standards to an outside body that starts picking up independent interested parties, I think they will have more options to go down from their current quality whether or not the current quality is acceptable to critics today.
I think the way to deal with these kinds of community-hostile (or community-abivalent) corporate open-source projects is to just hard fork them once they reach a stable version, and let the community fork break compatibility. You lose the continued efforts of the internal development team, but you get a stable foundation to fix bugs and add polish.
The documentation structure is often atrocious, the are always dozens of recognized but unresolved bugs, those bugs often remain for years, the documentation often is not updated to reflect the state of open bugs so code samples and tutorials are often broken, the bugs are resolved slowly, non-Google pull requests are often left to die on the vine[0], no road maps, the Google employees use an internal build system and the external packages are often broken, and these three words: "Not. A. Priority." If your bug is not an internal Google priority you are basically out of luck. Hope you like maintaining your own patches, for years.
I'm not saying that OSS projects from other large projects don't have similar problems, I'm saying that every Google project I've depended on has had all of these problems.
The idea of my OS being run like this? Absurd.
This just is a guess, but, I'd wager that most Google OSS developers just wanted a fancy corporate job and got stuck interfacing with the public on an OSS project. I don't think that most of them aspired to be OSS developers and it shouldn't be a requirement.
[0]: Just today a two year old bug that I've been watching was closed by merging a pull request that was first opened in early-2020, closed as stale in mid-2021, and re-submitted/merged this week.