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: mail@andrehansen.me

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: thow@dtu.dk

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