The Goldfish Chronicles

Dan Diephouse commented on my blog entry concerning Enterprise, Apache and various late night thoughts.

He has two chief points in his reply:

1) In response to my comment that “the ASF is not a place for developing new projects. Nobody starts a project there, and few ever have”, he thinks that “Apache should really be asking why?”. It’s definitely a conversation that has gone on all over the place for years at Apache now. I think the “Why?” is pretty easy, the “How would we?” isn’t even that hard - it’s the “Should we?” that is hard.

Here’s why projects are not started at the ASF:

• The Apache ideal community does not fit an early community project. It expects a community to exist, for there to be enough (3) people at the heart of
  the project and for the good of the whole community to trump development speed.
• There are locations within Apache where projects can be started - the Incubator and the Jakarta Commons Sandbox being the two major ones. The former does not have any formal barrier to someone showing up with a bright idea and a desire to code, but it would be quite the change from the norm and unless that someone was already an Apache committer they would have zero chance of pulling it off (I think). Even if they were an Apache commiter, I think it would be tricky. The latter has a formal barrier of needing to be an Apache committer somewhere to start something up, but more importantly it has a definite formal barrier in terms of what can be in Jakarta Commons. There are other sandboxes (Maven has one now), probably with much the same formal and informal barriers as Jakarta Commons Sandbox.

Here’s how you’d do it:

• Create an svn repository: svn.apache.org/repos/people/<login>
• Auto-publish: svn.apache.org/repos/people/<login>/public_html/
• Partition off the distribution side of things with various warnings for the downloader etc
• DO NOT have user restrictions. Allow any committer write access to someone’s people dir.
• Create a dev@people.apache.org mailing list. NO USER LIST.
• DO NOT assign copyright to the ASF.
• Allow multiple licenses?

Why should you do it?

• Encourage creativity and innovation between Apache committers.
• Easy audit to move quickly through the incubator - look at the svn logs.

Why shouldn’t you do it?

• Interferes with the mission of enterprise+open-source.
• Increased legal footprint - individuals are releasing things with no oversight from the non-profit.

Not that I’m good at giving the negative view here as I’d like to be able to do such things.

---

Dan’s second part of his commentary is that my comments imply that the Apache community style is not the right style for every project. That’s definitely true. He then lists the ‘dictator model’ as good for one or two person projects. His comment here is cyclic - a one or two person project has to be the dictator model, it can’t be anything else. There’s nothing wrong with the dictator model for one or two people projects, but when it becomes a three person project and it remains the dictator model - then you’ve not got an open project - instead you have a community dependent on the good nature of the dictator.

Commons is a very interesting case study here. Here’s a pretty obvious white elephant - nearly every Commons component is running under the dictator model. You can point to any component and as long as it’s active, it’s “So and so’s” baby. For a while that wasn’t true of a few components that were kicked off by Struts and Tomcat, but they’ve been more hands off in their Commons involvement and we’ve Commons-ized their committers who were involved such that they’re no longer the baby’s of other projects. Much of the reason for these components having dictator’s is that they’re too small to support huge development teams.

So why is this tolerated? There are a few reasons:

• No one knows! We’ve pulled a fast one and everyone thinks there are 20 active committers to Commons Lang. Okay; I doubt people are that daft
• Commons! The point of Commons is that multiple things live in the same space. We have a pretty primitive barter economy in place, help out with someone’s release and they’ll help out with yours. We have very high overlap; I may focus on 3 or 4 components, but there are another 6 or so that I keep an eye on.
• Process. We’ve been good at putting in line processes on releases and quality checking. Much of the Jakarta documentation came out of Commons, and a lot of that has found its way to the official Apache documentation. In many ways Commons is a canary - a microcosm of Jakarta, which in itself is a microcosm of the ASF.
• Open commit rights. Anyone can commit to any component. So if the ASF changes their copyright statement, someone may just go and fix all the components and let common sense prevail as to whether they were stepping on any toes. Non-specific work gets shared.
• It works. The components are not rocket science, but we put a lot of focus onto release quality
• It’s at Apache - so the culture is structured to not allow dictators who abuse their power. At the very least it’s a cm

What are the problems?

• Hard to know if a component has its dictator or not. If not, then it’s dead and we definitely have some dead components with bug reports piling up. That’s nothing new though, there are lots of dead projects out there - a nice advantage of Commons is that if there’s something very important, there are people who can step in and deal with it.
• Noise. All living in the same space is pretty noisy. I think we can take more though - especially if we split the commits, jira et al onto their own lists
  so the archives start to look more sane.
• Components need 3 commons people to leave the sandbox, but released components are ticking along nicely with 1 person. We’re lying to ourselves with the 3 person requirement and stopping components from growing; however as we don’t have any kind of mentor system the 3 person rule usually means that any new committers need to rustle up some support from those who know how things work.
• Common systems. We use both Ant and Maven-1 for all projects. Now Maven-2 is starting to take over, so we’re heading to supporting 3 build systems per component. That’s 2 too many. For a while we had Bugzilla and a few on JIRA - now we’re all on JIRA. Fortunately no one has gotten the Confluence bug yet and split our wikis or our sites (maven-1 generated, with a couple of sandbox maven-2 prototypes).

---

Dan links to Codehaus when he mentions the Dictator model. I think this is something that has not marketed Codehaus very well within the ASF - it implies that Codehaus is about dictators, be they benevolent or insane. It’s not. Codehaus is not a place that encourages despots to run around abusing their power and fragging newbies. It’s odd, but I think when it comes down to community-styles, you can liken the ASF to the GPL license and Codehaus to the BSD license. The ASF defines what’s good and mandates that things must adhere to that good. Codehaus defines what’s good, but allows people to walk their own path with the proviso that Bob the Uber-despot is up there watching and will act if anyone goes overboard. The Apache model is the natural model for any group of benevolent dictators who are working together.

How about this - Apache Project Chairs are dictators. They are solely responsible for a project, they are liable for a project, they can do whatever they damn well please. One foundation’s chairs are another foundation’s despots. Codehaus gets interesting in that it’ll allow more than one despot on a project (though that’s not common afaik). Instead of Bob, Apache have the board with Greg and Sander as chair/president and then the members behind the board. I imagine that Codehaus now also has the board (behind Bob? or as a replacement?) , and maybe the hausmates (aka members) are voting the board into place.

So what’s the difference? Personalities. Rhetoric. Age. Apache sets rules, Codehaus has tribal recommendations (use whatever license you want, but we recommend AL 2.0 etc). Apache has the Incubator, Codehaus has a nod (least I think it’s pretty informal to join - convince hausmates/bob that you’re worth it).

This entry was posted on Monday, October 9th, 2006 at 3:06 pm and is filed under Opinion. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.