[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SPAM] Re: Serious feedback and improvement headroom

From: David Kastrup
Subject: Re: [SPAM] Re: Serious feedback and improvement headroom
Date: Thu, 10 Apr 2014 23:18:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Jan Warchoł <address@hidden> writes:

> Or, to look from other perspective: at current development speed, it
> will take LilyPond somewhere between 10 and 100 years to reach the
> stage where it does most of the things The Right Way (TM) (i.e. that
> most of the ordinary scores are engraved 100% publication quality by
> default).  In that time LilyPond will become obsolete, or at the very
> least it will completely loose any chance to have any noticeable
> "market share", which would be a loss not only for us personally, but
> also for the cause of Free Software and music engraving quality
> worldwide.

A workflow relying on large-scale manual overrides will mean a "market
share" of useful scores close to zero at any given time in active
LilyPond development.  It's a dead end.

We don't have the manpower to throw away all of Mutopia every year.
A score overriding LilyPond's decisions will decrease in quality
whenever LilyPond improves even though it may be vastly superior at some
fixed point of time.

> Why i think that failing to get more market share soon will mean a
> failure of Free Software?  Because i expect with 80% confidence that
> if LilyPond doesn't become much better soon, in 5 years Steinberg's
> upcoming application will become an unquestionable leader in notation
> software, and noone except the most extreme geeks will ever care about
> using LilyPond at all.

LilyPond does not become "much better" by focusing on large-scale manual
overrides.  LilyPond continued development while even Finale was running
circles around it.  The one thing LilyPond can offer reliably is that it
is Free Software.  That is a promise it can keep.  It will always be
available and free for everyone to improve and adapt.

> It seems that this new application will really be much better than
> both Finale and Sibelius, which means that it will probably be better
> (i.e.  more effective) at creating publication-quality scores than
> LilyPond.

The one application that we need to chase after is LilyPond, and the
users we need to worry about are LilyPond's users.  The workflows
surrounding LilyPond are sufficiently different from other typesetters
of today that we are not really in significant competition.

> Look at what happened with Browser Wars: in the first half of 2000s,
> Firefox was obviously a better browser than IE by orders of magnitude,
> and nevertheless its adoption was slow.  Then, when Google Chrome
> appeared, it had won the first place almost overnight.  Now, the
> problem with Lilypond is that it's not as much better to Fin/Sib as
> Firefox was to IE.  When a new program will appear that will have both
> the user-friendliness (=GUI) and good notation features, LilyPond
> won't have a chance.

Which is why Emacs has died out, vi is just a faint remembrance, LaTeX
has died out, and nobody uses the command line for anything.  Notice a
trend?  Those tools are actually constantly improving and serving their
users better each year.  And the users _like_ using those tools.  But
the mainstream focuses on different workflows and tools.  Workflows and
tools that are outdated in another decade.

No, LilyPond will never be a market leader as an application.  It might
gain some market share as a batch typesetter in some processes starting
with different input formats, maybe MusicXML, maybe other stuff.  But if
it does so, then the only important metric will be the quality of
untweaked typesetting.

Now I'm not actually interested in the batch typesetting engine aspect
all that much.  I _like_ LilyPond as an input tool and language.  So
call it ironic or not: exactly when one wants to jump on the "market
share" hype, the best bet will be working on the untweaked performance.

TeX has some market share in publishing workflows from scientific
publishers, but the input format tends to be Microsoft Word that then
gets passed through several stages typically involving XML and some TeX
or LaTeX input generated in a final XSLT-governed stage or similar.  But
this market share does not particularly help TeX development as such.
Heavy hitters like Kaveh Bazargan contribute back in indirect ways.

> That's why i believe we need to make the development go faster so that
> we win as much "market share" as we can *before* Steinberg launches
> their new software.  If we don't do this, Free Software will FAIL on
> the music notation front.

Free software is meeting its downfall reliably every new year.  It has
gotten used to it, the GNU project probably more so than most of the

> One way to speed up development is to have many many more passionate
> users that will also become developers.  Another way is to have some
> "corporate" users that could sponsor further development on a large
> scale.  Both of these options require attracting these users with
> efficient notation software, software that works _now_ instead of
> "being really great somewhere in the future".
> Do you see my point?

"Software that works now" is something different from "software that I
can work around now".

> As i said, while having Lily Do The Right Thing by herself must remain
> our ultimate goal, the question that i believe we should be asking
> ourselves is: how to maximize LilyPond efficiency in the shortest time
> possible (without compromising our ability to implement the Ultimate
> Goal)?

I make slow enough progress working on the main goals for me wanting to
get distracted with side goals that will only be of temporary

> Implementing one tool for graphical editing of any object takes much
> less time than solving *all* positioning issues with *all* notation
> elements.  And this doesn't make implementing the Ultimate Solution
> harder in any way.

It creates scores that will not survive into the future as source code.

> As a bonus, new users will be less intimidated by Lilypond's text
> input.

Because the recommended way for getting nice output will blow up the
size of the text input by a factor of 5 and render it incomprehensible?

> Let me make sure that we understand ourselves: I agree with you that
> we should improve LilyPond's automatic typesetting.  But i believe
> that's not the no.1 priority.

You work on your no.1 priority, I work on mine.  That's the way Free
Software development works.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]