OpenSolaris Community Structure Thoughts

June 18, 2008 9:00 am gman OpenSolaris

Like Jim, I figured I might as well post this on my blog. Over the last month and a half, the OGB have been pondering the current OpenSolaris community structure, and that laid out in the constitution, in terms of how (if desired) we can simplify things and not only match reality, but lay rest to 3 years of confusion. Here’s my strawman on the possible roles or structures

Roles

OGB
OpenSolaris Governing Board member. Voted in by the OpenSolaris membership. Board members should monitor a selection of high level areas and be a point of contact, so as to broadly cover the activities of the community. Secretary may be an existing board member, or a non-voting board elected representative.
Member
A person who has contributed non-trivially to a related project or activity within the OpenSolaris Community. A person may apply for membership at any stage, listing their achievements and at least one referrencing Member who can vouch for them. Membership is for life, but expires after 2 years. All current Members have the opportunity of voting in the annual board elections.
Project Lead
A person who has commit privileges to an existing project, and can grant others commit privileges based on recognition of their contributions. A project lead also has the responsibility of deciding the direction (technical or otherwise) of projects among their peer co-maintainers, along with the responsibility of representing the opinions and feedback of those who have an interest in the code ie. predominantly users. Successful project leaders are those that can study the marketplace and make decisions that are right for it, and right for the long term well-being. As projects succeed, and interest is garnered, Groups form around those projects. Projects are orphaned when so little interest is gathered to maintain its lifeblood. Project leads may enlist regular contributors to share the day to day maintenance of the project.

Groups

SIG
A SIG, or special interest group, is a selection of people who gather around a specific technology to share experiences, tips and tricks or participate in contributing towards its development. A SIG would typically include project leads, direct and indirect contributors.
Release Team
A selection of people across different disciplines (usually project leads and program managers) who are responsible for organizing the software release schedule, and producing timely releases of the OpenSolaris OS.
ARC
The Architectural Review Committee are a body responsible for ensuring the technical and architectural correctness of the software pieces that make up the OpenSolaris OS through guidance based on their collective experience in dealing with software projects. The group may be sub-divided into full members, and those working towards full membership ie. interns.
Site Administration
A small set of people responsible for the site infrastructure on opensolaris.org – everything from the web application itself, wikis, blogs, planets, SCM hosting, authentication and grant databases, and overall general health of the machines that run this infrastructure. Content is usually generated by other groups within the community, but the site administrators may work with or be responsible for certain parts of the website from time to time.
User Group
A selection of OpenSolaris advocates that are locally distributed, who may meet in person, or virtually, to discuss the technology that makes up the OpenSolaris OS. Their meetings may involve learning about new or existing technology in the OpenSolaris OS, or taking part in wider events such as related technology conferences world to help spread the love of the technology they use on a daily basis.

Random Rationale

  • Try to split out governance of the code, from governance of the community
  • Code governance is a meritocracy
  • The people who write the code, come up with the rules for that code
    • License Choice
    • Coding Style
    • Development Process
    • Versioning
    • Technical Direction
  • The people who write the code are the Project Leads, and they are responsible for caring for the long term well-being
    • Who gets to commit
    • Encouraging contributions
    • Technical and architectural correctness
    • Responsibility of listening to their users
    • Enlisting regular contributors to share the maintenance load
  • If they are responsible enough, groups will gather around that code, and the project will be considered a success
  • If they do not show that responsibility (or many other factors), the project will be orphaned and/or die
  • All projects are different by their nature, and we shouldn’t try to artificially enforce the same principles, rules and processes behind them all
    • Different reasons for its creation
    • Different sets of people contributing
  • Ideas are the building blocks of our community, and they (generally) take the form of projects
    • Those willing to take an idea to implementation could be considered as project leads
    • The people who do the work, get to decide the direction of the project

Comments are closed.