:: Creating, Managing, and Sharing Hardware Projects as Source-Code ::
originally published: March 28th, 2014
As makers, we are constantly creating and sharing our ideas. We are part of the new open-source economy. However, open-source is not necessarily an accurate description to use with hardware because there is no source-code. The description of the entire hardware project, nuts, bolts, 3D printed parts, drill patterns, electrical components, etc. does not take the same form as software. There is no standard way to quantify this data; hardware doesn’t have source-code.
The importance of source-code is based around the concept of a praxis – the practical application/realization of concepts, theories, skills, or knowledge. A term I first encountered in Michael Nielsen’s book “Reinventing Discovery: The New Era of Networked Science” where he focuses on a ‘shared praxis’ and how it is applicable to science and to our current open-source economy:
“This points the way to a fundamental requirement that must be met if we’re to amplify collective intelligence: participants must share a body of knowledge and techniques. It’s the body of knowledge and techniques that they use to collaborate. When this shared body exists, we’ll call it a shared praxis … Whether a shared praxis is available determines whether collective intelligence can be scaled up, or whether it cannot be.” – Reinventing Discovery, Michael Nielsen
Software’s praxis is source-code and when shared, it works great. Human readable text, which can be generated and modified by pretty much anyone with a text editor. Software source-code has such a low cost of entry that extremely distant and diverse groups of people can create large, innovative projects. Just look at the Linux kernel – it is the basis for most of the world’s, smart-phones, web-servers and super-computers, and its built by an international community of thousands. These open-source benefits are big business as well: Companies like Facebook, Google, Apple, Oracle, IBM, RedHat, and virtually any other large company you can think of, use open-source software building blocks, tweak them to their (or their customers) needs, and generate huge profits from them. At the same time these companies contribute back to the open-source community they have benefited from. As a hardware maker and an engineer I realized that many of my favorite projects couldn’t be aren’t worked on in this way. What prevents this kind of collaboration from benefiting hardware projects and businesses? Perhaps it isn’t that hardware is unwilling to participate in altruistic open practices, but that they are unable to.
Hardware currently has a much more complex praxis then software which often makes it unavailable to many would-be contributors. Even within a company using the most advanced computer tools, a project can be described very accurately, but it often falls on the engineers to create their own medium to share the data and collaborate on the project. The hardware designers, electrical designers, software designers, and the manufactures, all waste precious time (and money) filling in the holes between their different systems. Moving between mechanical 3D models, electrical schematics, and software functions is often left up to, dated technologies like: post-it notes, printouts, and the intercom system. Furthermore, the difference in the tools used between the personal and professional create more layers of incompatibility. Unlike software source-code, the requirement to work with, and convert between, proprietary file types inevitably leads to data disintegration.
Now there is one data structure used to describe a hardware project, its called a Bill of Materials (BoM), and it is the basis for most PLM (Project Life-cycle Management) software. Accounting software isn’t exactly an ideal collaboration tool, but a Bill of Materials defines every part involved in a hardware project regardless of other proprietary representations, so it is a good basis of a hardware praxis. As well, web enabled features, like the ability to link with external data (ancillary files, models, data-sheets, supplier portals, etc.) make a BoM much more helpful for designing and building (as well as accounting).
An upgraded Bill of Materials itself is just a partial solution to our praxis problem. It is still lacking progress on the cost of entry or ability to collaborate, i.e. its accessibility. Enterprise software isn’t exactly something everyone has (or wants) access to. What if there were an inexpensive, open way, to create, store, manage, and share an advanced, user friendly, Bill of Materials? How would this benefit the maker eco-system on both a personal and professional level? Well that is exactly what we are working on.
With bndr we want to change the BoM from an accounting tool to a making tool. Modern web technologies offer a means to implement such a system. Leveraging proven open-source software and techniques we can create, manage, and share data in a new shared praxis that is accessible to all and therefore can be scaled. A simple web interface provides the first step. Cloud software is simple, inexpensive, robust, and secure. With technologies like OpenStack the cloud can be public or private anywhere you want it to be: across your desk, across the building, across the country, or across the world.
We store this data a human readable, standard text aka. source-code. Something robust and standardized like SQL or Structured Query Language. SQL is a standard of data storage mechanisms that can be imported and exported in a plethora of ways, or read straight from the file (like our friend software source-code).
Finally, now that we have source-code we can treat it as such, leverage existing software and services for managing and collaborating on it. Using things like Git to manage the versions of the code, and github to manage how we collaborate with it. Simple abstractions can allow anyone to intuitively use these features, while those with software expertise can use all of the same systems they are already used to. ‘Open-source hardware’ now isn’t just open, it is also source-code.
There is no democratization of making when the cost of contributing ideas is not free (and in many cases it is thousands of dollars). Software source-code has decades of practice at open collaboration, building businesses around open-source projects, and creating entire new economies. A shared praxis that gives hardware projects access to all of these same mechanisms can truly revolutionize both personal making and professional manufacturing.