Solaris is from Venus, Linux is from Mars

I thought SUN’s new release of Solaris 10 on x86 would be a great place to start my Blog.  If you’re looking for detailed feature descriptions, you can find those on the SUN web site, or even get a perspective from any number of industry analysts.  My goal here is to highlight all the things that SUN might not be telling you about Solaris 10/x86, but that you really should know about, or at least questions to be asking.  Keep in mind that this discussion is about Solaris on x86 and SUN’s attempt to take on Linux, unless I specifically call out Solaris on SPARC.

Is it really Solaris? 

While it should be obvious, be very clear that Solaris on SPARC is NOT Solaris on x86.  There are a couple of reasons why this is significant.  First, all of your Solaris/SPARC applications don’t work.  So, just because you have a Solaris application doesn’t mean it’ll run on Solaris/x86.  I do have to give SUN some credit for marketing these things as though they are one in the same.  Next, there’s the issue of byte-ordering.  Solaris on SPARC is said to be “big-endian”, while Solaris on x86 is “little-endian”.  Without going through the details of endian implications, think of it like a mirror.  When you look at yourself in the mirror, it’s you, but backwards.  When your data is written with Solaris/SPARC it’s like the real you, but when Solaris/x86 looks at the data, it’s backwards.  While it’s true that the big applications like Oracle and SAP will take care of this for you, all of your other data that’s not under the control of a big application will need to go through some form of a migration.  And, if you have both Solaris/SPARC and Solaris/x86 in your environment, don’t think your data can just move around without serious planning.

Is it really open? 

While Jonathan at SUN has talked about open sourcing all of Solaris, what we don’t know yet is exactly which license he plans to use.  Also, SUN has only talked about open sourcing Solaris on x86, and not the big guy, Solaris on SPARC.  That means that any code that tunes Solaris for SPARC won’t visible no matter which license SUN uses, and we can likely expect that they will hold a few crown-jewel algorithms to themselves.  So, ask yourself:  If Solaris on SPARC is proprietary and Solaris on x86 is open source, which Solaris am I running, and how far will they diverge?  Until we know which license SUN plans to use, it’s difficult to know exactly how open Solaris/x86 will be.  SUN has a history creating licenses that are supposedly open, but allows them to remain firmly in control.  Remember Java?  When it comes to Solaris 10, I encourage SUN to not create a new license, but to just use the GPL.

Why I don’t think SUN will use the GPL 

As soon as the Solaris code would become licensed under the GPL, developers would be able to take all the parts they like about Solaris 10, and move them to Linux.  That would cause SUN to be doing the one thing they are trying most to avoid: help Linux.  In fact, I suspect SUN’s new license creation will be specifically designed to make sure it’s not compatible with the GPL.  I’ll add more specific commentaries once I get to see exactly how SUN accomplishes its goal of an open source Solaris.

Who can check-in code? 

One of the other big tests of SUN’s approach to open source, is who will have check-in privileges to the main source tree.  I’ll be anxious to see if SUN will allow non-employees will be able to check-in source code changes.  If SUN wants to truly demonstrate openness, they need to create a governance model around Solaris that gives the community equal weight on the evolution of Solaris on x86.  The fundamental problem that SUN will have with this approach is that it would remove their ability to control the direction of Solaris on SPARC, and maintain synchronization with the x86 release.

Linux inside; Well, maybe

SUN is touting Solaris on x86 as integrating “Project Janus”.  Janus is a kernel facility which would allow you to run your Linux applications directly on Solaris.  While even I can think of a few cool uses for this, there are few problems with this approach that SUN neglects to mention.  The most basic is that by including this capability, SUN is admitting that there far more applications available on Linux.  If the most applications are on Linux, why run Solaris?  The next is that SUN is including compatibility with Red Hat Enterprise Linux 3 (RHEL).  Red Hat continuously updates RHEL through their Red Hat Network (RHN).  These updates make sure you have the latest patches for security and any other defects that might have been repaired.  Now the question is how does Solaris’ RHEL clone keep up with the real RHEL? What happens when RHEL 4 comes out?  What’s the lag time?  I’ve also been unable to find clear and reliable information on Project Janus’ support for 64-bit Linux.  While SUN touts that Solaris 10 on x86 support both 32 and 64 bit applications, I would like to see a clear mention of Janus’ ability to support more than just 32-bit Linux binaries.

Is Janus Indemnified?

The big part that confuses me about Janus is that SUN has a made a big deal about IP protection in Solaris 10, and offering indemnity.  What I can’t find out is if the “RHEL 3 Clone” inside Solaris 10 is indemnified along with the rest of Solaris 10.  If it’s not, then where exactly is the line of IP protection with running Solaris and running Linux applications inside Project Janus?  Jonathan, I could really use a blog entry to help me figure this one out.

Applications need developers

Through its Janus facility, SUN admits that there are more applications available for Linux.  The fundamental reason for this is that Linux has won the hearts and minds of application developers everywhere.  Developers for UNIX and Linux tend to use a collection of personally chosen tools that is unique to them and makes the individual developer the most productive.  Take a look at Freshmeat’s collection of more than 9,000 developer tools and ask yourself how many will ever be supported for Solaris.  If that’s not enough to convince you, have a look at the more than 12,000 developer tools under development at Sourceforge.net.  In the end, if the developers are writing for Linux, then where are the applications for Solaris going to come from?

Where will the developer community come from? 

Highlighting the massive community that’s building developer tools for Linux also highlights that there is currently no developer community around Solaris.  There is sometimes a misconception that open sourcing a software project guarantees that thousands of developers will come and play.  It’s just not true.  The Linux kernel, and the hundreds of other projects that make up a Linux distribution, have been building communities for more than 10 years.  If Solaris 10 simply represents yet another variant of a POSIX-based operating system, what possible motivation would the Linux community have to move their allegiance to Solaris from Linux?  The very fact that SUN will need to keep Solaris on x86 and Solaris on SPARC synchronized will make it impossible for anybody else to take the project in a direction other than the one SUN wants to go in.

What problem is SUN trying to solve? 

There are generally a few well defined reasons why someone open sources a project.  The goal is usually to build a community to share the work of developing the project of common interest.  This sharing brings ideas into the project from a very diverse set of perspectives, and often the project heads in a direction that is very difficult to predict, representing the collective self-interests of the constituency of the community.  Obviously, sharing the cost of development can be a big motivator as well.  From these motivations, other benefits become apparent:  The visible code allows one to quickly identify defects, or to choose a number of different avenues for support.  However, if SUN is going to control who can check in the code, as well as maintain feature set congruence with big brother Solaris/SPARC, then any of the benefits of an open source environment rapidly disappear.  The simple act of making the code visible does not magically turn Solaris into Linux.

Ah, but what about TCO? 

One of the parts of the TCO equation that everyone seems to be ignoring is the sustainability of SUN’s Solaris pricing plan.  In order for any company to remain viable, it eventually needs to charge enough money to cover the cost of making the product, and hopefully even make a profit (although SUN seems to have forgotten how to do that in any reliable way).  The beauty of Linux is that the cost is shared by thousands of developers around the world.  Companies like Red Hat and Novell can sustain lower costs by leveraging this community of developers.  You might be excited if Ford was willing to sell you a car for half of what it takes to make it, but at some point, if Ford can’t make a profit, they won’t be around to make sure your car keeps running.  I’ve already established that it’s unlikely that SUN will be able to build a community to share in the cost of continuing to develop Solaris.  That means SUN has to pick up the R&D tab on their own.  I recently read an analyst report that pegs SUN’s investment in Solaris 10 at $500 Million.  According to key industry analysts, SUN has sold less than 30,000 x86 systems this year, with only a few more than 7,000 of those running the current version of Solaris on x86.  That compares to more than 1.6 million x86 server units for HP (all operating systems), 1.2 million x86 server units for DELL (all operating systems), and 800,000 x86 server units for IBM (all operating systems).  SUN has absolutely no comprehension of what volume really means.  There were almost 1 million server units sold in the past year to run Linux on x86.  Now, you do the math.  How many people will want to run Solaris on an HP, DELL, or IBM platform?  How long does it take to go from 7,000 Solaris units to 1 million?  How sustainable is that $500 million investment?  What possible chance does SUN have to grow a 30,000 unit x86 server business to compete cost-effectively when the big three sell a combined total of more than 3.6 million x86 server units?  Do you still think the TCO adds up?  Whose car do you want to buy now?

In the end…

There’s one last part that I’m desperately trying to figure out, and that’s SUN’s real strategy.  Linux is apparently ok for desktop stuff as evidenced by their work on StarOffice, and JDS.  However, it appears that Linux is not acceptable for the server, as evidenced by their current push to encourage customers to move to Solaris on x86 from Solaris on SPARC, and obviously compete with Linux.  Next, they would like you to develop applications on Java, but then encourage Linux native applications to run under Project Janus.  In the end, I’m very confused.  Which is it, Solaris or Linux?  Native or Java? 

If Solaris is from Venus, and Linux is from Mars, sorry Jonathan, Venus is way too close to the SUN, I’m going in the opposite direction and to the red planet……