In response to us posting some information about our 2016 annual plan, we got a comment with some great feedback from Benjamin Brink that touched on a lot of different things. One of those that we wanted to respond to in more detail was hosting Open Source Hardware projects on GitHub.
GitHub is great for hosting software projects, and is a good tool even for hosting and collaborating on other text-based goods like books (you can see some on GitHub’s Writing Showcase). These could be quick, small pieces of software from a ‘hello world’ application that only prints a predefined message, to large, incredibly complex feats of engineering like the Linux kernel.
The difference between software or books and hardware is very important, though, and is why we feel GitHub isn’t a great tool for hosting open source hardware projects, or documenting and collaborating on them. This difference is that there’s a lot more items that make up what is really needed for a piece of hardware to be Open Source than text.
These items of the project that I’m talking about, for any project that is more complicated than a simple breadboard or a few components that are easy to see how they go together, are things like build instructions. Regardless of your expertise, telling someone how to build a physical thing from parts requires pictures. A good example of what I’m talking about can be found in our own Shepard Test Stand project.
There’s no way to describe in text how to assemble Shepard and expect people to be able to easily reproduce it. All the Open Source Hardware projects we’ve seen on GitHub either fall into the simple category, and even those that don’t, like KickSat, don’t have build instructions. KickSat sort of gets around this by using SOLIDWORKS to show the assembly, but this requires you to pay for SOLIDWORKS.
Now, you could put together build instructions into a PDF or another file format that isn’t just text and images, but this doesn’t make it easy to collaborate. What people working on Open Source Hardware, as well as those just using the designs to build their own need, is tools like a full-fledged Wiki, so that beyond just text and images like I mentioned, other media such as videos can be included all in the same documentation.
The needs don’t stop there either. As these projects get more complicated, and involve people with backgrounds that don’t include software development, there becomes a need to accommodate people that aren’t comfortable with version control software. These contributors might be mechanical engineers, or photographers, or any other discipline. Unless all of these people can contribute with gentle learning curves, the Open Source Hardware community won’t be able to grow as large or as quickly.
Open Design Engine, where we host Shepard Test Stand and other projects, is our way of providing some of these capabilities in one place, instead of across a handful of different websites, making it easier and more likely for projects to be truly Open Source. In all openness and honesty though, Open Design Engine has its shortcomings. We haven’t had the resources to invest in making it great. It’s a minimally viable product, and gives us just enough to be able to make our projects able to be collaborated on and truly Open Source.
Ultimately though, different projects have different needs. Many projects, for a variety of reasons, are relatively simple, and GitHub might be enough. If the project is simple, I’d consider recommending GitHub, if only because of its polish. But hosting open source hardware projects need a better, more advanced environment than that offered for the software world, and that’s the whole point of ODE.