[ogb-discuss] OGB/2007/002 Community and Project Reorganisation

[James Carlson]

Now that I'm back from vacation and somewhat caught up on email ...

Stephen Lau writes:
> 		- BrandZ, Xen, & Zones endorsed by Virtualization

Xen looks like it may be a project, but I'm not sure that "Zones" is.

The difference is that Zones (like BrandZ) has already delivered to
ON.  There are follow-on efforts related to each, but those may well
be separate projects.

> 		- 'Fault Management' and smf(5) endorsed by
> 			'System Administration & Management' 
> 		- MDB & DTrace endorsed by 'Performance & Observability'

These also suffer from the same sort of problem, and I suspect they'll
meet with some resistance (he says, now predicting the very recent
past ;-}).

Dtrace in particular is not much more than a bunch of smaller projects
flying in formation, just like "networking" itself is.  Would we make
"networking" a project under an "OS" community?  I don't think we'd do
that.

So, while I think I'll go along with what the other OGB members have
decided while I was away from email, I don't think it's actually
right, and I'd still like to register my discomfort with this
solution.

The problem I have is with the amorphous nature of projects that this
proposal implies.  The model I understand is that a Community
shepherds a group of projects that collectively reach (or at least
approach) some goal that's important to the community.  This implies
that projects have deliverables.  They don't just hang around
"forever" doing "stuff."

This proposal implies the opposite: projects hang around to serve as
gathering places for people who might be interested in what the
project did at some point in the past, and finding ways to enhance it
in the future.  Given that enhancements often mean a rechartering of
what the group means (e.g., adding resource controls to Zones ties
together two things that were once separate), I don't think this makes
lasting sense.

In other words, I do want to see those project proposals and community
endorsements for the follow-on work, every bit as much for the initial
projects.  Keeping the follow-on work within the same project breaks
that model.

I suspect one possible underlying desire could be to make "projects"
be the permanent repositories for their code, and then essentially do
away with consolidations like ON.  If so, then I'm not sure I see that
as a good long-term strategy.  It seems too much focussed on the
mechanics (the repositories) and not enough focussed on the goals.

Anyway, I know I'm late, so don't mind me.  Drive on ...

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677