[ogb-discuss] Community Simplification

[John Sonnenschein]

On 19-May-08, at 10:34 PM, John Plocher wrote:

> Jim Walker wrote:
>> My 2 cents...
>
> Worth much more than that!
>
>> I had problems with SIGS and Special CGs. I don't see the need
>> for additional classifications, and would rather have a
>> general theory of community organization, than a special one :)
>
> My organizational principle was "follow the code", draw a line
> around the way things are, and not try and invent some new
> theoretical structure.
>
> We have three kinds of groups in action today:
>
>    Those that control a source tree that is used as part of
>    OpenSolaris,
>
>    Those that have an interest in some source that is
>    controlled by others, and
>
>    Those that are interested in social/community stuff.
>
> I believe we are in the mess we are in today because (in part) we
> ignored (or at least significantly blurred) the distinctions between
> the first two groups.  We were so busy convincing ourselves that
> being part of the community didn't mean "writing code" that we lost
> sight of the fact that we were an open *source* community!
> If we can't create source code, it doesn't matter how good we are
> at mailing lists and contributer grants and ... :-)
>
> It all boils down to "what are the chunks of source code that we
> have?"  These are what I found when I went looking:
>
> 	OS/Net (ON)
> 	Desktop
> 	Documentation
> 	HA Clusters
> 	Storage
> 	Website
> 	X Window System
>
> In addition, it seemed likely that the following would soon
> qualify as well:
>
> 	Distribution (recipies, other ecosystem stuff)
> 	Software Porters (repositories, applications...)
>
> The others (that are not user groups) could easily be
> PROJECTS, except that they all tend to associate with
> multiple other groups.  They aren't source code owners,
> they aren't projects, what are they?  IMO, SIGs.
>
>> In addition, I took a stab at organizing things more logically
>> from an external first time users perspective, than the way
>> things may be organized within Sun.
>
> I don't think we can get there from where we are today.  The
> physics and logistics of what we have and how it works today
> get in the way of such a sweeping change.  In other words,
> refactoring ON into separate chunks for device drivers,
> networking, filesystems, power management, ... isn't practical.
>
> The problem I see is that (as an example), Networking does not
> "own" its own source code - it instead is responsible for a
> subset of the code "owned" by the OS/Net consolidation.  Same
> goes for Device Drivers, Filesystems, Observability, Perf and
> Power Mgt, ...
>
> In the end, if Networking wants to change something, they must
> get the ON gatekeeper to let them integrate the changes into
> ON's source tree.
>
> Inventing a community structure that tries to pretend that
> somehow Networking gets to decide these things on its own
> without involving ON, or, as in your list, doesn't even
> have ON as an entity seems to violate a basic reality check,
> no matter how attractive it might sound :-)
>
>   -John

Clearly what we need is a system such that one can only define  
relationships through heavy application of RDBMS ( i'm kidding )

+1, I think the best way to go about restructuring the community is  
finding those chunks that can act independent of each other  
( completely independent ) and aren't just sub-classifications of  
something larger ( like ON ) such that we could define a hierarchy in  
a tree structure ( OpenSolaris being on top... X11, ON, whatever being  
underneath )

Where this would run in to problems is when two communities "own" a  
project with tight binding like... I dunno, like observability. X11  
wants dtrace probes, so does ON. Maybe if projects were only owned by  
one community the projects would have to be defined in the scope of a  
single community ( eg, observability -> X-Observability & ON- 
Observability )