On Wed, Jan 23, 2008 at 08:04:49PM -0800, Alan Coopersmith wrote: > As long as we're dumping the churn from our brains, I'd been > thinking that there's really three different types of thing > we've currently lumped into the Community Group model:
Here's mine as well. We all seem to have similar thoughts but there are some important differences. It's probably almost time to propose what surely will be the mother of all constitutional amendments. The conclusion I've reached is that the structure we have makes little sense for us. The Apache organisation consists of standalone efforts that they call projects but are really about products: in essence, shrink-wrapped software. Each product is governed by a body on which our definition of CG is based. But we're not trying to deliver a collection of independent shrink-wrapped products (or haven't tried to do so in the past), so we struggle to find reasonable charters for our CGs. SMF is not a shrink-wrapped product; Tomcat is. Device drivers do not collectively form a shrink-wrapped product; SpamAssassin does. And so on. If we were to attempt to make the Apache model actually work for us, the Community Groups we would form (all of them) might be: OpenSolaris/Indiana MarTux SchilliX Belenix (if not subsumed by OpenSolaris/Indiana) This would be fine as far as it goes; each CG would own a release schedule, a repository, etc. Governing wouldn't be too hard, boundaries would be clear, and so on. It would all make sense. The only problem is that it would destroy most of the value we offer the open source universe. In such a setup, there is no concept of ownership of the underlying code base. Either every CG has its own copy/fork that they own exclusively or they all somehow try to share some common thing. Forking off in a dozen directions seems obviously wrong. Sharing the common thing makes sense, but there is no structure in place to govern the manner in which that resource (hopefully by now someone recognises my 'Consix' from another thread) may be accessed. And so we go round and round trying to make the square peg (shared development processes for a /single highly integrated code base/) fit into the round hole (a government structured to help people deliver independent products). Too often during the creation of the constitution we have today I heard "that's not a governance issue." Development process *is* a governance issue for us. Maybe it's not for Apache, but we're not Apache. It's of paramount importance that we create an environment in which people can continue to develop a tightly-integrated, architecturally consistent code base representing the foundations of an operating platform. Other people want to see other things happen with and around that foundation, and that's good too. Some of those things might well deviate from the kind of consistency and integration we think we value. That's ok, too - the license allows people to take arbitrary forks, remember, so whether or not you like a particular one doesn't mean we can or should try to prevent them from existing. The key for us is to keep Consix healthy; if it dies because we can't find good ways to represent the development processes I think most of us believe are needed, all the value here dies with it. How Consix is developed is one problem. How a broader meta-community of people interested in building products on top of it operates is another problem. It's time to accept that these are two completely different problems with completely different solutions. The ARC, DTrace, ON, and Distributions are not all instances of some common class called "Community Group." A moment's thought should make that obvious. The ARC is just the ARC: love it, hate it, or wish it were burning in hell, it's an integral part of the way we create excellent software. ON is a Consolidation, a sort of provincial government that manages a resource under a set of broadly-defined shared rules. DTrace is a SIG, a collection of people in various roles interested in advancing a specific technology. And what Mr. Walker has proposed is not a single Community Group but in reality the OpenSolaris Community as it was originally defined: a collection of independent product teams each reaponsible for its own destiny. Reworking the definition of Project as Mr. Rockwood suggests is fine as far as that goes. Projects are critically important; they're where all the really important work is done. In the organisational structure we have, they're owned by something (a CG, in effect a product team). But a Consix project is owned by no one; it's a voluntary association working to solve a problem. It doesn't need anyone's permission to *exist*, only to muck with shared resources (Consolidations). That Project Teams will be more successful if they start by talking with the relevant SIGs led to the idea that CGs should have to sponsor Projects from the beginning. That makes sense if you think the SIGs are CGs that can "own" a Project. But they really aren't. SIGs are just what their name implies. They provide valuable insight and a deep pool of experience, and the people responsible for the Consolidations will surely want to see that the right people from the SIGs were involved before allowing a Project to be integrated. But the SIGs do not themselves own Projects; at most, they may sponsor or endorse them, an advisory attribute. The ARC provides a different kind of technical expertise, and the Consolidation managers require its input as well in order to make the right choices. You can call these things whatever you want. Call them all CGs, call them Fred, Mary, and Bob. But the way they work together to add value to Consix looks NOTHING like the way the OpenSolaris Constitution says CGs interact with one another. That's why we've made no progress on any of these issues, and why this proposal, like so many before it, just rearranges the deck chairs. There are a lot of things in the constitution that I find confusing or just outright unnecessary. Simplification and clarification are welcome. And there are processes that could be put in place to make things easier for people operating in ways that the constitution anticipated. But unfortunately, in order to make any real progress, a whole boatload of stuff needs to be added to it. As it is today, it describes only part the activities that comprise this Community (and not those nearest its core purpose: making software!). The other half continue to operate under a set of rules that are by no means unwritten (the Sun SDF is a serious tome) but widely viewed as illegitimate because they're not found anywhere in "our" collective body of law. Directly incorporating that document verbatim is absurd: it makes a lot of assumptions that don't apply to open development, and the result would be unwieldy and unreadable. Instead, I'd like to see something like http://www.opensolaris.org/os/community/on/os_dev_process/ become a part of our "governance" structure. Something like Mr. Coopersmith's W-team replacement is probably needed too. But don't bother looking for clever ways to represent this stuff under the structures we have now. There are none. Mr. Plocher's thoughts seem to run in this same vein, but I'm not convinced yet that we're on quite the same page. Simply splitting the OpenSolaris Community and the organisation of a web site doesn't really solve the problem. Nor do I think it makes any sense to say that the other three activities he identified necessarily fit into separate CGs under the existing rules. It's still possible to have a single set of rules and a single umbrella organisation covering a multitude of different activities. The rules that aren't applicable to a particular activity may be ignored by the people engaged in it. > Consolidations though seem to be what the Community Group model in the > constitution was designed for, and that makes sense, since they're the > closest mapping to Projects in the Apache model. I don't think this is true. Consolidations are not shrink-wrapped software; they're parts of each of a collection of things, each of which is a greater whole. The manner in which they're combined and what else is added or taken out are how distributors add value for their respective markets. Those activities seem to make sense for CGs and/or independent corporations (depending on whether they are focused on commercial gain); they are producing shrink-wrapped software. Your ideas around "service groups" are interesting. I'm not sure it's worth generalising those out. The ARC and Advocacy do indeed have a couple of common attributes, but are those the attributes that are operationally relevant? That is, what commonalities do you see in how those two organisations should be represented, how they should be governed internally, or how they should be permitted/encouraged to interact with other bodies? -- Keith M Wesolowski "Sir, we're surrounded!" Fishworks "Excellent; we can attack in any direction!"
