The Goldfish Chronicles

And there I was thinking that things might get simpler somday - Vista EULA.

Very late, but finally time has arrived to be able to comment on the last few weeks. I’ll start with ApacheCon.

Ignoring the various flight hell I had (see next blog), ApacheCon was superb. With a couple of ApacheCons under my belt, it means that I’m not meeting as many people for the first time. So less of a “Hi, who are you?” and more of a “Hey! How’s it going?”. I remember the same kind of thing happening with mud-meets/mud-parties. The first couple are tentative, and then it becomes a much more comfortable affair.

That’s not to say I didn’t still get to meet people for the first time. It was very cool to meet both James Strachan and Stefano Mazzocchi for the first time - they were both wise old heads when I started doing open source things five years ago with smart things to say then and smart things to say now. Both have been quiet at Apache for a while, but are getting active again.

I also got to meet Phil Steitz for the first time. Phil’s a fellow Commoner (aka Jakarta Commons coder) and would have made it to ApacheCon a year ago if his employers hadn’t cruelly offered him a juicy promotion in the week before. Alas, this time it was flu that robbed us of Phil’s company for much of the week. Hopefully he’ll be back for next year.

During the Hackathon there were a couple of researchers from floss.syr.edu interviewing anyone they could lure near their microphone for their thoughts on open source communities - so I had fun rambling on about thoughts and ideas.

The keynotes were interesting this year - none of the three were obviously related to Apache. Some liked this and others didn’t - I liked it as it made them much more interesting than the usual open source call to arms, or editorial on the state of open source today.

Cliff Stoll talked about physics experiments he was conducting as a high school teacher - he’s a classic Christmas lecture type of lecturer, all energy and insanity. I like the subject matter, so it was fun and the main take away for me from the lecture was ‘this is what it’s meant to be like…. fun’.

Patrick Ball - CTO of human rights IT company Benetech - talked about the tools they’re creating for human rights groups. Interesting stuff, and it’s cool that they’re using lots of open source software to make it happen.

Howard Taylor - creator of comic ‘Schlock Mercenary’ - talked about how he moved from a day-job at a big corporate to running his own business around a cartoon he created. He used the term ‘fat tail’ to describe where he was (ie: not a big name, but doing well enough now), and it was interesting to see that it was book sales that funded him, the other options not being of comparable return on investment. This at a time when the publishers are complaining of much lower sales. No offense to Howard, but one thing this talk made me think was “Damn, they should have got Iliad to talk”. Howard had a lot of very good information and interesting business ideas, but User Friendly is our comic [quick pause while I read today’s].

All in all, I liked what they did with the keynotes. Something else I also liked was Sander Striker’s opening to the conference. He’s the ASF president and rather than doing the same old “This is what the ASF is” kind of speech, he reported back to the community on what had happened in the last year. I’m a big believer in the importance of feedback loops and this helps. Now we just need to get it in an online report as well.

I’m sure I’ll have more to comment on (especially regarding sessions I went to), but that’s a beginning. Now back to the debian install.

Email from Sander Striker:

Upcoming Saturday 21st through Monday 23nd the ASF
is moving a non-trivial portion of it's infrastructure
from the San Francisco area to Corvallis, Oregon.

During this move all services, save SVN, can be
expected to be down.  Mail will be brought down on
Sunday morning, California time.

Please be patient with our Infrastructure team, while
they work on the move and on bringing the services back
up.

The websites+downloads are in Europe as far as I know, so they shouldn’t be down either. Issue trackers will be, as will the download archives (I think), and the people.apache.org machine, so no site changes or releases will be possible.

Someone at OSCon I think it was compared t-shirts at conferences to the strength of the economy. The deubtante today at ApacheCon is an “ApacheDS 1.0!” t-shirt from the directory.apache.org project to celebrate their inaugral LDAP Certified ApacheDS release.

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).

In line with some other blog entries I’m seeing, here’s my todo list for ApacheCon next week.

• Goto the Jakarta BoF that Martin (the chair) is organizing.
• Infra-triage. Go through the bugs in the INFRA project in JIRA with any of the infra team who are up for it and try to encourage various resolutions to occur.
• Talk with people about Maven Archiva. Try to understand where it’s going and get hints on how to do some of the code.
• Talk with Phil about DBCP status.
• Attend Sally’s tutorial on talking to the media.
• Find time to do my dayjob open-source triage each morning.
• Eat healthily. My quality of food always suffers at conferences.
• Have..a…good…time. Relax.
• Try not to vent that I’m missing both Leo’s and Stefano’s talks on the Friday afternoon.