Hardware and software are certainly different beasts. Software is really just information, and the storing, modification, duplication, and transmission of information is essentially free. Hardware is expensive, or so we think, because it’s made out of physical stuff which is costly to ship or copy. So when we talk about open-source software (OSS) or open-source hardware (OSHW), we’re talking about different things — OSS is itself the end product, while OSHW is just the information to fabricate the end product, or have it fabricated.

The fabrication step makes OSHW essentially different from OSS, at least for now, but I think there’s something even more fundamentally different between the current state of OSHW and OSS: the pull request and the community. The success or failure of an OSS project depends on the community of people developing it, and for smaller projects that can hinge on the ease of a motivated individual digging in and contributing. This is the main virtue of OSS in my opinion: open-source software is most interesting when people are reading and writing that source.

With pure information, it’s essentially free to copy, modify, and push your changes upstream so that others can benefit. The open hardware world is just finding its feet in this respect, but that’s changing as we speak, and I have great hopes. Costs of fabrication are falling all around, open and useful tools are being actively developed to facilitate interchange of the design information. I think there are lessons that OSHW can learn from the OSS community’s pull-request culture, and that will help push the hardware hacker’s art forward.

What would it take to get you to build someone else’s OSHW project, improve on it, and contribute back? That’s a question worth a thoughtful deep dive.

The Patch and the Pull Request

Back in the early days of what we now think of as open-source software, there was the patch. Indeed, the UNIX utilities diff and patch are probably the unsung heroes of the OSS movement. They enabled a programmer to easily figure out the difference between two (source code) files and pass those changes on to someone else.

Then along came Linux, which started off as a pet project of Linus Torvalds’, but grew to include so many contributors that handling the patch requests became a full-time job for Linus, and then for his “lieutenants” as he subdivided the responsibilities. When Linus needed a version control system for the Linux codebase, he wrote his own: git. No surprise, it was based on the idea of recording and handling incremental patches, but in a distributed manner that gave his lieutenants (but also anyone in the community) the autonomy they wanted to work on the code and then ask Linus to pull their changes in when ready.

It’s easy enough to set up your own web-facing git repository to share your code with the world, but just as more people use e-mail or web-hosting services rather than rolling their own, it’s a lot easier to use a service for small projects. Add in a social-networking overlay to a public git repository, and you’ve got GitHub, the de facto means of sharing and working on OSS information. With a Wiki for community documentation helping you along the way, it’s all downright comfortable to tweak OSS these days.

TL;DR: the heart and soul of OSS these days is pointing your browser at a website, copying the code, using it and improving it, and asking to get your improvements pulled back into the project the same way you got it in the first place. Easy-peasy.

Costly Fabrication

What would the pull-request cycle look like in the OSHW world? I download your design, look over the bill of materials (BOM), and decide to get a PCB manufactured and parts ordered. It arrives, and I play with it. Maybe I make modifications on the board itself or maybe, assuming that I can open up your design files, I make some modifications and order yet another version with my changes. If my changes work, I’ll submit a pull request back to you. Do you verify my changes by producing another one of your things? You can see where the friction introduced to the system by the need for fabrication raises its ugly head, two or three times: at least once for the changed version and once to verify that the change doesn’t break the original project. That’s something we need to work on.

On one hand, small-scale manufacturing has never been easier or cheaper. Gone are the days of spending hundreds on prototype PCBs; there are sources everywhere that will get the job done so inexpensively that many otherwise respectable hackers don’t even consider producing a one-off board at home. Of course the home PCB fab has also never been cheaper, with CNC mills capable of routing a board coming in around $200, or the relative ease of getting good results at home even with toner transfer. Add to this the secret weapon of a well specified BOM, maybe even one that can be ordered with one click or CSV upload, and the frictions here can be minimized. So far, so good. At least it’s plausible that I could replicate your masterwork.

If the fabrication costs are around $20 and a half-hour of time, I could maybe expect you, the diligent project maintainer, to approve one pull request per week, or maybe only if the patch improves the project enough to warrant a rebuild. But what if you ran three or five such successful projects? And it gets worse as a project scales up, of course. I wouldn’t expect a project owner to spin up a board with a $150 BOM cost just to verify my tweaks to the audio output section.

For yourself and any potential contributors to the project, it’s probably worth thinking about making the design as inexpensive and non-time-consuming to fabricate as possible. If you want pull requests, you’ll be looping through fabrication more than once, so extra time here pays off. But with the capabilities of DIY and small-scale fabrication ever increasing, and the price of professional work dropping, the fabrication step is becoming less and less of a barrier, at least for small projects.

Design for Modification

What about big projects that are simply too intricate to replicate more than once or twice per user? Is there any hope for the pull request in ambitious OSHW projects?

If you look at the RepRap project as a whole, it certainly has resulted in the very rapid, distributed development of open-source 3D printers, but you might not expect downstream changes to percolate upwards very rapidly. After all, building any printer from scratch costs $300 to $600 or more, takes hours of time, and isn’t a task that someone’s going to undertake just to check out your pull request.

But still, some of the most successful printers have a good degree of visible community contribution: the old Prusa Mendel has 30 pull requests, and the current Prusa 3 design scores 44. [Nophead], the designer of Mendel90, the other early square cartesian bot, was initially very reluctant to take community help. Interestingly, since he opened his project up on GitHub, he’s received 38 pull requests, and incorporated 35 of them. Success!

How can this be? First, these printer designs are entirely open, written in the parametric, and very easy to tweak OpenSCAD language. OpenSCAD is itself free, as well. So anyone with a 3D printer who wants to try out a modification has a very low barrier to entry. And a 3D printer is also eminently modifiable and tweakable. Many of the sub-assemblies are entirely modular and can be swapped out at minimal cost. You don’t have to build a whole new printer to test out various new hot-end mount designs, and neither do [Jo Prusa] or [Nophead] when they accept your patch.

Incremental changes are easiest to make when you only need to change one section, and not the global design. Modular design, with well-defined sub-units whenever possible, encourages improvement. (Am I talking about object-oriented coding or parts placement that locates the power supply off in a corner on its own on the PCB?) Can you use off-the-shelf breakout modules that are sourceable on the cheap that can be unplugged and reused in the next revision? Maybe you should.

Releasing your design files to the world doesn’t mean anything if others can’t dig in and help you improve them, and that means that they have the tools to do the job. With code, all that’s really required is a text editor and maybe a compiler. With hardware, the “code” — the design files — are often wrapped up in proprietary tools, which instantly limits the audience of potential contributors.

The obvious choice here is KiCad, which is open source and runs on everything. Of course, there’s still the learning curve that accompanies any package that’s not the one you’re used to, but until the entire industry settles on a compatible file format for schematic capture and PCB layout, you might as well choose the most open, widely available, and least encumbered tool.

Eagle, which has had an XML export format since Version 6 in 2012, is another contender. The tool is free to use for small boards, and it has a large number of users. We know how to get files out of Eagle’s format very well these days, including exporting entire part libraries, which means that KiCad users can hack on your files. I don’t know if it’s possible to make the round trip, though; can one import KiCad files back into Eagle?

There are many other tools, ranging in price from free to professional-use-only. For this article, I don’t care at all about their relative ease of use — if a large chunk of your target audience can’t use it, or if the file format doesn’t lend itself well to differences and revision tracking, you’re shutting out potential pull requests.

The Fine Art of the README

If there’s something else we can learn from the OSS world, it’s how important good and inviting documentation is to the success of a project, both for the end-user and for the potential hacker. And perhaps the first lesson here is that the distinction between end-user and hacker isn’t that great.

The potential hacker will also be more likely to try your project out in the first place if it’s easy and appealing to make, just like the end-user. 77.23% of all statistics are made-up, but I’d bet that the overwhelming majority of folks contributing to OSS projects are satisfied, or maybe even slightly disgruntled, users of the software in question. So show potential builders how to build and use your project, but don’t forget to show potential hackers how it works and how they can get inside it. And if you want to accept pull requests, don’t forget to say so, out loud.

Feedback?

Can we build a pull-request culture in OSHW? I hope so, because that’s the best part of OSS, but I’m also realistic. The raw physicality of the real world will always get in the way to some extent, but the pure cost barrier of replication is shrinking year on year. After that, it’s a simple matter of software, and getting everyone to use interoperable design tools. Yeah, that’s hard.

So in the mean time, what can you do to make your OSHW project more appealing for other hackers to contribute to? If the costs, both in labor and money, of replication are as low as possible, someone might make it. If they make it, how likely are they to improve it? That depends on how modifiable and modular the design is.

If you’re using non-free software for the design, can the data at least be exported? Or can the user work around your inflexibility by simply exporting the design to the tool of their choice? Finally, how well documented and inviting is your project for potential contributors, not just in use, but also in modification? Do you say you encourage pull requests?

Anyway, there’s some brainstorming about how we could make large-scale community OSHW work. Naturally, I’d love to hear your take, and examples of any successful projects with contributions from the public, in the comments. What else?