The Plan-9 Effect or why you should not fix it if it ain't broken
I am quite sure that you do not know what Plan-9 is and that, probably, you never have heard of it too.Plan-9 was an amazing new version of Unix created by the very same team that in the 70s created Unix. It was really an amazing operating system. It was quite similar to Unix but it was not and it corrected many different idiosyncrasies that Unix had and still has today.
Unix was created under the promise that everything was "file"… by some definition of file. The fact is that not everything in Unix is a file. For instance, sockets — better, network connections — are not files and processes are neither.
In Plan-9 all of that was finally solved! The amazing 9P virtual filesystem protocol finally made everything a file. Directories started being "namespaces" and the resources were mapped to files… how wonderful! Now, it was possible to know what a process was doing just invoking "cat" on some file in the /proc directory (now a namespace). In the same way, it was possible to open a network connection just opening a file inside the /net/tcp directory and that's it. The system call "iotcl" was eradicated by the system since there was no more need for such an abomination in a modern (finally) file based operating system.
So, why didn't you ever hear of such a wonderful piece of software?
The reason why you never heard of it is that it did not succeed. How is that possible? Well, it is just because Plan-9 was fixing nothing at all. No one, in the Unix world, ever complained about the Unix's missed promise about file abstraction.
In a matter of months the /proc filesystem was introduced in Solaris and in many other commercial Unixes (Linux does have it as well). Another famous introduction of Plan-9, UTF-8, was rapidly adopted by many other operating systems and not only by the ones in the Unix family. In all the operating systems that did not adopt UTF-8 (for many different reasons) libraries were created in order to translate from the native encoding(s) and UTF-8.
Plan-9's way to interact with the network needs a special explanation. While it appears wonderful to have namespace/filesystem based approach instead of ad hoc API for dealing with network operations, everyone in the Unix world — and not only — already adopted the Berkeley Socket API as the standard way to do network programming. Even Windows — with some minor glitches — implemented exactly the same API in order to simplify the porting of network applications to Windows.
Furthermore, the disruptive way that Plan-9 introduced to change the way network programming was done was totally useless at the moment in which it was introduced. At the time, the majority of people doing network programming already moved to an higher level of abstraction. RPC and Corba were already introduced and all the applications needing to communicate with remote services already moved to those. The programmers needing to open sockets in order to communicate with remote services were less and less every day and all of them were already used to the Berkeley API. (As a side note: there is a POSIX emulation layer, called the APE — ANSI/POSIX Environment — that remapped some of the Plan-9 functionalities into a set of POSIX functions. This layer was never completed and the porting of complex application, such as X11, was impossible because "supporting it properly is too big a job" — Wikipedia).
One of the major problems with Plan-9 was that AT&T and the people behind Unix, while they were incredible scientists and programmers, they were not used to create commercial software and AT&T has never been in the software business. This, I have to admit, can sound as a blasphemy but it is the way it is. They used software and they used to produce internal software to run their high end network appliances but they never created software to be sold to someone else and it never was major source of revenue as, for instance, Sun, IBM and Microsoft used — or still use — to do. This just means that they never had a sense of what could have been needed into the outside world. For instance, Sun Microsystems used to and that is the reason why RPC was created. They realized that people struggled with network programming and they saw in creating an abstraction layer a commercial opportunity: "Hey people, SunOS has this cool thing that permit me to do network applications without messing up with sockets! Better moving to SunOS".
Moreover, in Plan-9, many of the "good old things" were removed and a lot of incompatibility was introduced in the system with respect to the other Unixes. This prevented many different companies to even start thinking of porting their applications to Plan-9. What is the point of trying to port your software, doing a huge amount of work, to a new platform if you do not know if that system is going to succeed? This is the classical chicken-egg problem: an operating system is worth only for the amount of applications running on it and nothing more. If a system is new, you need to be able to guarantee that you are going to have an ecosystem of applications that will make the operating system valuable. There are only two ways of doing this. The first one is to create a system that is as compatible as possible with the existing ones — and this is the case of Unix, POSIX and Motif. The second one is to create the ecosystem yourself in order to improve the value of the product — and this is the case of Microsoft Windows and the Office productivity suite.
Can we draw a conclusion out of Plan-9 history?
Well, we can actually draw a bunch:
The first one is not to try to fix things that are not broken or better, if you want to fix them, only fix the broken pieces and do not try to fix what is clunky but it does, somehow, work as it is intended to. For instance, UTF-8 is a wonderful idea and you need to do that but you can implement that in libraries or subsystems in such a way that you can use it in other operating systems more than create an operating system all around an encoding system.
The second one is to try to identify if there is a market or even just a need for the thing that you are going to build. For instance, the /net/tcp filesystems was a brilliant pure research topic that would have been a perfect concurrent to the Berkeley sockets if it would have been built years before but not at the time in which the amount of people actually opening a socket had shrunk to just a bunch of people.
Third one is to being totally autonomous or to be compatible with what is already there. Pan-9 was exactly in the place where it shouldn't have been: in the middle. It constructed a system that was incompatible with all the other Unixes around and at the same time did not provide any of the productivity tools that the other Unixes used to have and were bought for. There were no advanced text editors, spreadsheet applications, CAD programs or server applications. It was a wonderful empty box of a shape that made impossible to fit whatever was already around into it easily enough.
All of this looks like to be some very high level stuff and not very applicable to a developer's day-by-day life. While it is true that it is the way it looks like, it is actually not the way it is. Nowadays, it is quite easy to create your own start-up and start providing a service of some kind to the users. Anyway, if your service it worth being called a product or not and if it is just a novel Plan-9 or not is no simple matter of opinion. For instance, if you want to create your own reporting system for monitoring services or any other kind of visible state and you choose not to give the users the option to export such reports in Excel you lost far before writing the first line of code. If you plan to create a new web based social-thing and you do not accept Facebook, Twitter or LinkedIn as ways to log in, you lost before switching on the webserver. If you decide to start exporting the notifications of your service not in RSS or ATOM but in a brand new format, guess what? You lost before start having the very first user. But, more important than everything else: are you actually solving a problem that really exists or not?