[ogb-discuss] Bigger thoughts - what about refactoring OS.o? (was Distribution Community Group Creation)

[Ben Rockwood]

I think we all are seeing some serious flaws in the existing 
organization based on a variety of examples in the last year.  I have 
plans to introduce a proposal in the next few weeks, as I've not fully 
baked my proposed structure and associated constitutional amendments, 
but I'll start throwing out some ideas.

1) The current Constitution has within it a major flaw, in that it does 
not define Projects.  It refers to them, but never defines them.

2) Existing terminology is excessively confusing and has, to an arguable 
extent, painted us into corners.  A "Community Group" sounds like a 
loose collation of related "things".  A "Project" sounds like a place to 
do work, collaborate on details, and work in a targeted way.  The 
Constitution puts organization in CG's, but not in projects... projects 
answer to and are "owned" by CG's. 

This is where things get sticky.  Lets take two examples, one that works 
in this model and one that doesn't.

 First, lets take the Advocacy CG.  This is the model CG thanks to the 
hard work of Jim G.  You go to the CG main page and you are greeted with 
all the information you need to get started.  There are several 
projects, all well segmented, its a thing of beauty.   This works, I 
believe, because the core contributors of the Advocacy CG have a handle 
and grasp on all of the projects benieth it, even if they aren't 
involved directly, and people contributing projects trust and look to 
the leadership of the CG Core Contributors.  Sara D. or Jim G. or Teresa 
G. (on and on) can speak to any of the Projects under the CG with 
respect and trust, and then be back on their way.

 On the other side, lets consider the LDOM's CG proposal.  This was met 
with the suggestion of instead collapsing xVM/Xen and Zones CG's into a 
larger Virtualization CG as projects, and then bringing LDOM's along 
side.   This didn't work (short version) because while LDOM's, Zones, 
and xVM are all Virtualization efforts, they really are completely 
distinct.  Could Core Contribs of a Virtualization CG make judgements 
that would be respected, trusted, and useful to the underlying 
Projects?  Not to mention that these are large efforts which themselves 
may require projects.  For these reasons and more, it proved that in our 
Constitutional model "Virtualization" isn't a Community Group; LDOM's is.

3) Now, lets consider the Distribution CG proposal (that will go to vote 
regardless of any discussion, btw).  Shawn Walker is absolutely correct 
that there needs to be some way to bring distributions together in an 
organized way within the OpenSolaris community framework.  Linux distros 
are a great example, they are all over the place and independant, 
wouldn't it be nice if all the OpenSolaris distros had a home (if they 
choose to participate of course)? 

 The problems noted above with the LDOM's effort are almost identical in 
the case of distributions.  Should Core Contribs of a Distribution CG 
make decisions about Belenix, Nexenta, Schilix and Indiana?  I don't 
think so.  Never-the-less, there should be a grouping which I call a 
"meta-community" or "Consortium" which can provide a loose social 
grouping of CG's to facilitate collaboration and coordination.

4) There are two solutions (I'm still working through this, so this 
isn't final) that I see...

 a) Push things down a layer.  This would make the intuitive definitions 
make sense.  This requires major modifications to the Constitution, but 
more closely mimics what we actually do in practice today.
 b) Add an additional layer above CG's, my "meta-communities" or 
"Consortiums" idea.  Consortiums in this model wouldn't have any real 
power at all, but would provide a much needed means to pull together 
various functional areas of the project in a much more organized way.

5) If we are going to ever do away with the term "Community Group", we 
should do it sooner rather than later.  Its still very early in 
OpenSolaris's life, I think doing so is no out of the question if deemed 
appropriate.



Like I said, I'm still baking the idea, but we need to make contribution 
much easier than it is today and currently there is too much 
bureaucracy, partially because "projects" are somewhat heavy wieght... 
if "projects" are much more granular it could facilitate handing out 
projects more easily, better facilitating contribution, because projects 
come with repositories.


This all feeds into the contribution model which needs so much work, but 
I honestly have mountains of research to do before I can properly 
express a useful stance.


benr.