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 )
