Is Ableton Open Source?
Open source development has proven capable of providing great functionality and quality. It’s nice to think that a product can be arbitrarily customized by its users and that development can branch out whereever it makes sense — as what’s good for one is not necessarily good for all. Beyond the practical, we like the idea of a communal effort made to serve the greater good of all: open source appeals to us as a model for a meaningful social interaction among creative people. In this article I hope to explain what role open source might play in the future development of the Ableton Live platform.
For those who are unfamiliar with our product, Ableton Live is a music creation/production/performance environment for Mac and PC. The largest part of our user base is made up of musicians from all walks of life — from amateur to celebrity, DJ to guitarist, rock band to electroacoustic composer — whose purpose of using the program is to make original music. A smaller part of the user base is engineers who rely on the program’s flawless performance in critical live situations like theatre shows or awards ceremonies.
Our software is not open source. Why not? Let’s start out with the obvious: we can’t think of a business model that would work for what we do. We make most of our money with shrink-wrapped, take-it-or-leave-it products that get sold from shelves in music stores. There are open source based products like Linux distributions that get sold over the counter but that’s quite a different type of product. Most of the business around open source software is service, not product sales. The idea is that a consultant comes in to, say, a bank where they’re wanting to use open source software; he/she helps them install, customize and adapt the software to their needs. This model might apply to some of our customers but we have chosen to focus on making a better product for musicians who, by and large, cannot afford that kind of service.
Let’s look at where the money goes. The lion’s share is used to pay the salaries of the circa 100 Ableton employees. It is surprising how many people make essential contributions to the making and maintaining of a product like Live — the engineers who write the code are a relatively small group within the whole thing. A lot of these folks don’t get the visibility they deserve: testers, for example, who spend their work day hunting bugs; technical support specialists who answer hundreds of user questions every day based on their expertise; sound designers; interface designers; authors of manuals, tutorials and instructional movies; product specialists who travel to help at workshops and schools; and many more.
The team where I do most of my work manages the specification of the software and acts as an interface between the users and the developers who write the actual code. Most of our development efforts support user wishes more or less directly. Users typically propose solutions: “Give me a button that does X when I click it.” We then talk to them to understand the problem behind the proposed solution. Sometimes we end up implementing a button that does X when clicked, but more often, we come up with some other solution. That’s because we need to look at every potential change to the software from the perspective of many different types of users. One of our biggest challenges is to assume the perspective of a large number of users who never speak out: those who try the software for the first time, can’t make sense, shut down and move on. Our foresight is limited and we often need to try things out. We make prototypes and test them on real people, oftentimes with humbling results that lead to substantial re-design. Last but not least, some of our work goes into things that no one has asked for, but we believe will make them happy all the more. Naturally, you cannot predict the outcome of such ventures; some go nowhere but some result in innovation that actually makes our users’ creative lives better.
Making a consistent technology product for musicians is quite a different thing than, say, writing web server software like Apache. User interface plays a key role and there is little in the way of standards to guide the specification. Coming up with a good specification is about as big a deal as implementing it and some of that is more art than science. It seems to me that making such a product requires a tightly-knit team of smart people, mutual trust and respect, and clear responsibilities. I have seen this work in a small company that is run by its owners (and founders in our case), and cannot relate that experience to other environments because I don’t know them — Ableton is basically my first real job.
I do have a hard time imagining how the types of interactions that I perceive as essential to the making of a product like ours would look like in a distributed, remote work scenario that is typical for open source development. I find it helps to gather in a nice office every day, to reconfirm that you’re not alone but working with others on a common goal which is a lot more fun for sure. The vast majority of our product decisions are made unanimously, as a result of a discussion in the team. Sometimes, however, discussion ends with conflicting opinions that cannot be reconciled or resolved by way of logical argument — matters of taste basically. It then must be clear who makes the decision and takes the responsibility: “I understand and appreciate your idea but have decided we will not do it like this but instead like that. Sorry.” Not a nice message to find in your inbox first thing in the morning! This is better talked about in person and maybe over a beer.
A closed product vision doesn’t necessarily result in a closed product. Quite soon after Live came out, it got adopted by a very diverse user base. We realized it would become difficult to answer the growing number of user wishes in a timely fashion without compromising the quality and consistency of the product. We were impressed with the way our friends at Cycling 74, the makers of the Max (and MSP/Jitter) visual programming environment, circumvented that problem: it is Max’s very nature to be user-extensible and the value that Max users enjoy comes from both the manufacturer and other users. Users build all kinds of things with Max — anything from video performance applications to sensor data processing for sound installations — and many submit their Max-based developments in source code format to the public domain, where quite a lot of sharing of ideas and collaboration is going on. Cycling 74’s role is to maintain and improve the (closed source) development environment — which is what they have been successfully doing for 20 years now, taking brave chances at times. The look and feel of the recent version 5, for example, marks a radical departure from traditions, for the sake of improved usability. Despite hefty initial bashing from loyal users, the release turned out to be a big success.
We were lucky to enter into an agreement with Cycling 74 about a comprehensive integration of both companies’ technologies. “Max for Live,” due for release in a few months from now, brings the Max/MSP/Jitter visual programming environment to Live, enabling users to extend Live’s functionality in ways we cannot predict today. Users can create new plug-ins for Live that, on one hand, can process real time audio, MIDI and automation data. On the other hand, Max for Live plug-ins can access and modify Live’s internal data structures (for example, tracks, clips in tracks, MIDI notes in clips, etc.) through a comprehensive programming interface that we provide. The programming of Max for Live plug-ins happens by way of “open-heart surgery”: the plug-in keeps running in Live while the user modifies its architecture. By default, Max for Live plug-ins integrate seamlessly with the look and feel of the platform and can hardly be distinguished from Ableton’s own virtual instruments and effects. User can, however, create entirely different user interfaces and break out of the common scheme. Beyond that, Max for Live plug-ins can modify and extend the operation of controller hardware and thereby create completely new music instruments.
Screenshots of three example extensions for Ableton Live made with Max for Live follow. We show both the interface of the extension as it appears embedded in Live and the extension opened in Max for editing.
Another, related initiative was announced to the public early this year. We develop a social network for musicians with tight integration in Ableton Live. Our first result is “Share Live Set,” a menu command in Live which transmits a music project to other users via the Ableton server. Boring things like collecting files and preventing the transmission of stuff that’s already there are taken care of by the software. The music gets its own web page where the user can manage access rights and follow how the piece evolves through private or public collaboration, by clicking through a “remix tree.”
Music is exchanged via this service in “source code” format. Recipients gain access not only to a musical result but also to the “recipe” for achieving that result, and they can change every aspect of the recipe: add or delete tracks, change parameters, replace samples or sounds, change automation etc. This platform should evolve to support users sharing all kinds of music-related assets: songs, clips (containers for musical ideas), synthesizer and effect presets, samples and also extensions to the program’s or some hardware’s functionality made with Max for Live. It will be up to our users to choose among different licensing models for their contributions. We believe many will make their results available to others in “open source” form and under a license that is conducive to collective development.
Ableton Live enjoys a diverse and inspired user community. Only through close interaction with this community were we able to develop the software to its current state. Going forward, our goal is to serve the community by opening Live for user extension and facilitating exchange of music-making tools in open source format. We believe more and more of the value that Live users enjoy will be provided by other users. This will allow us, the manufacturer, to focus on the improvement of Live’s core functionality, to assure our software meets the highest quality standards and to continue innovating.
We cannot know now how this will turn out of course. I like to think we can arrive at a division of roles between users and manufacturer that combines the best of both the closed source and the open source world. Ableton continues to develop the core of the Live platform according to the current development model that has proven economically sustainable and effective at meeting the common requests of a very diverse user base. Max for Live empowers users to extend the platform’s functionality in arbitrary ways, opening it to the “long tail” of applications and use cases that musical innovators come up with. Ableton, in turn, provides an environment for users to share results and collaborate according to an open source philosophy.
Social top