Wednesday August 06, 2008
Free Software Project Management Axioms
Jesse admitted (in private, anyhow) that my
crazy ideas about free software release cycles and support plans may have some
merit. He also asked me to explain them in much more detail than pithy quotes
in email and on IRC.
First, I want to assert some axioms. I'm doing this separately so that
anything which isn't immediately obvious as true can trigger a lot of comments
and discussion separate from my thoughts on release cycles and support. Here
- Small, frequent upgrades are easier to manage than large, infrequent upgrades.
- Development freezes longer than a week don't work.
- You can't make volunteers produce work on defined schedules.
- Feature-based releases expand to fill all available time until someone feels guilty for not finishing the feature on a magical, wish-fulfillment schedule, and hey, has it been a couple of years already?
- A release with even one improvement over the previous release is worth releasing on a time-based schedule.
- (Almost) no one but contributors will test an alpha, beta, gamma, or release candidate in the same way that (almost) no one but contributors wants to run nightly trunk builds.
- The only reliable way to get real feedback from real users is to give them a real release.
- Users may complain that a feature doesn't exist, but at a fraction of the volume than if you remove a feature they thought they might want.
- Handing boring scut-work to volunteers is a great way to reduce their motivation.
- It's possible to release software every month without burning out
volunteers, patch managers, pumpkings, release managers, or testers -- and the
software can get better every month.
- Revision numbers are meaningless, except insofar as they increase monotonically. Revision identifiers (alpha, beta, release candidate) are evidence of an unhealthy release process.
- Rapid deprecation cycles are okay if you provide migration tools.
- Supporting more than two stable versions of a piece of software purely through volunteer effort is crazy.
- If downstream makes substantial changes to the code or to the release process, downstream has just volunteered to support those changes.
- If your project is under active development, the longer the period between stable releases, the less relevant your project is.
- Users who want critical bug fixes and new features without actually upgrading their software also want magic flying candy-dropping ponies.
I expect there may be a few objections to these sixteen axioms.