On Jan 27, 2008, at 1:19 PM, Keith M Wesolowski wrote: > 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.
Good luck. Since you guys haven't bothered to enforce the existing constitution, how is making changes to it going to be any better? > 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. Not shrink-wrapped software, but definitely products. Components would be a better word. Components that seem to be shipped within a lot of existing operating systems and JVMs, in fact. > 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. Sorry, that is ridiculous. Solaris ships various Apache products, as do most (if not all) Linux distros. That happens because building an operating system is not just building a shrink-wrapped product -- it involves consolidating a bunch of layered and sometimes independently developed products from a variety of sources into a coherent release structure. Some of the Apache products do the same (Cocoon, for example). Does that mean an OS is not a product? No, it means that there are a lot of products and products-of-products and even a few products-of-products-of-products. It is the same old common engineering solution to complexity -- divide and conquer. And at each level, the decisions that are made are essentially the same, the code reviews that are made are more granular but essentially the same, and the need for collaborative decision making that doesn't assume a monoculture is essentially the same. > 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) No, those would just be the product-of-product-of-products CGs, and only if those distros actually wanted such collaborative decisions to be made at OpenSolaris (as opposed to remaining external forks). A CG should be scoped to include only what is being created within that CG. They may or may not share the output of other CGs, depending on how the distro CG decided to consolidate. This is no different from any other software product that makes use of independently developed components. > 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. And here is where you go off the rails. OpenSolaris was created in the hope that getting the outside world to participate in OpenSolaris development would revive interest in the operating system. This notion that the "open source universe" has a need for any of the ridiculous centralized and legacy-oriented decision-making processes that make up the vast majority of ARC discussions is a total joke. Solaris needs ARC because there is an incredible legacy of overlapping API decisions that need to be addressed with any change, and a long history of decisions based on the best way for a single company to deliver a single product-line to an existing set of customers. Open source developers don't work that way. We have products that are built with various levels of interface stability and version numbers to indicate the scope of interface guarantees. And when work within a product gets a little too innovative for the legacy customers, we fork out to a new product version (or even a new product name) and then let the customers decide what to download. Each product group is independent because it must be -- we are volunteers, not employees, and we work on what is important to us (where "us" is a constantly changing group of people who have earned the right to make changes). In order to combine those two worlds into a working distribution within the OpenSolaris community, we need a governance structure that promotes independent development and local decision-making. That is what the constitution would provide if the OGB hadn't punted on its first task of the year, namely reorganizing the old discussion groups into real working communities. If you don't like that, then stop pretending there is anything open in OpenSolaris other than the end-product. Trash the constitution and stay within the existing model of development, wherein all the real decisions are made by Sun employees and source code is merely thrown over the wall long after it has been (often poorly) integrated within a consolidation. Nobody else is going to care. ....Roy
