OSNews

If they wanted the component model and the re-use benefits, they needed the OS, take it or leave it. Well, they left it, consistently, in Japanese, Korean, Dutch, French, English, and other languages. Whoops. We blamed the failure on a lot of things, but eventually, we faced the obvious facts. One, the interface of a desktop, server, or embedded OS kernel has been refined over time to become a more programmable machine than the instruction set. It's a standard conceptual interface. The same way you have the Intel and ARM instruction sets that support similar operations, you have posix, Windows and µITRON APIs for memory management and semaphores, but they are conceptually identical. If you offer radically different primitives, application programmers will not make use of it, for the sake of portability of either the code or their knowledge.

Two, a platform needs applications and a developer community in order to succeed. You have neither when you create a kernel from scratch. You could copy an existing design and API in order to have applications and developers, but it has already been done. Linux and BSD are free and fit almost any purpose.

Three, a new OS and code re-use are contradictory. For some reason, we couldn't sell to our prospects that they could re-use a lot more code than they currently do, and could architect their software a lot better, by throwing all their code away and rewriting it for our OS. Our prospects had the nerve not to want to invest millions of dollars to rewrite software they already had.

Four, you can be the world's best, or even really, really good, at only one thing. Everyone acknowledges this is true for a small to mid-size team, and I believe this applies to any organization, even the size of Microsoft or with Google's coffers. Microsoft does a lot of things, all of which lose a remarkable amount of money on fire and motion, except for their operating system and tightly related core applications. Google's managers won't touch anything not clearly related to search. Management droids even have a name for this: the hedgehog concept. Hedgehogs are really stupid animals, but they are superior to many, in the sense that they only know one thing, rolling into a ball of spikes when attacked.

Fifth, there is no entitlement when you design something. Your users, whether they pay for a commercial product, or they use a Free/Open Source piece of code, do not care that you spent thousands of hours of really hard work to come up with what you offer to them. Syllable and SkyOS are really neat technical achievements, but they are less functional than Linux and are not attracting normal users in droves. Linux still has to figure out how to be better than Windows on the home desktop in order to win users over.

Armed with this reality check, my company repositioned its product away from the operating system and sharply on the component model and code-reuse. Essentially that meant porting our OS on top of the popular platforms in Japanese Consumer Electronics - Linux and TRON at the moment - then removing what wasn't needed anymore. All of a sudden, customers started calling us to buy our product. By focusing on our one good idea, we were then able to make our component model cover a lot more needs, and today I think it is really a decent product. In retrospect, trying to shift them to a new OS had felt like pushing a rope.

Do I like working on what we sell now? Along with a couple of the programmers that were attached to doing kernel development, I really did mind that the market chose the least fun feature to work on. I couldn't use my kernel programming experience anymore. Then, I realized that in comparison to writing kernel code, anything else is easier. It's like training for a tennis match with weights and then removing them for the big game.

The skills you build for kernel development, the precision, rigor, testing, careful debugging, can be reused with nine times the efficiency when working on something above the kernel. You just have to find what can really motivate you and has a purpose to work on.

My company is not the only one that had this epiphany, it looks like. The Tao Group used to sell, guess what, an operating system for consumer electronics. You probably have heard of them as part of the Amiga saga. Their claim to fame is the Virtual Processor architecture, that lets you write portable but hand-tuned assembly code. Somehow they make this work. When the penny dropped, their OS, as a product, was taken out and shot, and now they are very successfully selling their one good idea. Their VP architecture allows very efficient, graphical content, that is portable across all CE devices. The JVM they designed on top of their VP architecture is mighty. They've found their one good idea and swept the rest under the rug.

Okay, so the second storyline was a bit longer than the first. If you don't hear from me for the next two years, please send me care packages at the Article Writing School. Now, both storylines are high speed trains going towards each other and they just collided.

1. "Do not write kernels, Page 1/3"
2. "Do not write kernels, Page 2/3"
3. "Do not write kernels, Page 3/3"