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
