Recent Lessons on Managing Open Source Projects
This is a post from Luke's old blog; it is saved here statically for historical purposes, as of October 2008
Ok, so it wasn't the next day, but, well, what can I say, I got sick, and this release is just taking forever. And my wife defended her dissertation last week, so things kind of got put on hold for that. Anyway, back to the program.
As I mentioned previously, I've learned a lot in the last few months, mostly by making mistakes.
Release Management
One of the biggest mistakes I've made recently is not putting out bug-fix releases in the last few months. The current release, 0.23.2, has some sticky bugs in it, and I've gotten so much development done in the mean time that it won't necessarily be a pain-free upgrade for everyone.
I let this happen because I haven't normally done large chunks of development, so it's been safe to release after each significant feature, since they were always short time periods, which meant at the same time there was no real need to keep a stable branch separate from the development branch. This batch of development has been varied and very large, enough work that I should have been maintaining a stable branch this whole time.
So, once I finally get 0.24.0 out (which should be tomorrow), I'm going to announce a new policy of always having a branch for every point release; in this case, there'll be a 0.24.x branch. All bugs will get fixed ASAP against that branch, and then merged over to the master branch if appropriate. This way I've always got a stable branch I can release if there are important bugs to fix, and I've always got any fixes in both the stable and development branches.
It looked for a while like I had someone to manage the point-point releases (e.g., 0.24.1 and 0.24.2), but he changed his mind at the last minute. It was an interesting idea, though, and got me pretty excited, so I'm probably going to try to find someone who will handle this role after all.
Community Involvement
While no one can argue I haven't built a pretty successful community, I think I haven't done quite enough to get them involved in the core of the project. Part of it is just the fact that most community members are sysadmins not developers, so it's reasonable that they wouldn't be mucking in the guts, but part of it is that I never quite know where to draw the line between the interests of the project and the interests of my company, which pays my salary and allows me to eat.
I think I need to work more toward getting a better balance of community involvement, which means finding more people to hand responsibility over to. A stable release manager would obviously be great, but I expect there are other areas we could find for people to take over. I've tried this some by defining community roles, but that was largely a failure. I'm still the only person really doing any ticket triage, even though we've had a published policy for months, for instance.
So it looks like I'll continue to make mistakes in this area, rather than starting to make the right decisions, but hopefully we'll eventually fumble toward a better balance.
This is a pretty rambling post, partially because I haven't really had time to lift my head much in the run-up to 0.24.0, but hopefully things will get better all around in the next few months.
