On 7/8/06, Daniel Poon <mr.d.poon at gmail.com> wrote:
> Is
> there anything analogous you can do in a community driven
> development?
>
<puts on his Scrum master hat...>

Certainly. Even though people usually just scratch their itches (which
makes it hard to predict which features will be built :-)), usually
one or more people sign up for, say, a release and they are usually
committed to do some grunt work, stick with what is agreed, etcetera -
just as in a regular project. The biggest difference is probably that
you don't know how much time people will be able to give.

I think the most important thing we're not doing is timeboxing.
Releases should be time-based, not feature-based. This keeps things
cooking so to say - regular releases will put some pressure on working
towards "we can release at any moment" systems: daily builds,
automated testing, etcetera. Releasing twice a year or even quarterly
also makes the feedback loop shorter (and thus better), so the
community can better steer the course of development. Finally, short
release sprints will make it easier for people to sign up and even
commit time - I can predict in advance how much time I can spend the
next quarter. I cannot predict in advance how much time I can spend
until, say, the original 3.9 feature list is complete. In fact, I
changed jobs in the meantime and I've switched from full-time Squeaker
to something very different :-).

I'd suggest a major release per year (so you can break backwards
compatibility once a year :-)), and a point release per quarter.