centralization of lilypond development and forking (was: branching)

[Graham Percival]

On Wed, Dec 11, 2013 at 08:39:58AM +0200, Mike Solomon wrote:
>    See:
>    
> http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870
>    as one of several examples.  There is truth in anything David says,
>    meaning that I (like him (and most of us on this list)) have caused bugs
>    that I did not find or fix before someone else.  How, does this warrant
>    this communication style?

Interesting.  I totally agree that lilypond has a problem (see
below), but in that email chain I find myself nodding along with
David.  I mean, he makes empirical claims (such as documentation
about partial elliptic stencils) that I assume are accurate (since
I doubt he would make empirical claims without checking that they
are true).


However, I am not blind to the end result of the communications.
I mean, at the beginning of September 2012 (after the meeting at
the ranch) I was more enthusiastic about LilyPond than I had been
for the previous 5 years, but one month later I decided to pretty
much quit the project.

I know I have the (well-deserved) reputation of being extremely
conservative, but that's in part because I don't want to abuse any
donations or make any demands on existing/previous volunteers.
The idea of providing multiple binaries is one such example
(donated web serving and bandwidth), and the general notion of
"lilypond should not break stuff that previously deliberately
worked" is another.

But that's not to say that those constraints are unbreakable.  The
usual approach in the open-source community to a situation where a
significant number of people want to have a radical break with
previous traditions is to fork the project.

As a thought experiment, let's suppose that a new project forks
from 2.18.0, called OakMountain instead of LilyPond.  At a bare
minimum, OakMountain would need:
- a git repository.  (trivially easy these days)
- does it want to provide binaries?  Using GUB would bring in a
  huge amount of technical constraints, along with a certain
  amount of bandwidth required.  But maybe OakMountain wouldn't
  care about that; it could target linux only, and provide an
  Ubuntu disk image for any users on windows or OSX who want to do
  engraving.
  (admittedly, the Ubuntu image would also require a fair chunk of
  bandwidth... but maybe OakMountain would target the default
  Ubuntu 12.04 live disk image)
- does it want to provide any defence against regressions?  Maybe
  not.  Maybe OakMountain would guarantee that monophonic music
  with no lyrics will still work, but anything else could change
  and break.


This is not a rhetorical question.  I'm still quite interested in
having a music engraving system that's suitable for a "final
version" of my string music scores (particularly in conjuction
with Vivi, physical modelling performances of those works).  As we
saw in Sep 2012, LilyPond does not qualify, but if this was a goal
of OakMountain then I'd be interested in joining.
(that said, I'm contractually forbidden from contributing code to
open-source projects until June 2014, although emails and
organization are fine)

Cheers,
- Graham