Hi, I am currently in a problematic financial situation and job hunting is not going well. Basically I am at a point where I have no good idea how to pay rent, medical insurance, and maybe some food.
Germany does have a social security system but essentially I have come to a stillstand here because of some family history that leads to me formally having some amount of money that I am not free to use because of moral obligations and verbal agreements while my father (now 91 years old, bodily rather frail, but still publishing research work in the mathematical foundations of theoretical physics) may need it to cover health or care costs. I am not touching this money; my chances to prevail in court (which would take at least 1½ years) regarding social securance are somewhat dim, and if I were to lose, I'd have racked up a lot of debt. As a result, I am mostly locked out from social security. Job prospects are not good at my age, and with my rather mixed CV that is the result of, well, a really bad ability to keep myself focused on stuff I am not interested in. So what about parts of LilyPond that would be in need of work? Far better documentation for programmers (I think some people already wrote several documents; maybe one should look at integrating them). Opening MIDI up to programming/extension in Scheme. Generally cater for Scheme performers and iterators. Making grob properties more efficiently organized than in alists (I am not sure the potential for savings are here all that high). As part of that: Turn interfaces into virtual base classes providing properties. That would require stratifying interfaces: a grob could not inherit the same properties from two different interfaces. Stop the explicit distinction pure/unpure and instead trace which property callbacks access information like the current line breaks, and cache based on accessed breakpoint-dependent grobs. This would simplify programming, avoid logical problems, likely speed up processing "unless you do something imprudent" which would become harder to diagnose. Improve parsing and Scheme functions: right now we have \etc being able to do an astonishing amount of heavy lifting after which you need to revert to explicit Scheme programming. Some intermediate level might be nice to have. Markup commands are quite less flexible than music functions. And the relation to markup lists is still iffy. Going serious about an extension system (examine what Urs left us with regarding openlilylib and see how it may make sense to integrate stuff into LilyPond proper). Get rid of Ghostscript for most uses, possibly getting closer to a framework for live rendering. Reopen and reorganize garbage collection now that Guile 2+ and the Boehm GC and 64-bit architectures are here to stay. Now for better or worse, I already spent a number of years with a focus of becoming more dispensable, and given that I am far worse at getting myself into doing "grunt work" than many others are, it is a good fit if I mostly invest work into making it easier for others do cater for themselves. And I am glad that in the past years where I have been very little active, the C++ code base has solidified, the build system has been well maintained, the administration has been run well: Colin has been a fixture in keeping the commit processes well in line, Jonathan has done marvelous work in connection with Dan to keeping GitLab's automations running well on multiple platforms (our old processes using Google Code and SourceForge and whatever else were quite more cumbersome to developers). A lot of rough edges have been taken off, and that really bodes well. The question is whether there is enough taste for getting some new rough edges in with a view to making it easier in the long run for people to get work done with LilyPond and contribute to LilyPond, and whether there is a feeling that it may be worth enough supporting me for doing that kind of work. I have a somewhat mottled record to be sure. But a number of things certainly were making headway for LilyPond's future. And for better or worse, some things I have improved a lot, like the movement of functionality into music functions, some C++ ways of writing things more naturally, subproperty overrides/reverts (which were flaky/dangerous to use for years). Even if we still have issue 34. Would there be enough people willing to commit to regular payments at a sustainable scale again that there is a point in me turning to work here instead of prioritizing other venues (that were not overly successful in the last two years or so: at age 61 as of next week, finding even comparatively trivial jobs is not a no-brainer)? Thanks for thinking about it! -- David Kastrup
