Saturday, January 22, 2005

Linus must step aside



Have you noticed that company founders or leaders often give up their pivotal role in a company that they have founded or been instrumental in leading? They either step aside or are forced out. Why is this? Because, in order for the company to continue to make progress and grow, they need to step aside. The smart ones recognize this - the dumb ones..... oh well.

So lets examine this phenomenon. The people we are talking about usually share the following character traits: They are brilliant, very talented, visionary and very demanding to work for. These character traits are what makes them different and allows them to create a company or product that others are incapable of. Those are the upsides. But there are corresponding downsides.

They are usually a royal pain in the ask to work with. Highly opinionated, very judgmental and apt to be very stubborn. They can also be inflexible. Again the smart ones recognize their weaknesses and surround themselves with other talented folk who help to balance out their personalities. It's not uncommon to find company partners with very different personalities and styles. And the dumb ones ... well no one can possibly be as smart or as talented as they are, and there's nothing wrong with their personalities anyway - so why even bother "playing well with others"!

So here's my point: Linus Torvalds must step aside and let Linux flourish. Linux has reached the personal limitations of Linus - it's creator and mentor. It's currently limited by the mental boundries and personality of its founder. Oh and yes - it appears the Linus does not recognize this problem and does not understand, that he has to step aside.

Lets take look at a serious limitation of Linux (the OS) which is a direct result of the limitations of Linus: Lack of a stable kernel API. According to Linus - having rigid APIs would limit the creativity of the kernel developers. Well ... yes it would, but it would also bring some decipline to the kernel code and it would allow a driver developer to deliver a device driver that does not have to be re-written every time the APIs change. It would also stop hundreds of developers from constantly rewriting and retesting their code every time the APIs change. It would also force the kernel developers to think with their minds and not with their keyboards!

But is this doable? Can the kernel APIs remain stable and not stifle developer creativity? Answer: Yes and yes. Look at Solaris 10 and the DTrace facility. Over 40,000 tracepoints in the kernel with negligible impact on performance, and yet, the tens of thousands of lines of code that I've written, going back to Solaris 2.5 and earlier, still run on Solaris 10 without any changes! And the same code runs on SPARC and Solaris x86 - with just a simple recompile. Time is money - and just think of the dollars involved by not having to constantly rewrite and retest Solaris based code.

On the flipside Linux has one thing going for it that Solaris does not have - a vibrant and active volunteer "army" of developers. But that's about to change when OpenSolaris goes live later this year. I'm a member of the OpenSolaris Pilot program and it's interesting and exciting to be perusing the crown jewels of Sun ... Solaris source code. Just think of it; you're looking at the fruits of the labors of hundreds of man years of effort from some of the most talented developers on the planet. Awesome.

So step aside Linus - or be run over by the OpenSolaris juggernaut.

4 comments:

Anonymous said...

Remember what happened to Apple when Steve Jobs left?

Look at Apple now, after his return.

(Just being The Devil's Advocate :)

Anonymous said...

Well ... yes it would, but it would also bring some decipline to the kernel code and it would allow a driver developer to deliver a device driver that does not have to be re-written every time the APIs change. It would also stop hundreds of developers from constantly rewriting and retesting their code every time the APIs change. It would also force the kernel developers to think with their minds and not with their keyboards!Sadly, it wouldn't. Everyone from RedHat to SuSE, to other major kernel developers have all made it clear that they will never guarantee a stable driver API, an d there doesn't need to be one since logically all drivers should be open source and belong in the kernel mainline. Any driver that isn't in the kernel mainline, probably isn't open source, and so tough noogies.

Dear < insert deity here > I wish what you suggested would be true.

Anonymous said...

It is a good thing that Linux has not had a stable kernel API. What would have happened if it had stablized at linux 2.0? 2.2? 2.4? 2.6.8? There have been significant changes (many for the better) since even 2.6.8. Before an API is stablized, it should be made as good as possible.

In hindsight, Sun's adoption of the DDI has been a mixed benefit. On the one hand, it is nice to have a single version of a driver that loads into various kernels. On the other hand, the DDI wasn't the nicest of interfaces, even back in the day. And it is quite long in the tooth now. The driver model in recent Linux kernels is far cleaner, and today it is easier to write a clean, correct Linux driver than a Solaris driver.

Anonymous said...

I personally would love to see Linux get 'run over by the OpenSolaris juggernaut.'

Linux served its purpose, making a Unix-like system affordable and accessible to all. Now that Unix is being opensourced, who needs Linux?

I mean, why use some Unix-like system, when you can have the real deal.

Besides, Linux has become more of an alternative to windoze than an alternative to Unix. I use it [ Linux ] on one of my desktops, but would never dream of using anything but Solaris on a server.

Sorry for ranting, I'm just pissed that Linux gets so much attention and recognition, and the same people who speak so well or so poorly of it, often haven't even heard of Unix.

So, to sum up: Solaris is superior to Linux and *always will be* - let Linux be the cult that it is, and if it ends up sucking as result - so be it.