A dead comment asserts that the reason Plan 9 didn't succeed as "unix 2.0" is because of licensing, and because it only became open source "30 years late".
This is an interesting argument and perhaps has merit, but as a matter of fact: It became open source in 2002, 10 years after the initial 1992 release; albeit under a GPL-incompatible license. In 2014 it was released under the GPLv2; 22 years after the initial release. Either way; less than 30 years.
Only because I was just reading the Wikipedia page before I posted this :)
It looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.
— Eric S. Raymond
The original Cisco PIX firewall used modified Plan 9 as the operating system. In fact, despite the official history, the name PIX came from Plan 9, or Plan IX. I know this because the person who wrote the entire PIX software stack, Brantley Coile, told me.
Shoot, much of the Go lang team came from Plan 9. And they brought a lot of code and ideas with them.
Currently on my mind os `os.FileMode`; here's a comment I wrote in some Go code that interfaces with Python:
// A StatMode represents a file's mode and permission bits, as represented in Python
// (i.e. `os.stat()`'s `st_mode` member). Similar to how Go's `os.FileMode` assigns bits to have
// the same definition on all systems for portability, Python's `stat` assigns bits to have the same
// definition on all systems for portability. And it just so happens that Go's bits match those of
// Plan 9, and Python's bits match those of the Linux kernel.
type StatMode uint16
PS: If you weren't aware, Renée French's connection to Plan 9 and Go is largely that she's married to Rob Pike.
It's used, bizarrely enough, to communicate between the Windows and Linux sides of Windows Subsystem for Linux 2 - if I remember correctly, it's used to expose NTFS to the Linux side.
In general, 9P2000 is simple and fairly elegant. If you don't need POSIX semantics (and fs metadata), it's really quite simple to implement. For a bit more cost in terms of complexity you can go for 9P2000.u which makes things POSIXy enough if you've got a single client (as you do with VM -> host). This is great if you want to provide virtual filesystems, either proxied from the host or backed by something more exotic. In addition to QEMU, the gVisor folks (https://gvisor.dev/) have made heavy use of 9P (with enhancements) for similar reasons (in addition to Google being generally populated with Plan 9 aficionados).
Then, there's 9P2000.L... This has that "let's just take the filesystem vtable and export it as a protocol" flavor. This works well enough on Linux if you're just looking to translate the calls over into syscalls. I wouldn't recommend implementing a bespoke server for it, though. You're better off just implementing things with FUSE.
When you are done praising Plan 9, head on to Inferno and Limbo, which are actually the last OS developed by the authors at Bell Labs and contain the genesis of Go.
This is an interesting argument and perhaps has merit, but as a matter of fact: It became open source in 2002, 10 years after the initial 1992 release; albeit under a GPL-incompatible license. In 2014 it was released under the GPLv2; 22 years after the initial release. Either way; less than 30 years.