I've heard Fuchsia referred to as a "principal engineer retention project" at Google. I'd be curious to know if others have heard the same.
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/c...
https://docs.github.com/en/free-pro-team@latest/github/creat...
https://docs.gitlab.com/ee/user/project/code_owners.html
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.
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.
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.
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.
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.
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.