SOAPBOX
The {Unspoken} Rules of Open Source Hardware
I truly believe open source hardware is here to stay. It has established itself as a great community, a great effort, and for many, a great business. I spend most of my days working on open source hardware in some way, and I want to talk about some of the unspoken rules we all seem to follow.
Why? Because the core group of people who’ve been doing what we’ve collectively called “open source hardware” know each other — we’re friends, we overlap and compete in some ways, but we all work toward a common goal: to share our work to make the world a better place and to stand on each other’s shoulders and not each other’s toes. Some folks will agree strongly and others will disagree. That’s great — it’s time we start this conversation.
We pay each other royalties, even though we don’t need to.
As odd as it sounds, we pay each other. I can be really specific: I introduced Mitch Altman, inventor of the TV-B-Gone, to Limor Fried, owner of Adafruit Industries. I wanted to convince him to work with her on a kit version. That was almost five years ago and it’s worked out great. Mitch travels the world doing workshops while MAKE, Adafruit, and many others sell his kits, and he gets paid a royalty.
Behind the scenes, open source hardware designers pay a royalty to each other when they make and design together. Do they need to? Technically no, but we all do. Actions speak the loudest for this unspoken rule.
We credit each other, a lot.
What does the open source maker usually want? Just to be credited properly. This usually isn’t an issue since the community members look out for each other, but there are examples where it’s just unclear who made what. It’s usually not malice, just forgetfulness.
There are a lot of giant companies taking open source ideas and making them commercial products (that’s always going to happen), but the open source hardware community is a community. We credit each other. When we get general ideas, we usually say things like “This was inspired by such-and-such.” Giant companies don’t or can’t do this, but the open source hardware world can.
Naming: It’s better to be unique.
In general, we try to avoid naming our projects in a confusing way. Trademarks are one of the few ways we can “intellectually protect” hardware (schematics are not copyrightable), so we focus on branding things and building products that people know come from a specific company or person.
There was a period where many people and companies made Arduino-like boards and stuck “-uino” at the end of the name or even just called their product Arduino, but I see that ending soon. The Boarduino, for example, was OK’d by the Arduino team. This was before a million “-uinos” came out later.
More and more makers are creating new and unique Arduino compatibles and calling them something completely non-“uino.”
Evan Hughes
Arduino, the name, belongs to the Arduino team. From their USB vendor ID to the name and logo on the board, it’s theirs. If you’re trying to fool people by using someone else’s name, stop it. There’s more value in creating your own name for your own products.
We actually do open source hardware.
This is an easy one. If you’re calling it open source hardware, release the files — schematic, source, BOM, and code — all under an open license. Don’t hide them. Don’t say you need to sign an NDA and attempt to obfuscate. If you’re trying to be tricky, just don’t do open source hardware.
Open source hardware isn’t a marketing term — it means something specific. We’re doing open source hardware because we want to, not because we want to trick people. The only issue that usually comes up for us at Adafruit is time, as we manage hundreds of projects concurrently, so not every file is updated instantly, but I’m going to try my best to make sure they’re all up. I’m moving everything to GitHub to make this easier on me (and everyone).
Basing your project/product off open source? Open source it.
Let’s say you make something based on an Arduino, which is under an open license — you need to do the same. Once in a while I’ll see an Arduino clone that someone has made and put under a non-commercial license. When I ask why, it’s usually something like, “Well, I don’t want to be cloned — like the Arduino is all the time.” Sometimes the maker changes the license to an open one after the project makes the rounds. If you do an Arduino shield it should be open source hardware too.
Code and designs: Add value.
It’s not valuable for the community to fork code and just change a name or something small and call it your own. You need to add more value. Many open source hardware companies have really expensive teams making and sharing open source code and hardware. Just changing a couple of things so you can ship your own thing is really frowned upon. It happens, but it’s pretty rare. It’s one thing to copy and improve — it’s another to just copy and sell.
I’m a big fan of copy, improve, and republish, but it’s rarely done because it’s hard work. When people fork just so they can change one comment or make it sound like they’re the original authors, it’s a support burden for the original makers too. It can be a mess. For open source hardware to work, we all need to support the original authors when we can. We want to avoid people or companies building their products off the open source software/hardware communities and then closing them off. Sharing needs to go both ways, always.
Cloning ain’t cool.
If your goal is just to make Arduino clones and not add code or hardware improvements, please go do something else instead. I see a few companies that make straight-up clones, give them confusing names, and think it’s socially acceptable. It’s not. The beginners get confused as to what’s a real Arduino with the quality, service, and support, and most of the time the clones are crappy.
I have a box of “Arduino killers” from all over the world. They’re not adding value in any way; they’re just examples of people being selfish. I get a dozen emails a week from parents or kids who bought a fake Arduino and are upset it doesn’t work and that the eBay seller or fly-by-night store won’t help them. Most of all, if any reasonable person gets cloned enough, she might just stop doing open source due to the support burden.
Support your customers.
If you’re doing open source hardware because you want to make an Arduino clone thinking you can just pass the hard work of customer support over to the community, that’s not fair to anyone. Spend the time and resources to create tutorials and forums, and support your customers. I’m using Arduino again as an example since I see customers purchasing cloned Arduinos but expecting support from the Arduino support team because it says Arduino. Open source is a way to make things better, not to just outsource support to someone else. Join in, support your customers, and they’ll reward you.
Build your business around open source hardware.
If you’re going to require that someone does open source for your newly venture-funded online open source hardware social network or whatever, you gotta do some open source yourself. If you’re celebrating open source and attempting to make money around it, you gotta put value back in too.
For example, if part of your product design is requiring customers to have all their files under an open source hardware license, you need to do that too and open up your own stuff. Otherwise, what’s the point?
Obviously there’s marketing value in the word “open,” and for small startups we’ve seen that many want to take advantage of that. Want your new company to be part of the open ecosystem? It’s worth something, so you need to do the same. I’m not saying you need to give it all away, but you need to do something to show you value open source enough to do it yourself.
Respect the designer’s wishes.
Sometimes the maker of an open source hardware project might have a request if you’re going to clone their hardware; for example, “Hey, don’t use this to kill puppies, OK?” Now, while open source really doesn’t stop anyone from making a puppy grinder from your open source CNC, it’s totally fair for the designer to ask you not to do that.
A few times, I’ve seen an open source hardware project get hijacked a little, and the author was concerned about its direction. We can email each other and talk when needed. It’s a strength that we’re a community with members who can talk to each other. It’s also helpful for the designer to include a bit of text in a Readme for the license or on a project page that lists some ideal uses. Of course it won’t always be followed, but at least there’s some framework and intentions spelled out. We are humans who get emotional about our works; it’s not a weakness. This, too, is a strength. 
Share your thoughts and read the full version of this column at makezine.com/go/osh_rules.
Phillip Torrone is an editor-at-large of MAKE and creative director at Adafruit Industries, an open source hardware and electronic kit company based in New York City.
