The Challenge

The power of open source lies in the ability to build upon others’ work, and good documentation is the key to making this happen. The goal of open source documentation standards is to facilitate a collaborative framework which encourages others to contribute to a common pool of human knowledge.

Open product development has the potential to transform the economic system by making widespread collaboration possible. If there are easy mechanisms for viewing and updating open product documentation, products can evolve rapidly under the hands of many contributors. However, several obstacles often stand in the way of contributions and improvements. Below is a list of problems and possible ways to approach them.

  • There are no unifying standards or best practices for creating high quality documentation. Beyond the excellent work done by Phil TorroneDavid Mellis and Nathan Seidle for open source electronics, there is no clear description of what should be included in OSHW documentation in order to facilitate the replication, modification and repair of all types of OSHW. The internet has many disconnected pieces of open source hardware documentation, but much of it suffers in quality or clarity. Clear guidelines for taxonomy and structure can help address this. We propose an initial set of standards and guidelines to be debated and refined.
  • Documentation for OSHW projects is dispersed across many platforms, websites, wikis and blogs. As the number of projects grows it’s becoming increasingly difficult to find them. We propose a taxonomy to identify both hardware and documentation modules, which may lead to an online OSHW repository.
  • No clear definition of scope exists. While open source electronics has become one of the most visible facets of open source hardware, there is much more. The scope of open source hardware, and its best practices, should include items such as medical devices, houses, cars, and washing machines.
  • Lack of standard formats, clear organization, and technical jargon makes it difficult for the layperson to understand existing documentation. The goal of an improved documentation platform is to enable anyone, at all levels of expertise, to study, reproduce and improve open source hardware.
  • Language is a barrier for the dissemination of open hardware plans. We propose that all textual descriptions be linked to Google Translate and that a Visual Language for OSHW be developed to describe fabrication procedures – see The Noun Project and IKEA’s assembly instructions as examples.
  • There’s no simple way to remix and mashup hardware. We propose a modular approach to open source hardware documentation that would facilitate remix, mashup and branching.
  • Derivative work is difficult to track. Taking into account that OSHW is developed mostly by iteration and derivation, the number of branches of any successful OSHW project is significantly higher than what is typical of OSS projects. Given the proliferation of derivatives and lack of clear information about each, it has become difficult for users and developers to identify and decide what branch of a project to replicate or derive from. We suggest that a dashboard be adopted by all open source hardware projects containing essential information about each version or derivative, such as: name, brief textual description, hi-res images, hardware and software version, attribution, open source label (indicates which parts of the hardware are open source), status brief (honest description of the state of the hardware, software and documentation), changelog, dependency (what other hardware is required to run/use the hardware), compatibility (what it’s compatible with), genealogy (information on the hardware’s origins, derivatives and replications), etc. In addition to this overview about the hardware itself, we also suggest that adoption of a build dashboard containing information on difficulty level, cost, as well as time, tools, space and skills required.
  • Lack of appropriate software for designing, displaying and sharing plans makes collaborative development difficult.
  • It’s difficult to update and evolve open source hardware designs due to documentation dependencies – one small alteration affects several other components of the documentation.
  • Documentation is time-consuming. A clean, easily accessible platform would facilitate this. If the barriers to contribution are low and a universally-understandable format is developed, then combined micro-contributions of numerous developers can make the arduous task of proper documentation tractable.
  • Unclear licensing and fear of infringement of intellectual property (IP) rights discourage people from producing documentation. Documenting involves reuse of content from other sources. If people do not understand IP licenses or have little understanding of their own IP rights to use content, they may be afraid to contribute documentation. A clear how-to on open hardware documentation IP Issues, as well as a legal support framework, can mitigate this.

HOW (the process)

Being conscious of the wide scope of the challenges, we propose to host a 3-day event, that will be based on a mashup of well known co-design formats for group cooperation: Service Design Jams and Hackathons.

The event will be focused on:

  • identifying and sharing outstanding problems concerning the diffusion of open source hardware documentation practices
  • generating creative solutions and prototyping them collaboratively
  • improving awareness, cooperation, and coordination betweeen open source hardware stakeholders
  • drawing new talent to open source hardware by identifying a range of problems and challenges in development tasks

The event will be held on a weekend. A preliminary meetup on Friday afternoon will be used to identify challenges and form the groups on an interest-based choice. The groups will be then left to work, within an agenda that will encourage periodical coordination throughout the event for cross fertilization. The group will be asked to prototype all the work, in the form of documentation and soft deliverables, pieces of software, service or business ideas, animations, handbooks, guidelines, stencils and graphics sets, and so on so forth.