I live among the worlds of technology, art, and philanthropy. A lot of my job is based on learning lessons from one of those and figuring out how to apply them to the other two; it’s pretty fun. Usually I get to bring new insights to my job at New Music USA. But recently I brought one to my actual composing.
I’m working on a saxophone and soprano duet, Finishing The Rose for premiere in March in Amsterdam, and I’m experimenting with opening up the process to my collaborators. That means sharing notes, sketches, and early drafts with Ian, Hanna, and all the other members of the commissioning consortium. If you’d like to join, you can email me or Ian for more information, or you can chip in right away:
So why am I doing this crazy thing? Why not just write the piece myself, and then hand it over when it’s done?
Well, because I want to try being open in my music the way developers can be open with their code. “Open” as an approach and a philosophy is about much more than just source code, and I want to see what it can bring to my composing.
A blog post from Eric Mill of 18f has been sticking in my head for a while: Working in public from day one.
Definitely go read the whole thing, but here’s a key quote:
In the wide world of software, maybe you’ve heard someone say this, or maybe you’ve said it yourself: “I’ll open source it after I clean up the code; it’s a mess right now.”
Or: “I think there are some passwords in there; I’ll get around to cleaning it out at some point.”
Or simply: “No way, it’s just too embarrassing.”
These feelings are totally natural, but keep a lot of good work closed that could easily have been open. The trick to avoiding this is simple: open source your code from day one. Don’t wait for a milestone, don’t wait for it to be stable — do it from the first commit.
So what does that mean for a composer? My kind of music, written scores delivered to performers (who often have to act as well) is a lot like software. It’s a set of instructions that can be executed, with some complex interactivity, to produce a result. I don’t produce finished electronic tracks and hand them over, and I don’t make sounds; I make instructions that go on paper.
And in the case of Finishing the Rose there’s a growing commissioning consortium around the piece. There are people who are invested in how it’s going. They can benefit from having early access to drafts and sketches, and can give valuable feedback, improving the piece.
I don’t write music in a code-based system like lilypond, so I can’t use actual version control, or GitHub. So how am I doing it? I use pdfs and Finale files (yes, you need a copy of Finale to open them; oh well), as well as my thoughts and research, uploaded to a Trello board. I’m using Dropbox links so that when I update a Finale file, I don’t have to re-upload it to Trello.
That’s just how I’m writing the piece, so why not share it? Knowing that other people can look in any time they want does help me keep organized, and it does push me to make good decisions, carefully, at every step.
So that experiment is going on right now. You can join the consortium if you want to (instructions above), and the piece is due in early February.
I’ll let you all know how it goes. I think it’ll make the piece a lot better.