While this does not represent all of the Solaris code base, the launch of OpenSolaris does mark the beginning of a new development model for what was formerly Sun’s Unix variant.
Now, Solaris is yours and mine to do with what we will.
This is a powerful concept, and one that should not be trivialized. If anything has the chance to preserve and extend the use of the Solaris platform, which is undeniably one of the most stable, secure, and widely used enterprise-class operating systems in the world, then moving development to an OpenSolaris community is probably it. And now, the Solaris operating system can even outlive Sun, if need be. No one is talking about that, but it is obviously true.
However, taking Solaris open source is not a last ditch effort by Sun to save itself, as many of Sun’s competitors might have us all believe. It is as much Sun returning to its roots in the open source community from which it was spawned, just as IBM’s and Hewlett-Packard’s embracing of Linux were an effort for them to actually grow some roots and gain some cred in the increasingly open source world.
All three had open systems cred – they all have Unixes, they all support open APIs, they all talked the open systems talk for many years – but open source takes it one step further and actually lets go of the code. This is something that Sun ought to do with Java, by the way, for all the same reasons that it has just let go of Solaris. If OpenSolaris works, the days of the Java Community Process are numbered.
While OpenSolaris is not yet the vehicle through which Sun’s own 1,000 software engineers go about the task of creating new features and making fixes for the commercialized Solaris environment, over time Sun expects that an increasing percentage of those Sun engineers will get their paychecks from Sun, but really end up working for the OpenSolaris community and developing code in conjunction with Solaris enthusiasts, bit twiddlers, and bona fide hackers (in the original good sense of that word) from all over the world.
The code base that is being distributed through OpenSolaris is a tweaked version of the code base that Sun froze when it released its Solaris 10 operating system at the end of January. Since its January launch, the commercial product, which has had over 1.7 million downloads as of this week. While Solaris 10 is distributed for free, it is a closed source set of binary programs compiled for Sparc and X86/X64 platforms.
On opening day, OpenSolaris is an open source set of code that has actually had various tweaks, changes, and bug fixes added to the core Solaris operating system. The OpenSolaris that was released yesterday includes the core kernel, the network stack, the system libraries, the Solaris command, and key new features of Solaris 10 such as DTrace, Solaris container virtual partitions, and predictive self-healing features; it is missing features such as the Solaris installer and administration features. But in a sense, that OpenSolaris is a more current release than Solaris 10, even if it is not, as yet, complete.
Like the commercialized Solaris 10, OpenSolaris has the same code base for Sparc platforms as it does for Opteron platforms, and the OpenSolaris community will almost certainly want to keep it this way. What happens to the OpenSolaris code base when someone puts together a port of Solaris to PowerPC or MIPS or Xscale chips (there are zillions of these being sold in embedded devices) remains to be seen. Sun’s CDDL and the OpenSolaris community are not only allowing such ports, but were created explicitly to try to encourage them. Obviously, keeping the code bases as tightly synchronized as possible makes sense, but whether this will be technically possible remains to be seen.
The exact naming conventions for OpenSolaris, the version control system, and the process by which changes and additions are made to OpenSolaris have not, as yet, been set. The reason why, of course, is that Sun feels correctly that it is not up to Sun to determine these things, but rather the OpenSolaris community.
Claire Giordano, a Sun engineer turned marketing executive who was instrumental in the creation of the OpenSolaris community and its Common Development and Distribution License (pronounced cuddle, by the way), says that the community will probably add a hardware compatibility list of its own, separate from Sun’s own list, as OpenSolaris gains support for more machinery. As for naming conventions, something akin to what the open source Linux and BSD Unixes use, which denote which branches on which ports are current, stable, and development releases, seems logical. But the OpenSolaris community will decide how it proceeds.
It might seem pretty daunting to try to compete with those 1,000 Sun engineers in understanding and helping to craft the future Solaris platform, and Ms Giordano and her colleagues know this. A newbie developer who is just getting a look at Solaris for the first time is not going to be able to contribute a new feature like DTrace right out of the chute. But the OpenSolaris engineering team has posted a roadmap on the opensolaris.org Web site that has a bunch of relatively easy things for contributors to take on.
Ms Giordano says that this is how Sun’s own newbies get started – they get assigned a relatively easy task such as making a bug fix or adding a small feature to get them acquainted with the code base and the processes by which Sun goes through changing the code. That list has under 100 things on it now, but as the community develops, the list will grow, she says.
The thing to understand is that we are not just open sourcing Solaris, but moving Solaris to an open development process, she said. You don’t need a Sun badge any more to participate. However, participating could eventually lead to a Sun – or another company’s – badge, which is one reason (among many) why people contribute to open source development projects.
Whatever reasons people have for contributing, what they contribute will most certainly matter. Future versions of the commercial Solaris operating system – Solaris 11, Solaris 12, Solaris 13, and so on – will be based on the code that the OpenSolaris community creates. Sun will take OpenSolaris and qualify and certify it on specific pieces of gear and for specific sets of software – this will be Sun’s value add, and what it charges money for in some form or another (very likely through tech support services).
According to the roadmap, the core Solaris code can be built using the Sun Studio 10 compilers, and within the next three months it will be possible to do a build with the GNU gcc compilers. Over that same time, Sun will be tossing in more Solaris code to cover cryptography and other drivers (such as for Sun storage products) and various graphical user interfaces (Gnome and the Java Desktop System) as well as a freeware and open source companion CD image.
Within six to nine months, the OpenSolaris community expects to deliver test suites of the complete code, and within 9 to 12 months Sun will roll out the installer program (which Sun is apparently going through line by line to make sure it doesn’t violate anyone’s copyrights by taking open source) and various administrative tools that are part of what makes the Solaris 10 platform useful in commercial settings. OpenSolaris expects to have some form of source code management system in place within 3 to 6 months, workflow tools to manage patch submissions and such a few months after that, and a more refined development process within 9 to 12 months.
