Re: Supporting my work on LilyPond financially

[David Kastrup]

Mike Solomon <address@hidden> writes:

> On Nov 30, 2013, at 12:06 AM, Janek Warchoł <address@hidden> wrote:
>
>> 2013/11/29 David Kastrup <address@hidden>:
>>> 
>>> But one person who just works on LilyPond can make a difference.  Can we
>>> keep this up?
>> 
>> As you can see, it appears that David (address@hidden) is doing abou
>> as much as the rest of the development team combined!

Going by commits, it's more like 30-40%, and I tend to break issues into
quite more commits than most contributors.  So while I'm unsurprisingly
the largest _single_ contributor (everybody else works mostly in his
spare time), "as much as the rest of the development team combined"
would be quite an exaggeration even if we talk just about committed
lines of code.  But that does not take into account a lot of other
important work that is going on for keeping LilyPond alive.

> I would argue that the point that Janek brings up above is not a
> healthy sign for LilyPond development.  Several developers, including
> myself, have lowered their participation considerably over the past
> two years.
>
> In my opinion, it would benefit LilyPond, and David too, if there were
> more skilled volunteer developers working on the project.

The main problem for letting skilled volunteers work effectively to the
benefit of the project is the state LilyPond's code base is in.  Then
there are the tools, and the work dynamics.

If you take a look at

commit 7d3d28de0ce6e2f018aff599cecd944d1754fe3c
Author: Mike Solomon <address@hidden>
Date:   Thu Jan 10 08:54:12 2013 +0100

    Makes all side-positioning based on skylines instead of boxes.

via the tracker
<URL:http://code.google.com/p/lilypond/issues/list?can=1&q=7d3d28de0ce6e2f018aff599cecd944d1754fe3c>
then you'll find its core issue in 2.17.10, and followup problems in
2.17.15, 2.17.25, 2.17.26, 2.19.0.

For one thing it means our reviews and the underlying infrastructure
don't work out well when people apply them as they understand them.

For another, it means that LilyPond's architecture is becoming
increasingly fragile: improve one corner, and four distant corners
crumble under unforeseen consequences.  At some point of time we are
running into an equilibrium where any change will cause a chain of
repercussions that does not really die down in a sane amount of time.

When we arrive there, more skilled volunteer developers working on the
project don't really achieve more.

The backend is a mess, with simple-closures, pure-unpure containers,
cross-staff flags and other cryptic stuff with strange interactions that
only few people can tamper with while causing only moderate damage to
existing functionality.

There are some subsystems which are surprisingly independently
maintainable, like the MIDI system.  But that partly also means that
they are not actually well-integrated with LilyPond's data structures
and concepts.  The various output format backends don't make a whole lot
of sense to me, but they are also somewhat independent.

So there would be some room for people specializing on some things, and
there is a lot that could be done even without messing with a whole lot
of other things.

A Cairo backend would be a mostly independent endeavor.  Fast rendering
interfaces would be mostly independent.  Work on Emacs modes would be
completely independent (Frescobaldi is a whole independent UI project).

GUILEv2 migration is sorely needed, and would be a mostly independent
project even though it touches quite a bit of code all over the place.

It is clear that our development cycles have not worked out well.  It's
taken probably 9 months at least from the time we wanted to go for
releasing 2.18 to now, and it has been frustrating to people.

If we take a look at Linux development for comparison, the "merge
window" for a new version is open two weeks, then it takes months to get
to release quality.  That's a linear development model at the core, but
widely distributed code tested and merged in different combinations in a
host of repositories.  Nonlinear is, for example, GCC, where work
commences on several branches but done mostly centralized.

LilyPond is not modular enough to work well with the Linux methods where
Linus Torvalds merges patches at an insane rate (he probably merges more
patches on a hard work day than I produce in the whole year).

Work in the GCC style where work is done on unstable branches only makes
sense when people see their changes through to a state where they don't
cause lots of problems, both as genuine bugs and more importantly as
impediments to further development.

We have basically the situation that a month of initial work comes with
followup costs before a stable release is reached.  That's more or less:

month of documentation -> half a month of translation
month of frontend work -> month of bug fixes
month of backend work -> four months of bug fixes

and so on, for different parts there is a different amount of followup
work that is necessary.  Working on several parallel branches without
taking this into account will get us in the situation where the
unstability just runs off and does not get back into releasability.

Now the frontend ratio is where it is not really because of the fabulous
state of it (though it is slowly improving) but rather because of a
continually available expert with the tools and mechanisms used for it.

The backend is much less coherent, so expertise is harder to acquire,
people tend to work with partial knowledge, and progress is a lot more
fragile.  We need to get those four months down, and yes, a shouting
match is not going to help.  What will help is refactoring and
rearchitecturing, and that needs people with a thorough programming
background.

-- 
David Kastrup