Current state Open Source Hardware – The need for and Open Source development platform.
André Hansen
Section of Engineering Design and Product Development, Department of Mechanical Engineering, Technical University of Denmark email: [email protected]
Thomas J. Howard
Section of Engineering Design and Product Development, Department of Mechanical Engineering, Technical University of Denmark Tel: +45 45 25 47 41 email: [email protected]
Abstract: Open Source Hardware (OSHW) is a new paradigm attempting to emulate the Open Source Software movement. While there are several flagship OSHW projects, this product development paradigm has yet to live up to its full potential. This paper reviews the current state of OSHW and revealing the lack of a robust and simple development platform to being a major barrier to the uptake of OSHW. The authors argue for the need for and Open Source Cloud based platform to be the most viable direction.
Keywords: Open source hardware, Open source hardware collaboration platform, Open Source software.
1 Introduction
While free software is becoming as commonplace as your very own personal computer,
free physical products are more of a rare phenomenon. However, it is our strong believe
that this will change in the not too distant future, following the emerging paradigm of
Open Source Hardware (OSHW). Free products may only be the minor benefits of
OSHW as it might revolutionise the way new technologies are created and the way we
interact with physical products in our everyday life.
The Open Source movement has in recent years managed to challenge even the
biggest international software companies, threatening the closed systems [1]. Open
Source Software development has been able to capitalise from the development in
communication technologies, enabling dispersed individuals and communities to
efficiently share information. While Open Source Software (OSS) is motoring ahead and
changing the realm of software development, one wonders why engineering design and
the development of physical products still seems to be a mere bystander yet to embrace
the full potential of the Open Source methodology.
Some obvious barriers arise when trying to transpose the paradigm of Open Source
Software into the realm of physical products and engineering design, e.g. problems
regarding test and validation. However, engineering design has become more and more
digitalised through the use of CAE. This realisation should allow a better utilisation of
André Hansen & Thomas J. Howard
communication technologies in engineering design and foster hope for a further adoption
of the Open Source methodology in the development of physical products.
A key aspect of the future success of OSHW is the development of a robust
collaboration platform. Using the words of Koch and Tumer “Why are robust
collaboration tools openly available to the programmer, but not to the designer?” [1]. It
seems evident that this must change if OSHW development is to counter OSS in
efficiency and success. Another important realisation is that, for now, OSHW
communities do not work on or share partial designs [2]. If OSHW is to embrace the
efficient development of more complex and meaningful products, this must also change.
This paper sets out to explore the characteristics of collaboration platforms supporting
OSHW development.
2 What is open source hardware?
So what is Open source hardware? Before investigating the questions regarding OSHW
collaboration platform, this chapter sets out to give a general overview of the OSHW
Paradigm.
2.1 A framework and definition
Some conceptual ambiguity seems to be surrounding open source development of
physical products. At the moment two terms appear online and in literature: open (source)
design and open source hardware. The use of the term open design could result in
confusion as it could be both a noun and a verb, which is why this paper will be using the
term OSHW as convention. We propose the following Open Source Design Taxonomy
(Figure 1) emphasising the activity of designing open source elements of all kinds.
Figure 1 The taxonomy of open source design
A Paper Submitted to ICoRD ’13
Although OSS has reached a stable definition, work is still being carried out to
finalise an OSHW definition. The OSHW definition hosted at freedomdefined.org
(definition in 2012) gives hope to this work being concluded in the near future:
Open source hardware (OSHW) is a term for tangible artefacts -- machines, devices, or other physical things -- whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things.
2.2 Protecting and Profiting from Open Source Design
Reaching a stable definition is most important in respect to creating suitable licenses
protecting OSHW products from unintentional exploitation. One of the most used
licenses at the moment is variations of the Creative Commons license,
http://creativecommons.org/. Licenses are a key element of creating sustainable OSHW
business models.
According to Fjeldsted et al. [3] there are some fundamental characteristics of open
design business models that apply to both OSS and OSHW. The nine building blocks of
business models [4], used to describe an archetypal business model, illustrate these
characteristics. There are a number of important elements that are needed for a successful
implementation and operation of open design, such as attracting and retaining
participants, creating a value proposition that appeals to both end-users and participants
but most notably, a platform to build the open design activities upon and a strong
community. The platform enables, facilitates and empowers interaction and development
between participants through a symbiotic relationship. The community involves the
company’s key resources as well as participants that co-operate through mostly a self-
serviced platform, which in addition works as a channel for sales and services. The
fundamental business part of the model and one which holds the biggest potentials for
improvements is the identification and exploitation of revenue streams.
In this relation Fjeldsted et al support Fitzgerald’s [5] claim of trademarks and brands
becoming the next IP mechanism, taking Oracle as an example, using the “unbreakable
Linux” slogan. The exact approach is being used by the OSHW developer Arduino that
licenses their brand and logo to manufacturers for a 10% share of their sales.
On top of licensing there are other revenue streams to be found such as incorporating
manufacturing and direct sales, providing consultancy, writing books, selling
merchandise, enabling subscriptions, membership fees, etc. These revenue streams affect
other parts of the business model, resulting in an iterative process which may produce
different versions of business models for a company to choose from and adopt.
2.3 Commons-based Peer Production and Open Source
Following the advances in communication technologies, the phenomenon of large-scale
collaborations between individuals in non-hierarchical communities is becoming
commonplace. Most Open Designs seem to be taking advantage of this new mode of
economic production. Commons-based peer production (CBPP) [6], is the collaboration
among large groups of individuals who effectively provide information, knowledge or
cultural goods without relying on market pricing or managerial hierarchies to coordinate
their common enterprise.
André Hansen & Thomas J. Howard
Common-based peer production as a mode of socio-economic production has proven
to be feasible to such an extent that it rivals other modes of economic production such as
market-based and managerial-firm based production. CBPP differentiates itself in two
core characteristics from other modes of economic production. The first being
decentralization of authority. The authority to act resides with the individual and not a
hierarchical based organiser. The second is the use of social cues and motivations to
motivate and coordinate the actions of participating agents, rather than prices or
commands [6]. Although open design projects do not necessarily need to make use of
CBPP as a mode of economic production, there is an obvious synergy between the two
paradigms. Open source elements seem to be a prerequisite for an efficient exploitation of
CBPP and vice versa. Most Open Design collaborations take advantage of CBPP while
you often find it implemented alongside more traditional firm-based production
exemplified by a somewhat hierarchical structured core foundation.
2.4 OSHW development process
Most OSHW projects seem to be initiated by core teams which publish a more or less
finished design for a community to start working on. Not having a design to start from
might leave new developers too high an entry barrier to start developing. This seems to
be the case with the collaborative space travel and research team, cstart.org, a promising
project whose activities have now ceased. With the core team facilitating the
development, a larger group of perimeter participators contributes with varying
commitment. This resembles OSS set-ups where established companies, such as IBM,
also undertake open designs development. In this case, the community of developers acts
as a virtual development team [1]. To the knowledge of this author no big established
company has yet to implement OSHW development in their product development
strategy, had their initial product not started out as an open design.
Traditional product development is often guided by a somewhat well defined
development process creating a framework for development and collaboration. In many
cases having such a well defined process allows for a more aligned development thus
heightening efficiency [7]. Many Open Design developments seem to take on a more
autonomous approach where formality and standards emerge from the ongoing
collaboration and where different processes can coexist within a project. In common
practice there would usually be a difference between how core team members and
projects perimeter participators would work. This autonomous approach might allow for
more people to participate while possible misalignment could affect the projects
negatively, e.g. designs made available in different formats thus harming the
communication between developers.
In such non-hierarchical distributed processes the trust networks between participators
becomes one of the guiding elements in the development. Especially when dealing with
complex products as groups and individuals will need to trust the input of others to a
higher degree. Individuals and groups with better reputation will have it easier getting
their ideas implemented while new developers might find it hard to be heard.
One of the most interesting things about Open Design development is when the
developer also becomes the user (see figure 2). The traditional lines between user and
developer are being blurred in open design development, which in the end can result in
very close feedback loops between usage and development [2] as it is the case in OSS
projects. Being both the developer and user is also one of the reasons people contribute to
A Paper Submitted to ICoRD ’13
OSS projects. Developers give their time and knowledge and will in return get to use the
product for free as they can simply download it. Free use of the product is not always the
case in OSHW as someone has to put out money for the product to be produced before it
can be used. Furthermore, developers using the product are In OSS projects a key source
of improvements as they will report mistakes in the code, “bug reports”. Due to the ease
by with the developers can test new ideas and solutions, mistakes in the code are
corrected with incredible speed while the data management systems automatically keep
track of these changes. Most OSHW projects will never match OSS in this aspect as the
tangible product often needs to be manufactured before it can be tested and validated.
However, this is being somewhat eased through the emergence of DIY manufacturing
and electronics projects such as the RepRap (3D printer) and Arduino (microcontroller).
Figure 2 The Life and Activity cycles for Open Source Design [2]
2.5 Challenges facing Open source hardware
Three main challenges facing OSHW are presented by Howard et al [2] that partly
explains why OSHW is yet to repeat the success of OSS. The challenges are
interdependent so one needs to take a holistic view on these challenges to overcome them
The first, and most obvious challenge, comes from the fact that OSHW entails a
physical product needing allocation of physical resources to be produced. So there is a
challenge of manufacturing. OSS products can be copied and distributed at a negligible
cost, facilitated by the same system used for its development. OSHW products need a
more complex and investment-heavy supply chain set-up to reach its end user. On one
hand this can result in some OSHW products never reaching a final form, benefiting
society. On the other hand, the manufacturing cost can result in a more sustainable
business model for the project originators as consumers will choose to purchase the final
product instead of producing it themselves [2].
The second challenge facing OSHW emerges from the need to validate designs.
Again there is often a need to produce prototypes to test and validate designs properties
André Hansen & Thomas J. Howard
to allow close loop iterations. Considering the complexity of common products today,
this could be a major obstacle for the realisation of OSHW products, not only in respect
to the cost but also the know-how needed. Digital simulations are the first step to
overcoming this obstacle but creating systems that support and lower the cost of
testing/validating design properties is crucial if OSHW is to entail the development of
complex products and efficient product development. Such a system could mirror the
peer-review systems in OSS projects. Having partially open systems, which allows some
parties to capitalise on closed source test documentation, as proposed by the 40 fires
foundation, could also be part of the answer to overcoming the challenge of validating
designs. The concept of “Manufacturing as a Services” (MaaS), community based
manufacturing shops which allow individuals to make use of flexible manufacturing
equipment, might in time create a base for easier design validation as it allows
communities to bypass large operations and manufacturing facilities [1,9].
Finally, there lies a challenge in allowing OSHW communities to efficiently
collaborate on high-tech complex products [2]. This is closely related to the validation of
designs as complex products will entail more sub designs in need of validation. Benkler
and Nissenbaum [6] present three structural attributes of the CBPP relations which are
highly relevant with regards to overcoming the challenge of complexity in OSHW
projects: modularity, granularity and low-cost integration.
For now OSHW communities do not work and share partial designs [2] mainly due to
a lack of a suitable collaboration platform. A higher focus on attributing modularity to
OSHW objects could allow the OSHW system to better handle partial design
development and allow communities to work on more complex products. Modular design
will also allow subsystem to be tested and validated independently, one of the module
drivers of Erixon [10]. Focusing on modularisation will however also result in higher
requirements for the discipline in the development process as modularity will lay
additional constraints on the object of development in the form of structural standards.
The granularity of the modules is important, as appropriate finely-grained modules
allow contributors to contribute in respect to their motivation and skill [1], lowering the
barriers of entry to complex projects. Defining modules with the “right” granularity can
be a difficult task but tools such as the “design structure matrix” are available.
The cost of integration refers to the cost of integrating the modules into a whole end
product. OSS benefits from low-cost integration due to efficient integration software,
which allows somewhat automated integration (merge features), and established iterative
peer-review practices. The latter plays a big role in design validation as well and is in
some cases formally integrated in the collaboration platform, e.g. sourceforge.com.
Although many OSS peer-review practices could easily be adopted in OSHW
development, automated integration cannot, partly due to the wide range of digital
formats used in many OSHW projects. One way of dealing with a higher cost of
integration in OSHW projects could be having a more formal development process, in
which stricter requirements are set on the various contributions. The level of formality on
OSHW projects seems to vary a lot, not only between projects but also between different
participating groups within each project, e.g. as mentioned between core team members
and perimeter participators. Creating an OSHW collaboration platform that supports
development of designs that contain the three structural attributes is seen as an essential
part of letting OSHW communities deal with the challenge of product complexity. The
next chapter will go further into detail with the requirements for an OSHW collaboration
platform.
A Paper Submitted to ICoRD ’13
3 OSHW Collaboration Platforms
OSS and OSHW platforms alike seem to have two fundamental functions; to function as
a social platform and to provide tools to enable efficient collaboration. Social platform
referring to a platform that creates awareness of the OSHW projects and allows projects
initiators, participators and stakeholders to meet creating a base for the community.
Although no studies have been done on how the size of an OSHW community affect the
success of a related project, most successful OSHW projects today seem to have large
and active communities.
The second fundamental function is to provide the community with the right tools,
collaboration tools such as design repositories and wikis. As mentioned earlier, there is a
lot of variation in how OSHW projects are structured so there is a need for the platform
to be flexible. OSS platforms, such as sourceforge.com and github.com, provide a lot of
flexibility. When projects are created on these platforms it is easy to activate the tools the
project creators see a need for. There is no current collaboration platform specifically
designed to support OSHW development. The Opendesignengine.net looks to be one of
the only promising OSHW platform projects judging by their guiding values and
potential features. The project has not yet reached a state for evaluation and unfortunately
the project progress seems to have halted.
Koch and Tumer present 6 main areas that must be integrated into a collaboration
platform; Project overview, Documentation and Design Repository, Communication,
User Identification Standard, Funding and Licensing [1]. The following will discuss the
first 3 areas further.
3.1 Project overview
Providing a good project overview allows for several things. First of all it gives new
potential users a good first impression which might result in them participating in the
project [1, 11]. Project overview in this sense is very important in relation to allowing the
platform to function as a social platform. The project overview also allows for an overall
guiding of the project by providing information to the participators, e.g. displaying news
and urgent matters. There is a question of how big a role such a collaboration platform
should play in regard to the management of the projects? There are open source project
management tools out there, why building on this work, implementing a suitable product
data management system, seems to be a logic way forward.
More commercialised current OSHW projects e.g. makerbot.com and arduino.com,
implement a product website focusing on marketing, providing product introduction and
selling their products while maintaining links to the development site, which give a good
current view of the project. Other OSHW products such as RepRap.com and
Openeeg.sourceforge.net use a wiki as their main page, focusing more on displaying the
development of the product. In general it can be said that a good project overview is
something that is lacking in OSHW projects. This is especially the case with regards to
documenting the development process. One comment on the opensourceecology forum
gives one reason for this. “The OSE development process is intended to be completely wide open and accessible to anyone who wants to watch. However, knowing HOW to watch can be challenging. OSE activities take place in a wide variety of web sites, software applications, email, conference calls, and on-site meetings at the Factor e Farm development facility.”
André Hansen & Thomas J. Howard
This case is repeated in many OSHW projects and results in a high entry barrier for
new developers. Especially for widely distributed projects such as RepRap, it is hard to
keep track of new derivatives and development tracks.
3.2 Documentation and Design Repository
Most, if not all, current OSHW projects collect most of the development documentation
on wikis. The dynamic nature of wikis makes them the perfect tools for collaboration,
making knowledge sharing in large groups easy. However, the wiki content should be
standardised using page templates to make communication more efficient. Many
developers might share the view that documenting your work is tedious work although
important, so tools with allow for an easy documentation will most likely heighten the
quality of the documentation. By utilising the script based CAD software, Openscad, the
RepRap community is working on implementing automated documentation by
embedding the product documentation, such as assembly instructions, into the CAD
model, making it much easier to keep up-to-date documentation. Openscad functionalities
make it appealing to the 3D printer communities as it is script based, but will probably
not be the dominant CAD software any time soon. The idea of automatically creating
documentation is however very interesting.
The design documentation, e.g. schematic, CAD files etc. in larger OSHW projects,
are for now often made available via design repositories on sites such as Github.com and
Sourceforge.com while providing some product data management. The Design
repositories on these sites are very focused on OSS development, just understanding the
syntax can be an obstacle for people without knowledge about software, although the
sites have easy to use functionalities.
An important aspect of design repositories is which product data management (PDM)
model, or version control system (VCS) as it is called in software development, they
make use of as it can have a huge impact on the development workflow. The most widely
used model is the centralised. Such a system has a single master repository from where
all developers check-out the documentation. However, not all developers will have write-
access [12]. The centralised model therefore focuses the project control to the initiated. A
decentralised model lets every check-out be a full-fledge repository with complete
commit history. With no evident master repository a repository is identified by
convention within a community [12]. Clarifying which model is most suitable for OSHW
projects is beyond the scope of this paper as it also depends on how the projects wish to
structure their product development. There exists several high quality PDM/PLM
solutions on the market today although they are probably too expensive for most OSHW
projects. Aras corp. provides an open source PDM solution which might be useful as it is
currently being used by international companies such as Motorola. A very interesting
notion is cloud PDM. Such a thing could be exactly what is missing for OSHW to
undertake more complex product development. It could be the Github.com of OSHW.
Solidworks n!fuze is leading the way in commercialised cloud PDM but for now no open
source counterpart exist. Although a wider use PDM’s in OSHW projects might benefit
the development process, there is still a need to gain access to the documentation via one-
click downloads.
Thingiverse.com is a site which makes design documentation available in a more
accessible form than the OSS focused repositories, and is widely used in the desktop 3D
printer communities. Although it has none of the features embedded in more advanced
A Paper Submitted to ICoRD ’13
design repositories, such as an actual version control systems, it provides an easy and
visual access to the design documentation. As a design repository Thingiverse is not the
best choice when dealing with complex product development as it functions more like a
showroom. A combination between thingiverse’s ease of access and sites such as
Github’s functionality would be an interesting possibility.
3.3 Communication
Kock and Tumer speak of three main forms of communication; group (forums), one-on-
one (mail) and real time (Skype, chat). As communication is essential for an efficient
collaboration these three forms should definitely be implemented. Furthermore,
automated indirect communication on a community level would be helpful in respect to
project overview. For example having voting systems that lets participators vote on
promising development tracks could allow other developers anticipate which direction
the project is taking so they could streamline their efforts. This is especially useful in the
implementation of standards. Following a thread on the RepRap forum, a group had
decided on a standard. The next step was to inform the community. Quoting one of the
posts, “now it’s time to scream, shout and make noise”. How do you make a community
aware of the “good” ideas? Voting and bidding systems seem to be obvious solutions,
alongside competitions. These elements are used to a wide extent at crowdsourcing sites.
3.4 A platform that sources the crowd
Looking at the collaboration system at OSHW projects today three main tools facilitates
the development (not looking at the inter-collaboration between the core team members).
These three tools are the wikis, forums and design repositories. Between them, these tools
make a rather complex system of information which results in a development process
easily lacking tractability. Although this system might, to some extent, prove sufficient
for the dedicated developers it leaves a high entry barrier for new developers, as for
example in the opensourceecology example earlier. This results in OSHW projects not
fully utilising the possibilities of CBPP. Even for successful projects such as RepRap this
is the case. Looking at the RepRap model “Prusa Mendel” which is focusing on low cost
and ease of sourcing, making it the ideal choice for new developers, only four “pull
request” have been made the last year judging by the activities at github.com and only
three commits a available under the Prusa improvements overview at RepRap.org. It
looks as if the new improvements are not integrated into an “optimal” design. Instead,
new derivatives a created which are hard to find or poorly documented. One reason for
this could be the high cost of integration as the models are not modular. Another reason
could be that many people actually do not share their designs. In this aspect there might
be lessons learned from crowdsourcing. A crowdsourcing site like 99designs.com has
113 designs per project (contest). It is very easy to contribute to projects on such sites and
it is easy to get an overview of the different contributions due to the use of “design
contests”. Such a concept could easily be implemented in a platform to attract more
perimeter participators who just wants to give small contributions, while more complex
collaboration tools should be implemented to suit the need of the more dedicated
participators.
André Hansen & Thomas J. Howard
4 Conclusion
OSHW projects have definitely gained more awareness following projects such as
Arduino and RepRap, but OSHW development does for now not mirror the efficiency in
OSS development. This is partly due to the challengers that come from dealing with
physical products and the fact that there is no collaboration platform specifically design
to support OSHW development. As part of the solution to overcoming these challenges is
giving OSHW products the structural attributes of CBPP, creating rightly grained
modular products which will lower the cost of integration and allow for independent test
and validation of designs.
As many OSHW projects entail some OSS elements, an OSHW collaboration
platform needs to provide the same service as OSS collaboration platforms today, and
more, for the complete project to be run on the same platform. A platform should not
only play in tact with the development process and work flows, but also support the
business models and revenue stream all of which are in need of further research. Two
fundamental functions of an OSHW collaboration platform are found to be: to function as
a social platform and to provide the community with collaboration tools. For this to
happen, better product data management systems need to be made available to the OSHW
communities and workflows defined which will lower the entry barriers for new
developers.
Although many agree that making a true OSHW collaboration platform a reality is of
utmost importance if OSHW is to emulate OSS in success, there is no apparent solution
out there which will truly fill the void any time soon.
References
1 Koch, M. D., Tumer, I. Y., “Towards Open Design: The Emergent Face of Engineering - A Position Paper” , Proceedings of ICED’09, Vol.3, No.11., 2009, pp 97-108.
2 Howard, T.J., Achiche, S., Özkil, A. and McAloone, T.C., “Open design and crowdsourcing: maturity, methodology and business models”, 12th International Design Conference 2012
3 Fjeldsted, A.S. Aðalsteinsdóttir, G. Howard, T.J. McAloone T.C. “Open Source Development of Tangible Products”, NordDesign 2012, Denmark August 22 – 24, 2012
4 Osterwalder, A., & Pigneur, Y., Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. Wiley, 2010.
5 Fitzgerald, B. “The Transformation of Open Source Software” MIS Quarterly Vol. 30 No. 3, pp. 587-598/September 2006
6 Benkler, Y., Nissenbaum, H., “Commons-based Peer Production and Virtue”, The Journal of Political Philosophy: Volume 14, Number 4, 2006, pp. 394–419
7 K. Ulrich and S.D. Eppinger, “product design and development”, 4th ed. McGraw Hill 2007.
8 Balka, K., Raasch, C., Herstatt. C., “Open source enters the world of atoms: A statistical analysis of open design” , First Monday, Vol.14, No.11., 2009, pp 248-256.
9 “Manufacturing as a Service (MaaS)” Postfully yours, oct. 2007
10 Erixon, G. “Modular function deploymet – a method for product modularization”, KTH, Royal institute of technology, Sweden, 1998.
11 Saade R.G. and Otrakji, C.A. “first impression last a lifetime: effects of interface type on disorientation and cognitive load, “ Computers in Human Behavior, vol 23, 2007, pp.525-535
12 B. de Alwis and J. Sillito “Why are software project moving from centralized to decentralized version control systems?” CHASE ’09: Proceedings of the 2009 ICSE Workshop on Cooperative and Human Aspects on Software Engineering pages 36–39, 2009. IEEE