All the Perl that's Practical to Extract and Report

Free Software Project Management Axioms

chromatic on 2008-08-07T00:18:26

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 goes.

  • 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.

Successful projects are for developers

mr_bean on 2008-08-07T01:18:14

I remember Aaron Farr having some interesting
principles of free software project development.

One thing I think he said was that the most
successful ones involve developers. That is
they are producing software developers use.

I think he mentioned exceptions like OpenOffice.

One other thing he talked about was how
users become contributors.

I wish I could remember what he said.

alpha/beta/rc axiom?

depesz on 2008-08-07T05:54:19

While I'm not object to the point, I would like to have it somehow explained.

Other points are either self-explanatory, or simply obvious, but I don't immediately see why alpha/beta/rc releases are necessarily evil.

Re:alpha/beta/rc axiom?

depesz on 2008-08-07T05:56:18

While I'm not object*ing* to the point...

Re:alpha/beta/rc axiom?

chromatic on 2008-08-07T06:55:14

I don't immediately see why alpha/beta/rc releases are necessarily evil.

In the first place, they're ineffective as tools for gathering feedback. There's no substitute for getting your software to actual users and hearing directly from them what works and what doesn't work.

Worse, I believe they're fundamentally at odds with the practice of done done. If you get in the habit of releasing software with features you think probably aren't complete, you think are mostly complete, or you're pretty sure are complete but aren't willing to say are complete, you lose so many benefits of knowing exactly where you stand and what you really can deliver.

There's also a psychological cost. You're making some releases more significant than others. You're almost saying it's okay for people to ignore alphas and probably betas and maybe even release candidates by admitting that their quality might not be sufficient for every day use.

I have a big problem with releasing software where you're not sure that the quality is sufficient for your users to use regularly. I also have a problem with making some releases more significant than others. I want releases to be boring and routine. That's great! That's wonderful! I want upgrades to be small and routine and uninteresting and frequent!

Many people still won't upgrade frequently, but at least removing the pain of the Big Thud After Five Years Massive Upgrade is one fewer excuse.

Re:alpha/beta/rc axiom?

LTjake on 2008-08-07T11:45:35

In the first place, they're ineffective as tools for gathering feedback.

So true! Though, at least you'll get smoker reports...

Re:alpha/beta/rc axiom?

chromatic on 2008-08-07T17:07:28

I prefer to get daily smoker reports from trunk and significant branches. Hourly reports are even better.

The shorter the period between an action and its feedback, the more you can learn from the experience and the faster you can correct an incorrect action.

Sensible

acme on 2008-08-07T08:33:33

These all seem quite sensible. Now where are you going with this? ;-)

Book title: Open Source Project Management

gabor on 2008-08-07T12:13:57

I really would like to see a book about Open Source Project Management.

It should include both how one can run an open source project - stuff you started to write in the journal but also other things such as

  • How to run an OS project when you are a company e.g. MySQL or better yet some other company that decided to release - some of - its code under some OS license.
  • How could a company use the OS strategies you mention in their not open source products?
  • How could a company use the OS strategies in their in-house projects which are not products to be sold?

Re:Book title: Open Source Project Management

chromatic on 2008-08-07T17:23:33

I really would like to see a book about Open Source Project Management.

That's a good idea, especially the business perspectives. The most similar book is Karl Fogel's excellent Managing Open Source with CVS, which doesn't go into this much detail on releases.

Re:Book title: Open Source Project Management

ask on 2008-08-08T09:49:11

Are you sure you aren't thinking of Karl's "Producing Open Source Software" book?

http://producingoss.com/

Re:Book title: Open Source Project Management

chromatic on 2008-08-08T17:48:57

Somehow I confused both into one book. Thanks for the correction!

Volunteers and "scut" work

colink on 2008-08-08T03:01:00

From my experience managing my church's web team, people really don't mind menial work so long as the work is valued and appreciated, and doing the work is fun.

There were folk who would volunteers hours every month updating web site content, changing pictures, proofreading and checking for dead links. We'd get together at somebody's house, or a coffee shop with wifi, and just work.

Not only that, but menial tasks are a great way for people to get introduced to a project, and for them to do that at low risk.

I wouldn't call it scut work, because then you're branding it as stuff people don't want to do. They're just maintenance tasks that often don't get done, or done well, by developers.

Re:Volunteers and "scut" work

chromatic on 2008-08-08T06:23:55

Good point. There's a difference between the game development model of making everyone do tech support or manual QA before coding or design and having non-coding tasks available for interested volunteers. The latter can be enjoyable and rewarding.