On Tue, Feb 26, 2013 at 5:22 PM, David Kastrup <d...@gnu.org> wrote: > Adam Spiers <lilypond-u...@adamspiers.org> writes: >> I just blogged about this: >> >> http://blog.adamspiers.org/2013/02/25/music-industry-learns-nothing-from-the-avid-sibelius-saga/ > > Well, I see some fatally flawed assumptions here, riding on your notion > "both MuseScore and GNU LilyPond would serve as excellent starting > points for a world-class music notation product." > > Now I can't vouch for MuseScore, but GNU LilyPond is anything but a > "starting point" for software development. It is large with an > elaborate and complex architecture. And most particularly, an > architecture that is not the core expertise of the former Sibelius > development team.
I don't follow your logic here at all. Being large and complex doesn't rule it out from being a starting point. If it *wasn't* large, there wouldn't be as much to gain from starting with it vs. starting from scratch. Yes, of course there's a learning curve, but it's still miniscule compared to the effort of rewriting something of equal complexity from scratch. That's particularly true of LilyPond, which already has in the CG etc. way better developer documentation than most large complex projects will ever have. Some people might assert that's not saying much, but the fact is that I went from being more or less a total newbie to LilyPond internals to being able to track down and fix an obscure bug in the MIDI performer, over the course of a week or two of working on it in my spare time, with very small amounts of assistance from anywhere except the documentation - and I'm certainly not claiming that was any kind of impressive feat. A good developer who was a complete newcomer to LilyPond should already be somewhat productive at the end of their first one or two 40-hour weeks. In contrast, I very much doubt that 12 full-time developers would two weeks after starting from scratch have any useful code at all. There are plenty of prominent examples where fresh projects succeeded by inheriting a large and complex codebase. Firefox is one, and LibreOffice another; here's a great talk I attended at FOSDEM demonstrating precisely this: http://video.fosdem.org/2013/maintracks/Janson/LibreOffice__cleaning_and_re_factoring_a_giant_code_base.webm Those code-bases make LilyPond's look about as complex as two lines of BASIC ;-) As for core expertise, I doubt that many of that team were there when the code-base was first written, so architectural design and rewriting from scratch is unlikely to be the team's core expertise. In fact, for one definition of "first written" I can guarantee that *none* of them were there, because it was originally written by the Finn brothers for the Acorn Archimedes (the world's first computer with an ARM chip, of which I was a proud owner at the age of 13), and those two long since ceased development. The first C++ version was started (presumably significantly) prior to the first Windows release in September 1998. With software developer churn being what it is these days, I'd be really surprised if many of the original team are still around and now working at Steinberg. I expect that team's core expertise is fixing bugs and making enhancements. > They are, as a group, focusing on their areas of expertise and teamwork, > and that will imply similar architectural choices as the ones they are > already familiar with, in order to continue working as a competitively > efficient team. I don't buy that either. If they are smart, they should be aware of the strengths and weaknesses of the architecture of the Sibelius codebase, and be able to make different architectural choices this time round. In fact, if they don't, they are almost certainly doomed to failure because they'll spend x years building a complete clone of Sibelius from scratch, which has no competitive edge. In the mean time, Avid may have even found some decent replacements and got them up to speed. > They also are not in a position to prescribe the business models to > Steinberg Not "prescribe", no - but they could certainly try to convince Steinberg it makes sense. Of course, this would not be easy and would require them to not just grok how business models can be built on Free Software (which I sense from my short dialogue with Daniel Spreadbury that they don't) but also be really motivated to fight for it. Sadly that's very unlikely to happen. > and of course, starting from LilyPond implies a business > required to distribute under the GPL. Sure. As an employee of a highly profitable company with a 20-year history of successful trading based on software released under the GPL and similar licenses, I don't see any problem with that. > I can perfectly well understand their development choices. However, > they are in the same position of dependency as they were under Avid. If > Steinberg decides to pull the plug, they'll be empty-handed again, left > without software they are allowed to continue working with. And as > opposed to the buyout from Avid, they'll not have potential restarting > capital as a compensation. > > So again, their brainchild might be taken from them and left in the > desert to bleach, and all they will have gotten for it will be paper > from the bank. Good for trading stuff, but not helpful in itself for > leaving anything of lasting relevance to the world. Precisely :-/ >> Like it or not (and I certainly don't), a large proportion of people >> who need to notate music will run away screaming if you explain the >> compilation-based design of LilyPond to them. I think >> >> http://lilypond.org/text-input.html >> >> is absolutely fantastic, but some people's aversion to anything which >> looks at all technical seems unsurmountable to me (although I'd love >> to be proven wrong; after all, I still see "non-technical" airport >> staff happily typing cryptic commands into old-school terminals in >> order to query flight data ...) > > The staff is getting trained for that. That's all it takes: training > and confidence. Ask Janek. The problem is that LilyPond is notionally competing with products whose user-base don't want to spend time getting trained, and don't have to. They're happy learning "on the job" via point-and-click and help menus. Maybe one solution would be to enhance the help menus of a really good existing front-end such as Frescobaldi. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
