With my OGB seat came a re-newed effort on my part to really look long and hard at where we’re at (OpenSolaris) and where we need to go. There are a lot of problems that need fixing, most of them frankly are social, not technical.

A common sentiment has been that OpenSolaris is “open, but not really open”. I’ve expressed this view myself… but what does it mean?

OpenSolaris, by which I actually mean Nevada, is in fact “Open Source”. Its code is readily available complete with gobs of tools and supporting componants. There is an constantly declining number of closed componants, but those are not required for OpenSolaris to be usable. Its covered under an OSI approved license. And, if we look at Richard Stallman’s criteria, we meet them all:

• Freedom 0: The freedom to run the program for any purpose.
• Freedom 1: The freedom to study and modify the program.
• Freedom 2: The freedom to copy the program so you can help your neighbor.
• Freedom 3: The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.

Its important to note that I can’t find a single definition of free or open source software that requires the original code author to accept improvements back. So long as you can modify and redistribute you fit the definitions.

So why isn’t OpenSolaris truly open in the minds of many community members? It comes down to what “open” really means. There is a distinction to be made between “open source” and “open development”.

Some people use the term “openness”. This can refer to either the quantity of code thats open, such as in the case of closed applications that release certain modules or API’s as “open”. It can also refer to the development model associated with open source codebases that are distributed as a binary software package, commonly a commercial application. For example, Cisco could release IOS code completely under an OSI license, but if you couldn’t get modifications back into Cisco routers you might be tempted to say “not very open.”

Applied to OpenSolaris, the problem is all the hurdles to pushing changes up-stream so that they appear in a GA release of Solaris or Solaris Express. Currently those hurdles include signing the Sun Contributor Agreement, requesting and then working together with a “sponsor” who helps you with code review and walking you through the integration process, etc.

So we might conclude that a “very open” project is one that readily accepts patches and integrates them so long as they are appropriately licensed (commonly this is just assumed, actually) and don’t break anything (an informal code review, typically with the outcome of “yes” or “no”). At some point you contribute enough patches to be trust worthy and you get commit access to the repository. A lot of projects function in this way, I’d say most of the projects you see on Freshmeat or SourceForge run in this way.

To be honest, do most people adopt that sort of model because its philosophically superior? Not really, its just low hassle. If someone has good stuff to add, great, but no one is gonna baby sit the contributions typically, if it breaks anything its gone and future contributions are more closely screened. I use this model for my own projects, such as ToasterView, but not for any great reason, just because I’m happy to have others help fix bugs, but I don’t want to manage an effort. In the case of ToasterView someone actually made enough changes that they forked it, and I was happy that they did… ToasterView is still alive and well, but there is a great (and superior) alternative now as an independent development effort, and I’m very honored by that.

Solaris, by any name, is a big beast known for its quality control and stability. Sun would be irresponsible to make up-stream integration easy… its not easy for Sun employees, frankly. So how do we make contribution easier?

The method in place today, as re-iterated by Dr. James Hughes, Solaris CTO, in the January SVOSUG meeting, is to “train” external contributors to embrace long standing internal development methodology, with the hope that over time people will become more and more accustom to it and accepting. There are some ups and downs to this. The “up” is that if your a student, for instance, who really wants to know what developing software in a big shop like Sun is like this is a great opportunity. But for the weekend warrior or SysAdmin who just wants to push in a bug fix or one-line patch its a major pain in the butt.

Lets just assume, for the time being, that no matter what happens contributing Solaris code upstream is going to include sponsors, and ARC, and C-Teams, and all those things. What do we do?

Well, we want to make our community more “developer friendly” in general.. that means we want to provide the resources to work on what they want to work on. We can encourage that by making projects easier to instantiate. Want to develop an extension for SMF? You should be able to go to the SMF community, outline your idea and request a project, if approved you get a project space, mailing list, SCM repo, and you’re off and running. When your code hits some maturity point, you go back up to the SMF Community Group and start pimping your bad ass code. This allows you to work with minimal hassle and attract other developers that might want to help, all the while doing it in close relation with the SMF core team.

A next step might be to provide some place where people are encouraged to share changes that aren’t ready to go through a formal integration process. Thanks to distributed SCM’s like Mercurial (Hg) pushing change-sets around is really easy. OpenSolaris currently provides resources for posting WebRev code reviews: cr.opensolaris.org. Its possible that better advertising this existing resource might be enough to ease the process. Pull down the code you want to work on from Hg, modify it, create a WebRev based on your changeset, post it to cr.opensolaris.org, and shoot out a mail letting people know its available if they want it, and just walk away.

The extreme, of course, is to fork a given repository. Anyone can create their own ON repository, Genunix has provided an SVN repo for years now at svn.genunix.org. It would be easy enough to create an “open dev” codebase that is sync’ed with the master gates but allows commits from a variety of community contributors.

But the question is… are those things enough? What do we really want to get to? Will I, Ben Rockwood, ever have the ability to commit to the main ON Gate at will? No… even Bryan Cantrill has to go through code review, ARC, etc.

This is where we need to have a community dialog. If we could do anything we wanted to the OpenSolaris development and contribution model, what would it look like? We need to gather those opinions together and then temper them against reality to see if they can work.

I encourage you to ponder the question and share your opinions here or on an appropriate OpenSolaris maiing list so that we can all collectively drive towards the “place we want to be”(tm).