I started work on debhelper 8 years ago and it's still one of my best known contributions to Debian. At the time, we had a tool called debstd that was clearly meeting some important needs, and was catching on like wildfire, but also clearly sucked. I managed to come up with a design that was cleaner and more flexible, while also having an easy migration path. Today it's a rare Debian package indeed that is not built using debhelper.

A few things stand out in how I did debhelper compared to free software tools I'd written before. I posted a proposal first, and used a lot of feedback to refine the design before I got started. I set down some design fundamentals that I've not wavered from at al all through the whole life of debhelper. I explicitly targeted users of debstd, and made it easy for them to switch over. I spent a lot of time tracking the market share of debhelper versus its competitors and working on inproving it.

If there was an early period when I was just making debhelper work well enough for me, and a middle period when I was working to make it dominate its space, we must now be in a late period, where it pretty much works for everyone, it's important not to break it, and most of the pressure is to add edge-case features, and new commands for new needs.

I've managed to avoid some of the problems in this period of debhelper's life cycle by adding the concept of compatability versions -- essentially the same as library symbol versioning -- to debhelper. This lets me make big incompatable changes without breaking things that need the old behavior, at the expense of some cruft. Still, debhelper has unavoidably developed some inertia now that it's mature, and some of the dynamicsm and excirement that was one of the things that drew people to use it is gone.

There's still constant demand for more tools to be added to debhelper, and increasingly they are for things -- new programming languages, subsystems I'm not involved in, etc -- that I cannot deal with very well. For a lot of these things it's important to say "no". But some of those "no"'s may have been misplaced, since the tools get added to Debian anyway outside of debhelper. In other cases, I have let other people maintain a particular part of debhelper, which has worked pretty well.

Debhelper has had a (second or third) rewrite listed in its TODO file for years, and the fact that I've not gotten around it it yet makes me think I probably never will. It's really hard to hand off a peice of software like debhelper to someone else to maintain, but it could really use someone with some more energy to co-maintain it with me.

My initial design for debhelper was pretty good, but one problem I did not anticipate was that a seemingly simple task like "install documentation" that was broken out into a single command like dh_installdocs could end up being complex and full of special cases. debhelper's design does not make it easy to refactor something like dh_installdocs when it begins becoming too complicated to fit in a single easy to learn command.

Next: ten years of free software -- part 6 ticker