Jakarta: 2005
January 3rd, 2005 by HenThe last 6 months as Jakarta chair have been a slow learning experience.
To start with, you have to figure out what a PMC chair’s role is. It’s different from project to project in terms of what the community expects, but what the board expects is the same. I began by putting down what I thought it would be, and over the last 6 months it’s grown: http://wiki.apache.org/jakarta/RoleOfChair.
The first big problem was the report Jakarta gives to the board. The board wanted a lot more info than previous reports had contained and over the last year we’ve improved this a lot: http://wiki.apache.org/jakarta/JakartaReport.
The latest report was a very happy success. The board suggested that we do subproject reports based on which ones have had releases; I modified this to include changes of status (sandbox->commons, commons->jakarta, out-of-jakarta) and every subproject put in their reports with limited cajoling.
Next up, as I remember it, was the Jakarta charter/list-of-bylaws. It was getting very out of date and so I used the same superb mechanism that I used to change the Jakarta Commons charter; create a copy of the page and use red font to indicate addition and strikethrough to indicate removal. Then get people to vote on it. It works quite well as a strategy and although there was no vibrant new direction, we at least had an accurate rendition of how we worked.
Around the same time as the charter update, I cleaned up various removals and pending additions to the PMC that had gotten stuck. We’d spent the previous year adding lots of people to the PMC and have now reached a point where subprojects and commons-components should have 3 PMC committers on the books. Whether they’re active is another story.
It’s important to explain what all the fuss with PMCs is. Simplistically, Apache can be looked at as two communities. The original httpd C coders and the large explosion that was Jakarta + XML. In the httpd world, virtually every committer is on the PMC. Effectively, to not be on the PMC means you’re a new committer and not quite in the management of the code part yet. In Jakarta, the PMC was effectively the Jakarta board and all committers had voting rights and were on the management. Things had to change, and the two obvious choices were either an independent Jakarta, or to fold Jakarta back into the httpd (and thus ASF) style. The latter was chosen and we’re about halfway on the road to its end-goal I think. More ‘Apache’, less ‘Jakarta’. In case anyone didn’t know, this is why it’s ant.apache.org and not jakarta.apache.org/ant; and why it’s Apache Tomcat instead of Jakarta Tomcat (though it’s still currently in Jakarta; it’s just being branded under Apache).
Having digressed a little, the important point was that a) the Jakarta PMC include the active committers, and that b) we would thusly have a structured oversight of the codebase. I think there’s still a way to go on this, mainly just because Jakarta is still too large to be treated as a TLP, and we need to decide if it should shrink more or if it should try to come up with some other way of organising itself (less sub-project; more one-project; or maybe more independent sub-projects). I’ll probably ramble on this further in the future; there’s a lot of material.
So, charter good; PMC somewhat good; report improving. What was next? There were minor things, trying to encourage usage of general@jakarta instead of the private pmc@jakarta list for one, but I spent a bit of time relaxing into the role and discovering the mailing lists I should be on. Currently this is board@apache and prc@apache (Apache PR). Increasingly legal lists too; because:
Next up was the legality of licensing. A lot of the reason for Apache existing is legal protection for the coders (well, the members, officers and committers on the PMCs). So a lot of attention is spent on whether certain 3rd party projects may or may not be used. This is usually a slow, slow process and while a lot of progress has been made, there’s little I want to announce publically yet. Suffice to say, this is a big part of the job.
The announcing publically line above links me nicely into another part of my role. As a VP at Apache, I’m privy to internal info; however I’m not a member of the ASF (originally there were 2 of us non-member chairs, now there’s 6 or so) so my privy to info role is rule-challenging as not all of the system is designed for non-member officers. It’s “fun” as a) it’s like having a contracter as a CTO, and b) I have to be very careful about what I say. So a lot of my learning curve has been on how to fit in as a bridge between the partly private board and the public project.
The last month has had a few new themes. I’ve started to nudge subprojects about the move from CVS to SVN. The Apache Infrastructure group would like to be off CVS someday and Jakarta was lagging. Given that those most willing to reorganise were already at TLP level, it’s natural that those less likely to move out of Jakarta are also less likely to move to SVN. Momemtum is growing though: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion.
The last week has seen a sudden burst of mental energy on my part. The website is getting a clean-up and over the next quarter (the board reports are quarterly, so I think in quarters) you should see simple cleanup and reorganisation there. Part of this involved moving from the older Anakia setup to an XSLT setup that had been there for a long time but was unused. Much fun, especially when you find out that many other projects are using the website’s CVS stuff for their own websites 
Currently my target is a site much like: http://www.apache.org/~bayard/mock-jakarta-frontpage.html, though I don’t plan to stop there. Organising the website is a good way to organise the community; I think the same thing applies to any company where the employees have a high buy-in to the website.
One of the things I’m de-emphasizing on the front page is the view of Jakarta being Java@Apache. I’m effectively pruning this ‘feature’ back so that I can try to grow it as a separate concept within Jakarta. It was really confusing our message of ‘reusable components and server frameworks/containers’. As if that’s not confused enough already
Another big thing to improve is the much maligned download system. The aim is to improve subproject download setups and turn the top level download page into more of a portal concept for getting to them easier. I want to do the same for Javadoc as well; perhaps even try to use my osjava multidoc there.
Day to day tasks as chair are a pretty small list. Monitoring the Jakarta dev mailing lists is something I do, and this uses a fair amount of time and gmail.com space. I change user permissions for CVS and SVN when needed. Otherwise it’s about sitting back and being aware of what’s happening, or trying to.
Recently one of the directors has pointed out a nice legal fact; the chair is the project. Thanks, no pressure, gah. So I have motivation to make sure I’m not biting off more than I can chew It also puts me in much the same position as a monarch in England; legally there’s enormous power, but in fact nearly all of it is unusable, and I have to be careful of meritocracy as one person’s good act on merit can seem like despotism for the chair.
All in all, an interesting semi-year and I look forward to the next year. Hopefully I’ll be able to get to ApacheCon in November and learn more.