Octave Orgeron wrote:
> Speaking of CG's, I think the way things are organized is a little confusing.
More brainstorming - trying to synthesize the several threads...
The more I think about this (and read the excellent comments in this set
of threads), the more I feel that the CG - Project relationships should
be more like "tags" or endorsements and less of a hard parent/child
ownership.
For once I think I agree with Keith - the structure we have isn't the
one we need. The constitution says Community Group and Project, yet
when we talk, we use terms like "Consolidation", "SIG", "Project" and
"Distro".
As my friend Bob is fond of saying, "code talks". The reason most
people do open source is the code. It only makes sense to make the
thing that does code easy - what would happen if we dropped the
requirement that a CG needs to be the one to create Projects, and
instead say that any OS.o affiliated person could, as Glynn said, JFDI?
Creating a Project could explicitly make the initiator an OS.o
Contributer. Projects would exist independently from any CG - at least
for a period of time.
Going further, what if we broke up CGs into Consolidations, SIGs,
Distros and Service groups? Projects affiliate with one (or more?)
Consolidation(s) when they wish to integrate their code into that
consolidation's source base, and Consolidations behave like Apache
Projects. SIGs endorse Projects that they wish to support, interact
with, or otherwise influence. They also could produce roadmaps,
requirements and best practices to be used by the Projects and Service
groups as a mechanism to share values and expectations. Service groups
(ARC, OGB, ...) may provide arbitration, certification or validation
services that cross community boundries. Finally, Distros take the
output of Consolidations and SIGs, add special sauce of their own, and
make products.
(In Sun SDF terms, Projects are I-Teams, Consolidations are C-Teams,
Distros are W-Teams, and SIGs are something new)
If, at some point, a project team wishes to take advantage of something
offered by one of these (such as access to their Consolidation
repository, use of the SIG's name as an endorsed-by tag, whatever...),
they would first need to "do" whatever that group required (such as ARC
interactions before integration into a consolidation, voting by the SIG
members before getting an endorsement from a SIG, etc...). This would
be the point where Projects get connected to other things.
The point is that a Project can get going easily, and if it never wishes
to interact with any of these other groups, it can still get things done
- or die off naturally if it fails to get its act together.
-John
