OpenSolaris: No Standing Still On A Moving Train

Yesterday I sat down on the phone with Larry Wake -- official title: Group Manager, Solaris Strategic Marketing -- to chat about OpenSolaris. I ended up with an answer to an unexpected question: How do you get people who use software measured in lifetimes of years and decades to move to software lifetimes of mere months?

This insight actually came towards the end of our conversation, when I pointed out that the way OpenSolaris related to Solaris generally seemed to be designed to have an impact on existing Solaris and Solaris-application users. Most of them, I opined, tended to set up a Solaris installation and just ... leave it alone. Five, six, seven years, whatever the support lifetime of the product might be. A good part of that was easy enough to do, because many of the things that they ran in that stack -- including Solaris itself -- were only updated once in a blue-green moon.

Now all that has started to change. OpenSolaris's release cycle is meant to be closer to Ubuntu than previous versions of Solaris -- once every several months, with new core features rolled directly into it. When I opined that this made OpenSolaris sound like Fedora to Solaris's RHEL (a parallel that's been drawn before), Larry put it this way: Fedora's the place where future technologies to be used in RHEL are staged, but it manifestly isn't Red Hat. OpSol, on the other hand, is manifestly the next version of full-blown Solaris, and Sun wants it that way.

That leads me back to my previous point. If Solaris as a whole -- both OpSol and Solaris -- is moving to a much faster upgrade cycle, how do people get used to that in a product environment that's been tuned to only handle upgrades that took place every several years or so? Is there a compelling reason for them to upgrade more frequently, when before they did no such thing?

Sun doesn't have a full-blown methodology for this yet, but they are starting to offer a way towards it: use OpenSolaris to get people's hands dirty with the new features, and even let them run it in a production environment. (Little-known fact: people with Solaris support contracts can substitute OpenSolaris for the regular version and still get Sun support.) Then let them move to the next real version of Solaris, which maintains binary compatibility with previous editions -- something Sun sweated blood to make sure of -- and continue where you left off.

Did Sun need to make Solaris open source as part of this methodology? No, but from what I can tell, it seems to have been a big help -- it removes a lot of the burdens of getting one's hands on the software, on making immediate use of it in a production context, and all the other things (contributing, modifying) that are part of the usual open source environment.

Our conversation touched on a lot more than that, and I want to go back and talk about it in future posts. But this particular subject was worth breaking out on its own, for a whole host of reasons. Sun's positioning Solaris more than ever as the key element in a kick-butt application stack -- both for open source and closed third-party binaries -- and if the pace of development on all of those things is only going to move faster, it makes sense to not leave their own customers behind.

InformationWeek Analytics has published an independent analysis of the current state of open source adoption. Download the report here (registration required).

Follow me and the rest of InformationWeek on Twitter.