The MeeBlip synthesizer project is about to reach five years old. I feel this collaboration with engineer James Grahame has been one of the most important to me and to CDM. We haven’t talked so much about its open source side, though – and it’s time.
In five years, we’ve sold thousands of synths – most of them ready-to-play. The MeeBlip isn’t a board and some bag of parts, and it isn’t a kit. You don’t need a soldering iron; after our very first batch, you don’t even need a screwdriver. The MeeBlip is an instrument you can use right away, just like a lot of other instruments on the market.
But unlike those other instruments, the MeeBlip is open source hardware. Not just the firmware code, but the electronics design that makes it work are all available online and freely-licensed. We became, to my knowledge, the first ready-to-play musical hardware to be available in that form in any significant numbers.
That’s not to brag – we should actually consider whether we’re innovative, or whether we’re just plain crazy. Being end user open source hardware isn’t just unusual in music. It’s still a tough sell in hardware in general.
When we embraced the idea in 2010, we frankly didn’t know whether it would work. Now, I think we can have some new confidence – not just for us, but for anyone interested in the concept. So let’s talk about how open hardware works, why we think it will continue to work for the MeeBlip, and how people interested in making hardware can make it work for them.
There is a definition for open source hardware
The 2010 launch year for MeeBlip also saw the release of the Open Source Hardware Definition and the first big annual summit on the topic. I was lucky to get to know the two women who spear-headed making these things happen – Ayah Bdeir (founder of littleBits) and Alicia Gibb. You can read our interview with them from the time, which covers a lot of history.
The final definition is here:
http://www.oshwa.org/definition/
And in fact, the Open Source Hardware Association has its annual summit tomorrow in Philadelphia. James is heads-down in Calgary, and me in Berlin, so we can’t make it – hope we can see a European satellite event soon:
http://2015.oshwa.org/
There were a lot of significant folks contributing to that definition. Creative Commons, littleBits, MakerBot, SparkFun, Wired, Make, Arduino, Adafruit, the MIT Media Lab, NYU ITP, and Parallax are all onboard – and I see a lot of old NYC friends (some of them now more famous, like Bre Pettis and Limor Fried). Like a lot of ideas, it helps to be in a scene; it made a big difference to me to get to know these people and talk to them about it.
What they did in the end was to closely follow a software definition, the Open Source Definition for Open Source Software built by Bruce Perens and the Debian project.
MeeBlip has to do some work to be open source hardware
It’s been great to see the for-sale music technology field get more open. We’ve seen makers publishing schematics, releasing open source firmware, and more. But to be really open hardware, the standards are tougher.
Manufacturers who want to call themselves open source hardware have some work to do. The OSHW definition is a really tough definition, but we have done our best to understand and follow it. You should definitely read the whole definition if you’re interested, but here are the big points:
1. The design is public.
2. The source and documentation are public, and in a way that lets you modify it, using an all open source toolchain.
3. You can learn from that design, modify it, make the hardware yourself, and make and sell your own derivatives.
4. A license guarantees your rights to use the tool, without discriminating against how you use it or what you use it with. (That doesn’t come without obligations to the user, though; see below.)
We meet all those manufacturer obligations with the open source components of the MeeBlip, including the front panel. Enclosures are a separate problem, because you design an enclosure specific to the equipment used to manufacture it – yes, even a 3D printer doesn’t really solve that. (Think of it this way: you can’t make a recipe for cake without specifying what kind of cake.) So our enclosure is proprietary, as it’s specific to our manufacturer, but I’d actually love to see people make and share custom, fully open enclosure designs in the future.
There are two aspects to this. The one you probably know best is the license – for the MeeBlip, that includes the GPL v3 (for code) and Creative Commons BY-SA (for hardware designs and look). But the job of the manufacturer is to provide both the design/documentation and the license.
Think of it like building a public park: you need the actual park first, and then maybe a sign that explains to people how they are allowed to use it. As with that sign, just posting rules isn’t enough to make them magically happen. And as with a park, odds are other park-goers, not the police, will be the ones who are most effective at keeping each other to the rules.
Sharing is generous – but it has obligations, too
“Open source” is not a free-for-all, not an invitation to give away your work – not with software, and not with hardware. It’s a system that works when all the participants understand and act on their obligations.
For most people, this isn’t an issue. The whole point for us is to make the MeeBlip as accessible as possible. We hope you’ll poke around the code, even if you’re not a programmer. We hope you’ll look around the circuits and learn them.
Where your obligations come in are if you want to share something you’ve made.
The first and most important requirement is attribution. If you make something based on the MeeBlip, you have to tell people you’ve done so. And that should be a standard for anything we make, even before we get into licenses or legal obligations – this is what’s ethical. Folk singers will often introduce a song by saying who wrote it, or who taught it to them. In synthesis, we’re very often proud to be connected to those who came before.
The second obligation is to contribute to the open source process. This means that if you share something you’ve made with others, you need to make sure the license goes along with it. That way, derivative products give people the same freedoms the original does.
The licenses actually require you to do this, too. We use “copyleft” licenses for our code and our designs. This means that any derivative works have to have the same license. It doesn’t mean you can’t combine the MeeBlip with proprietary tools – the open source hardware definition actually says you’re free to use whatever you like! But if you make a new synth based on the MeeBlip, you need to share what you’ve changed. An easy way to do this is to simply “fork” the GitHub repository, as that also lets people see your changes versus the original, and makes it easy to link between versions.
We know a lot of this can be complicated. So, the easiest thing to do if you’re thinking of making something is simply to get in touch. We’d really enjoy the chance to talk to you about it, and we can probably help you through what might otherwise be a tricky process.
We will certainly enforce these rules. That doesn’t mean stopping anyone from making hardware – on the contrary, we want to help people make any derivatives correctly.
We recently encountered a synth builder who had made a copy of the MeeBlip anode hardware; the internal electronics had only minor modifications and the firmware and use were identical. In this case, we did point out that James’ engineering work wasn’t attributed, and we made ourselves available to help that builder follow the rules and follow these licensing requirements. That builder seems to have decided not to pursue that project, but we’re still available to them and anyone else who wants to do this. We are literally volunteering our time to help you do it, so it’s the very opposite of trying to stop anyone from modifying or producing derivatives of the MeeBlip.
How are we doin’?
I’m proud of the first five years of MeeBlip, but we’re only getting started exploring its open aspect. What we have seen is some immediate advantages to open source synthesizer hardware.
People are learning from the project. We’ve had many MeeBlip customers poke around in the code and schematics. We’ve been able to use those to answer questions, for the more technically minded. And people have used this exhaustive documentation to make some of their own projects.
People do fabricate their own synths. There are markets where we simply can’t afford to sell the MeeBlip. In those corners of the world, it can be cheaper and more efficient for people to make their own. Because the MeeBlip uses all standard parts and nothing unusual or proprietary, they’re free to do that, and a handful have. And meanwhile, in the rest of the world, we can usually provide a better value proposition than the DIY method – so this freedom doesn’t put us out of business.
Open source is peace of mind. In an age when so much is relegated to sales cycles and doomed to wind up in landfills, having open source hardware means you know a product becomes obsolete far less easily.
Openness can lead to modifications. We’ve even seen some firmware suggestions from users. We’ve people build their own, very often amazing, enclosures. Just having schematics available makes this easier.
But look beyond the box. Now, there’s a whole lot more to do. Giving musicians the freedom to modify their instruments is more than just providing documentation and licensing. They have to have the know-how to do this.
This has probably been our biggest failing, but also our greatest opportunity. The next stage is really applying that openness as a way of helping people learn more about electronics, code, and synthesis. Now that we’re smarter about the product side, I hope our next five years are more about the experience side – from the end user just learning to make sounds for the first time to those delving deeper into engineering and invention.
And don’t be afraid. Fear has I think been the greatest obstacle to open source hardware. It’s clearly not the right paradigm for every project. On the other hand, I think fears about clones and theft may overestimate the dangers – at least when it comes to music.
Ultimately, what allows an open project to be effective is a respect for sharing and originality. And that’s where I think the music community has something special. Provided we keep our brand clear, I’ve been struck by how willing musicians are to invest in buying direct from the maker, and recognizing designs that are original.
The reality is, no one is stopping clones with or without special licenses. Even many mid-sized manufacturers can’t afford intellectual property litigation; most can’t afford patent registration in the first place, which these days is often a vanity project.
But what we can do is build a community of people who care about music, about musical instrument design, and about sharing what they do. Those are the people who will value originality. They’re the ones who challenge us makers to be better.
The history of electronic musical instruments is rooted in sharing. Theremin’s designs inspired Bob Moog. How-to-build-your-own-Theremin articles inspired future synth builders – and engineers in many other fields, not just music. Learning from a filter design or a sound routing architecture became a 20th century analog to details of woodworking and drum heads in acoustic instruments from years before. Sharing how we make musical instruments is part of what makes culture.
You can get an anode right now. The limited edition white MeeBlip anode is still available – but there are only about 50 left.
Get yours from us direct:
Get MeeBlip anode Limited Edition
For a limited time, shipping is free (US/Canada) or reduced (US$9.95 worldwide with tracking info – customs may apply).