Re: Future of OpenLilyLib

[Mark Knoop]

Thanks to all for your responses. There seems to be a general agreement
about the desired direction but I'd still like to hear who is actually
using this code at the moment. Is it just Kieren and me?

### Usage

Several people mentioned difficulties using OLL.

- how to install?
- what does it do?
- combersome, unwieldy, unmaintained

This is the prime reason I decided to propose this reorganization. I
have started work to improve documentation and plan to work through most
of it incrementally. See below re maintenance.

### Shouldn't this all be in LilyPond or LSR?

Possibly, but it isn't at the moment.

Certainly there are features in OLL which could/should be moved into
LilyPond, and some which already have been. I believe maintaining _and_
**using** that code in the meantime is the best way to a) work out which
features should be prioritized, and b) come to some agreement about
interfaces and syntax for those features.

_Shouldn't this be done in code review as part of adding to LilyPond
directly?_

Possibly, but users are not always able to be focussed on this at the
time of development. If I'm engraving a score which is due next week and
need to do X then I'm most likely to write/adapt/hack together something
which works "well-enough" to get the score out next week. I almost
certainly won't have time to polish it to the point of submitting, and
following up, a merge request to LilyPond.

But I might be able to include it as an OLL module which somebody else
might see and either improve, use to solve a different problem, expand,
etc.

LSR has it's own set of problems, some of which have already come up in
this thread.

### There should be a better/easier way to include modular code in LilyPond

Yes, I think we all agree on that. At the moment there isn't, but even
if and when that might be implemented, I can still see a role for a
repository such as OpenLilyLib to collect and host those modules. Is the
future really copying blocks of code from websites or email attachments
and saving them to randomly organized local files?

In the meantime, OLL (mostly) works and can be improved with better
documentation.

### Maintenance

At the moment I use several parts of the OLL (mostly edition-engraver,
scholarly and bits from oll-misc) and so will keep maintaining them. I'm
also happy to help maintain any other parts which are used by others.
I'd like to identify what _isn't_ used so it can be marked as
unmaintained/deprecated/scavenged for parts.

Regards,

Mark
--
Mark Knoop