Re: sustainable development in LilyPond

[Graham Percival]

On Wed, Aug 04, 2010 at 09:10:25AM +0100, Trevor Daniels wrote:
>
> 1) There is no architectural overview and no program logic manual to 
> guide new developers through the early stages.
> This has the advantage that

No; there's no advantage to this.  It's simply due to an imbalance
of high skill, available time/interest, and an overwhelming number
of other concerns.

I'm quite aware of the problems that this causes for new
developers, but as long as we have over 10 patches waiting for
review for the past few months, the current bottleneck is *not* in
the initial "getting started" stages.  The current bottleneck is
reviewing patches.

The CG section on programming has been improving slowly but
surely, as have the Frogs.  I wish that we had more Frogs
submitting doc patches to the CG explaining the stuff they've
learned instead of leaving that task to the already over-burdened
Carl, but I didn't think it was worth raising this point directly.


> 2) There is no overall design plan to guide future development.
> New features are added in an ad hoc fashion at the whim of individual 
> developers.  The danger is that the overall structure will lose 
> coherence, properties will increasingly behave in inconsistent ways, and 
> the complexity of the user interface and the barriers to new developers 
> will increase.
> At present we rely on Neil and other core developers to
> maintain the integrity of the design by reviewing patches,
> but that is not guided development.

This part and parcel with the general way that volunteer
open-source projects work, though.  Projects with large commercial
backing (like mozilla and openoffice.org) can give a roadmap with
the knowledge that they have 20/50/100 developers to assign as
they wish.

Even something as "simple" as documentation writing was a huge
challenge to manage for the guided development in GDP.  I can't
imagine any such system working in lilypond [1].

[1] the single exception would be if we got a 50,000+ research
grant to do some notation project.  But that's not at all likely,
and I can't see this working with individual donations.


I'm comfortable with the "herding cats" style.  Most of the time,
we let people wander around at will; once in a while, we'll have a
Grand Project that attempts to capture people's imagination and
make them all move in (approximately) the same direction.

> We have an opportunity within GLISS and GOP to tackle these
> dangers, although their terms of reference would need to be
> widened to embrace them.  GLISS would need also to consider
> future needs and how they would be accommodated in the
> input syntax, and GOP would have to break down the barriers which new 
> developers currently have to overcome themselves.

This is possible, but I don't think it's realistic.  In
particular, it would need:
1. a large amount of developer time being placed under the control
of a benevolent dictator (or council of dictators), and
2. the "mundane" development tasks to be sustainable, and to have
enough effort to cover those tasks without needing to distract any
minions working on #1.

I'd say that we're at least a year away from having sustainable
mundane tasks... the Bug Squad will probably be sustainable in 2-4
months, but GDP utterly failed at creating a sustainable doc team,
and I'm not certain if anybody in the world other than Jan and me
can build releases.  (I know that Patrick's been working on some
stuff, but I don't know if he can build everything)


However, IMO we shouldn't be fussing too much about these
long-term issues until 2.14 is out.  We need a stable foundation.
(it's a bit unfortunate that the talk was when it was)

Cheers,
- Graham