That last comment by OCTO is actually the keyword which I wanted to pick up anyway. I'm *very* late to that thread but wanted to add a number of thoughts, as comments to aspects discussed in this thread, and by adding some that haven't been considered enough in my opinion. And collaborative editing is one of the most important ones, one that makes a REAL difference between LilyPond (or rather: text based tools/workflows) and GUI ones. I intended to add this aspect to an extensive comment on other thoughts, but finding this last post I think I'll start out with this one and exclusively write about that for now.
The fact that LilyPond compiles plain text files makes it possible to use all the established tools and workflows from software engineering, particularly the concept of collaboratively editing scores. The key technology to this is version control, in the sense of this:
https://en.wikipedia.org/wiki/Version_control. This is fundamentally different from any versioning mechanism found in tools like MS Word or Sibelius. Version control compares a whole project repository line by line, and that makes it possible to pinpoint modifications with that precision. Changes are logged in the project history forever, so I can tell exactly who has modified exactly what and when, and usually also why (if the person has provided a reasonable "commit message") to it. If you look at this
(online) commit you can exactly see that on April 4, 2015 Davide Liessi changed the erroneous regular rest to a full measure rest in measure 521 of trumpets 1-3.
Of course this is just one example, and there's a full story behind the concept of version control. But the point is: if someone else would have changed something in measure 522 of the same parts at the same time this would have been integrated smoothly without any hickups. In the project this is from we set up a huge score (200+ musicians and singers, 50 minutes) into a grid of 90 columns (rehearsal marks) and around 65 lines (parts), and anyone of our 15-20 collaborators could pick any of these cells to work on at any time. LilyPond would always produce a correct score, displaying the music that had already been entered and leaving the measures blank where music hadn't been entered yet. Or you could have it compile just the "cell" you're working on (one part for about 10-35 measures) to save compilation time.
On the other hand version control gives you the concept of *branches*, which you can understand as a kind of isolated sessions that allow you to work on different topics at the same time. This allowed us to establish a workflow of "constant peer review". This means that anybody doing music entry would reserve some material (a number of cells) and work on them on an isolated "working branch". This new material would then have to be reviewed by someone else who would be eligible to "merge" it into the "master" branch. What this meant is that rather than having the prospect of having to do proof-reading "someday" everything that was actually added to the official score had already been reviewed by *at least* two different persons. Of course this significantly increases the average quality of music entry.
This is just a glimpse of that aspect, but I can assure you this is something where working with LilyPond (or LaTeX, or any text based toolkit) is so fundamentally different from anything you could do with Word/InDesign/FInale that it's hard to comprehend if you haven't experienced it first-hand. A direct consequence of this is that responsibilities and workflows can be re-thought from the ground up. In traditional edition/publishing workflows you have a very sequential chain of responsibilities usually tied to specific persons that have to pass on the documents (files or phyiscal engraving plates) to the next. As editing is an iterative process documents have regularly to be passed back and forth, and as soon as we're talking about digital files this becomes a very risky operation creating lots of duplicates.
In a versioned workflow you're not dealing with documents that are passed around, instead everybody is working on the same data repository. This means that technically every collaborator can perform every necessary task. In reality you will rarely have that "ideal" case, instead you will have a set of responsibilities (e.g. music entry, scholarly review, engraving beutification, proof-reading, pre-press) with lots of overlap and (usually) one person with the final responsibility for a given task. But apart from that final say tasks and responsibilities are shared much more fluidly than with traditional workflows. This is not only more efficient because it reduces idle times waiting for tasks you can process, but (even more important) this creates a context of mutual exchange that is indeed very inspiring.
I must admit that not everybody seems to agree with that perspective. People who haven't had this experience and who are used to traditional workflows may have significant (although usually unbacked) reservations against giving up their guaranteed responsibility. Unfortunately I know that because I discussed these things with a number of major publishing houses (one of the other aspects I will write about in another post to this thread). Unfortunately promoting text-based workflows is a pretty evangelistic undertaking. You constantly have to convince people that once they have tried it they will "see the light". This does even apply if people realize that what you're talking about is promising to evaporize the frustrating problems they are facing on a daily basis. Still this "text thing" seems just too foreign a concept.
The metaphor I'm using for this is not just a metapor but I really believe it's true: Jumping into text-based tools *and* then into version control is comparable to basic techniques like learning to
- turn from back to belly (9 months)
- stand up and walk (15 months)
- speak (2 years)
- write (6 years)
These are tasks many children have reservations to undertake because they seem just too laborious and of dubious value. But once you have jumped into it and mastered the new skill you can't imagine how you ever could do without.
For those who aren't exhausted yet by this longish post I provide a number of links to blog posts that discuss this matter more thoroughly or from different perspectives: