What Open Source Hardware can Learn from Software

By on February 28, 2013

 

When I look at the slowly emerging universe around open source hardware I often have a glimpse of great promises.

Recently we have also published on this blog, a list of worthy projects from the world of ‘open source hardware that has stimulated a lot of discussion and interest on social media.

Some of us still do not realize the potential that a consistent open hardware movement would  have if it reaches a global size in which the projects are more visible to one other with an increasing percentage of reuse, exchange and transformation of common artifacts.

The sentence that best evokes the potential of this movement, that I often like to mention is:

it’s not about not reinventing the wheel, it’s about open sourcing the wheel.”

BikeThis sentence by, Marcin Jakubowski, founder of the ambitious Open Source Ecology, reveals all the potential that is behind this: who would write code for a new web server at today? Nobody, we just use Apache or Tornado. Tomorrow no one will design an engine, a transmission or a universal joint from scratch: we’ll create them from a shared open source design.

Open source software is out of a decade of huge successes. When I think back to what was the open source software around 2000 (Linux and a handful of promising projects) and I think what we have today (a set of best in class products that essentially run the Internet) then I think it is natural to dwell of those that were the key choices – consciously or not – to this successful decade.

Is legit to think that, as for what has happened with open software, open hardware will also enable companies around the world (small ones, then bigger, then huge ones) to move up the bar of innovation and devote resources to create short term competitive advantages on top of common, interchangeable components.
As today we see open source products declare support for this or that database, perhaps tomorrow we will see open source engines declare support for different models of car frames, or 3D printers to declare support for this or that extruder.

Now I want to try to draw parallels between these two worlds, to identify the differences that will never be 100% overcome, and the practices that open source hardware should borrow from the open source software success story.

The very first difference between these two worlds that comes to my mind, is the role played in facilitating the explosion of open software, by two basic elements: the existence of common programming languages ​​and shared frameworks.

Java and PHP

Think of Java or PHP: how many open source projects are created around these environments? a LOT.

java

Java, released as open source by Sun around 2006, had a huge role. Many may not know that Java is the foundation upon which what is arguably one of the most successful open source project in history, Android, has based all its applications environment.

The Dalvik virtual machine is in fact derived from Harmony, an open source Java virtual machine created by the Apache Foundation, which allowed Google to create – in a very limited time – a development environment that was easy to understand and familiar to millions of developers.

Despite the achievements of Java are so incredible – making it still one of the most used frameworks for the development, twenty years since its creation – PHP itself perhaps had an even greater role in the development of the web. A large proportion of sites in the world is working thanks to this technology and, in time, PHP become part of an even more powerful framework: the LAMP stack, with Linux, Apache and MySQL.

More recently, we can even think about the role that Twitter Bootstrap is having: a lot of interesting, often open source,  projects are basing them on the framework that Twitter released as open source (Apache License) in 2011.

Git

Another fundamental advantage that open source has been able to exploit in the years has been the relative centralization of repositories for source access.

A common approach to versioning has made ​​it easier the contaminations between projects and the emergence of a community of developers with a remixing point of view.

Although there have always been different solutions, the role that was of SourceForge in the early days was then in time gained from GitHub.github_logo

As some of you may already know, GIT, the protocol behind GitHub which is basically its as a Service implementation, was created in 2005 by Linus Torvalds. From a wonderful article that appeared in Wired in February 2012:

“…Using Git, anybody can tinker with their own version of Linux — or indeed any software project — and then, with a push of a button, share those changes with Torvalds or anyone else. There is no gatekeeper. In practical terms, Torvalds created a tool that makes it easy for someone to create an alternative to his Linux project. In technical terms, that’s called a “fork”

Fork: this is the word that has made ​​the incredible success of GitHub, a fully bootstrapped startup now having almost (positively) embarrassing financials.

Again from the Wired article I like to quote another key passage:

Back in the 1990s, forking was supposed to be a bad thing. It’s what created all of those competing, incompatible versions of Unix. For a while, there was a big fear that someone would somehow create their own fork of Linux, a version of the operating system that wouldn’t run the same programs or work in the same way.

 But in the Git world, forking is good. The trick was to make sure the improvements people worked out could be shared back with the community. It’s better to let people fork a project and tinker away with their own changes, than to shut them out altogether by only letting a few trusted authorities touch the code.”

Here’s the key: a simple way to encourage changes and contribution (in the hope which proved true that this could facilitate the emergence of a an ultra innovative context).

 

Is OSS smaller than OSHW?

OSS-OSHW

The main problem now with open hardware, is that to have something to what GIT and GitHub were for software is much more complicated.

The main difference lies not so much in the management of files – many open hardware projects already manage all documentation via GitHub today – but in the realization of real-world projects that generate a tangible impact on productive activities.

While with software you just click a button and start the “build” process that will produce the software to put into production, the process of “building” objects, open hardware artifacts – such as an electronic board or even a chair – is relevantly more complex and requires a substantial set of support tools, such as installation guides or the trivial details within a Bill of Materials (which in the world of software we can just settle thanks to a #include at the beginning of a file)

So far the documentation necessary to replicate open hardware projects is much bigger – the challenge to replicate a real artifact – than that which normally accompanies an open source software and tools that want to play a similar role had by GitHub, for hardware, will certainly be something more structured and complex.

Interfaces

Another fundamental not negligible difference and is related to interfaces. Despite drawing common interfaces in the digital world is simpler than in the analog world, this does not mean that interface design and standardization didn’t play a key role in the world of computer software.

For example, today’s Internet is interoperated around a fairly limited number of standard APIs such as the generation of JSON and XML and, more in general, by means of best practices and paradigms such as RESTtful.
In addition, this type of interfaces have helped the open source software to penetrate gradually into the contexts in which proprietary software was still the master, often substituting it day after day.

Several attempts are underway to replicate this type of approach in the hardware world: we have recently spotted Open Structures OSGrid on this blog, and a less ambitious but interesting example can also be found in MakerBeam, a project funded on kickstarter and then ended up for sale at SparkFun, which is also operating as a basis for the creation of more complex projects, such as the polar plotter.

Therefore, to consider interfaces key and to encourage modular design that enables re-use, emerge as major challenges with still not so clear solutions at today.

The real growth of the movement will also inevitably be linked to the capacity that the world of open hardware will have to come to the market with credible and, most importantly, available products. With software it took a website and a download button: hardware distribution is more complicated as it takes workshops and small factories, such as those in which you can build a tractor, a car or an engine.

In the real world distribution counts and means of production are not as easily accessible as on the web, despite examples of on demand production networks – fated to grow and distribute worldwide – such as those represented by Alibaba or Shapeways give a glimpse that something like this could happen soon.

Once this will be achieved, tangibly lower costs and the benefit coming from participatory and community driven innovation will be so clear to catch the attention of all the actors of the productive chain and the obvious advantages in not reinventing the wheel, but in making it, rather, open source, will get clear for everybody.

If you liked the post, you shall follow @meedabyte on twitter.

About Simone Cicero

Simone Cicero is a blogger (at meedabyte.com), strategist & speaker. Simone is also a long time Open Source advocate and Open Source Electronics editor. Follow him on twitter at @meedabyte