I’ve been asked to provide some insight in this blog regarding the activities of the OpenSolaris Governing Board (OGB), and so I’m delivering.

I debate is raging on the OGB-Discuss list regarding the nature of our community, its future, and the applicability of our current Constitution. From the outside it might seem a bit unruly, and to some extent it is, but let me help sum up the nature of this debate and its importance.

As I’ve stated in the past, the OpenSolaris community is a social organization first and foremost, built around the source code that makes up the Solaris core operating system, currently known as “Nevada”. The scope of the community has grown over time with the additional codebases being opened, such as Sun Cluster know in the open as “Open HA Cluster”. The community is still chiefly focused on Solaris code but we’re growing. Activities of the community range from various documentation efforts (led by the Documentation Community Group and its projects) to evangelism activities (led the Advocacy Community Group and its projects) to bug fix (this is more of a gray area).

We have two intertwined discussions going on.

The first is about the structure of our community as defined by the Constitution. The model comes from the Apache Software Foundation (ASF). Community Groups (known as “projects” at ASF, Ant is an example) are the heart of it all, here there is a governance structure composed of “Core Contributors” who you can think of as the Core Team, and “Contributors” which is a more generic term for “developer”. Contributors and Core Contributors both have voting rights both in their Community Groups (CG for short) and the community in general for OGB elections and ratifications. The Core Contribs and Contribs from all the CG’s together comprise the membership of the OpenSolaris Community en mass.

Community Groups can create Projects by an approving vote of at CG’s Core Contributors. Projects are provided with special resources on OpenSolaris.org including a SCM repository (either Hg or SVN, it’s your choice), a web structure, etc. Projects then can go off and do work. The intent is that the CG Core Contribs will be there to offer assistance, guidance, and leadership when required.

Currently we don’t actually enforce this structure. Projects are created by but not explicitly owned by a CG, rather a project can be “endorsed” by any number of CG’s (there is actually a page of check boxes in which your CG can just check off any and all Projects which it wants to endorse). Some people feel this is a strength, others a significant weakness.

Another problem is that most of the current Community Groups, which are formed by submitting a proposal to the OGB for approval, pre-dated the existing governance. They were created more so as Special Interest Groups (SIGs) for the website around launch time and have existed since. For instance, “Storage” is a CG, “ZFS” is a CG, “Desktop” is a CG, etc.

The infrastructure provided to projects and CG’s contributes to another problem, each of these entities has a mailing list. This is why we have more mailing lists than I can count, some of which are accessible via Email or Web via Jive Forums, others that are straight up Mailman mailing lists.

The second issue is how this structure relates to development efforts. This is where terms unfamiliar to many start flying around such as “ARC” (Architecture Review Committee), “Consolidation” (a specific functional area of Solaris), “C-Team” (Consolidation Team), etc, which are either unknown to much of the community or, at best, highly misunderstood.

Naturally the debate revolves around how to continually “open up” development of the codebases while still maintaining quality through existing procedures.

The position Sun seems to have taken, and sticks to, is to modernize existing internal procedures and methodology (such as moving from Teamware to Mercurial as the SCM) and making that process more externally visible and accessible. This is why contribution today is only possible by requesting an Sun internal developer to work with you, walking you through the process ultimately leading to integration into the golden repository inside of Sun. In addition, it is required for all developers to sign a Sun Contributor Agreement (SCA) to ensure Sun has all the rights it needs from a legal perspective regardless of the license you contribute with. (NOTE: There is some debate about this actually that I’m exploring privately with the appropriate persons at Sun and will divulge my findings when I know what the story is.) Today the primary repository is secure within Sun but plans are in place to create Mercurial repositories that will act as bridges, one that is synced for read-only checkouts, another which accepts commits which are screened before being put into the master Teamware repository (known in Teamware-esse as a “gate”).

I’m raising a question though… is integration in the way described above all there is? While the code is open and there is a method to integrate code back into the respective internal gates, the OpenSolaris community actually has no control over them. Thus, the OGB doesn’t control that code, only the social organization (community) around it. As I described in my last blog entry, there is no open source or free software license of which I am aware that requires that the code author (in this case Sun Microsystems Inc, SMI for short) accept patches, thus we always face a potential issue between what members of our community want and what SMI will accept. Sun’s procedures also don’t facilitate rouge development or “submit and forget” (patch on list) style development.

I want to encourage as much development as possible, and I want to extend the resources of our community to everyone that wants to be involved. The fact is, many external contributors don’t care about Sun procedures or whether they get integrated, only so long as that their work is available to others who want it. For these people, we can either let them work alone, create an effort on SourceForge like anyone else, or we can try to be the SourceForge of OpenSolaris inviting developers to use our resources and work within our framework, which brings a great deal more attention and potential input and collaboration from other similarly minded developers and the core engineers (who are all internal to SMI today) themselves.

In that light, I want to ensure CG’s are properly formed and organized, and that developers can create Projects as easily as possible. I want people to be able to start developing regardless of intentions to integrate. Contribution thus occurs to the community, not exclusively to the internal gates.

Let me reiterate, as a member of the OpenSolaris Governing Board my duty is to the community, not to Sun or to Sun’s internal gates. I must therefore seek for every opportunity by which to empower, enable, and bring together that community… the social organization, the people.

The idea of developing independent of “the process” is controversial. John Plocher, who most certainly will serve on the board next year if he’s willing, describes this best. Bear in mind while reading this that Sun’s Architecture Review Committee (ARC) is a requirement of any non-trivial change and the saying goes “ARC early, ARC often”:

Sun’s ARC process is simply “think before you act”, “do things
by intent”, and “set expectations, then live up to them”. In other
words, “be an engineer”.

This is very true, but ultimately at odds with the weekend coder hacking for fun. I have several projects I’d like to work on, but I have no intention of going to an ARC, making a case, and then arguing my approach… that feels a whole lot like work… for free. At that point I might as well start looking at the SMI Jobs Board and get paid for it. However, that said, if your a 3rd party company who wants to integrate functionality then this is a great help to you. And, doubtless, there are true open source developers who wouldn’t mind the ARC process and perhaps even enjoy it.

The Sun procedures and ARC process will always be a reality of putting code into (insert name for Solaris here; ON, Nevada, OpenSolaris, whatever). What I’m fighting to ensure is that its not the only way we are willing to accept contributors, because if it is I’m not governing the OpenSolaris community as I see it, but rather coordinating unpaid external labor… not fun and not in line with Free Software ideals, imho.

There are a host of issues that become important as a result of these visions. Making SMI development more and more transparent is important to everyone, and that means making SMI developers comfortable with having discussions made in the appropriate external forum. Perhaps the easiest way to accomplish this would be for Sun to explicitly disallow internal email lists and force all non-direct discussion to be transparent…. but boy would you piss off a lot of people internally that way. If its not forced, it will simply be a matter of making the external community space a friendly place to be, with minimal fluff and maximum exposure, to the benefit of all.

Another long post, I know, who has the time to read this crap… if you scanned quickly to the bottom thats fine by me, the essential take away here is that while things may look a bit heated on some of the mailing lists right now its all for honorable reasons, and we can only hope that the discussion drives towards action that will better ourselves and our community.