Project management is the craft of applying limited resources of time, money, and knowledge to produce a desired result.
We talk too infrequently about limited resources in the free software world. The theories are nice: there's a near-infinite army of programmers each willing to run one test, or add one feature, or write one line of documentation, or fix one bug. It's a lovely theory. It's not entirely wrong, either. When someone new posts a patch or a bug report or even says "Hey, I used your software and it saved me time," my motivation level improves. I've made a difference in the world, and the collaborative, open development strategy I've chosen lets other people help make a difference in the world.
That doesn't mean every project always has a wealth of resources. I believe that we have to manage our existing resources wisely.
For Users
Do you want a project that you can install and use and never manage and never upgrade? Do you want to configure it once, and leave it alone, and forget it's there?
Do you want a project that fixes bugs and adds new features as it comes to understand the problem domain better? Do you want your life to get easier, as polish removes some of the rough spots and the software does more of the heavy lifting for you?
Pick one. You can't have both.
For Developers
Do you want your source code to get easier to work with over time? Do you want your bug count to trend toward zero? Do you want predictibility in your release schedules, an active user community helping you iterate toward the ideal software for the problem domain, and the freedom to evolve?
Do you want your users to never have to worry about changes? Do you want them to be able to step away from the project for several years and suddenly on a wild whim install a new version and have nothing changed, nothing to worry about? Do you want to be so predictable that the best way to use your software in 1994 is still the best way to use it in 2009?
Pick one. You can't have both.
You Can't Have Both
Nothing says it better than The Itchy & Scratchy & Poochie Show:
Man: How many of you kids would like Itchy & Scratchy to deal with
real-life problems, like the ones you face every day?
Kids: [clamoring] Oh, yeah! I would! Great idea! Yeah, that's it!
Man: And who would like to see them do just the opposite -- getting
into far-out situations involving robots and magic powers?
Kids: [clamoring] Me! Yeah! Oh, cool! Yeah, that's what I want!
Man: So, you want a realistic, down-to-earth show... that's
completely off-the-wall and swarming with magic robots?
Kids: [all agreeing, quieter this time] That's right. Oh yeah,
good.
Milhouse: And also, you should win things by watching.
Like most false dilemmas written on the Internet as rhetorical devices, the truth lies somewhere in the middle — but for goodness' sake, is it possible to recognize that software under active development cannot guarantee perfect stability, and that if your goal is perfect stability, there's no point in continuing to maintain software?
Spending limited resources to ensure that change never happens is a great way to ensure that improvement will never happen — and that you won't have the problem of limited resources in the near future.
