Re: critical issues

[Łukasz Czerwiński]

First of all I would like to apologize for misjudging Lilypond project.

As for all the emails that were written it the last two days, I believe that a sort of coordination is needed in each project. Maybe for some of them there must be one boss with many programmers and designers, while for other projects a better solution is to create several small loosely connected groups, nevertheless each of them having a leader.

As a person who knows only a bit of Lilypond, I would like to get a better view of Lilypond, so I'd like to ask some questions:

• What's the aim of Lilypond? And why isn't it competing with Finale and Sibellius? Aren't all three programs "making PDF files with music"? Of course Finale and Sibellius have some other functionalities, but the common one is related to PDFs.
• Every computer program and in fact every thing or machine have a "most common user". How would you describe a most common user of Lilypond? How does he/she use Lilypond, what kind of music (and how complex) does they (re-)write? What annoys or disturbs them most in Lilypond?
• Let's assume that I would like to help in developing Lilypond, but I don't have my own idea, what part of it I could improve. What would you suggest me to do?

If everybody does it in his own local way, it is more a distraction than
anything else.  "How does one do x in LilyPond?" "Depends on whether you
are talking about functionality written by Mike, David, Han-Wen, Jan,
Graham, Carl or Werner".  That's not what a user wants to hear.

Are there some guidelines how to write new code to work in the same manner as the already written code? If no, is there a person (several people?) that could answer such questions?

Well, uniform code is nice, modular code is better.  You don't need to

worry about uniformity if everything actually calls the same code.  And
if you need to change how it works, being able to do it in one place is
much less likely to cause problems.  Of course, that needs to touch
foreign code in a lot of places instead of just leading by example.  And
that's where actual leadership is helpful since it can _make_ people
change their _own_ code, and they usually are much better qualified to
see problems in connection with those changes than a self-appointed
global janitor can hope to be.

I totally agree.

 

> I think a good policy is that, when working on that which one wants to
> work on, one should always strive to do it in a way that leads to
> better maintainability and extensibility.

If those efforts are not coordinated, there is no end user benefit.

"Coordinated" does NOT mean slavery and being a bored, sad programmer ;)  It just means that no one is "a self-appointed janitor", because there is always someone, who keeps an eye on some guidelines of a quality of a Lilypond code.

Hoping to read soon your answers to my questions,

Łukasz Czerwiński