John Willis on Open Source
John Willis just made a great post on the Open Source vs. Commercial software for enterprise management:
Now contrast this with the infamous iLike/Puppet story. Last year iLike.com added a new Facebook application to their service and they gained 35k new users in 24 hours and over 700k new users in just a couple of days. Within a three week period they went from 3 million users to 6.7 million users. Less than a year later, they now have 23 million users. Surely, they must have used an industrial strength multi-million dollar provisioning system - 'not'. Their provisioning system was FREE. With the help of a consulting company called HJK they used an open source product called Puppet to manage their server growth. HJK boasts that with a really short services engagement, one or two weeks, they can achieve 10 minute psychical system bare metal installs. On Xen images they can provision a system in two minutes. In other words, for about 15k in services and another 15k for a Puppet maintenance contract, HJK can provide a solution that the Big Four charges over a million plus and they can deliver the solution in two weeks instead of 3 months.
Fri, 21 Mar 2008 | Tags: opensource, puppet, opennms, hjk
Puppet on Ohloh
Looks like someone added Puppet to Ohloh. I hadn't heard of the site before, but it looks pretty interesting. I dunno how well it will succeed in its goal, but I really like the idea of there being a site that draws in the conversations about a given project and shows how different projects connect.
Fri, 21 Dec 2007 | Tags: puppet, opensource, project, social
Recent Lessons on Managing Open Source Projects
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.
Wed, 12 Dec 2007 | Tags: development, opensource, projectmanagement, lessons
Tags
