lilypond-user
[Top][All Lists]
Advanced

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

Re: promoting LilyPond


From: Joseph Rushton Wakeling
Subject: Re: promoting LilyPond
Date: Tue, 03 Dec 2013 21:58:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

On 02/12/13 16:00, David Kastrup wrote:
How about companies which cannot risk getting locked in to software that
may stop being maintained in future?

I'm not sure that's a selling point, either. As long as there's a paying market, commercial software tends to keep getting maintained. By contrast the risk with Lilypond is that it's vulnerable to the continuing contributions of a fairly small set of core volunteers.

At any rate, we need to pitch LilyPond to _ourselves_ and listen what
annoys us.  Particularly when explaining LilyPond to others and/or
pitching it to them.

A good rule of thumb is, to ask "What is easy to do by hand but hard to do with Lilypond?" But you can also add to that the question, "What is easy to do with Finale/Sibelius but hard to do with Lilypond?" and "What is hard to do with Finale/Sibelius and can we find a way to make it easy?"

I don't suggest just casually asking those questions but really documenting extensively the evidence and experience of users. Some of those things will come up against David's "play to your strengths" remarks -- there are going to be things which are unavoidably difficult in order to make some other things very easy, and those will not be the same between Lilypond and WYSIWYG engraving software.

But on the other hand, I am not convinced that the most practical way to improve Lilypond's future is not to look inside and focus on making sure the internal design of Lilypond's codebase is optimal from a future-development-and-maintenance point of view.

Graham pointed out to me not so long ago that a problem with new enthusiastic contributors is that they can come, "fix" some issue and in the process break so much stuff that it costs far more time to correct it than to just reject the contribution out of hand and have one of the existing developers do the work. Trying to think about how the codebase could be refactored so that this isn't likely to happen seems to me to be a potentially productive way to expand and engage the Lilypond community.



reply via email to

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