Making a fork of ChromiumOS is easy, the hard part is getting laptop makers to use it. If you fork Chrome you lose all the integrations with Google services and those are valuable to users. Think auto translation, Google account sync, other stuff.
Personally, I think Microsoft would have the best chance at this. They've been trying forever to get Windows to fit into a smaller footprint and failed over and over (Windows 10X, S Mode...).
They've got the browser, they've got the Sync integration, they've even got some Android apps (or, well, the Amazon Appstore, but best attempt?) They've even got the Win32 support from a cloud environment (Windows 365 Cloud PC). They could just market it as "Edgebook" or "edgeOS" or "cloudOS" or "liteBook" or something similar... Just don't call it anything related to "Windows."
If they really gave it their full effort it could be interesting hardware. It would be the product of choice for IT departments to deploy in companies that use Azure AD; for employees that don't need more than a web browser, or only need a Win32 app that isn't Microsoft Office on a rare occasion. As for education, just "we're not Google" is a nice pitch in some areas.
I think one thing putting Microsoft off though is that launching a non-Windows-based desktop OS is daunting; and also, one of the dirty secrets about how Chromebooks manage to get so cheap is they use the cheapest ARM processors with ridiculous amounts of binary blobs patched in that will never go upstream, so kernel updates are almost nonexistent (thus why many Chromebooks, even the one I bought from Walmart for $110 last week, have a ~5 year end-of-life). For Microsoft, maintaining customized kernels for each device that will never see an update, for many years, and basing a device's lifespan based on that kernel is antithetical to the design of Windows. Microsoft wants to ship one Windows to everyone, with an objective End-Of-Life standard, and relatively high-quality drivers; not a device-specific Windows, with a device-specific EOL, with binary blob drivers that merely hit the level of "functional on this one weird kernel".
> one of the dirty secrets about how Chromebooks manage to get so cheap is they use the cheapest ARM processors with ridiculous amounts of binary blobs patched in that will never go upstream, so kernel updates are almost nonexistent
I don't think that's actually true? For starters, the majority of Chromebooks are x86 machines, even most of the cheap ones. But more to the point, AFAIK Chromebooks, even ARM Chromebooks, are maintained mainline/upstream in linux. This is surprisingly hard to get a good citation for, but see ex. https://github.com/torvalds/linux/blob/master/arch/arm64/boo... which is device tree stuff for... honestly the code names confuse me, but I think kukui, jacuzzi, and fennel are all names for Chromebooks (or boards in Chromebooks, I think).
Just like on Android, there is Linux kernel, and then there are the stable ABI Google specific driver frameworks with OS IPC that will never be part of upstream.
> one of the dirty secrets about how Chromebooks manage to get so cheap is they use the cheapest ARM processors with ridiculous amounts of binary blobs patched in that will never go upstream, so kernel updates are almost nonexistent
doesn't seem to be true. Google doing its own thing in userspace is separately annoying to me but actually an advantage in terms of keeping the machine's kernel up to date.
You wouldn't need to fork it. Any of those companies could integrate their thing the same way that Google Drive is integrated into ChromeOS. Whatever their reasons are, it's not being stopped by anything that would be fixed by forking the project.
- dropbox
- Mozilla
- nextcloud
- Backblaze
has forked ChromiumOS and replaced the backends with their storage. That would be wonderful.