Re: Hushing up Sibelius news?

[Adam Spiers]

On Tue, Feb 26, 2013 at 5:22 PM, David Kastrup <address@hidden> wrote:
> Adam Spiers <address@hidden> 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.