On Mar 7, 2007, at 3:02 PM, Keith M Wesolowski wrote:
On Wed, Mar 07, 2007 at 01:55:02PM -0800, Roy T. Fielding wrote:
Article VII delegates all such work to Community Groups. Article
VIII
Article VII delegates nothing. Nowhere does it assign powers to any
Community Group or require that the OGB delegate any particular
function to any or particular Community Groups.
7.1: "... the OpenSolaris Community is held to be composed of
Community Groups that are initiated by the OGB for the purpose
of focused management and accomplishment of a given set of
activities. Community Groups are, in turn, responsible for
initiating and managing projects to accomplish those activities."
There is nothing in the OpenSolaris Community other than the set
of Communities initiated by the OGB, and the activities/products
governed by those Communities. By definition.
The charter says: "establish an OpenSolaris Governing Board (OGB)
to manage and direct an OpenSolaris community in its efforts to
improve upon and advocate in favor of OpenSolaris, so that the
community may long endure." That clearly says to me that the OGB
does not fulfill the charter if it does not initiate Community
Groups, since the constitution says there is no OpenSolaris
Community without said Groups.
Theoretically, the OGB could eliminate all activities by eliminating
all Community Groups, but the OGB itself serves entirely at the
discretion of the Core Contributors, who are in turn appointed
by the Community Groups as Members and said appointment survives
even if the OGB terminates their respective Community Group(s).
In short, even if the next OGB has its minds eaten by aliens and
forced by zombie-control to eliminate all the Community Groups
in one fell swoop, the same core contributors that elected that OGB
can fire them following the process defined in the constitution.
Your concerns have been heard several times. I find them to be
completely irrelevant to the proper operation of a governance model
that has a well-defined feedback mechanism. We don't need to write
down every possible screw-case that might apply because the system
is governed by people, not machines. We don't need to enshrine one
committee's view of how C-Teams operate in an organization-wide
constitution because C-Teams simply aren't relevant to *every*
activity at OpenSolaris, and the vast majority of comments we have
received so far clearly indicate that the existing consolidation
boundaries are arbitrary AND dysfunctional. Personally, I am hoping
that the communities feel empowered to change the things that are
obviously causing them harm right now, and let the consensus
process ensure that the traditions are adequately promoted and
maintained over time.
All Article VII does
is define how a Community Group forms or terminates and who composes
it. It does not require the existence or empowerment of any Community
Groups, much less that any or all of them are to have technical
control of existing consolidations. The OGB can act to make such
assignments, but nothing obligates it to do so. Indeed, if one
skipped article II, one would never even guess that the primary
function of this community is the maintenance and extension of an
existing operating system; none of the operative articles has anything
whatever to do with that purpose or mentions how the _already extant_
content of that operating system is to be managed. It's almost as if
the constitution were written with the intent that the OGB would
somehow form a collection of Community Groups which would sally forth
into the world creating project teams to go build an operating system
from scratch, along the way fabricating from whole cloth a novel
culture and set of social conventions.
Except for the minor detail that the initial Core Contributor set
is supposed to be representative of the existing (Open)Solaris
contributors, and hence the entire organization is subject to the
current set of people, culture, and traditions of the existing
operating system for the next two years (at least). That is,
assuming the community leaders did an adequate job of identifying
the core contributors of their own communities, at least to the
minimum extent necessary to ensure oversight of the OGB.
The OGB is first given all powers from the charter, and then
forced to
delegate most of those powers, because that is how common governance
Nothing in the Constitution requires the OGB to delegate anything.
7.1 merely permits their existence at the OGB's discretion.
Read it carefully.
Let me distill it further: the OGB has the power to decide what code
may be integrated.
Nope. It has the power to stop integrations on opensolaris.org.
If one assumes the desirability of a unified engineering community,
these two are one and the same. Although I would phrase it slightly
differently to remove the dependency on a particular web site: the OGB
has the power to decide what code may be integrated into the
community's repositories. This allows for the possibility that Sun
will abandon its purported interest in open development, leaving the
OGB no less empowered to make decisions for the entire community - one
that no longer includes Sun employees - but stripped of Sun-supplied
infrastructure.
The OGB has the power to shut this organization down. Sun has the
power to shut down the OGB and remake this organization. BFD.
Having the power does not make it so.
Don't get me wrong; this power must exist somewhere within the
OpenSolaris community. But its assignment to the OGB without
requiring subsequent delegation to (or even the existence of)
appropriate technical bodies is a major weakness in this proposed
constitution. Again, the code that requires open management _already_
_exists_ and is effectively controlled by Sun today, mainly because no
functional structure exists in which any other organisation can
exercise that control. The constitution as proposed offers absolutely
no improvement on this state of affairs; it leaves all powers in the
hands of the OGB. This is the same argument I've made since the
current basic structure was proposed, and no one has yet succeeded in
explaining why this concern is irrelevant or inappropriate, despite
the GWG's decision not to act on it.
We didn't "decide not to act on it". We decided that your comments
had no merit beyond the clarifications that were added to the
constitution where certain separations of responsibilities were
unclear. Further discussion of those concerns is irrelevant until
after the constitution that was approved by the OGB and Sun is
ratified by the community, after which there is a defined process
wherein you can propose an amendment for the Members to adopt.
C-Teams are projects of a given community. What community that may
Yes, they should be. Could you please tell me which section in the
constitution requires this (or that technical control of the codebase
must be assigned in any fashion to one or more Community Groups, or
for that matter even acknowledges the necessity of exercising said
control)?
3.1, given the Charter's stated mission.
Nor does it need to -- those are not governance issues, they are
decisions made by a community. The decisions will be made according
to the governance procedure in the constitution, but that is
significantly
different from enshrining one person (or one employer's) traditions
within the decision-making procedure itself. The personal and
cultural
traditions and biases of the voting core contributors will determine
the results of each community decision, not some stale piece of
parchment.
Then perhaps you and I may be in agreement as to the effects of the
constitution (modulo your assertion that the OGB is required to
delegate any of its powers), and we disagree only as to the
desirability of these effects.
The Constitution as proposed does nothing to allocate, share, or limit
powers and responsibilities that the Charter does not already do. And
under that Charter, Community Groups have thus far exercised no power,
made no important decisions, and controlled (with any semblance of
transparency) no aspect of the process of engineering anything. As a
referendum on this state of affairs, the constitution fails
completely. As a guide to the next OGB's actions it offers little.
As an opportunity to confirm the OpenSolaris community's replacement
of Sun as the sole technical authority over OpenSolaris's engineering
practices and content, it is a lost one.
None of the current Communities on opensolaris.org are operating as
a Community Group, as defined by the governance. The constitution
hasn't even been enforced yet, even though the charter placed it into
effect as soon as it was approved by the OGB and Sun. Some of
the OGB members felt that it would be inappropriate to enforce the
constitution until after it is ratified by the community and a
fully elected OGB has been established.
All along this project, the CAB has been hamstrung by our unwillingness
to force EVERYONE concerned to obey a single set of open principles
while making decisions for the OpenSolaris project. It is easy to
create Communities and Projects in an ad hoc, undisciplined manner
with weak scope and unclear objectives -- it is much harder to remove
or reorganize them on an ad hoc basis, or to deal with internal
conflicts when the contributors aren't all working for the same boss.
The constitution won't really be tested until there is no other
behind-the-scenes alternative to making decisions, at which point
it will either succeed or fail based upon the community's willingness
to obey its own procedures.
There is nothing more we can ask for, and nothing more that we can do,
other than to ensure that the constitution can be changed later
if changes become necessary. I would hope, however, that folks here
have the sense to realize that they should focus on correcting the
misbehavior first and actually give on-list collaboration a try,
rather than assume a document that hasn't even been obeyed yet
has some fundamental flaws. The same structure is in use by several
successful open source projects, in addition to the 45+ distinct
communities at Apache, precisely because it provides an agreed upon
mechanism for resolving conflict in the face of competing demands
from many individuals who happen to work for many different companies.
....Roy
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
