Conceptualization of an Open Source Hardware collaboration platform by André Hansen

Conceptualization of an Open Source Hardware Collaboration Platform Creating a concept for a web-based collaboration platform that supports Community-Based Development of tangible objects

M.Sc. Thesis in Management Engineering Department of Management Engineering Technical University of Denmark

Written by AndrĂŠ Hansen s053952 - mail@andrehansen.me Supervised by Thomas J. Howard Fall 2012

This report is developed and published under Creative Commons Attribution-Non Commercial-Share Alike 3.0. All photos retrieved from Flickr are licensed under Creative Commons while other photos and illustrations are from the authorâ&#x20AC;&#x2122;s private collection and published under Creative Commons Attribution-Non Commercial-Share Alike 3.0 unless otherwise stated. Appendix 1 contains references for all pictures and illustrations not the property of this author.

Printed in Denmark, 2012

Ab st rac t The objective of this project was to study the field of Open Source Hardware (OSHW) and to propose a concept for a OSHW online collaboration platform. Such a platform should support community-based development of complex physical products.

A conceptualization process was completed based on the research. The process resulted in a concept for a web-based collaboration platform, building on PDM functionality, Crowdsourcing and Collaborative Project Management tools, implemented in a Web 2.0 environment.

As of now not many OSHW products develop in communities can say to truly compete with industry products. One reason for this is that the development tools used in many OSHW communities are designed for software development. This results in poor data management, and makes especially co-creation ineﬃcient when doing development of complex products.

The concept takes form as a website oﬀering online hosting of development projects, making the system easily accessible. Both private and public project can be run on the platform, but where public projects can be run for free, private projects would have to pay.

It is therefore believed that there is a need to make a robust collaboration and development platform accessible to the OSHW communities, that is designed for community-based development of physical products. Such a platform could also be utilized by established companies wanting to undertake open design or run small more traditional user-driven product development projects. To investigate the need for such a platform research was done on OSHW communities. Case studies of two larger OSHW communities were completed: The RepRap community and The OpenSourceEcology community. The tools used in these communities also underwent analysis which, along side interviews with OSHW community members, provided insight in how OSHW development is carried out today. As literature on OSHW is scarce, theory on Open Source Software (OSS) was drawn in, and new models was developed to support the research. Knowledge, technics and experience was also drawn in from crowdsourcing, distributed product development, product data management (PDM) systems and theory on product platforms and architectures. The main challenge found in OSHW communities is that the communities do not truly collaborate on partial designs. This supports previous findings (Howard, 2012). Based on the research findings it was concluded that there indeed is a need for a new collaboration platform. It was also concluded that PDM and crowdsourcing solutions, should serve as inspiration for its development. Such a platform should among other things allow: • Communication and control of product structures to lower the cost of integrating designs • Easy location and validation of information in a distributed setting • Communication of project activities to the community to make the development process transparent.

The concept entails the following functionality related to the most important identified needs. • To control product structures the standard PDM approach is used, by allowing the definition of product structure in the database system. The approach is supported by a formalism emphasizing the definition of modules, interfaces and systems, which communicates all aspects of a product structure. This should facilitate the development of modular products and put focus on interchangeability. • Location of information is made easy by allowing documentation stored in the system to be related to both a category and product structure. This approach creates both a flat and a hierarchical data structure in the system, which permit easy overview of existing documentation. Such overview would also support a validation of information. • Project activities are communicated to the community using the same approach as crowdsourcing sites. Based on the project activities, “Challenges” can be posed to the community which are easy to engage in. The process of answering the challenge is guided by well defined steps enhancing transparency. The concept is called DeDoCu - Social PDM. User interface mock-ups of the concept was created and used for evaluating the concept. To support the evaluation process a case study of a NPD project was completed and used to create use scenarios. Design reviews with users and experts were also completed. The concept proved promising. Based on the evaluation and feedback from design reviews the proposed concept is seen to bring value to the field of product development of tangible objects. The concept is seen as a first step toward realizing a online collaboration platform that supports community-based development of physical products, and thereby allow OSHW communities to eﬃciently co-create complex physical products. Keywords: Open Source Development, Open Source Hardware, Co-creation Platforms, community-based development.

Tabl e of C ontent Preface 7 Acknowledgement 8 About the Project 9 Introduction 10

Chapter 1: Background Knowledge

1 2

Theory 14 Research Methodology 26

Chapter 2: Research 30 Research Overview 32 Case Analyses 34 Answering the Research Questions 46

Chapter 3: Exploring the Product Idea

Users 50 Needs 50 Goal Specifications 51 Market & Business 52 Technology 52 Product 53

Quick Overview Chapter 4: Concept Development Introduction to concept development General concepts Function breakdown and solution generation Presentation of solutions Detailing the concept

Chapter 5: Closing Evaluation of the Concept Conclusion Limitations and Future work References

54 56 58 60 62 66

86 88 90 91 92

For readers who want a quick overview, I recommend reading the following pages. These are KEY pages containing overviews and models illustration the results of the projects. Look for the KEY icon. About the Project

Project Objective

Open Source Hardware Defi nition

Overview of Case Analyses

Answering the Research Questions

Overview of Product Idea

Functional Breakdown

Quick Introduction of DeDoCu

Overview of Solutions

Entity Relationship Model

Overview of User Interface Mock-up

Core functionality

Conclusion

“Value y o u r f r e e d o m o r y o u w ill lo s e it, teach e s h i st o r y. ‘ D o n ’t b o th er u s w ith po l i t i c s’ , r e sp o n d th o s e w h o d o n ’t w ant to l e a r n . ” - R i c h a rd M . S ta llma n

M a i n au t h o r o f t h e f r ee so f t w ar e l i cen se

h t t p : / / w w w. j u n a u z a . c o m / 2 0 0 8 / 0 9 / 1 5 - g r e a t - q u o t e s - f r o m - t o rvalds-and.html

PAGE

Pre face My venture into the domain of open source hardware started at “Produktudviklingsdagen” (Product Development Conference at The Technical University of Denmark) in January 2012. Here I overheard the presentation on open design by Thomas J. Howard. Seldom do you feel you have just heard of an idea that might change the world, but this was exactly how I felt after hearing the presentation. Now, almost a year after, I am still as enthusiastic and motivated to further explore open source hardware and I hope that my contribution to the field will be helpful for further research – theoretically as well as in practice. I still believe that open source hardware has the potential to change the world and the way we, as individuals and society, interact with the everyday physical objects surrounding us. I think it could result in the creation of more innovative products for the benefit of everyone. Hopefully I will have the opportunity to help make sure that is does.

PREFACE

PAGE

Ack now le d g e m e n ts First and foremost I would like to thank Thomas J. Howard for his motivating support and supervision of this project. He gave valuable feedback and guidance throughout the duration of the project. I would also like to thank Per Alvin Frandsen from Labitat, Jesper Jepsen Jensen from Visma and Christopher Stub Michelsen from MAN Diesel for giving time for interviews and their inputs to this project. Peter Rosenbeck Mortensen from IPU, and Jonas Torry-smidt and Hans Peter Lomholt Brun from DTU shall also have thanks for their time and valuable discussions. For letting me adopt their report template I would like to thank Gudrun Adalsteinsdottir and Asta S. Fjeldsted. Finally the family Antonsen shall have my thanks for their support doing the last stages of the project.

PAGE

A b ou t th e proj ect This is a mater thesis project titled “Conceptualization of a Open Source Hardware Collaboration Platform”, conducted at The Technical University of Denmark, Department of Mechanical Engineering. The project was carried out by André Hansen from the Department of Management Engineering, under the supervision of Thomas J. Howard, during the fall semester of 2012. The main goal of this project is to bring new knowledge to the field of Open Design and community-based development, by investigating what is needed to allow Open Source Hardware projects to reach their full potential and develop truly competitive product. The needs are exemplified in a final concept of a collaboration platform, meant to inspire and to lay foundation for future development of such systems. The project can in that sense be seen as partly a research project and partly a conceptualization project. The aim with this report is on one side to communicate my results to allow them to be evaluated and be used for a thesis defence. On the other side the intention is also that the report should contribute more generally to the emerging paradigm of open source hardware, why a broad overview of related theory and issues are drawn in. I see the readers of this report as being primarily researchers and people involved in developing platforms supporting community-based innovation.

DeDCu o

(This is a project development page)

JOHN JOHNSON My account

Organisation

Start Organisation

The Strong Hand The Strong Hand

ADMIN

Revesion 3

INVENCON Playground LAYOUT

Invencon

Following

Download

Arthritis Group

COMING ACTIV

Mech - hand

COMMUNITY

IFD

EDIT

Box

Gripper Button

Interfaces Digital Physical

Fingers

MMI

Casing Wrist

Power

Drive Quick release

Actuator

Control

Othoses

EXPLANATION BOX Hold the mouse over the feature you want explained (note: not everything is explained)

DATE CARD Name: Item ID 000000534 Description: Gripper fingers Parts: Top finger Introduction Buttom finger Cam

Inactive projects Two material extrusion Improve mobility Lower weight

Technology

Power

Aktivities

Issues

Worksheets

Requirements

Add App EDIT

Funding

Interfaces

Related Discussions Interfaces I want that I need help Are we doing the right thing? Lets have a meeting Playground

Comment (Link to forum)

ABOUT THE PROJECT

Design Con day

Test of subm

MOST RECENT

Model X spe

Model Y mo

ECR ID 543

Project Plan

Created: 5/3 - 2012 Responsible: George Market Projec Check out by: Jenny research plan Where used: Gripper, the strong hand Functional Breakdown User Survey Market Research

Glove

Model X, m meeting

view: all systems The strong hand - Gripper - Button - Sensor - Casing - Fingers - Top finger - Buttom finger - Wrist - Frame - Cam - Box - Drive - Actuator - Motor

Arthritis Mechanical Hand

APP Vault Forum Product Vault Idea Compete

PAGE

TASKS

Review wik

Change par Send Susan

CALENDER

PAGE

Introduc ti on 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 this authors 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 (Kock & Turner, 2009). Open Source Software (OSS) 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 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 digitalized through the use of CAE. This realization should allow a better utilisation of communication technologies in engineering design and foster hope for a further adoption of the open source methodology in the development of physical products. In many OSHW communities co-creation of complex products results in products of low quality. The OSHW products are seldom more than prototypes - toys for the DIY hobbyist. One reason for this is that the development tools used in many OSHW communities are designed for software development. This results in poor data management when dealing with physical product development and it makes co-creation difficult when undertaking development on partial designs. It is believed that there is a need to make a robust web-based collaboration and development platform, designed for OSHW development, accessible to the OSHW communities. Such a platform will heighten the efficiency of the core team development activities and it will support co-creation of modular products in the communities. Such a platform could also be utilized by established companies wanting to undertake Open Design.

Koch and Tumer (2009) have asked the question, “Why are robust collaboration tools openly available to the programmer, but not to the designer?”. This project aim to take a step towards a future where they no longer needs to ask that question.

The report is structures as follows: • • • • •

Firstly some background knowledge is provided for newcomers to the scenario of open source development for definitions and theories to be presented there aft. Then the research phase is described. The aim was to provide initial answers to the research questions, to create a good foundation for the concept development process. The general product ideas is then explored by drawing in all the aspects of a product idea. The aim was to take a more focused look at the research findings and related these to the concrete object of design - the collaboration platform. Thereafter the concept development is described, presenting solutions and final concept The reports sums up by presenting the conclusions and suggestions for further work.

INTRODUCTION

PAGE

P rojec t O bjective Due to apparent challenges facing open source hardware, the field has yet to mimic the success of open source hardware. There is seen a need to create a collaboration system to handle these challenges, to empower the open source hardware communities in their development eﬀorts, especially in regard to complex product development. This leads to the objective of this research:

To propose a concept for an Open Source Hardware collaboration platform that support community-based development of complex physical products In order to achieve this objective the following research question have been formulated: 1. What are the needs in open source hardware communities in regard to efficient collaboration? 2. Can the functionalities of today’s Product Data Management (PDM) solutions be beneficial to open source hardware development? 3. How do you ensure a more eﬃcient utilization of “the crowd” in open source hardware collaborations? 4. How do you empower open source communities to undertake partial design development? The overall objective and the research questions are based on the overall assumption, that there is indeed a need for a new collaboration platform. The assumption stems from the fact that extremely few open source hardware communities have succeeded in producing truly competitive innovating products. By answering the research questions the assumption will be tested and the research phase will create a foundation for the conceptualization of a open source hardware collaboration platform.

PAGE

C ha p te r 1

Bac kgrou nd know le d g e

INTRODUCTION

The objective of this chapter was to present the theory supporting this project. Due to the fact that Open Source Hardware is a emerging paradigm a broad scope of theory relating to this ﬁeld is presented. Chapter 2 content • • • • •

Key terms Theory introduction Open Design Open Source Hardware Research Methodology

14 16 17 24 28

PAGE

Key temrs This chapter sets out to provide some initial background knowledge about Open Source Design and Open Design Hardware in particular. First some key terms will be defined followed by a theory section describing and discussing the theory this project builds upon.

O pen S ou rc e Open source refers to the philosophy or methodology of releasing designs and documentation allowing others to make, modify, distribute, and use those designs. For many, open source is equivalent with Open Source software (OSS). Although OSS is the leading entity in the open source movement, open source can embrace a wide range of elements. Hansen & Howard (2012) propose an Open Source Design taxonomy emphasizing the activity of designing open source elements of all kinds (see figure 1 on the next page).

O pen S ou rc e D e si g n Open Source Design (OSD) is a design of any kind which has been released to the public in such a way that anyone can make, modify, distribute and use that design.

O pen D e sig n Open Design is the activity of designing open source designs by means of Common-Based Peer Production (CBPP), Co-creation or other collaborative innovation strategies. It means that one can release an Open Source Design without having undertake Open Design.

O pen S ou rc e H a rdwa re Open Source Hardware (OSHW) is a term for tangible artifacts - 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 (http://www.oshwa.org). Open Source Hardware can be the focal point for a open design project.

OTHER OPEN DESIGN DEFINITIONS:

â&#x20AC;&#x153;

The independent researcher Peter Troxler (van Abel et al., 2010) defines open design as a practice that borrows its operating principles from open source software and applies them in the domain of design. He describes it as a peer-oriented form of production, which makes production tools, methods and experience accessible to everybody as a common infrastructure, giving people options for controlling their productivity. - (Fjeldsted & Adalsteinsdottir, 2012)

â&#x20AC;&#x153;

Professor Michel Avital (van Abel et al., 2010), states that open design signifies open-access digital blueprints that can be adapted at will to meet situational requirements, and can subsequently be used by consumers to fabricate products on demand by commercial, off-the-shelf production methods. The open design model diminishes the traditional vertical value chain that is formed by designer-manufacturer-distributor-consumer relationships and offers an alternative, open web of direct links between designers and consumers. The resulting short-spanned, transient and non-hierarchical relationships forge dynamic and flexible arrays of design blueprints that are not only user-centred but also user-driven. - (Fjeldsted & Adalsteinsdottir, 2012)

BACKGROUND KNOWLEDGE

PAGE

O pe n S ourc e H a rdwa re - OSHW The focus area for this project was Open Source hardware, which can be seen as a subset of Open Source Design, se figure 1. 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 author will be using the term Open Source Hardware (OSHW) as convention. This definition seen below is adopted from the Open Source Hardware Association. It is based on the open source software definition and has been developed in collaboration with the OSHW community, why it also seems to be the most widely accepted definition.

Figure 1 - Open Design Taxonomy (Hansen & Howard, 2012)

O pe n S ou rce H ardware D efinition Open Source Hardware (OSHW) is a term for tangible artifacts - 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. (http://www.oshwa.org)

PAGE

Theory i nt roduct ion Open Source Hardware is an emerging paradigm so litterateur directly concerning OSHW is therefore scarce. By drawing on litterateur on the more mature paradigm of Open Source Software and also adding to existing theory, the necessary theoretical foundation has been found for this project. As development of physical products is by no means a new phenomenon literature regarding this field is abundant, so the challenge became narrowing down the search. This was done on the basis of earlier research (Hansen & Howard, 2012) which lead to focus on Distributed Product Development, Product Data Management and Product Modularization. These next sections starts by giving a overview of Open Design and the principles hereof, followed by an introduction to Open Source Hardware. In particular the challenges facing this paradigm. All the while other relevant theory will be drawn in and related to the fields and relevances oﬀ this project. Because one of the aims of this projects is to also contribute with general knowledge to the emerging paradigm of community-based development of OSHW products, a broad overview of theory relating to Open Source Design is presented and discussed. As part of this project, new models relating to the field of open design was developed to support the research. The models are “Degree of Openness” and “Open Source Design Participators”. These models are also presented in the theory section. The models should be applied and tested further, to validate their usefulness. However it is concluded that they proved useful and supportive of this research.

BACKGROUND KNOWLEDGE

PAGE

O pe n S ource D esi gn Open Source Designs today, span from services such as OpenIDEO, a guided development process dedicated to finding solutions for problems benefitting the common good, to tangible physical objects such as the 3D desktop printer, RepRap. Open Source Software is by far, still driving the open source movement in terms of number of projects and impact, but more and more focus has in recent years been put on other elements of Open Source Design. This section will give a general overview of aspects relevant to Open Source Design.

Why O pen D e si g n?

Figure 2 - An open design’s life and activities (Howard et. al. 2012)

OPEN DESIGN BENEFITS Crowd of free developers ‘Experts-users’ Increased customer feedback Rapid and cheap publicity Media coverage through social networks • Increased product varieties • • • • •

One can ask oneself why anyone would release open source designs. You are giving your ideas away for free. What will you get in return? Several incentives for undertaken Open Design can be identified the most valuable of which is the possibility of drawing on the crowd of expert users (Howard et. at., 2012) see figure 2. The user becomes the developer which can result in close loop feedback, something OSS has managed to utilize very successfully. Employing the crowd in the development also presents a diversity which has a significant positive impact on problem-solving eﬀectiveness (Jeppesen & Lakhani 2010). Following Linux Law: “Given enough eyeballs, all bugs are shallow” (Raymond 1999).

C ha r ac te ri sti c s of O pen S ou rc e D esign Fjeldsted & Adalsteinsdottir (2012) have presented a model of the characteristics of Open Source Design (see figure 3). This model provide a good overview of the elements of Open Source Design. TA. S. Fjeldsted and G. Adalsteinsdottir set the platform as the core element in Open Source Design. â&#x20AC;&#x153;The core of the OSD model is the platform. The platform enables, facilitates and empowers interaction and development between participants through a symbiotic relationship.â&#x20AC;? (Fjeldsted & Adalsteinsdottir, 2012)

Creating a viable platform for collaboration is then a vital element for Open Design to be successful as all other aspect relies on it. Based on the OSD model, the aspects, Community, Development and Business, will now be described, while drawing in aspects relating to the Platform and Drive.

Fjeldsted & Adalsteinsdottir (2012) have presented a model of the fundamental aspects of the process of open design

â&#x20AC;&#x153;

In order to create a model that demonstrates the fundamental aspects of open design and how they are connected, we have developed an Open Design Process Model which should clearly visualize the process. The core element is the platform, through which a network of symbiotic connections is created between stakeholders. The other elements that make up the process and represent the most important dimensions of open design are then community, development, business and drive. (Fjeldsted & Adalsteinsdottir, 2012)

Figure 3 - Characteristics of Open Design (Fjeldsted & Adalsteinsdottir, 2012)

BACKGROUND KNOWLEDGE

O pe n D e si g n C om m u n i t i es Understanding the community and the social dynamics behind Open Source is crucial if one wishes to create a collaboration platform that will be adopted by the Open Source communities. However, due to the scope of this thesis less focus will be put on the socio-technical aspects, however important they are. The following section will briefly describe some of these aspects. Much Open Design development takes place as large-scale collaboration between individuals in non-hierarchical communities. Such collaborations can be seen as a new mode of economic production, common-based peer production (CBPP). Common-based peer production 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 (Benkler & Nissenbaum, 2006). Although OSS has managed to embrace CBPP and thereby utilize the crowd, other elements, such as Open Source Hardware, are lacking in this aspect. One could say that OSHW projects are not fully harvesting the benefits of being Open Source. 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. For OSHW this core foundation seem to be extremely important for at projects success. Fjeldsted & Adalsteinsdottir (2012) writes that a common question in relation to open source activities relates to Glass’s considerations on “who are these crazy people who want to write, read and even revise all that code without being paid anything for it at all”. They continue by explaining about Bonaccorsi & Rossi (2003) three types of participants. First of all, there is a large group of individuals who will never contribute to the development but may be capable of using the platform, but only if it is decidedly user-friendly. Secondly, those who contribute in their spare time and consider the development as a hobby. Their contribution is inevitably limited and clearly insufficient to explain the enormous results achieved by the open source movement. To do so, it is necessary to refer to the third group, formed by the members of the ‘hacker culture’ – the real heavy contributors who drive and manage the process.

Characteristics of Common-based Peer Production • Decentralization of authority: The authority to act resides with the individual and not a hierarchical based organizer. • Motivation and coordination: The use of social cues and motivations to motivate and coordinate the actions of participating agents, rather than prices or commands

Why Do People Participate? • • • • • • •

Feedback Prestige Satisfaction of solving challenges Acknowledgement Pleasure of learning Pleasure of creativity Answering niche needs

PAGE

Ty pe s of ope n de si g n Pa rt i c i pators

“ The Guru”

This projects is based on the assumption that one of the reasons why OSHW are not yet as successful as OSS it that OSHW communities do not have the right tools. But another issue might also be that the field of hardware development is lacking members of the “hacker culture”. How to support the built up of such a culture could be an area for further research. The growing Hacker Space movement is an important piece in regard to supporting a “hacker culture” for OSHW. The symbiotic eﬀects of having physical arenas to support online collaboration is seen extremely important, but is not dealt with in detail in this project.

“ The D isci pl e ”

“ The O racl e ”

“ The E lves”

Understanding the users of a future OSHW collaboration platform is however dealt with, so based on the work by Bonaccorsi & Rossi on understanding the participators of Open Design is here continued. The following is this author’s own analysis on the matter of Open Design participators. Focus is on OSHW and OSS. The three mentioned groups presented by Bonaccorsi & Rossi can be broken down into more specific roles or “types of Open Design participators”. Relating to the mentioned third group “hackers” you have “The Guru”, “The Disciple” and “The Oracle”. “The Guru” is a highly dedicated developer often the founder or leader of a specific project. They have in-depth knowledge of the project and are often specialist in a specific field. “The Disciple” is also a highly dedicated developer. “The Disciple” can come to take a leading role in the project. With their contributions as merit they gain greater authority over collective work even though they do not gain authority over other individuals (Dahlander & O’Mahony). Although “The Disciple” might not have the same skill as “the Guru” or participate to the same degree, they play a vital supporting role. “The Oracle” is in many ways similar to “The Guru”, but where “The Guru” might focus on the development of a single project “The Oracle” has overview and knowledge of relating projects as well, which he shares with the community on for example forums and chats. He therefore becomes a valuable linking entity. Part of Bonaccorsi & Rossi’s second group of hobby developers you have “The Elves”. This group contributes by keeping the documentation on for example the wiki’s up to date and correct small bugs. They can be related to as “Wiki Elves” in some communities, for example RepRap. The role might look to be of minor importance but this is not the case as many dedicated developers do not have the resources or desire to fully document their work.

PAGE

“ The Foll owers”

Finally there is “The Followers”. These are the people who uses the product but almost never contribute to the development. These roles are stereotypical and a participator can take on each role to various degrees depending on project and time. These “types of Open Design participators” are defined on the basis of case analysis made of the RepRap community and interviews with dedicated reprap developers (see appendix 3) Studies have shown that it is common in open source software projects that enjoyment based intrinsic motivation is the strongest and most pervasive driver (Lakhani & Wolf, 2003). However extrinsic motivation must not be forgotten, especially regarding OSHW which do not oﬀer the same user rewards as OSS. Bits are not as cheap as bytes. It is not uncommon that participators contribute on monetary incentives, either on the prospect of future profit or simply because they are paid to carry out a specific task.

Fjeldsted & Adalsteins (2012) comments on management of open source projects.

“

Bonaccorsi & Rossi (2003) explain two factors that shape the lifecycle of successful open source projects: a widely accepted leadership setting the project guidelines and driving the decision process, and an eﬀective co-ordination mechanism among the developers of shared communication protocols. It seems important to understand that core development group of a project (initiators/founders) do not carry out the bulk of the co-ordination eﬀort. In general, no one is forced to perform a particular task but agents choose freely to focus on the problems that they think to best fit their own interest and capabilities. This requires a clear modularization and sets of standards which is a part of the co-ordination mechanism shared by open source developers in order to produce a well-structured flow of contributions (Bonaccorsi & Rossi, 2003).

How to m a nag e t he ope n s ou rc e proj e c ts ? Looking at the two factors that characterize successful OSS project put forward by Bonaccorsi & Rossi (2003) Widely accepted leadership and effective coordination mechanism, they match well with theory on achieving successful distributed product development. Raja Bajani (2009) defines a set of critical success factors for distributed product development. He states that “setting a base camp” which defines the base architecture and design guidelines, can insure eﬃcient resolution and clarity of issues and conflicts. Such a base camp must inevitably have to be defined by a widely accepted leadership to be have value in Open Source projects. R. Bajani also argues the need to “cut communication loops” and create timely selection of technical alternatives. In traditional product development this can help keep the project within budget where in Open Source it ensure project progression and motivation of participant who grows tired of limitless forum discussions. This follows Bonaccorsi and Rossi argument for an eﬀective coordination mechanism among the developers of shared communication protocols. So on the question of how to manage open source projects, much can be learned from how distributed product development in firms are managed. You can say that a goal of this project is to develop a platform that creates an effective coordination mechanism. Many of the aspects discussed later in this reports is related to the question, how do you manage open source projects?

BACKGROUND KNOWLEDGE

PAGE

O pen S ourc e D esi g n dev el op m en t In many ways Open Design of Open Source products can be seen as distributed product development. Distributed product development has been taking place in global companies for decades, but where most of these projects have had commercial interests and facilitated by a central entity, Open Design projects often focus on “the benefit of the community” and is developed through the before mentioned non-hierarchical communities. Some communities revolve around a strong core team who helps set the goal of the development while other communities are more autonomous. The initial focal point of successful Open Design projects are often presented as a complete design from which the community can start development. Relating this to

distributed development, where creating a well defined staring point is also one of the success factors (Bavani 2009). In successful distributed development, collaborations can benefit from multi perspective on ideas due to the participants diversity in background and culture as well as shorter cycle times due to the flexibility and mobility of the workforce (Larsson et. el., 2003). The heterogeneity, that in one aspect holds the possible benefits, also creates complexity, same as in OSHW. Characteristics of the processes present some of the challenges in distributed development (Kim et. al., 2009): • • • •

Participants are often geographical distributed The computing environment they use are mostly heterogeneous Individual tasks are carried out independently Collaboration of the participants is critical to the success of the product development

These characteristic are especially shared by OSHW projects and contributes to the challenges in this field. A clear example of the challenges can be seen in the diversity of the data formats used in manu OSHW communities. How do you manage this diverse set of data to allow an eﬃcient collaboration, where resources are used on actually working on value adding activities, in contrary to searching for information? Modern product data management systems are in many aspects providing an answer to this question (Brown 2011), but implementation of such software might only provide half the answer. The other half lies in the minds and competencies of the developers.

A proposed definition on Distributed Product Development Distributed product development constitutes a product development project where distributed allocated individual or groups, collaborate under the sense of a shared vision and direction. Such collaboration is often supported by web-based collaboration software

BACKGROUND KNOWLEDGE

O pe n S ourc e D esi g n Bu si n ess Fjeldsted & Adalsteinsdottir (2012) also presents an archetypical business model of Open Source design, see figure 4. They argue that despite a wide range of diďŹ&#x20AC;erent Open Source Designs, the building blocks of the business models surrounding these products and services are somewhat similar. One exception is the revenue streams which are highly diverse. To gain an overview of possible revenue streams Fjeldsted & Adalsteinsdottir (2012) have defined the Wheel of 12 revenue streams, see figure 5. Together these models can be used to define an Open Source Design business model. But an important question to answer is, how open do you wish to be?

Figure 4- Archetypical Open Source Design business model (Fjeldsted & Adalsteinsdottir, 2012)

Figure 5 - Wheel of 12 Revenue Streams (Fjeldsted & Adalsteinsdottir, 2012)

PAGE

O pen S ource H a rdwa re C hallenges fac i ng O pe n S ou rc e H a rdwa re Although Open Source Hardware shares many characteristics with Open Source Software, the crucial diﬀerence is that you in OSHW operate around a tangible artefact. This fact sets very diﬀerent demands for the system in which it is developed, and how the business models are set up. The following section will go through the challenges of open source hardware and touch upon OSHW specific business models.

Re vi

sit e

O pen S ource H a rdwa re Open Source Hardware (OSHW) is a term for tangible artifacts - 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. (www.OSHWA.org)

Three main challenges facing OSHW are presented by T. Howard (Howard et al., 2012) The challenges 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. Allocation of physical resources is need for such a product to be manufactured. 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 side this can result in some OSHW products never reaching a final form. On the other hand, the manufacturing cost can result in a more sustainable business model for the project originators. This is because consumers will choose to purchase the final product instead of producing it themselves (Howard et. al., 2012). 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 to allow close loop iterations. Considering the complexity of common products today, this could be a major obstacle for the realization 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. Having partially open systems, which allows some parties to capitalise on closed source test documentation, as proposed by the 40 fires foundation, could be part of the answer to overcoming the challenge of validating designs. The concept of “Manufacturing as a Services” (MaaS), or community based manufacturing shops, which allow individuals to make use of flexible manufacturing equipment, could be another another. This might in time create a base for easier design validation as it allows communities to bypass large operations and manufacturing facilities (Koch & Tumer 2009). Not to forget hacker spaces.

BACKGROUND KNOWLEDGE

PAGE

O pen S ou rc e H a rdwa re Bu si ne s s Mode ls Finally, there lies a challenge in allowing OSHW communities to efficiently collaborate on high-tech complex products. This is closely related to the validation of designs as complex products will entail more sub functions in need of validation. Benkler & Nissenbaum (2006) present three structural attributes of the CBPP relations, which are highly relevant with regards to overcoming the challenge of complexity in OSHW projects. The attributes are: modularity, granularity and low-cost integration. • Modularity: Modular design will allow subsystem to be tested and validated independently and support asynchronous development. This aspect therefore also regards the validation of design. Focusing on modularization will however also result in higher requirements for the discipline in the development process as modularity will lay additional constraints on the object of design in the form of structural standards. • Granularity: To allow contributions from participators of various skill and motivation the size if the modules are important also in relations to the breakdown of tasks. Defining suitably grained modules can be difficult but much research and practical experience is present to support this task. • Low Cost of Integration: Refers to the cost of integrating sub elements into a whole end product. Due to the wide range of different CAD software used by developers integrating designs can be a tedious and manual task in many OSHW projects. This makes sharing of work less accessible. Although neutral formats do exist, much information is lost in the conversion. Software development benefits from having software that aids mergers of files. CAD files cannot be merged in the same way. Lowering the cost of integration is one of the keys to empowering OSHW. Encouraging OSHW communities to focus more in defining interfaces could lower the cost of integration (Hansen & Howard).

Some OSHW projects are making money on a Open Design Business model. As mentioned, dealing with tangible objects usually requires a diﬀerent business model than when dealing with OSS. Development and fabrication of OSHW products require more investment, so there need to be more focus on the revenue streams. Many OSS projects can support themselves alone by donations, and for some non-profit OSHW projects, this can also be a viable solution. As mentioned does the challenge of complexity also present and opportunity because consumers will choose to purchase the final product instead of producing it themselves (Howard et al., 2012). Arduino have made a successful business on such direct sales, while they also license their brand name. Same approach is used by Makerbot. In the future more OSHW business might make use of the Freemium model used by many software companies. A company could have a simple or experimental prototype product which they sell to the community as kits open source. The community will then contribute by generating and validating ideas the company can implement in their “real” high performance industrial products. These products they sell, closed source, to the rest of the world, that does not really care wether product designs are open or closed. For companies that have a hard time breaking into a marked because of strong competition, going open source might prove advantageous. Which business model to base a open source hardware company on, depends on the characteristics of the product - as with normal companies. However, it is still not fully understood which products create a good foundation for a OSHW business. This is a subject for further research. Without going into detail 3 types of products, that have proven to support a OSHW business, are presented here: 1: General Purpose Electronic Boards. Such products are cheap, easy to hack, and its multitude of uses support community growth. (arduino, adafruit, Rasperri Pi) 2: Minor Mechatronic-kits: These products can be assembled in you own home within reasonable eﬀorts. For now these products often resembles prototypes. (3D-printers, Window farms) 3: Product for Society: Complex products with a feel of “for the good of society” about them. This allow them to attract donations and funding. They are not really DIY and have a relatively small community supporting them. They illustrate the possible synergy between social business and Open Design business (Riversimple, OSE) In fact, many OSHW product share this “for the good of society”. That could be as a learning tool, for environmental protection or helping people in need.

While many projects can be said to undertake Open Design, the degree of openness under which they operate can vary considerably. To understand this variation, and to support the research in the this project, a model called “Degree of Openness” have been defined, see figure 6. It is especially minded on OSHW. The model builds on the three aspects of openness defined by Balka & Raasch (2010): Transparency, Accesibility and Replicability.

Degree of Openness

Figure 6 - Degree of opennes model

One dimension is the openness of the product. By what ease can the product be replicated: • Is the product transparent? Meaning what is the quality of the design documentation, and are there sufﬁcient amounts of documentation made available for an easy replication of the product? You can say you know how to replicate the product. • Is a replication of the product accessible? Meaning how easy is it to access the design documentation, and by what easy can the product components be acquired? You can say you actually can replicate the product. A second dimension is the openness of the process. By what ease can a developer participate: • Is the process transparent? Meaning how easy is it to understand the development process, and is it easy to track design decisions? You know how to participate. • Is the process accessible? Meaning by what degree is the development process centralized, and how much value is put on outsider contributions? You actually can participate in the process. PAGE

- The Product Openness related to the ease of use/application of the design work. - The Process Openness relates to the ease of participation in the development of the design. An important realization is that, you can have a high degree of product openness without having a open process, but not the other way around - there is an openness mismatch. A high degree of process openness demands a somewhat open product, for example you need to reveal some element of the product for people to contribute on developing it. Analyzing the degree of openness can be useful in two aspects. The first regards the business model directly. For example, if your key activity is to attract participators you want to make sure you have ease of participation. Further, where do you see your revenue streams? Some companies undertaking Open Design focusing on direct sales so they lower the ease of replication, making the product diﬃcult to produce for the individual. This leads to the second aspect. To prevent the branding value of Open Source Design to be diluted, there is a need to be able to define Open Source Designs in respect to its degree of openness. Answering, “How open is it really?” This will prevent companies to do Open Design in nothing but name. The problem of exploitation the Open Source brand can be seen in the RepRap community, and there is even discussion on how open one of the flagships of open source 3D printers, Makerbot, really is (Makezine.com). Using the model “degrees of openness” four types of projects have been defined, see figure 7. The “Closed Projects” are traditional development projects run in most companies today. Although their products might be easy enough to replicate if the documentation was available, the fact that it is not, leaves the product closed. The product are run inside the walls of the company, and people outside are not invited to join, so the process is closed as well. “Crowdsourcing Projects” invites people to join on in solving specific tasks. Again it is often in a company setting, and the company claims the ownership of the outcome. Both process and product has to be opened up, but only a bit, to allow the crowd to contribute. Contributions are often superficial and relates to the general product idea. Projects run by Quirky.com is a good example of such project. “Open Product” projects are in most cases companies selling open source products. The products are open in the way that product documentation is accessible online, but the actual development is taking place backstage while the company sources the community for ideas. Makerbot is an example of such a project (makerbot.com) Last we have an “Open Design” project. An open design project makes the product documentation available online and invites the crowd to participate in the ongoing development by allowing them to change documentation and join in on discussions. Many project in the RepRap community is examples here of.

Figure 7 - Analyzing project openness using the Degree of Openness model

Another aspect of OSHW business can be protecting the IP rights. Although everything is open, and the whole point is that people adopt and share your ideas, you might still want some protection from unintentional exploitation of your ideas. OSS has been able to protect its products via copyright and networks of resource rich institutions, that help protect open source IP rights. For OHSW the situation gets more complicated as the copyright do not cover the physical product itself, but only to some degree the product documentation. The idea/expression divide only enables copyright to protect the expression of an idea and not the idea itself (Samuels 1989). When licenses cannot protect the IP rights, branding and smart business models might be the answer. Fitzgerald (2006) argues that a strong brand will be the next IP mechanism. Always being in front is also an approach, exemplified by the Linux mantra â&#x20AC;&#x153;Release early, release oftenâ&#x20AC;? (Raymond 1997) because the design is then no longer patentable. The common licenses used in OSHW at the moment is the creative commons and GPL.

BACKGROUND KNOWLEDGE

PAGE

R e searc h Met h od ol o g y Now a genereal introduction to the field of Open Source Design has been given. Focus will now be turned more to the activities and results of this project. This section will describe the overall approach used in this project, and explain which activities was undertaken. This section ends the Background Knowledge Chapter. The project can be viewed as one part research project and one part concept development project. At the beginning of the project, not much was known from about the object of design or the arena in which is should operate. Much energy was therefore set to gain a deeper understanding before diving into the actual concept development. The project progressed through 2 stages; research ans concept development. The concept development framework of Ulrich & Eppingder (2008) presented in “Product Design and Development”, was chosen to guide the process. It was however mainly used in the concept generation phase. The chronological structure of this report do not reflect the iterative process of the project.

R esearch phase The objective of the research phase was to develop a deeper understanding of Open Source Hardware and the need of the communities regarding collaboration, thus providing initial answers to the research questions. This would create a foundation for the following conceptualization phase. As literature on open source hardware is scarce a qualitative approach was applied. Three main activities was undertaken as part of the research phase: Literature studies, case analyses and Interviews. The following will describe some of these activities in relation to the research questions. To gain a deeper understanding of “the needs in Open Source Hardware communities in regard to eﬃcient collaboration” exploration of several OSHW communities were undertaken, going through wiki’s and blogs. There was a focus on the development aspects of the communities so time was spent looking at the collaboration tools and development processes. Two cases were chosen for further analysis: RepRap and OpenSourceEcology. The two cases represent two extremes in regard to centralization of authority, and both projects have gained considerable awareness. The case analysis was supported by interviews with dedicated OSHW developer, Per Alvin Frederiksen a many year member and contributor to the RepRap community, and by talks with members of Labitat, a hackerspace in Copenhagen. Based on previous research (Hansen & Howard, 2012) a challenge regarding utilization of the crowd was identified for OSHW communities. The entry barrier is too high for new developers and the process not transparent enough to allow co-creation, resulting in the development being carried out by a few initiated individuals. To investigate this problem, focus was turned to crowdsourcing sites and their solutions. Special focus was put on Quirky.com and their development process. The case analysis of the OSHW communities and development tool were also used. To answer whether the “functionalities of today’s Product Data Management (PDM) solutions could be beneficial to Open Source Hardware development?” OSHW development was looked upon as distributed products development. Drawing on literature studying the relation between distributed product development and

PAGE

C oncep t P hase PDM, aspects of PDM systems was looked upon. Interviews were done with industry expert Lars Jepsen Jensen, consultant at Visma, and PLM developer Christoﬀer Stub Michelsen from MAN Dielsel. Development on partial designs is nothing new in traditional product development. Therefore literature studies were started using keywords such as modularization, interface management and partial design development. Interview with PLM developer Chistoﬀer Stub Michelsen, and talks with Hans Peter Lomholt Brunn PhD at the Technical University of Denmark, also proved very valuable. The tools, Github.com and Thingiverse.com was analyzed with the intent of determine to what extent they supported partial design development. Both tools are already being used by OSHW communities. The Interface Diagram formalism (IFD) was given special interest.

As mentioned was the concept development framework of Ulrich & Eppingder chosen to guide the development. The framework states that the concept development could be initiated based on a mission statement, the output of the planning phase. The mission statement as described by Ulrich & Eppingder (2008) put much focus on the business aspects of a product. But since so little was known about the object of design this approach was not very beneficial for creating support for the concept development. Instead was the Product Idea Model of Hansen & Andreasen (2005) used to explore the diﬀerent aspects of the product idea. The Product Idea Model also consider the market and business opportunities but more aspects of the products actual functionality is also explored. The Product Idea Model can be seen as the linking element between the research phase and the concept development, summing up the lessons learned from the research and creating a better understanding of the product which should be developed. Product concepts were generated, using the five step method by Ulrich & Eppingder (2008) and a concept went through further detailing for then to be evaluated. No real test of the concepts was made as the scope of the project did not allow the creation of a true functional mock-up. Instead a user interface mock-up was created to allow the concepts functionalities to be evaluated through use scenarios. To support the detailing and evaluation process a case study of the development project “The Strong Hand” was made. This provided real life scenarios of a company based development project. From these, themes was derived to guide the scenario creation. Doing the case study the concept was also put under the eyes of experienced product developers from the Institute of Product Development (IPU), were especially workshops and talks with developer Peter Rosenbeck Mortensen and Hans Peter Bruun gave much insight. The final step was to evaluate the concept, which was done based on the goal specifications and design reviews with users and experts. This was the final remarks in the Background Knowledge chapter. Now the findings from research phase will be described.

RESEARCH METHODOLOGY

PAGE

C ha p te r 2

R esea rch P hase

RESEARCH METHODOLOGY

The objective of the research phase was to develop a deeper understanding of Open Source Hardware communities and the online collaboration tools used. Furthermore it should provide initial answers to the research questions, creating a foundation for the following conceptualization phase. Chapter 2 content • Overview of case analyses • Case analyses • Answering the research questions

32 34 46

PAGE

O verview of case analyses The research phase consisted of 3 overall analyses: • OSHW communities • Platforms that support OSHW and crowdsourcing • Product Data Management The following section will recapitulate these analyses, but detailed discussions are also found in this chapter for reader wanting more information. The final section in this chapter present initial answers to the research questions, see page 46.

O SH W C omm un i t y c ases The RepRap and OpenSourceEcology communities where chosen for further analysis as they each represent an extreme in term of centralisation of authority and approach to development. • Development: RepRap has a relatively anonymous core team and the overall approach to development is based on evolutionary thinking. OSE is more hierarchical guided by a visible leadership and more traditional engineering processes. A shared value seem to be “for the good of the community”. Few dedicated individuals drives the development in both communities. • Information: Both communities aim to be completely open, but low process transparency hinders them in achieving this. Information is diﬃcult to find and its is hard to figure out where the projects are heading. OSE seem only to have one main design. RepRap have many, but it is hard to find the “good” designs as designs are not validated in a structure way. • Modularity: OSE have high focus on developing modular products but it is poorly communicated. Examples of interchangeable modules can be found in the RepRap community, without them being formally described. There is a clear progress towards creating more modular product in the RepRap community. Both communities are however missing a way to clearly document and communicate modularity and interfaces and provide easy information search. The main conclusion of the case analysis is that the development of the designs are pushed forward by a few individuals without collaborating much with the community as a whole. The main reasons for this is low process transparency, high cost of integrating designs, insuﬃcient data management and in some cases, monetary incentives.

P l atfor ms that su pp ort O SH W a nd C row d s ou rc i ng Thingiverse and Github are a web-based tools used by the RepRap communities to store and display documentation (mostly CAD files). Thingiverse offers little in terms of functionality, version control or basic social media features, but it provides a very easy way to share you designs with the world. Github is based on the distributed version control software Git. Because OSHW communities still experience a high cost of integration, using a distributed VSC system might result in non value adding forking. Github is a very sophisticated platform which offers a wide set of tools while still being relatively easy to use. But, is intended to be used for software development. Github is mainly a configuration management tools which means its version control is fundamentally different from how PDM systems’ do version control . Neither Thingiverse nor Github truly supports large scale co-creation of complex hardware products. Quirky is a industrial design company who have created a crowdsourcing platform that involves its users in almost every step of the design process. Although the products being developed are relatively simple, it shows a good example on how to open up the process transparency though clearly defined stages and activities. Users are employed to validate design and it is easy to get overview of good ideas. The contributors are rewarded based on their influence on specific projects.

P roduct Data M a nag e m e nt Very sophisticated PDM solutions exist today. They are however, expensive and diﬃcult to implement leaving them out of reach for most OSHW projects and small companies. In many ways PDM provides functionalities needed in complex product development but it will be a challenge to adapt an existing solution to a community context. A new solution therefore needs to be developed. Such a solution should still provide some of the same functionality: Document Management, Automated Processes, Product Structure Management and Program Management, but which also supports community-based development. It need to handle data both in a centralized system while adapting to the distributed nature of OSHW and still be easy to use. Basing the underlying data structure on the interface diagram modeling formalism could be a way to encourage and support the communities in developing modular products.

RESEARCH METHODOLOGY

PDM

PAGE

The R e p R a p C om m u n i t y The RepRap project is focusing on developing open source general-purpose self-replicating manufacturing machines. RepRap is short for replicating rapid prototype. For now the RepRap community is almost entirely focusing on the development of 3D-printers. These 3D printers are capable of printing 3D plastic objects of arbitrary shape, why the printer, to some extent, can produce a physical copy of itself. Some of the cheapest RepRap models can be constructed for under 500 US$ making it accessible for individuals users across the world. RepRap is the most used open source 3D-printer (Manufacturing in motion), see ﬁgure 8. Partly due to the projects early beginnings and branding. It stands as one of the open source 3D printers with the highest degree of openness and has one of the largest communities dedicated to its development. All ofﬁcial RepRap models are made public under the GPL open source license. Although advances have been made, RepRap printers do not propose a serious threat to commercial industry printers due to the RepRap’s relative poor print quality. They are still to be considered “toys” for tech-geeks and hobbyist. Backg round

“

RepRap community members are spending between 145 and 182 full-time equivalents and have spent between 382,000 and 478,000 dollars on innovation alone (by 2010). At the RepRap project’s 6 month doubling interval, it is entirely feasible that its adoption and disruptive levels of innovation will exceed that of the incumbent industry” - (Bruijn, 2010)

“ “

If you’ve got a reprap you can print another reprap for a friend - (reprap.com) One of the first end-user parts made by a RepRap was a clamp to securely hold an iPod to the dashboard of a ford fiesta - (wikipedia.com)

success by supplying easy to assemble printer kits. However, the projects have a much lower degree of openness than the original reprap project in regard to ease of replication and ease of participation. For example is the complete set of documentation for the MakerBot not available in any one location but scattered around the web and one need access to laser cutting tools or similar to fabricate the needed parts. Many of the more focused development tracks on reprap.org have in fact commercial interests (Appendix 2a). C om m u n i t y

RepRap was founded in 2005 by Adrian Bower, a lecture in mechanical engineering at the University of Bath in the United Kingdom. The result of the project was shared online attracting interest by a diversity of distributed allocated people across the world. This is a example of how a open source product was developed by a single individual or small group and the released online. As the project made progress a core team was founded which set up the collaboration infrastructure and guided the process early on. The core team has become less and less visible in recent years. The nature of the project was based on a kind of Darwinistic model where the optimum solutions should emerge from the ongoing collaboration. From under 10 participants in 2005 the projects has grown to almost 400 participants by 2010 (Bruijn 2010), with a doubling rate of 6 month this number is sure to have risen. By now there are six oﬃcial reprap models with a large amount of derivatives. Several spin-oﬀ projects, such as MakerBot and PrintrBot have emerged from the original RepRap project. These projects have more commercial incentives and have gained a lot of

The majority of the developers actually have a background in OSS (Bruijn 2010). The reason why might be that many software developers are familiar with the workings of Open Source project. However, the development is still focused mainly around the mechanical elements of the machine. The diversity of the community is huge, in regard to incentives for participation, level of participation, processes and ideas on where the project is headed. It can be somewhat wrong to look at the RepRap as a single project. It is more a large variety of projects all focusing on developing some kind of 3D printers. Some parts of the community are following standards develop in most cases through consensus but the community is clearly divided on the need for standards. The majority of the dedicated developers (gurus and disciples) are using OpenSCAD an open source script based CAD program. The fact that many of the developers has a background in software development and the use of stl. files in the community is most likely the reason why openSCAD has become the most used CAD software. There is ongoing discussion on the role of the core team. Many wants them to be more active in setting the direction of the project, but the core team itself is dedicated to the evolutionary approach which they mean will result in innovation. Most new models are created by individual and released to the community on its completion, without having collaborated much with

RESEARCH METHODOLOGY

the community. One reason is that some developers still want to protect their ideas, another is that it is simply difficult to follow a project and make valuable contributions without dedicating many hours to the project. Information is scattered around wiki’s forums, chats and blogs, so finding it is hard and then you are still not sure the information is correct. Github.com seems to be the choice of design repository for the most serious project, but thingiverse is also widely used to show of new releases and developments. The elements of the different models released are seldom integrated although somewhat interchangeable modules are used within the same models. The interfaces of the different modules are however not defined why sharing of modules can demand many re-configurations. One exception is the vertical x axis standard which was defined because of frustration among developers on the exact dimensions of the x axis on mendel style machines (RepRap.org). Some elements of the wiki tries to encourage more collaboration, but not many uses them (RepRap Forum). The question is if the developers actually do not want to collaborate and share designs or the features are simply not good enough to allow it. Judging by the forum activity the later seems to be the case. A final thing is the many cases of what seems to be poor project management. In many cases project management seem to be given little attention. Why this is, is not fully understood. Is it because they project owners don’t want to or are not capable? Or is it the systems that does not allow it or communicate it? Perhaps a mixture of everything.

PAGE

R epR a p O vervi ew Community • Informal processes • In homogeneous • Relatively large Successes • • • • •

Examples of standardization through consensus Examples of business spin-oﬀs High degree of Openness Large community (in relation to other open source hardware projects) Overcome the challenge of manufacturing (self replication, product simplicity)

Challenges • Ineﬃcient collaboration due to poor data management. The wiki and forums make it hard to find information • No common direction (can be seen as a success as well as a challenge) • Overview of direction of the diﬀerent projects • Going from individual to community development • Encourage collaboration on designs before release

Figure 8 - The most used Desktop 3D Printers. Manufacturing in motion: ﬁrst survey on 3D printing community http://surveys.peerproduction.net/2012/05/manufacturing-

O pen S ou rc e E c ol o g y The OpenSourceEcology (OSE) is a very ambitious open source project which have gained awareness around the world. “OSE is a movement to create the open source economy. The movement consists of hundreds of entrepreneurs, producers, engineers, makers, and supporters around the world – who believe in the power of open – who share the open ethic. The OpenSourceEcology projects main purpose is the development of the Global Village Construction Set (GVCS). “GVCS is a modular, DIY, low-cost, high-performance platform that allows for the easy fabrication of the 50 different industrial machines that it takes to build a small sustainable civilization with modern comforts.” - (www.opensourceecology.org)

BACKGROUND The OSE group was created by Marcin Jakubowski in 2003. The ﬁrst year was used to set up the base camp for the OSE but after the TED talk by Marcin in 2011 the project has gained global awareness. So far there has been only one full release of a design, the CEB press, but the community is working on no less than 50 other machines. The project revolves around the Factor E Farm located in USA. Most of the core team work from this site making it the centre of the development. Smaller physical communities exist in Europe. More than 5,5 million views of the OSE wiki, containing more than 4000 content pages. Over 1800 registered users, where 120 is active (opensourceecology. org).

PAGE

C om mu n it y As mentioned is the development of the GVCS centred at the Factor E Farm. The process are very well documented on the wiki, but it is still hard for new developers to gain a overview of the progression of the project.

“

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

On aspect of the process openness is therefore lacking, lowering the overall Process Openness, something which has also made this case analysis difficult. The project does not seem to have a structured approach to release design documentation, meaning they are hard to find. OSE have tried to make use of OpenPario as a design repository, but the tool is not used in the actual development to judge by the activity (Openpario.net). There is a focus on modularization but no specific infrastructure is set up to handle this modularization and communicate it to the community. Wiki and forums is the main communication channel to the project “followers”. It is hard to determine how many “followers” actually take part in the development. Collaboration seems to take part mainly among the core team members. There is a clear hierarchy in the community by designating project leaders. The community seems to accept the leadership and there seem to be a common sense of direction. Overall the project and community is homogeneous and centralised, probably due the small size of the community. There is a focus on developing physical communities to support the development. Many of the products demand larger machinery for them to be produced. Through successful marketing, resulting in donations, and the factor E farm, OSE has overcome the challenge of manufacturing on a small scale. The main lesson learned from OSE is that some communities can thrive under a more well defined hierarchy. I might result in a smaller but more dedicated community. A project such as OSE talks to other people than “the hacker” in the hacker culture. It also show that even though a project has a more defined hierarchy does not mean that the projects is more accessible for new developers.

O pen S ou rc e E c ol o g y O ve rvi ew C om mu n ity • Defined hierarchy • Small • Homogeneous Su c c e s s e s • Overcome the challenge of manufacturing through network and DIY approach • Common sense of direction. shared goal • Product modularization (although poorly communicated) C h a l l eng e s • Utilisation of the crowd • Making the process transparent • Community growth

RESEARCH METHODOLOGY

PAGE

O SHW C om m u n i t i e s - g e n e r a l ized fin din gs Now the case analyses of the RepRap and OSE communities have been presented. Here some general ﬁndings regarding OSHW collaboration is be described, before moving on to the analyses of OSHW and crowdsourcing platforms.

The groupware used in OSHW are almost identical to the groupware of OSS even though OSHW development have other requirements. The most widely used groupware in OSHW communities is listed here:

There are very large differences in the work systems between the different OSHW communities, and the projects within the communities. The participators have a wide range of incentives for contributing, and it is hard to identify a common set of values. However, for the good of the community (society) is a value found in both communities, only put aside when contradicting with commercial interest, as it seems to be the case with some projects from the RepRap community (RepRap Forum, Appendix 2a).

Wiki: Wiki’s are powerful collaboration tools as they provide easy access to information for the entire community. Through collective work and peer review high quality documentation can be created. However OSHW communities have problem updating and structuring the documentation. Forum: Forums are online discussions sites that through its often hierarchical structure can provide god overview of ongoing discussions. Forums are very useful to handle queries. A pitfall using forums can be bad communication loops as often the discussions have no time frame (Bavani 2010) Chat: Chat provides real-time online communication between individual and groups. It is widely used, especially in the 3D printer communities. Often no record is kept of the transmission why the important information can be lost if it is not documented elsewhere. E-mail: Subject related mailing-list are very common and can be a good way to keep people updated. The downside can be that people use excessively amount of time re-contextualising fragmented information. Design repositories: Provides storage and control of documents. OSHW communities use repositories designed for software development. Although these repositories in many ways are powerful tools, they are missing some key features, such as eﬃciently being able to handle multi-level data models and visual diﬀerencing. Another aspect of these repositories is that the demand the user to have some knowledge of coding. Something which might keep potential contributors away. Blog: Many developers document and communicate their progress on blogs. The blogs give a good general overview of the development and is one of the easiest ways to get an idea of where many of the smaller projects are heading. The blogs are easy to use and can provide a chronological history of the project. They are however also sometime relatively long and it can be hard to catch the most important information.

Both RepRap and OSE have somewhat low process openness. This is mainly because of their processes lacking transparency. It simple hard to figure out how you can contribute. This means that you have to be truly dedicated to take part in much OSHW development, making it a club for the initiated. Design are usually first released when finished, and the work is usually carried out by single individuals or small core teams.

L ist of the mo st u sed groupwa re i n OSHW c om m un i ti es • • • • • •

Wiki Forum Chat E-mail Design Repository Blog

“

The RepRap wiki is useless, I’ve seen people complaining about it for years but the advice is to always ﬁx it yourself, which is obviously no small task! The only way to keep track is to use IRC or perhaps the developers mailing list.

(RepRap forum, appendix 2a)

RESEARCH METHODOLOGY

The correlation between these different tools presents a complex system, which can be blamed partly for the challenge of ﬁnding information. The Wiki is the focal point. For a wiki to be truly effective enough resources have to be available for its development. It could be in the form of hardworking individuals or by small contributions from the masses. Resources have to be put into creating content but also into structuring and relating content. When looking at the RepRap wiki it seems as if not enough resources are available or put into it. Information is fragmented and incomplete. Even the wiki of more focused projects such as OSE, can be confusing. A wiki seem unsuitable to handle product documentation, partly because of developers’ lack of enthusiasm for documentation, and partly because a wiki demands too many resources to structure due to the ﬂat documentation structure. The strength of a wiki is that is makes information easily accessible to all. Which alternative have that ability while demanding less resources?

“

After ﬁnding out that some schematics were wrong I digged further in the website (reprap.org) and found a completely different manual and different parts of information were ﬂoating elsewhere. -

(RepRap Forum, appendix 2a)

PAGE

Thin g hiv e r se

“

Thingiverse is a “low-tech” design repository mainly focused on sharing user made design documentation. “Thingiverse is a website dedicated to the sharing of user-created digital design ﬁles. Providing primarily open source hardware designs licensed under the GNU General Public License or Creative Commons licenses, users choose the type of user license they wish to attach to the designs they share. 3D printers, laser cutters, milling machines and many other technologies can be used to physically create the ﬁles shared by the users on Thingiverse. Thingiverse is widely used in the DIY technology and Maker communities, by the RepRap Project, and by 3D Printer and MakerBot operators. Numerous technical projects use Thingiverse as a repository for shared innovation and dissemination of source materials to the public.”

I really would have no problem with the site if they just integrated common everyday social network aspects. If someone comments on my object, i wanna know. If i get a reply to a comment i make, i wanna know.

(Making thingiverse better - Appendix 2a)

Thingiverse present an opportunity to tag your design as an derivative, which many does. This can give an overview of the progress of a design - if you are willing to do the detective work. It can also show which design create most derivatives, indicating a dominant design.

- (www.wired.com)

Thingiverse was created as a sharing platform for the makerbot community and it is still mainly used by the 3D printer communities. “The dream behind Thingiverse is that someday in the not so distant future, when everyone has a RepRap machine, they will be able to go to Thingiverse.com, ﬁnd a useful/interesting/cool thing, download it, print it, and 15 minutes later be able to hold the actual thing in their hands”. - (www.wired.com)

There are some discussions on how bias Thingivers is, because of its connection with MakerBot Industries. Some believe that the site administrators favours things made by Makerbot and questions are posed regarding their license policies. Several users have express wishes about an independent site providing the same services as Thingiverse. (www.reddit.com). Thingiverse is lacking in terms of social network aspects. Users would like to be able to follow projects and get updates. They also want to be able to up/down vote projects, users and comments. Functionalities similar to Slashdot and Reddit.

PAGE

Thingiver se O ve rvi ew S u c c e s se s • • • • •

Easy upload and download Derivative tracking Featured projects Good license overview (when downloading things) Overview of the 3D printer community in general

C h a l l eng e s in re g ard to OSHW • • • • •

Little power to the users in regard to what get featured No version control No history tracking Opaque license policies (when uploading you things) Not possible to follow projects and get updates

Gith u b GitHub is a web-based hosting service for software development projects that builds on Git, a software configuration management (SCM) system. GitHub offers both paid plans for private repositories, and free accounts for open source projects. As of May 2011, GitHub was the most popular open source code repository site (www.wikipedia. com) The site provides social networking functionality such as feeds, followers and the network graph to display how developers work on their versions of a repository. Git offers distributed version control. It differs from a centralised system by allowing cloning of entire repositories, including the change history and old versions. Other version control systems track the changes as a list of changes. Github looks at snapshots. Every time you commit, or save the state of your project in Github, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored (github.com). One thing github.com does particularly well is its use of social media. It is possible to follow projects and get feeds on ongoing development. You get good overview of derivatives and the development three through a network graph, a very powerful tool to gain overview in distributed projects. Github is made for software development and you need knowledge of coding to use it. There are no visual differencing tools which is desirable in hardware development. Because hardware does not have the same low cost of integration as software the easy cloning and branching might result in uncontrolled forking. The solution might be to set git up to function as a centralised version control system to minimize this risk. Although it is possible to work with “sub modules” the feature does not seem to support partial design development of hardware, because of the weak link between the sub module repository and main repository making it easy to overwrite changes and commits. The Sub modules feature does not seem to have matured enough to be used even by software developers (Blog why-your-companyshouldnt-use-git-submodules) and the highly successful RepRap project Prusa Mendel has tried, and abandoned, the use of sub modules on GitHub (github.com/PrusaMendel). Where source code can be read as a sequence of lines, CAD files are a collection of data stored as a singe entity - Blob. This sets fundamentally different requirements n regard to version control It should be investigated further to what extent git can be configured to mimic they way product data management systems handle version control.

Gith ub O ve rvi ew Su c c e s s e s • • • • • • •

Good project overview Ease of use (for software users) Eﬃcient version control (git) Use of social media Overview of branching Easy merging (git) Highly configurable

C h a l l eng e s i n re g ard to OSHW • • • •

Need knowledge of coding No visual differencing Might result in uncontrolled branching when dealing with hardware (git) Does not support partial design hardware development

RESEARCH METHODOLOGY

PAGE

Q ui rk y Quirky is a industrial design company that involve a community of individual developers and users in their design process. They do this using crowdsourcing letting individuals submit product ideas that the community will help develop through their online platform. The ideas are evaluated by the community and the Quirky employees which lets the company determine which product to design. The Quirky development team draws in the community through the design phase but they control the direction. Quirky also manufactures, sells and distribute most of the develop products. The inventor and any other contributors then get up to 30% of any resulting revenue. The influence that a single individual have on the development is measures by breaking down the development process and looking on how the individual has contributed according to this. The result is a percentage of influence which will determine how much you will get of the resulting revenue. “We bring two brand new consumer products to market each week, by enabling a fluid conversation between a global community and Quirky’s expert product design staff. The world influences our business in real-time, and we share our revenue directly with the people who helped us make successful decisions.” - (Quirky.com)

The Q u rk y P ro c ess The phases of development are very clear. It is very easy to get an overview of the project and how you can contribute to the project in its different phases of the development. There is a low level of entry for new developers. However, contributions are for most restricted to comments. Because the products chosen for development are all relatively simple the comments can be very useful but are in some cases only “likes” and “dislikes” which is not very constructive. You can say the design undergoes contentious design reviews by the community but the actual product development is done by the quirky team. This approach could be used by many OSHW projects as the actual development of these projects often also is done solely by a core team. Creating smaller centralized systems (projects) where is it easy to make smaller contributions would let OSHW projects utilize the crowd better. The key elements would be to create good overview and breakdown of tasks and thereby letting a larger crowd evaluate the designs.

PAGE

C ase O verview S u c c e s se s • • • • •

Low entry barrier for new developers Measure inﬂuence Effective business model Good Ideation phase Effective Co-Creation

C h a l l enge s i n re g ard to O SHW • No Co-determination • Development of complex products • Distributed Product Development

PDM P rodu c t Data M a nag e men t This section constitutes discussions on the advantages and challenges of PDM. The research here differ from the community and platform cases, as it is based mainly on literature studies. It is presented here, and not in the theory section, due to its close relation with answering the research questions. As engineering design has become more and more digitized it has become easier to create and change product data. Especially in large collaborations the conventional data management was not able to handle this rapidly changing data, resulting in people spending more time on finding and validating data appose to actually using it in their work (Brown 2011). Product Data Management (PDM) has emerged to handle this, often large amount of rapidly changing digitized data. PDM brings value in three overall aspects: Controlling product data, making product data accessible, and sharing product data (Brown 2011). PDM lets the developers focus on innovation and adding value instead of handling data and searching for information. PDM systems today entail a large amount of functionality, especially considering that in recent years PDM has evolved, broadening the scope to involve the entire Product Life cycle Management (PLM). However only focusing on PDM a set of basic functionalities can be identified (Liu & Xu, 2001)(Kumar & Midha 2001)(Siemens PLM): • Document Management: Version controlled retrieval and storage of documentation • Workflow and Process Automation: Manage and execute automated workflow and processes. • Change Management: Issue tracking, ECR and ECO • Part Management: Provides information on standard components and facilitates re-use of designs • Program Management: Allows coordination between processes, recourse scheduling and project tracking. (project management) Many companies have experienced problems with implementation and use of the often highly complex PDM solutions. None-user friendly interfaces and complex integration with company processes results in long learning curves for new users (Liu & Xu 2001). Many solutions are also very expensive leaving them out of reach for start-ups, small business and especially OSHW projects. Still, creating a cheap and simple alternative could be beneficial, because PDM seems to support the need of OSHW development.

PDM and O pe n S ou rc e H a rdwa re Because OSHW development in many aspects can be looked upon as a conventional distributed product development project, PDM could bring the same value to OSHW as it has to development companies around the world. Especially considering the more autonomous nature of many OSHW projects, and the potentially larger population of developers in these projects. Is has to be mentioned that PDM has potential to support large complex product development projects with large amount of data, but might be to comprehensive a tool for simpler products with less documentation. Therefore it should be possible to adapt the functionalities to the need of specific projects, for example if a product is documented in a 2D sketch and on a few wiki pages a automated ECR process would probable not be needed. Focusing on complex product development, several challenges exist in creating a PDM for OSHW projects. One challenge lie in allowing the system to support the wide range of CAD formats used, and to adapt to some of the more simple programs such as goggle sketch-up, which to do not offer the same functionalities as programs such as Solidworks and Creo. Unfortunately no open source CAD solution exists that can truly compete with these advanced programs, why some project might need to set process constrains to deal with “simple” CAD. Another challenge lie in creating workflows, that support development on connected development tracks. Parallel development might result in critical forking and high cost of integration, if there is not a high control with the inter-model linkages. In industry this issue is dealt with through Top-Down design using CAD layouts (skeleton models) which set the overall architecture of the model. But what if the right CAD skills are not present to create and support Top-Down designs or the open source CAD programs do not provide the functionalities? The result might be repetition of work, high cost of integration and uncontrolled forking, as it is seen in the OSHW communities today. Is it possible to create workflows which lower the above mentioned impact of insufficient CAD skills or functionalities? High focus on defining modules, interfaces and responsibilities might be an answer. There should be a way to effectively communicate relations that are not embedded in the CAD documentation and gain overview of the impact that design changes to sub functions, have on the overall functionality. This might be achieved by introducing the interface diagram modeling formalism proposed by Bruun & Mortensen (2011). This formalism and its relation to PDM will be explained on the following page.

RESEARCH METHODOLOGY

PAGE

The interface diagram (Bruun & Mortensen, 2011) is a visual, block based representation of a product structre illustrating the relations between assemblies and components. “There are several objectives for creating an IFD. Among the most important are: Acting as a vehicle for communication between stakeholders; providing guidance for the decisions of detailed design; to support a modularization process; keep track of latest design changes; complete overview of the product; to ensure simple interfaces; dealing with transformation of the product over time; point out responsibility of interfaces, and to form basis for a PLM data structure”. (Bruun & Mortensen 2011) These objectives relates very well to the needs in OSHW development, and in any traditional complex product development project. “The purpose of working with interfaces is to ensure responsibility for the components interaction and to ensure that components are interchangeable, when relevant” (Bruun & Mortensen 2011) Due to the many uncertainties in the early stages of development, the interface diagram is envisioned most valueable in the late concept development phase, moving in to the system-level design phase where the product architecture is defined. Bruun & Mortensen (2011) suggest using the interface diagram to structure data in an PLM system. This could not only offer a possibility of gaining an easier control with interdependencies between product structure elements, but also of linking program management and process automation in ways that support development on partial designs. It could for example do this by allow linkage of project activities, product documentation, product structure elements and defined workflows, hence supporting supporting change management in many aspects.

PDM O ve r v i e w Appl ic at ions • Used in a wide range of ﬁelds to store and manage product and process related information. • A simple PDM system could be suitable for OSHW projects (and small companies and start-ups) • No such solution exist, that supports community-based development Main f u nc t ions • • • • •

C ha l l e nge s in re g ard to O SHW • • • •

PAGE

Document Management Workﬂow and process automation Product Structure Management Part Management Program Management (Project Management)

Ease of use Implementation of generic workﬂows Flexibility (combining open and closed systems) Many different CAD systems or no “real” CAD

Ge n e ri c In t e rface D iagr a m

E n t it y R e l ati onshi p Mode l f or PDM lin k (UML) “ T he produc t i s the top entit y. Ass emblies and sy stems can be par t of the produc t s. IF component s are a par t of a ss emblies and a spec iali z ation of an a ss embly i s a module. Sy stems are a ss oc iated w ith IF component s and IF component s are a ss oc iated w ith inter faces. CA D a ss emblies and component s are par t s of IF component s. CA D par t s can be a par t of component s but are alway s a par t of CA D a ss e mblies.” - H.P. Bruun & N.H. Mortensen (2009)

“The diagram follows the approach of modelling architectures by use of block diagrams. The main elements of the diagram formalism are functional objects denoted Interface components (IF component). The purpose of the IF components is to decompose the systems and modules into smaller functional building block. IF components can have different characteristics and are thus modeled in different ways. An existing IF component represents a generic assembly or part in the architecture and is symbolized by a white block. An optional assembly or part is symbolized by a grey block. A future assembly or part which has to be taken into consideration in the architecture but has not been developed yet has a dotted line around a white block. Finally variety of assemblies or parts is modeled by placing blocks on top of each other with a little offset”. H.P. Bruun & N.H. Mortensen (2009)

RESEARCH METHODOLOGY

PAGE

A ns w eri n g th e re sea rc h qu est i on s

Here the research questions will be answered based on the case analyses. This serves as sub conclusions on which the following exploration of the idea and conceptualization process can be based. These pages are the last pages before starting the next chapter, exploration of the idea.

What are the needs in Open S ource Hardware communities in regard to efficient coll aboration?

Can the functionalities of today’s Product Data Management (PDM) solutions be beneficial to Open Source Hardware development?

This question is especially focused on the needs of the dedicated developers devoting much of their time to developing OSHW products. No OSHW community is exactly the same, so this describes some generalized findings. In general, the document structure in OSHW communities is chaotic, as information is scattered around wiki sites, forums, mails, chats, blogs and design repositories. Especially for large communities, like the RepRap community, this setup proves inadequate, making it complicated to follow the ongoing progress of the projects. It can be difficult to find information and it can be difficult to validate the information is correct, especially for the uninitiated. Gaining an overview of different solutions is hard and there is often no validation of the designs. To gain an overview of the good solutions requires that you read through massive amount of wiki pages and forum threads.

Today’s PDM systems provide much functionality needed in OSHW development, but they are expensive and diﬃcult to implement. PDM is used in distributed product development which shares many similarities with OSHW development. It will be a challenge to adapt PDM to an OSHW context because of the many diﬀerent CAD formats used and because PDM is usually based on a centralized system. Creating a semi-distributed version control system for hardware development might be beneficial as you see it in some software projects, using git. Product structure management would allow the structuring of data with focus on modules and interfaces, which would lower dependencies on complex CAD solutions.

• • • •

It needs to be easier to find information and validate that the information is correct It needs to be easier to follow the ongoing progress of the projects It needs to be easier to gain an overview of existing solutions It needs to be easier to evaluate and validate designs

• Today’s PDM solutions are too expensive and diﬃcult to implement for OSHW projects • The basic functionality of PDM relate well with the needs of OSHW communities but would need to be adapted to suit community based development. • The most important functionalities is seen as being: Document Management, Automated Processes, Product Structure Management and Program Management.

RESEARCH METHODOLOGY

PAGE

How d o you ensure a more ef f i c i e n t u t il i z at i on of “ t h e c row d” in O pen S ourc e H ardware c ol l a b or at ion s ?

How d o you e mp owe r O pe n S ourc e C ommun itie s to un de rta ke pa rt ia l desig n deve l opme n t?

The case studies show that most OSHW designs are published after completion without the community having been actively involved. Extrinsic incentives, e.g. prospects of proﬁt, are in some cases the reason for this. Mostly though, it is because the current collaboration structure makes it hard to communicate the ongoing development. You have to continuously monitor the project via several channels to know how and where to contribute. This exclude contributes who do not wish to dedicate that much time to the project and makes the project a club for the initiated. Crowdsourcing sites such a Quirky make use of very deﬁned processes to, on one side communicate how to contribute, and on the other to validate the input from the crowd. They pose concrete assignments or challenges which are easy to engage in. Although these processes are often used in relation with simple or concept level ideas, they might also used to allow followers to contribute in small scale, to complex development. Such challenges based processes can also be a way of structuring the inputs making it easier to get overview and validate the inputs.

In traditional product development, collaboration on partial designs are guided by well structured CAD. If the right competencies and resources are available in the core team this might be a valid approach in OSHW projects as well. However if this is not the case then clear communication of the product architecture, modules and interfaces might be a way to overcome unintentional forking. Such an approach should also be supported by clearly defined responsibilities. Such an approach might not suit some segments of the OSHW communities, but the case study shows that other segments are willing to sacrifice “freedom” if it means more control of the product structure, because this will allow them to benefit from interchangeable modules. The IFD formalism (Brunn & Mortensen, 2011) is seen as a possible approach to encourage and support communities to develop and communicate modular products.

• Crowdsourcing site use very structured processes and poses challenges which are easy to engage in. Such processes can also make contributions easier to validate due to better overview and crowd moderation • OSHW project should adapt the crowdsourcing approach to gain overview of contributions and create more transparent processes

• There is a general willingness to develop more modular products in OSHW communities • More clearly defined and communicated product architectures, modules and interfaces would support development on partial designs, and lower the cost of integrating designs

PAGE

C ha p te r 3

E x pl oring t h e Ide a

RESEARCH METHODOLOGY

PAGE

The objective of exploring the idea was to focus the ﬁndings from the research phase, and relate these to a more concrete product idea. The objective was also to consider all aspects of the product idea, drawing in business and market considerations. In many ways the exploration of the idea can be seen as a mission statement, aiming on creating a clearer goal and linking the research phase and conceptualization phase. Chapter 3 content • • • • • • •

Overview of the product idea Users Needs Goal Specifications Strategy & Business Technology Product (task)

50 50 51 52 52 53 54

PAGE

E xpl oring the idea This section will elaborate on the overall concept idea based on the overall aim of this project, namely to develop a concept for a online collaboration platform that support community-based development of complex physical products. Until now a broad perspective was used to explore aspects of OSHW communities and related collaboration tools. Now a more narrow focus is set, leading up to the concept development. First step is to deﬁne the aspects of the product idea. Hansen & Andreasen (2005) sums up the dimensions of an idea in the Product Idea Model. The model illustrates eight dimensions of a product idea which has been used to guide the elaboration of the idea. The dimensions are: Users, Needs, Goal Speciﬁcations, Business, Strategy, Technology, Task and Product. The aim is to sum up the lessons leaned from the research phase and relate these more directly to the product idea, while bringing in more business aspects.

Overview of the Product Idea Users

• Community-Based OSHW development projects • SME’s doing product development of physical products

Major Needs

• Easy location of information • Control and Communication of product structures (lowering the cost of integration) • Communication of project activities to the community

Goal Speciﬁcation (Simpliﬁed) • • • •

Document Management Product Structure Management Project Management Co-creation mechanism

Technology

• Database Management

Strategy

• Mission: Empowering OSHW communities and SME’s to reach their full potential through efficient collaboration and product development, for the benefit of society • Vision: Creating a efficient online collaboration platform that in time will be the centre of OSHW development, and the number one choice for SME’s to run their development projects

Market

• Target Market: Service provider to small scale hardware product development projects. World wide • Business: Freemium business model. • Market Potential: Hundreds of thousands of users. No direct competitors.

Product

• Cloud PDM and project management tool, which is designed for community-based development

D i m e nsi ons of a product i de a The following will go through the eight dimensions of a product idea: Users, Needs, Goal Specifications, Market, Business, Technology, (Task), Product.

USERS Two overall types of users are identified: OSHW community members running community-based projects and Employees in SMVs running small/ medium scale product development projects. The users are described generally by looking at the projects being run and not the individual users. A final user group could be defined as the followers, the users of OSHW products who do not contribute. However, they will no be given much focus here. Community-projects: Two kinds of community projects are defined: Hobby projects and Core team projects. (Community-projects are also described in more detail in the theory section, from page 14) Hobby projects are small projects run by single individuals, “hobby participators”, as a hobby. These hobby participators will often participate based on incentives such as prestige, self-realization or to support a good cause. The projects would most often be DIY projects and the project owners are often tech-geeks. They can support the core team projects by commenting on their design, fixing small bugs and correct data. Examples of such projects are small projects on Thingiverse or RepRap.org. Core team projects are projects run by a core team of “dedicated participators”. These projects would often be larger and be the focal points for the development in the community. The dedicated participators contribute based on the same incentives as the hobby participators, although you see more dedicated participators being

RESEARCH METHODOLOGY

motivated by the prospect of proﬁt. This is also why you see some projects with very low process openness and the designs are ﬁrst released on completion. The core teams can consist of a wide range of developers with different background and knowledge. Examples of these projects are the more successful RepRap projects, such as RepRap Mendel. SMEs projects: These companies do product development of physical products. They could be established companies or tech start-ups. Two categories of small company projects are seen being run on the collaboration platform: Closed and open. Similar for both types of projects is that they would usually not be supported

by any PDM application, making them face many of the same problems in regard to data management as the OSHW core team projects. They would however, often have more deﬁned process and authority. The open company projects resemble the core team community projects. The line between them is blurred because it is based on what “drives” the project participators. They resemble each other in regard to drawing on the community and using their contribution in their development. The difference being that the company project would have a more hierarchical structure and the general incentive for doing product development would be proﬁt. Examples of such projects are Arduino and MakerBot.

L i st of gen era l n eeds 1. Ease of fi nding information and validating that the information is correct. More resources could be used on the actual development. 2. Ease of following the ongoing progress of the projects and enhance traceability. It will create a better foundation for people to contribute and give a clearer view of where the project is heading and help communicating goals. 3. Ease of evaluating and validating designs. It is very difﬁcult to gain an overview of existing solutions and their speciﬁcations. If this was possible it could focus resources into developing the most promising solutions. 4. Ease of communicating and controlling product structure architecture, modules and interfaces. This will be part of lowering the cost of integration and make partial design development easier. 5. Make it possible to confi gure the level of openness to allow projects to develop en accordance with their business model. To attract closed projects - for example companies not wanting to do Open Design.

The closed company projects would resemble the open company projects and core team projects in regard to how the member collaborate internally, but will not make use of a large community. They could still be run in a distributed setting. Any small traditional physical product development project run in companies today is an example of this.

Needs A long list of user statements was collected on-line and through interviews during the research phase. All these statements can be found in appendix 2. These need statements are in combination with the answers to the research questions on page 42, interpret into a list of general needs, on which a set of goal speciﬁcation are created. Focus is set on OSHW core team projects. The needs of the company projects is believed to be better understood, why they have not been given the same focus. The needs of users doing more traditional product development will also be taking into account when looking a the functionalities of PDM systems in more detail. PDM systems are designed with more traditional product development in mind. As the overall aim is to develop a collaboration platform that allow community based project to develop complex products through co-creation, need statement 1 and 4 is seen as the most important because these needs lay the foundation for meeting the rest. It was decided not to focus as much on the socio-technical aspects in regard to community development. For example how

PAGE

do you support the creation of networks? That could be a network of Hackerspaces or research institutions, physical platforms, that support the online development. Design paradox: One on side the platform should be easy to use and implement, not repeating the mistakes of the complex PDM solutions. On the other side the platform should provide enough functionality and configurability to support many different kinds of projects. So there is a design paradox between functionality and configurability on one side, and ease of use and implementation on the other side. Web-based platforms such as Gihub. com and Podio.com seem to have found a good balance. It is believed that a way to deal with the paradox is to create different out-of-box solutions pre configured to different kinds of projects, and platform embedded step-by-step tutorials as seen in Podio.com. The first step will be to get an overview of the possible functionality. Another design paradox lies in encouraging branching and experimental designs, while still remaining focused. The platform should allow chaos to flourish while providing overview and structure, to ensure resources being channeled into integrating designs. This is partly a communication responsibility of the core teams running the focal projects. Supporting partial design development and creating overview and validation of designs another aspect. This is where an efficient co-creation mechanism comes in.

G oa l spe c i f i c at i on This is a list of initial specifications relating to the needs and user requirements. Specification metrics was created to support the validationg process, seen in Appendix 11, but due to the fact that no real functional model of the final concept was managed created to allow test, the metrics did not prove especially useful. Instead the goal specification was used as evaluation criteria used when benchmarking the final concept.

St r ate g y a nd Bu si n ess These are initial thought on the strategy and how you could create a business around the product. A business plan executive summary is found in appendix 14. Strategy: The overall mission is to let OSHW reach the same impact of OSS. This is tried achieved by creating a collaboration platform that can support OSHW in their development efforts and thereby letting them develop truly competitive products. This platform could also be used by small companies who cannot afford expensive PDM solutions. • Mission: Empowering OSHW communities and small tech companies and start-ups to reach their full potential through efficient collaboration and product development, for the benefit of society • Vision: Creating a efficient online collaboration platform that in time will be the centre of OSHW development and the number one choice for small companies to run their development projects

PAGE

Goal Specifications 1. Ease of finding information and validating that the information is correct. Meaning there is a need of better Document Management. 1. Centralized version control (still allowing forks) 2. Peer-review 3. Easy to structure data (Hierarchy) 4. Data structure linking documentation and project activities (discussions, issues, CAD) 5. Communicate responsibility 6. Overview of completeness of documentation 2. Ease of following the ongoing progress of the projects and support traceability. It will create a better foundation for people to contribute and give a clearer view of where the project is heading and help communicating goals. Co-Creation mechanism, Project Management and Process Automation. 1. Communicating completeness of documentation and activities 2. Communicate the focus of the core team 3. Well defined step-by-step processes 3. Ease of evaluating and validating designs. It is very difficult to gain an overview of existing solutions and their specifications. Co-Creation mechanism 1. On-click use moderation (Likes, up-down voting) 2. Support the creation of networks between projects, Hackerspaces, research institutions and manufactures. 3. Easier documentation process (documentation templates, linking CAD and non-CAD documentation) 4. Ease of communicating and controlling product architecture, modules and interfaces. Meaning there is a need for Product Structure Management 1. Define product structure to support interface management 2. Graphic overview of product structure, module, system, interfaces 3. Communicate responsibilities 4. Support automated change processes. 5. Make it possible to configure the level of openness to allow projects to develop en accordance with their business model. For example, let totally closed project protect their IP rights by securing their data and allowing them to be “invisible” on the platform. 1. Pre configured settings supporting different types of projects. 2. Securing data

Business: The market is defined as being OSHW project and small companies doing development of physical products. These are the “lower” segments on the PDM market. Being web-based the platform can reach user worldwide. The business is seen expanded through a freemium business model, which will create a large user group of non paying users, and smaller group of closed company projects paying for access, training and information.The biggest expense in running the platform is seen as investment in- and maintenance of the IT-infrastructure (servers). • Target Market: Service provider to small scale hardware product development projects. World wide. • Business Goal: In time be the #1 hosting site of OSHW projects. Build on a freemium business model, where public projects can be run for free and private project are charges according to their requirements. Create revenue by offering consultancy, and training. • Market Potential: Reach the impact of Github.com hosting thousands of active public and private projects, and having millions of users (Github.com). No existing collaboration platform, designed to support development of complex physical products, is accessible to OSHW project and small companies. No direct competitor. • Entry Strategy: By developing the platform with the help of open source software communities and allowing open source projects to use the product for free, fast diffusion and awareness of the platform in the open source communities will be created. This awareness will spread to companies running closed projects as well. For the platform to have real value on a community level it needs to reach critical mass. This will be achieved by running design competitions based on high profile OSHW projects, like RepRap, on the platform and by offering special offers to early adopters. Through partnership with companies and research institutions known nationwide and let partners use the platform for free, success stories will be created which will attract the first paying customers.

as initial enquiry did not result in any serious complications, and existing products, such as Github.com and ARAS, provide many of the functionalities also envisioned in the collaboration platform. An aspect of the development strategy is to ﬁnd existing solutions to build upon and thereby make sure the technology used is robust. How to deal with the various CAD format, letting them be controlled and view by the PDM system is however not know. Open Source Product such as ARAS seems to have found a solution. Perhaps through neutral formats such as STEP. Application integration should be investigated further.

PRODUCT From a business perspective the product is web-based hosting of hardware development projects. To be able to provide that service a software product is needed that allow hardware developers to efﬁciently co-create complex hardware product. So the object of design is a software platform. The task it to develop a concept for such a platform focusing on the use aspects. The software product should mimic current PDM systems and hence support development of complex hardware products, but adapted to community-based development. It should allow easy location and retrieval of information and ensure that information is correct and in the wanted version (Document Management). The product structure should be easily viewed and communicated, allowing efﬁcient co-creation of partial designs (Product Structure Management). Process transparency should be high and project activities easily communicated (Automated Processes, Program Management and Co-creation mechanism). It should do all this while still being chaste, easy to use and easy to implement. This sums up the chapter on exploration of the product idea. The next chapter is concept development.

TECHNOLOGY The base technology is database technology. There is several open source database software such as mySQL. Version control software, such as git, and Client/server software such as ftp and rsync would also be needed as the platform builds on the client/server model. No thorough technology feasibility analyses have been completed

RESEARCH METHODOLOGY

PAGE

54 PAG E

C ha p te r 4

C oncep t D ev el op m e n t

CONCEPT GENERATION

The objective of the concept development phase was to generate a concept that meet the needs and requirements, deﬁned when exploring the idea. The main aim was to develop a broad concept covering many aspects regarding community-based development. The concept should in that sense could serve as inspiration for future development. Chapter 4 content • • • • •

Introduction to concept development General concepts Functional breakdown Presentation of solutions Detailing the concept

57 58 60 62 66

PAGE

56 PAG E

Figure 11 - Mind map of the DeDoCu concept

CONCEPT GENERATION

Introduction to c oncep t devel opment The following chapter will go through the concept generation process, focusing mainly on describing the chosen sub solutions, and detailing of the total concept. The concept generation can be seen as three main activities: • Generating general concepts: First some overall concepts was generated by brainstorm and evaluated. The aim was to re-think the overall concept. • Function Breakdown and solutions: Then one general concept was decomposed into sub functions and solutions generated. • Detailing the concept: Last the solutions was detailed and synthesized into a final concept. Here use scenarios played an important role. The framework for the concept generation was, “the five step concept generation method” defining the following elements: Clarify the problem, Search Externally, Search Internally, Explore Systematically, Reflect on the result and the process (Ulrich & Eppinger 2008). Clarifying the problem was done in the previous chapters, so this chapter focuses on the last four elements. However, the method was not stringently followed and the process became more iterative, than a step-by-step process. Reflections on the process can be found in appendix 4. This process resulted in a single concept called DeDoCu an abbreviation of design documentation. The concept is here summed up in a mind map, see figure 11 and a UML diagram of the data structure clarifying relations, see figure 12.

Figure 12 - UML diagram for DeDoCu data structure

PAGE

Ge n erati ng Genera l C on c e p ts Based on interesting existing solutions, identified in the research phase, general concepts were generated internally. The three most interesting was, Project-Thingiverse, Group of Groupware and Social-PoDM, which represent three levels of complexity. The three concepts will be described in short here. The “two sides of a product idea” by Hansen & Andreasen (2002) are used to describe the concept. The concepts can be seen on the following page. The section below will give a quick description of the evaluation of the concepts.

Re t h i n k i n g the concep t

Evaluati on of t h e t h ree c on c ep ts

From the beginning, the overall aim of this project was to develop a concept that “support community-based development of complex physical products”. The research supports the need of such a solution. “Project-Thingiverse” is an interesting idea and could present real value for simpler projects. But it does not support complex product development. The value proposition of this concept does not justify a change of course. The concept “Group of Groupware” has been tried before by OpenDesignEngine and OpenPario, none of these projects are successful, and the overall architecture is still minded software development. This leaves Social-PoDM. Social PoDM is the most radical and complex concept with many uncertainties, but it is seen as the only of the generated concepts, that meet all the requirements identified in the research phase. It is also seen as the only concept that would attract established companies. It was decided to continue on the path of Social-PoDM, but aspects of Project-Thingiverse should be drawn in.

D ef i n i ng th e overa ll c on c ep t framework

Based in Social PoDM, the general framework for the concept was defined in more detail. Two elements will be drawn out: The network framework and the database system. The Network: The concept is a web-based collaboration platform where users can sign up and get access to their own design repository and project management Figure 13- Network framework tools. The repositories can be used by teams sharing a repository and running many projects, by single individuals running small projects, or individuals without a repository who just signed up to contribute to, or follow other projects. The platform should supports the creation of networks between these users and the forming of communities. Lessons learned from Open Source communities shows that a few “large” influential projects will dominate these networks and smaller projects will contribute with minor improvements, (see figure 13). The platform will be specifically minded on supporting such networks. Both private and public projects can be run on the platform. Private projects can protect their designs and be “invisible” to other users and public projects can easily collaborate with other public projects. In this way it mimics Github.com. PAGE

The Database Management System: The system is based on an relational database, such as mySQL. Data and metadata are separated for version control purposes, standard procedure in PDM (Dahlqvist et. al., 2001). This is fundamentally diﬀerent from how version control of source code is handled in SCM systems and the reason why existing open source SCM solutions are not well equipped to handle product definition data of physical products. It was decided to focus on a centralised version control system as distributed version control, however useful, could result in unintentional forking. Hardware do not benefit from relatively easy merger as software does, why unintentional forking can be harmful for the progress in individual projects. Role management can define how users outside the centralised system can interact with the documentation. In open projects it should be possible to download product documentation and clone projects. Within projects it should also be possible to branch a project and develop alternative solutions simultaneously. Product structure management can supports this process through well defined interfaces.

The overall system is based in the client/ server model, see figure 14. Local applications lets users interact with the PDM system that controls metadata of the managed files. One local application allow integrated interaction with local CAD applications and control of local files. This application is more or less black boxed in this project, but the application will mimic the same applications used in traditional PDM solutions. Another local application is your browser, from where you only interact with the PDM system. Focus has been put on how you interact with the PDM system through your browser.

Figure 14 - Client/server model for PDM

Social PoDM Project-�ingiverse

Group of Groupware

Idea With This idea constitute being able to create projects on a site similar to Thingiverse, but were you can have several connected “things” uploaded. This would make an excellent showroom, making design documentation easily accessible and allow small communities to form around interesting projects, in a simpler way than using wikis. Idea In You would have a small repository with version control, similar to dropbox, embedded in Thingiverse. Also standard social networking features should be embedded, like follow and news feed. There would not be any sort of project structure management only a “folder” for each project. The Diﬀerence that Matters Easy upload and download of documentation. Show a group of things.

design

Evaluation The concept would not be suitable for running complex product development projects. No elements of the project support partial design development in particular. The platform would be more suitable for minor projects, similar to what Thingiverse does today.

Idea With This idea constitutes having a web-based platform based on the structure of current OSHW projects, where all tools are pre-linked which makes the platform “ready to use”. This is pretty much the idea of OpenDesignEngine who are basing their concept on the open source project management tool Redmine. Idea In Wiki, forum and repository are already linked together along with standard issue tracking and activity management. Already existing open source SCM (git) allow version control. The diﬀerence that matters Having a linked system of groupware “ready to use”. Evaluation Although it presents a step up from how OSHW project are structured today, and might be useful for development of simpler products it does not support partial design development as it oﬀers no product structure management and does not provide suitable version control.

The idea With This idea constitutes having a chaste easy to use, Cloud PDM solution designed for community-based development of physical products. Because the platform is web-based, no IT-Infrastructure needs to be created and maintained by the users. Crowdsourcing like processes is implemented to make it easier to validate ideas. The platform should suit the needs of both community-based and private based development. Idea In The PDM functionality allow partial design development through product structure management focusing on interface management. The PODIO app is implemented which, with some modification, presents a new way of creating and structuring documentation and processes. The App should then replace the Wiki. Commonly used OSHW groupware, such as forums, blogs and chats, are also implemented. The difference that matters Chaste, Easy to use, Cheap, Social oriented web-based PDM platform. Providing Efficient data management for community based development. Evaluation The concept would be relatively complex which might harm its ease of use. It would also be more difficult to realize as new technology might need to be developed. The concept has many uncertainties. However, it meets the requirements for community-based development of hardware products.

CONCEPT GENERATION

PAGE

60 PAG E

Fu nc ti onal Brea kd ow n a n d S olu t ions After narrowing down the overall system architecture, the system was broken down into sub functions, se figure 15. The functions are based on the main functions of PDM identified in the research phase, see page 42. It was chosen to focus on three main functions as they were seen most closely connected with the identified needs. The three functions are: Program Management, Document Management and Product Structure Management. The system administration is the overall controlling and linking function. To bring in the aspects of adapting to community-based development Co-Creation is added as a sub function under system administration. Some aspects of standard PDM which have not been dealt with in detail are: Part Management, Application Integration, Data Transport and Translation. An alternative breakdown structure, which was also used to create sub solution, can be seen in Appendix 13.

Concept Breakdown 2 3 5 1 2 3

The identified needs were related to the concept breakdown to ensure that all needs were covered. Although many of the needs can be related to several of the sub functions, they are only related here to those functions where actual solutions were developed to fulfill it. Questions were written, for example, “How can role management be used to allow ease of following the ongoing progress?”, or “How do you define the project structure to make it easy to find information?”

1. Ease of fi nding information and validating that the information is correct.

2. Ease of following the ongoing progress of the projects and enhance traceability.

3. Ease of evaluating and validating designs.

4. Ease of communicating and controlling product structure - product architecture, modules and interfaces.

1 2 3 1 3 4 Figure 15 - Functional breakdown of concept

5. Make it possible to confi gure the level of openness to allow projects to develop en accordance with their business model.

CONCEPT GENERATION

PAGE

Ge ne r ati n g solu t i on s Based on the concept breakdown solutions were generated. This section will present an overview of the context and some of the chosen solutions. Many of the solutions are based on ideas from the external search which have been modified and combined (see Appendix 5). The solutions described here are chosen based on importance and novelty. Other important solutions are not described in detail as they are standard solutions, expected easily implemented. Such solutions are mainly online communication tools such as chat and forums. In Appendix 6 a longer list of ranked solutions can be viewed. 47 individual solutions were generated. Before presenting the solutions the overall context will be presented. THE

CONTEXT

The solutions have been developed in a context, and many of them have to be viewed in a context to be fully understood. So before presenting the individual solutions a quick overview of the finished concept will be given and key terms defined to try and present this context. If need be a glossary is found in Appendix 7. The finished concept was as mentioned given the name DeDoCu. Here is a short introduction. (Words in capital letters are key elements)

start developing. Through your organization you also have access to your APP VAULT. All non-CAD documentation is structured using these Apps. The App vault contains the Apps you have fetched from the DeDoCu App Center, and the Apps you have build yourself. An app is a category folder in which you create entries based on a predefined configurable template (see PODIO.com). These APP ENTRIES (documentation) can be linked to other Apps or to an element of a product structure. App entry content can be easily altered online while being version controlled. This gives the possibility for documentation to be co-created in a distributed environment. You can configure App Categories to define and control workflows. Through you organization you also have access to the PLAYGROUND. The playground is meant to be used by followers of you organization’s projects, to run experimental development tracks. They are given a branch of their own in your repository. They can then link their data to yours, giving all the projects in the playground a common point of reference. You also have access to your organization‘s CHALLENGE site. From here you can pose challenges to others, asking them to help you develop your products. You can communicate with others on DeDoCu using forums, chats, blogs, video conferencing, news feeds and personal messages. You can always chose how much you want to show, whether you want to be private or, release your projects for the world to see - or clone.

Quick introduction of DeDoCu.com DeDoCu.com is a website oﬀering online hosting of hardware development projects. After signing up you are free to browse the site and its communities. If you want to have access to you own repository you have to create an ORGANIZATION. Through your organization you have access to your PRODUCT VAULT a central repository. You can be a member of many organizations and a organization can have many members, sharing a repository. You can have public, simi-public or private organizations. When creating your organizations you also start you first PROJECT. You can think of a project as a sub folder containing the data related to a single project. You can start several projects giving you several development tracks or “branches”. Members of other organization can clone your project to their own organization, depending on you settings. The reason you started a organization is most likely that you want to do development of hardware products. Before you can do so, you have to define your product in the system. Defining you PRODUCT means creating and linking system elements (Items/objects), to which you can link documentation such as CAD. When defining a product structure you are guided by the INTERFACE DIAGRAM (IFD). The IFD lets you define you product structure in terms of assemblies, modules, interface components, components, interfaces and systems. When you have defined a product you can link it to a project and

Sign-up

Create Organization

Define Product

Start/clone Project

Figure 16- Initial steps when beginning to use DeDoCu

Document and collaborate

P resentat ion of c once p t solu t i on s The next four pages will give you an introduction of the chosen concept elements and solutions. The boxes above the sections contain the most closely related need statement. Below is given a quick overview of the solutions.

Overview of Solutions IFD

The IFD guides you when defining product structures. It lets you define you product in terms of modules, interfaces and systems.

App

The App let you co-create documentation online and can help define and control your workflows

Challenge

The Challenge let you pose challenges to other asking them help you in your development eďŹ&#x20AC;orts.

Playground

The playground let people not part of your team run experimental project relating to yours, in your repository. They run these projects under specific terms.

Monitor

The monitor can be configured to analyze you projects for trends indicating possible risks.

Openness Lever

The Openness lever let you configure your organizations privacy and access settings

The IFD

Ease of communicating and controlling product architecture, modules and interfaces. The principles of the Interface Diagram are described on page 43 and will not be dealt with here. Introduced here is a how the IFD is envisioned used to define product structures in the database. This relates to product structure management.The approach suggested is inspired by the article of Bruun & Mortensen (2011).

The approach of defining a generic product structure in the PDM system is not new, but a possibility in most PDM system. What is interesting is basing this generic structure on the IFD and displaying this graphically in the system. I suggest implementing a fixed generic product structure in the database, based on the IFD, to guide creation and structuring of items (objects), see figure 17. This will streamline how products are communicated and support developers using the platform in defining systems, modules and interfaces, a good foundation for developing complex products, and essential if the product is being developed in a distributed setting. The figure below illustrates that part of the system relationships defining the product structure.

Communication

You can communicate with other using, forums, chats, blogs, video conferencing and messages

Community

You can create networks and communities to help each other to develop better products.

Project Master

A project master can be assigned to your project and communicate and guide your project activities. Figure 17- Database classes based on the IFD

PAGE

The guiding definition is that a product, a module and an IF component are all specializations of an assembly. When you have defined the generic structure you have prepared the system to structure actual product data. This can be done without having any CAD. The activity of defining actual products in the system will be describes in more detail in the following chapters. A possible disadvantage of this approach is that it might construct too rigid a data structure, which could make it diﬃcult to suit it to specific product definitions used in established companies. In OSHW no clear definitions are communicated. Some communities might see it as an “evil” standard, hindering innovation. However with assemblies and components being the standard elements the approach is seen quite flexible.

The App

1. Ease of fi nding information

The app is a modifiable element which can be used to create and structure documentation and processes online in a Web 2.0 environment. By using standard building blocks you create App categories via a drag and drop interface. These App categories can be compared to “folders” holding a template on how a file in the folder should look like. You create App category for many types of documents or processes. Iﬀ you for example create an App called “Activities”, then an entry to that App would be an “Activity”. Using building blocks like “category”, you can communicate defined workflows or states of the documentation, For example can an entry can have the states “In progress” and “Complete”. Notification setting can be used to allow someone to monitor an App. This is all the same as Apps in PODIO [Podio. com]. To add to the idea I propose making three changes. 1: Monitored Category: The first is to make the system monitor certain building blocks to control workflows, instead of needing a person to supervise changes via notifications. This would be especially important in OSHW projects and for complex products. The building block is called “Monitored Category” and would replace the normal PODIO “category” block. In this you can set rules for changing category states. The rules can be based on the states of other monitored categories in other app entries. This relates to System Administration (workflow)

2: Version Control: The second change would be to version control the App entries so changes could be peer-reviewed in much the same way as wiki pages. This is again something especially useful for OSHW projects. This part of the solution has not been fully detailed. The solution relates to System Administration (Co-creation and workflow) and Document Management (version control) 3: Hierarchy: This leads to the third change. Both wiki pages and the PODIO App, create a flat documentation structure. That can be a good thing. But when structuring documentation for hardware product, you often want to do so, based on the product structure. This is not easily achieved in wikis and PODIO, and it would be resourceful to keep the structure updated. So the change would be to allow app entries to be linked to the product structure, similar to how documentation is structured and linked in current PDM systems. This would allow you to have both a flat and a hierarchical documentation structure. This sub solution relates to Product Structure Management and Document Management.

The Project Master Ease of following the ongoing A Project Master let you define progress of the projects and and communicate project enhance traceability. phases and top level activities. A Project Master can be used in relation with an overall product development model or it can be used to support detail project planning of individual projects. When creating a project you can chose to let it follow a Project Master defined by system administration. The Project Master communicates which kind of project it is and which phases, activities and documentation that will relate to it. Predefined Projects Masters will be available when an organization is created. These predefined project masters can build on generic product development models, such as NPD, SCRUM or Lean Product Development, or they can build on best practice approach on a more detailed level, such as concept development of mechatronic, Test of hardware or maybe Market Analysis. Central decision supporting documentation, and rules for progress can be defined. you for example can say that, we will not proceed to the development phase before the Mission Statement document is complete. You can then link the mission statement (app entry) to a specific activity in the master making it easily found by a project owner. Which phase the project is in, is displayed together with the project folder. The state of the product being developed is independent of the project master. So is the release status of the project. CONCEPT GENERATION

PAGE

64 PAG E

Ease of following the ongoing progress of the projects and enhance traceability.

TheChallenge

The challenge is an element on the website used by the organization members to pose challenges to fellow project members, project followers, and partners – in fact all the people they want. To make it easy to contribute a clear step based process is defined setting the rules and guiding co-creation. The challenge is the easiest way for followers and others to contribute to a given project. It should attract people who would normally not take part in OSHW projects and support companies user-oriented design activities. Submitted answers to the posed challenges can be commented and voted on. This way it will be easier to validate ideas. The individual contributions, made by the community members, would be monitored and the influence shown. The process of answering the challenge is based on the Quirky and OpenIDEO process from which 3 steps are defined: Submit, Refine and Evaluate. A main difference between the Challenge and the Quirky/IDEO approach is that each challenge can be easily modified to suit all stages in product development. 1: Modifiable Challenges: How people interact with the individual challenges can be modified to suit the different needs of different projects. This is possible because the Challenge is build of building block much the same way as Apps. In some cases you only want people to comment, in others you want them to show their results and explain how they got them. You modify the challenges with a click of a button. 2: Suited for Product Development: The 3 steps are in connection with the App building blocks, used to define a series of predefined challenges relating to hardware development. These predefined challenges are guided by two themes: Inspiration and Decision. Quirky does this to some extent, but this will take it one step further. There will be different types of challenges depending on which stage development is in. For example, in concept development you could have a predefined challenge saying “help find solutions for this sub function” or “which concept is best?”, and in the test phase you could have “Help Test this” or “Help build this”. You can then start the challenge with a push of a button. For the challenge to prove truly useful the platform would have to reach critical mass. The Challenges can help to achieve this by users being able to share individual challenges, and through application integration with other platforms. The Challenge solution relates to System Administration (Co-Creation)

Ease of evaluating and validating designs

The Playground The playground is meant for non-organisation members to create their own projects focusing on development of sub functions. The idea is to keep many diﬀerent development tracks “under one roof ” and in that way keep overview of alternative solutions. By making the playground public you allow other people to create projects and stored documentation in your organizations product vault. When creating a playground project you can choose to base this project on an existing organization project. Doing so will create a shared project (you share a branch). Changes made to playground documentation will not be transferred to the main project, hence resulting in forking, but changes to the main project can be allowed transferred to the playground project. You can then choose to which extent you want your playground project to fork from the original project. You can keep some parts of the product identical while changing others in that way creating multiple versions of the same product. Using the IFD the two versions can be compared and diﬀerences shown. The figure 18 shows you see an example of how that could look.

Figure 18 - An example of comparing IFDs between two assemblies

In this example the IFD indicate that your module is interchangeable with the reference model’s module although two IF components are different. However, for this to be affective there has to be discipline and understood processes from both organization and playground project. It would be easy to imagine examples where a much more confusing picture would emerge. An interesting element of this is that the different between the structures are “measured” in terms of IF components – How many IF components do the structures share. This can be used to indicate how much two projects have forked and you will have an idea about the effort needed to integrate the products. There is an issue regarding validating that two IF components actually are identical. This issue is tried dealt with using shared database items explained in the next chapter.

CONCEPT GENERATION

Ease of following the ongoing progress of the projects and enhance traceability.

The Monitor The intention with the Monitor is to let you set up organization specific KPI’s. In all projects you want to keep overview of the project progression. If some parts of the project are not being given the focus it requires the potential is that the project will fall behind schedule. In other cases you might want to gain overview of the current issues regarding a specific product or part of the product under development. You can for example configure it to notify if one element of the product attracts the most attention in form of comments. You can also set it to notify if too many activities fall behind schedule. It uses excel like syntax to make it usable by all. Preset settings and functions can be added to help get the answers you want. The monitor is meant as a tool supporting project management through simple datamining.

PAGE

Make it possible to confi gure the level of openness to allow projects to develop en accordance with their business model.

Openness Lever The Openness Lever is a set of pre configured settings that allow easy configuration of how people can interact with documentation connected to a project. It is a form of crowd control and communication tool. The predefined setting is based on the 4 types of projects described in the research section page 27. The types are: Closed, Crowdsourcing, Open Product and Open Design. The Openness lever defines if and which documentation can be downloaded, altered, viewed, checked out, which projects are visible, which can be cloned and if you yourself wants to be seen. Setting The Openness Lever to “Closed” will hide your organization and your team from all other users of the platform. It will be as secure as if you were working on your private network server. On the other side if you set the lever to “Open Design” you will be ready for large scale co-creation, where you projects can be forked and your documentation interacted with by all other users of the platform. Newly created items and APPs will have default settings matching the overall preset configuration. The Openness Lever would make it easier for the crowd to know how to interact with diﬀerent projects. All settings can be re-configured at every level to suit specific needs. 1. Ease of fi nding information

Community Each organization is only a small piece in regard to all the activity on the platform. Overview of all organizations and networks should be created by allowing informal network creation. An organization should be able to assign themselves as being part of a community, e.g. the 3D printer community. They should also able to define which type of organization they are. They could for example imagine a HackerSpace sharing a repository. They should be able to display themselves as such. And it should be possible to write address putting a geographical location on a project supporting the creation of physical networks as well. It should be possible to make platform wide searches using keywords. The result can then be sorted and filtered. It could then be possible to find information such as – “how many projects related to this community are located near me?” Or “how many Hackerspaces are located in LA?”, Goggle search should be integrated. All this can be done on the “community” site. Here you have an overview of you network and can search all projects on the platform.

Communication

This section presents a list of know solutions use to communicate online. They should all be implemented but are not detailed here as they can be regarded as standard elements.

News feed: The news feed is similar to PODIO’s and Facebook’s. It shows recent activity. The news

feed can be filtered to only show specific news. For example if you follow a project and you only want information about a module or only see activities by a specific person. You use keywords and tags to filter. Personal Message: You can send e-mail like messages to people. People should use the news feed to ask questions, or the forum. There is nothing hindering them in using PM to do it, but tutorials and guides should encourage use of forum and news feed. Chat: You can how public or private chat rooms. An existing application should be integrated, e.g. IRC Forum: Forum threads should be tagged to relevant items and documentation to show discussions of these related elements. Like the discussion tab on wiki pages. Video Conferencing: People can hold online meetings using online video conferencing. An existing application should be integrated, e.g. BigBlueButtom. Blog: Blog is an important feature in open source projects. It lets you get an overview of recent activities and considerations. A facebook like blog should be implemented showing big events chronological. Important notification should be added automatically while people could still make posts. I should show a bigger picture a than the news feed. Every project could have a blog being summed up in an organization wide blog.

D eta i li n g the c oncep t Now the individual solutions have been presented. In this section the solutions will be detailed and synthesized following some overall themes. How to define product structures in the system and how to create and link documentation to that structure, was the main focus of the detailing. The reason being that this is seen as the backbone of the concept. If this does not work the concept will have little value because almost all other elements depend on it. That said, what sets DeDoCu apart from a traditional PDM systems is it Co-creation elements and its ease of implementation. Based on use scenarios three overall themes was defined to structure the detailing process: “Product Data Management”, “Project Management” and “Co-Creation”. A case analysis of a user-oriented development project “The Strong Hand”, was carried out to support the creation of use scenarios, see appendix 15. The case analysis was done by studying project documentation and having discussions and workshops with the projects lead developer, Peter Rosenbech from IPU, and PhD Hans Peter Bruun from DTU Mekanik, see the full analysis in appendix 15.

A user interface mock-up was also created (see next page). This muck-up was created to illustrate “How can you actually use the product?” and give the concept visual appearance. In total 75 individual muck-up pages were created to present how the concept could be used through the diﬀerent development phases, running from early planning, to test and refinement. Snap-shots of this can be seen in appendix 8. The second way overview was gained was by defining a conceptual overview of relations between database objects, using UML diagrams. The figure to the left shows the final version were the classes have been grouped into systems. You see that the “assembly” is the core element, being part of all systems and being the element to which most documentation is linked. To cope with the design paradox, flexibility vs. ease of use, the approach was to define two “views”, a simple and a advanced. This is tried achieved by having predefined “sets” of settings communicating few options, while all options and configurations can be achieved in the advanced settings. This approach is used in several solutions. Now the concept will be detailed.

User Interface Muck-Up

PAGE

DeDCu o

(This is a project development page)

JOHN JOHNSON My account

Organisation

Start Organisation

The Strong Hand The Strong Hand

ADMIN

Revesion 3

INVENCON LAYOUT

Invencon

Following

Download

Arthritis Group

COMING ACTIVITIES

Mech - hand

COMMUNITY

IFD

EDIT

Box

Gripper Button Digital Physical

Fingers

MMI

Casing

Interfaces Wrist

Power

Drive Quick release

Actuator

Control

Othoses

EXPLANATION BOX Hold the mouse over the feature you want explained (note: not everything is explained)

Functional Breakdown User Survey Market Research Inactive projects Two material extrusion Improve mobility Lower weight

DATE CARD Name: Item ID 000000534 Description: Gripper fingers Parts: Top finger Introduction Buttom finger Cam

Power

Design Contest ID 354 ending in 1 day Test of submodule ID 354

MOST RECENT ACTIVITIES Model X specification update Model Y module Y,1 update ECR ID 54364 approved

Project Plan

Created: 5/3 - 2012 Responsible: George Market Projec Check out by: Jenny research plan Where used: Gripper, the strong hand Status: Concept

Technology

Glove

Model X, module X team open meeting

view: all systems The strong hand - Gripper - Button - Sensor - Casing - Fingers - Top finger - Buttom finger - Wrist - Frame - Cam - Box - Drive - Actuator - Motor

Arthritis Mechanical Hand

Playground Challenge APP Vault Forum Product Vault Idea Competetions

Aktivities

Issues

Requirements

Worksheets

Add App EDIT

Funding

Interfaces

Related Discussions Interfaces I want that I need help Are we doing the right thing? Lets have a meeting Playground

TASKS Review wiki update (model X, mission) Change part number ID 253 Send Susan new things

CALENDER

Comment (Link to forum) CONCEPT GENERATION

PAGE

DeDCu o JOHN JOHNSON My account

Organisation

Start Organisation

(This is a project development page)

The Strong Hand The Strong Hand

ADMIN

Revesion 3

INVENCON

Project settings

Playground LAYOUT

Invencon

Following Arthritis Group Mech - hand

Product structure settings

Assembly ICON

COMMUNITY Arthritis

EDIT

Interfaces

Mechanical Hand

Hold the mouse over the feature you want explained (note: not everything is explained)

App Category

Introduction

Project Plan

Aktivities

Projec plan

Funding

Functional Breakdown User Survey Market Research

Issues

Requirements

Worksheets

Technology

App Entries

Interfaces

Related Discussions

Add App

App category

settings Interfaces I want that I need help Are we doing the right thing? Lets have a meeting Playground

Comment (Link to forum)

PAGE

MOST RECENT ACTIVITIES Sub aktivities: Lorem ipsum dolor sit

ECR ID 54364 approved

Market research

Two material extrusion Improve mobility Lower weight

DesignLorem Contest ID 354 ending in 1 Description: ipsum dolor sit amet, day adipiscing elit, sed diam nonconsectetuer ummy nibh euismod tincidunt ut laoreet Test of submodule ID 354 dolore magna aliquam erat volutpat. Ut

amet, consectetuer adipiscing elit, sed Model X specification update diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutModel Y module Y,1 update

EDIT

Inactive projects

Open App Entry

meeting

IFD Overview

EXPLANATION BOX

APP Vault Forum Product Vault Challenge Blog

Model X, module X team open Interfaces Module 1 Module 2 App building block Module 3 IF Component IF Component

Mechanical

Navigation panel

Duration: 15th of Maj to 4 of April Progress: 50 %

TASKS Responsible: Jenny Tags: Idea Compettition Aktivity Review wiki update“Interfaces”, (model X, mission) “Tecknology”, Worksheet “Interfaces”, Worksheet “Gripper concepts”, TutorialID “Interfaces”, InterChange part number 253 face “Box/wrist” Send Susan new things

CALENDER

D etai l ing t h e s olu t i on s

The detailing of solutions was done using themes derived from use scenarios. There are three overall themes: “Product Data Management”, “Project Management” and “Co-Creation”. The Product Data Management section will describe how to define product structures by using the IFD, and how to create documentation and workflows using the APP. Then the Project Management section will describe how to use the App to create project plans, and how to apply the Monitor to create project KPIs, finally to show how to use Project Masters to create a framework for each project. Last will the Challenge and the Playground be described to illustrate how DeDoCu supports Co-creation and community-based development. This final section will also explain how DeDoCu can be used in distributed product development, and the creation of networks. First, however, will the fundamental building block of the concept be described - the database items (objects).

Database It e ms ( obj e cts ) The following lines constitute a short description of how you can use database classes and items based on how they are described using Solidworks Enterprise PDM (see appendix 16) Classes are the element used to create the systems data structure, for example the generic elements in a product structure. One can think of an class as a table, e.g. “Assembly”. An object or item is an instance of a class, with its attributes defined by the class, e.g. “Assembly ID”. When defining a product in a PDM system one creates database items acting as placeholders for metadata and hence consist only of metadata. One can then link files, or other items to that item, based on the defined object. Linking items will create item structures, which can be defined to follow a given product structure. You can create folder items which can group a range of items. For this system a project is an Item folder. A new type of Item is defined here which is not described in Solidworks Enterprise PDM. The Item is called Shared Item. It is an item that can exist in two folders concurrently. A master/slave relationship can be defined in regard to which folder will “control” the item and linked documentatoin. If the item or item’s linked documentation is “accessed” through the master folder and changed, the change will be “transferred” to the other folders, and the shared relationship remains. If the shared item or item’s linked documentation is accessed through a slave folder and changed, a new item is created in the slave folder (changing Item ID), and the

shared relationship is broken, leaving the previous Item and linked documentation in the original version. The changed file can then be sent for review to the owner of the master folder (push changes), who can choose to implement the changes to his file or simple re-link the item in the product structure (pull changes). The later will re-establish the shared relationship. When linking an item, the item IDs of possible child items will be matched and non matching items would be overwritten. Parent item would remain and revision numbers would clarify interchangeability. In Solidworks PDM files can be shared and linked to two or more items. I see benefits in also being able to share and link two or more items, because it will allow you to compare products structures in diﬀerent item folders (projects) using the IFD, without any files are linked to the items. This shared item is used when describing the playground solution, how to create platform projects and creating organization networks. Is has to be noted that to which extent this item can be created is not fully known. Current feasibility studies, mainly talks with people with knowledge in database technology, indicates that it should be possible. The Shared item should allow for “where used” searches and overview. Many current PDM applications oﬀer this function but it has not been possible to determine how the function actually works in these applications. This is the reason why the Shared Item has been defined for this project. A shared Item can in some ways be compared to a shortcut on your desktop.

D ATA C A R D S Data Cards display metadata about files, items and item folders, and are linked to each of these respectively. A data card is created and stored in the vault whenever an item is created or a file added to the vault. The data cards can be accessed through their linked element, for example will clicking an element in the IFD (an item) give access to its data card. When checking in a modified file or item a new version is created which can be given a revision number in the data card, either manually or automatically by a defined workflow. A change of revision number can be set to ripple up or down a product structure to related items and files. The revision function has not been detailed, but should follow standards procedures in current PDM solutions and standard numbering schemes and definitions for when a new revision number is assigned, for example when interchangeability is lost between two versions.

CONCEPT GENERATION

PAGE

P roduc t Data M a nageme n t

DeDo o Cu Social PDM

DeDoCu Social PDM

JOHN JOHNSON

- t he f i r st th e m e

My account

Organisation

Start Organisation

Invencon

How to de f i n e produ c t st ru c t u res

Following Arthritis Group

Define Product

View full screen

IFD EDITOR

DRAG AND DROP

USE: Drag a box into the IFD overview panel to create a new item. Attach a file to the ITEM by clicking the box and chose: Add File. Change metadata by clicking the box and chose: Open Data Card. Dropping a box on an existing box will request an answer: Add as ITEM CHILD | Redefine ITEM

Top level item The strong hand Define openness

Mech - hand

The following will describe how product structures can be defined in the system using database items. The structure is based on the following definition: Assemblies can be a part of project and/or other assemblies. Product, Modules and IF components all are specializations of an assembly. An IF component can also be a specialization of a component and relates to a system. Interfaces relates only to IF components. Components can be part of assemblies. A CAD part can be part of a Component and CAD assemblies. CAD assemblies are part of IF components. Before going into detail with how the structure is created, it has to be noted that this approach is based on definitions. There is not one right way when defining modules and interface components, and even though the underlying database structure is the same, there are many diﬀerent ways to define a product using the IFD. For the sake of example two IFDs, in various details, have been drawn for a simple product – a box (see figure 19)

Figure 19 - Two examples of a IFD for the same product - a box.

The box has feet and handles. In the simple version the 3 three subassemblies; Box, Handle and Foot, have been defined as interface components, the interfaces shown by a line with a dot. In the more detailed version the 3 subassemblies have been defined as modules, where the parts are interface components. In the first case the IFD is an abstraction from the BOM, in the second it is a replication. This is of cause a hypothetical example. To which extent the IFD need detailed depends on the type of product being developed and in which state the development is. Tutorials should be available on how to use the IFD based on theory, for example the module drivers (ERIXON 1998). Hopefully a community will develop around the platform itself that can help achieve this.

PAGE

Advanced

COMMUNITY Mechanical Hand

PRODUCT

Create Assembly

The strong hand

View: IFD | BOM

Create Product

EXPLANATION BOX Hold the mouse over the feature you want explained (note: not everything is explained)

Create component

Module

Assembly

IF Com.

IF Com. Variant

IF Com. Future

IFD overview panel

Create Module Create IF component

Product Create Items by File

List of Interfaces Gripper

Box

Mechanical Electrical

Define System

Control Signal

Variants Deriviative

Orthosis

Define new interface

Systems Mechanical Electrical Control Signal Finish

Define new system USE: Activate system category and click the IF component belonging to the given system

Figure 20- UI Mock-up of the IFD editor used to define product structures. See appendix 17, page 34

A drag-and-drop GUI is envisioned utilized to support the definitions of product structures graphically (similar to BOM), see figure 20. This could be useful in early development phases (Item-Based design), for simpler products, or if data cannot be imported as XML (or other mark-up language). You simply drag a box from the IFD Editor Panel over into the IFD Overview Panel. This will create an Item to which you can link files or other items. Depending on which box you chose the created Item will have diﬀerent behavior and attributes, based on the IFD definition. There are three types of links between items: Shared, Parent/child and Interface. Interface links between items can be created by dragging in interfaces and joining them to the boxes. Dragging one box over another will create parent/child relationships, also used to create BOM structure. Shared Items are created by clicking the box and choose “link existing item”. This will let you browse the Product Vault, and choose the relevant Item, see figure 21. This is the same way files are linked. When creating items you can also push the buttons on the left, the more traditional way. Components Items will have to be created in the BOM view, because Components are not “represented” in the IFD – only IF component are. The product structure could also be defined using existing CAD files in the vault. Doing this will create linked Items for all files, but creating only assembly and component items. Interfaces and specializations would have to be defined afterwards. The last way is to import XML created from an externally created IFD, e.g. in MS Visio.

When creating interface links (interface items), you can do so using predefined interface types, such as: Mechanical, Electrical, Mechatronic, Temperature, Control, Power, Monitor, Spatial, Signal etc. (Bruun & Mortensen, 2011). A graphic IFD product structure, embedded in the platform, could functions as a vehicle of communication between developers, and as a navigation tool for navigating the product related pages. Just as a product structure tree is used today. But the IFD put more focus on modules, interfaces and systems. The IFD would be online and always accessible. This would make updating the IFD easier and a more continuing process. Access levels should oﬀ course be defined. Because documentation is structured based on the product structure, a fixed generic product structure would also streamline how documentation is structured throughout the platform. This can be seen as both an advantages and disadvantages. As mentioned could the IFD act as a navigation tool to navigate the product related pages. It would do this in connection with the BOM overview. When an assembly is linked to a project (item folder) the IFD of that assembly would be shown on the project pages, see figure 22. The idea is to let the levels of the project follow the levels in the IFD. Navigating through the project would resemble navigating using the product three in a CAD program. If you for example have linked an assembly to a project, then the project would have as many pages (sub folders) as there are sub assemblies in the product structure. If you then link a new child item, for example by defining a new IF component, then your project would automatically gain a new page – a new sub folder to which you can relate documentation. Deleting the item of the IF component would delete the link and you would have a “homeless” app entry or file in you Vaults. The App entry would be easily found by going to an App Category in the App Vault and filter for unrelated App entries. The file found in the Product Vault. (Note: The local application handling managed files would consist of items and files checked out from the product vault, the app entries would have to be accessed online through the browser)

DeDo o Cu Social PDM

DeDoCu Social PDM

JOHN JOHNSON My account

Organisation

Create product

INVENCON

Import Product

Playground

Start Organisation

APP Vault Forum Product Vault Challenge

Invencon

Filter

SORT BY : Date | type | Name Following

The strong hand - ASSY

The strong hand

Arthritis Group

Name Describtion Version Check-out Created Project

Advanced Search

Mech - hand

COMMUNITY Mechanical Hand

VIEW

CHANGE LOG 6/3 - did this 9/2 - did that 10/1 - did nothing

The stong hand - ASSY Gripper - ASSY Box - ASSY Orthosis - ASSY

EXPLANATION BOX

Fingers - ASSY Wrist - ASSY

Hold the mouse over the feature you want explained (note: not everything is explained)

Screw - PART

EDIT

The stong hand -drawing Gripper - drawing The strong hand - Layout model

Compare: IFD| BOM View Systems

Figure 21 - UI Mock-up of the Product Vault where all structure items and CAD files is stored. You can define a new product by clicking the green button at the top or you can search existing products. Here the top level structure item of the Strong Hand has been chosen. See appendix 17, page 35. (This is a project development page) DeDCu o JOHN JOHNSON My account

Organisation

Start Organisation

The Strong Hand The Strong Hand

ADMIN

Revesion 3

INVENCON Playground LAYOUT

Invencon

Following

Download

Arthritis Group

IFD

EDIT

Box

Gripper Button Digital Physical

Fingers

MMI

Casing

Interfaces Wrist

Power

Drive Quick release

Actuator

Control

Othoses

EXPLANATION BOX Hold the mouse over the feature you want explained (note: not everything is explained)

DATE CARD Name: Item ID 000000534 Description: Gripper fingers Parts: Top finger Introduction Buttom finger Cam

Inactive projects Two material extrusion Improve mobility Lower weight

Technology

Power

Design Contest ID 354 ending in 1 day Test of submodule ID 354

MOST RECENT ACTIVITIES Model X specification update Model Y module Y,1 update ECR ID 54364 approved

Project Plan

Created: 5/3 - 2012 Responsible: George Market Projec Check out by: Jenny research plan Where used: Gripper, the strong hand Functional Breakdown User Survey Market Research

Glove

Model X, module X team open meeting

view: all systems The strong hand - Gripper - Button - Sensor - Casing - Fingers - Top finger - Buttom finger - Wrist - Frame - Cam - Box - Drive - Actuator - Motor

Arthritis Mechanical Hand

APP Vault Forum Product Vault Idea Competetions

COMING ACTIVITIES

Mech - hand

COMMUNITY

To which extent the IFD will fit the need of established companies has not been fully investigates. It will perhaps prove too rigid a framework and larger changes could be hard to implement. The IFD framework is however being implemented in a large Danish company on trial basis at the moment, which indicates it’s usefulness. An important question to ask is “What happens if a structure item is deleted?” Then linked documentation would be floating in the system. The central object is the assembly. Having a central object as here can be risky because deleting such an item would create much floating documentation. Corrupted links are a problem in many database systems and can result in many resources needed put into controlling it. For now these issues will not be dealt with, only to say that it is believed that recommended tags could be a way of quickly restructuring data, and that inspiration on how to deal with these issues could be found in already existing solutions, that all face the same problems.

PRODUCT VAULT

Aktivities

Issues

Requirements

Worksheets

Add App EDIT

Funding

Interfaces

Related Discussions Interfaces I want that I need help Are we doing the right thing? Lets have a meeting Playground

TASKS Review wiki update (model X, mission) Change part number ID 253 Send Susan new things

CALENDER

Comment (Link to forum)

Figure 22 - UI Mock-up of the project front page. Here you can also access and configure the product structure of the linked product by editing the IFD. Pushing an element in the IFD will take you to a new page. See appendix 17, page 45

CONCEPT GENERATION

PAGE

72 PAG E

How to c re ate a n d u se projec ts ( Item Folder s ) Creating projects is another aspect of PDM relating to Program Management but also Product Structure Management. A project is, in this concept, an Item folder containing the assembly the project aims to develop, and all child items and linked documentation. A project can only have one main assembly related to it, but an assembly can be related to several projects. This allows you to have several development tracks focusing on developing diﬀerent versions, or elements, of the same overall product. You can say that when creating a project you create a development branch where you fork designs to the extent you wish it. A project is created on the development page by pushing the button “Create new project” ,see figure 25. This will open the project creation panel. From here you can create three variations of projects: Single project, Linked Project and Shared Projects. • Single Project: A single project is a project containing the assembly the project aims to develop and all child items and linked documentation. A single project has no shared elements or links to other projects. (Item folder with no links) • Linked Project: A linked project is a single project which has been linked to another project making both projects linked projects. A project can be linked to several projects. The two projects do not need to have any shared elements or other relations. They are linked for search, overview and communication purposes only. (Linked Item folder) • Shared Projects: Shared projects share assemblies, meaning they contain shared items. See the description of shared items in the previous section. Shared projects are also linked projects. Shared projects have a master/slave relationship. You can have projects were only part of the contents is shared. (Shared projects are Item folders containing shared Items)

You can also create share projects by cloning the project. This is done by other organizations that do not have direct access to your Vault. You can clone a project by clicking the “clone” button on the project’s icon. An organization can define to which extent they allow other organizations to clone their project. If you do not allow cloning of all your projects you would be a private organization and would have to pay for using DeDoCu. At any point you can “release” a project, meaning it will be shown on your organizations front page. P l atform P rojects

This is an example of how to use shared projects to create platform projects. Platform projects can allow high product variety while keeping the system complexity low. The product platform approach is common practice in many large companies, for example in the car industry. An OSHW company such as Arduino also benefits from oﬀering a “platform” product. The following will illustrate how you can use the system to conform to the product families’ framework of Ulf Harlou (2006) see figure 23. The same framework the IFD formalism of Brunn & Mortensen (2011) is based on. The following is again based on definitions. A platform can be defined as: “A structural description of a product assortment, product family or a product. A platform is an instance of an architecture that only includes existing standard designs and their interfaces, i.e. interfaces among standard designs, interfaces among standard design and design units and interfaces among standard designs and/or the surroundings.” (Harlou 2006)

You create single projects by choosing to link an assembly, not linked to any other projects, or by changing Item ID of all shared Items defined as IF components in the slave project (Either by continuously changing linked files or by changing revision number and let the change ripple up the product structure). You create linked projects by tagging the related project, in the single project’s setting or by drag and drop in the project overview on the development page. You create shared projects by choosing to link an item already linked to another project. This can be done when creating the project or later in a project configuration panel, if you for example wants to re-establish a broken shared relationship. This will overwrite the item and linked files in the slave folder being shared.

Figure 23- Illustration of a product platform (Harlou 2006)

CONCEPT GENERATION

Without going into too much detail, an assembly in this system could be defined as a standard design by the team members, and be the assembly that is shared between product and projects. The assembly could have the specialization module to support this definition and emphasize focus one documenting and controlling IF components and interfaces. Here is a short walkthrough relating to this, see figure 24. An assembly is created in the system using the IFD editor in the Product Vault. Let us call the assembly “module A”. A project is then created to which this assembly is linked. The project could be called “platform A”. The project is completed and module A, IF components, interfaces and components are developed and all documentation linked. A new project is created called “Project AB”. Module A is also linked to project AB and shared items are created in this new item folder. Platform A is set as the master folder. From Project AB the product structure configuration of module A is accessed using the IFD by pushing edit IFD, on the front page of the project. Here a new assembly is created, specialized Product, and called Product AB. Module A is linked to Product AB as a child item. Another assembly is created, which is also specialized module, and called Module B. Product AB now consists of modules A and B. Module B is developed. The same procedure is carried out for Projects AC an AD. Because module A is a core module, access to Project A is restricted (Item folder access). By comparing the IFD of products AB, AC and AD you get the “Family Platform” as all elements are standard designs (modules). If some modules had not been developed (future standard designs) or some products contained subassemblies not defined as standard designs, but design units (designs unique for that product) you would get the Family Architecture.

PAGE

might be necessary. You could for example allow forking to occur on the platform, here module A, creating two modules A1 and A2. The product based on the platform would then be A1B and A2C. For the sake of example this is all very simplified. Creating product platforms can have the drawback that it maintains a certain development track. This is especially the case when creating business based on a platform. Radical innovation would often entail changes to the overall product architecture (Smidt, 2009) why more uncertainty would usually accompany the launch of a radically innovative product – the more complex and expensive the product is, the higher the risk. The same phenomenon is seen in OSHW communities, for example the RepRap community, where people try to adapt to the dominant designs. Introducing more stable and well defined platforms to such a community might amplify this eﬀect, resulting in less radical innovation, although strengthening incremental innovation. But one can ask what real radical innovation has come from the RepRap community that was not already presented by the introduction of the very first RepRap. I believe that OSHW in general could benefit from the idea of product platforms and modularization. I actually believed that it is the only way for community-based OSHW development to overcome the challenges of high cost of integration facing this type of development, and for OSHW to match the success of OSS. DeDo o Cu Social PDM

DeDoCu

(This is the development overview page)

Social PDM

JOHN JOHNSON My account

Organisation

Start Organisation

DEVELOPMENT

ADMIN

INVENCON Playground

Projects (development tracks)

APP Vault Forum Product Vault Challenge

Invencon

Following

COMING ACTIVITIES

Arthritis Group Mech - hand

The Strong Hand

COMMUNITY Arthritis Mechanical Hand

The strong hand 2 generation: This development track focuses on next and future released of model x. They next release is going to etc...

Model X, module X team open meeting

3 Generaion

Design Contest ID 354 ending in 1 day

The strong hand 3 generation: This development track focuses on next and future released of model y. They next release is going to etc...

Test of submodule ID 354

MOST RECENT ACTIVITIES Model X specification update

EXPLANATION BOX Hold the mouse over the feature you want explained (note: not everything is explained)

Figure 24 - Creating a platform project

All this is based on definition and you would have to know the definitions to derive such information directly from the IFD. This scenario is based on an Item-based approach. You could have created the same situation through several other scenarios. It is assumed that many conflicts and broken links would occur during such a process. Some conflict

Model Y module Y,1 update Inactive development tracks Related development tracks Introduction

Roadmap

Standards

Tools

Process

- Description: Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie conseq - uat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id qu

How-to

Add App EDIT

Related Discussions New standard Change standard? Where is the X standard I don’t like standards Why standards Playground

ECR ID 54364 approved

TASKS Review wiki update (model X, mission) Change part number ID 253 Send Susan new things

CALENDER

- od mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus legentis in iis qui facit eorum claritatem. Investigationes demonstraComment (Link to forum)

Figure 25 - UI Mock-up of the DEVELOPMENT page. Here you have overview of the organizations’ projects. Clicking the Project icon will take you to the project’s front page (top assembly). See Appendix 17, page 37.

C reatin g and deve l opi n g d o c umen tat ion The App is the central element of creating non-CAD documentation. The following will describe the detailing and use of the App. It has to be noted that the App described here “The DeDoCu App” is heavily inspired by the PODIO App (see appendix 9 for snapshot from PODIO.com) You can choose to either fetch a predefined App from the DeDoCu App Centre or you can build your own App from scratch using predefined building blocks. An App is stored in the App Vault, from where you can add the App to individual project pages (items folders). An App has two elements: An App Category and an App Entry. An App Category is a “folder”, the App Entry a “file” in the folder. From now on App refers to an App Category. You can gain an overview of all you Apps in the App Vault or, you can access app entries tagged to product structure items on the relevant projects pages. The app has two general purposes. One is creating online documentation and provide overview and structure documentation. The second is defining, monitoring and controlling workflows. How you can use the App for these two purposes are describes here. First, creating online documentation. See UI-mock up on page 68 for a visual overview of the app elements, and see appendix 9 to get an overview of how the app looks on PODIO.com. C R E AT I N G O N L I N E D O C U M E N TAT I O N U S I N G A P P S An App is built from 12 possible building blocks using a drag and drop GUI. The example (see figure 26) shows an App called Issues build using 4 types of blocks. The building block create a template showing what need to be defined when creating an entry to that App. Descriptions of the other building block can be found in Appendix 11. The building block “category” has been given special focus and will be described further later on.

Figure 26 - Example of what building blocks a App category can consist of PAGE

Advanced settings can define how people can interact with the App and if tasks and notification should be created when the App is used or altered. The starting point for rethinking PODIOs building blocks was an analysis of the RepRap Wiki and DS/ISO 29845 – Technical Product Documentation – Document Types. DS/ ISO defines 45 types of technical documentation used in engineering. The conclusion on the analysis was: • All documentation created in CAD applications should be linked directly to the product structure Item in the Product Vault. App entries can then be made which link to that documentation using tags. • Flow and Block diagram need to be created in external application and attached as ﬁles or, new building blocks created to make these kinds of diagrams. The same GUI used for the IFD could maybe be used. • Spreadsheet application should be integrated as a building block. (This is under development by PODIO) • All other non-cad documentation could be generated using Apps. The App is seen especially useful during the turbulent phases of development where documentation is frequently changed. Here is a quick example of how you can use the App. - In the concept phase of a development project much documentation is made by hand. In the Strong Hand Case worksheets where used to structure this kind of documentation. To adapt to this approach a “Worksheet” app could be created. The App should be structured according to the worksheet template used. For example: title | description | date | creator. The App building blocks used will be: text, text, date, contact, reference and upload file. Uploading a file (scanned worksheet) would create a copy in the Product Vault and put in your local folder with managed files. Uploaded non-CAD files will then be managed and version controlled similar to Dropbox.com. The most important handmade documentation and pictures would perhaps be added to presentations for meeting, as was the case with The Strong Hand project. A “Meeting” app would then be used to store and categorize meeting information and documents such as presentation and minutes. The content of an App entry can be access online by people permitted. They can change the content, for example add to a text box or attach a new file. In some cases you would want the App entry to be version controlled so content could be restored or changed content could be peer-reviewed before being integrated. Exactly how this is implemented is not detailed.

One of the advantages the DeDoCu App is seen to have over wiki pages and the PODIO App is that you can link documentation to items in your product structure. Linking App entries to the product structure will create both a flat and hierarchical document structure. An central function when linking is the use of “recommended tags”. When setting the cursor in a field meant for tags, e.g. the App reﬀ building block, and start writing, the system will show a list of suggestions based on what is written. This is the same method used when tagging people in facebook. You can gain an overview and browse all documentation related to a product on the front page of a project, and by diving into the product structure you automatically filters out irrelevant documentation only showing what is relevant for that particular part of the product. Meaning, App entries tagged to a parent item, is not show in a project page related to the child item. It is exactly like opening folders on your desktop only that all the files in the low level folder are also accessible in the top level folder. You can gain quick overview in the top level folder by clicking “Show only entries with direct tags”, or by filtering, sorting or using keyword search.

If you instead want to find information running across projects, for example, how many activities are related to you? You could then go to the APP Vault where you open the Activity App (category folder). You search by keyword “you name”. You then see all the activities where you are mentioned. If you then want to find the most important activity you are responsible for, that need your attention, you filter by “responsible” (tag), “High Importance” (App category) and sort by “due date”. Perhaps a simple sort by “due date” would have been suﬃcient.

For example, you need to find a certain technical specification for an IF component. You then use the product tree or IFD, from the project front page to quickly go the page of the IF component and open the “Specification” app. It shows just the specifications related to that component. At the same time you have overview of what other documentation categories are related to this component by looking at the other Apps at the page. See figure 27 for a illustration of finding information.

A problem with Apps can be if one wishes to create hierarchies not guided by the product structure. An example could be specifications. There a many forms of specifications that does not necessarily follow the same template. If you want to create a single category called specifications you might have to compromise on template structure to fit in all kinds of specifications and use categories to structure them. Instead you could create a category for each specification type but them you might lose overview of all specifications. Looking through the diﬀerent kind of documentation types this is however not seen as a big problem.

An alternative would be to use keyword search on the organization front page top right corner “Name of IF component” “Name of Interface”.

In all Apps you can see the tagged forum threads in the comments overview panel. The comments overview panel shows the most active and rated discussion relating to this app entry taking place in the forum (depending on people tagging the discussions). Clicking it will take you to the tread in the forum. In this way you have documentation and related discussion accessible from one point. On the RepRap wiki, wiki documentation being discussed are often linked in the forum threads (if such documentation exist), but rarely the other way around.

Figure 27 - finding information workflow

CONCEPT GENERATION

PAGE

When adding the “monitored category”, he adds a predefined rule to the state “closed” called “depended state”. He does so by clicking “add rule to state” and chose from the list of predefined rules. He fills in the blank using recommended tags. So the rule looks like this:

76 PAG E

If an entry to “Activities” is tagged to an entry in this app and “Status” in related entry “is not” “completed” then state cannot be set.

C reatin g workf l ows w i t h t he A pp The previous section explained how to create documentation. Now the second important function of the App will be described - how you can use the App to define, monitor and control workflows. This will be done by first explaining the use of the App building block “Monitored Category”, after which the use of the Apps “Issues” and “Activities” is describes in connection with change management processes.

App: Activities

M O N I T O R E D C AT E G O R Y A “category” building block, as in PODIO, can allow you to categorize App entries, for example: Type 1, Type 2. Type 3, or: Stage 1, Stage 2, Stage 3. You can use it to, for example, declare that a document is under review and is awaiting approval. Any with write access to the App can change between the category types of an entry and settings can allow the App owner to be notified if an entry is changed. I propose being able to define rules for changes of category type, and to relate these rules to the categories of other Apps. You would define such rules in the App’s settings see figure 28

Activity Title: Fix This Status: Not started, In progress, Completed Responsible: George What should be done?: this and that Related documents: “Issue – This is a problem” Related Product: “Module 1”

App: Issues Issue Title: This is a problem Description: The problem happened like this Status: Proposes, Accepted, Resolved, Closed Rule

Responsible: Jenny How was the issue resolved?: Related documents: “Activity – fix this”, “Specification – 10 units” Related Product: “Module 1”

Figure 29 - examples of App entries to App categories “Activities” and “issues”

Text: Title Text: Description Monitored Category: Status States: Add state Proposed Accepted Resolved Closed

Add rule Add rule Add rule Add rule

Rules

IF an entry to > App Appreff reff < is tagged to an entry in this app

Depended state Notify if Change state if

depended monitored monitored category condition AND depended category in related entry “condition”

Mandatory

Whenever you add a building block you have to define it. When using the “category” Rule syntax: you defi neentry its name, the isstates theentry category, and if you want to attach a rule. You IF an to “App reff” taggedof to an in this app monitored category” in related entry of depended monitored defineAND the“depended rule based in a set syntax. Predefi ned“condition” standard“state rules are defined to choose category” then state cannot be set. from, making it easier for the users. The standard rules are: Depended state, notify if, change state if. The following will present a short use scenario using the Depended state rule together with the Apps activities and issues.

“state dependedmonitored monitored category” then state cannot be state of depended category set.

Fill out the boxes

Description on how to use

Contact: Assigned to Text: How was the issue resolved? App reference: Related documents Product reference: Related product, module or part Heavily inspired by Podio.com Figure 28 - Monitored Category App building blocks

Two app entries to the apps Activities and Isses has been made as illustrated in figure 29. You see that the Activity entry “fix this” is related to the Issue entry “This is a problem”. Someone has proposed an issue directing focus to a problem. The issue has been accepted and an activity was created to resolve the problem. The activity is in state “in progress”. To make sure the issue is not closed before the problem is actually resolved and the activity completed, a rule is defined for the state “closed”. You cannot close the issue before the activity is set to “complete”. The predefined rule used is the Depended state which follows the syntax: IF an entry to “App reﬀ ” is tagged to an entry in this app, AND “depended monitored category” in related entry “condition” “state of depended monitored category” then state cannot be set. When defining the rule you chose from the list and fill in the boxes using recommended tags. When choosing an App Reﬀ, the system knows which categories the App has, when choosing the category the system knows which states the specific category has and condition can only be “is” or “is not”. So the rule for this specific case would look like: If an entry to “Activities” is tagged to an entry in this app and “Status” in related entry “is not” “completed” then state cannot be set. If a new entry to activities is tagged to the entry in issues, then this too would have to be completed before the issue could be closed.

CONCEPT GENERATION Social PDM

DeDoCu JOHN JOHNSON My account

Organisation

The Strong Hand

LAYOUT

COMMUNITY

Resubmit

Delete ECR

amet, consectetuer adipiscing elit, sed

laoreet dolore magna aliquam erat volutModel X, module X team open meeting

EDIT

Modules

Mechanical Hand

Responsible: Jenny MOST RECENT ACTIVITIES

Name: Description Created Drawings Responsible Where used

EXPLANATION BOX Hold the mouse over the feature you want explained (note: not everything is explained)

Design Contest ID 354 ending in 1 day Duration: 15th of Maj to 4 of April Test of submodule ID 354 Progress: 50 %

Module 1 Module 2 Module 3

Arthritis

Tags: Idea Compettition “Interfaces”, Aktivity Model XWorksheet specification update Worksheet “Tecknology”, “Interfaces”, “Gripper concepts”, Tutorial “Interfaces”, Interface “Box/wrist” Model Y module Y,1 update ECR ID 54364 approved

Introduction

Project Plan

Issues

Aktivities

Requirements

Worksheets

Add App EDIT

Market research

Projec plan

Interfaces

Funding

Technology

Inactive projects Two material extrusion Improve mobility Lower weight

Related Discussions Interfaces I want that I need help Are we doing the right thing? Lets have a meeting Playground

Functional Breakdown User Survey Market Research

TASKS Review wiki update (model X, mission) Change part number ID 253 Send Susan new things

CALENDER

Comment (Link to forum)

Verify changes

Figure 31- a project page showing including the apps “Activities” and “Issues”. See Appendix 17, page 38

Submit ECO

Implement changes

Form CRB 1

Playground Description: Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonAPP Vault ummy nibh euismod tincidunt ut laoreet Forum dolore magna aliquam erat volutpat. Ut Product Vault Competetions Sub Idea aktivities: Lorem ipsum dolor sit

COMING ACTIVITIES diam nonummy nibh euismod tincidunt ut

Mech - hand

Approve ECR

Review ECR

Interfaces

INVENCON

Arthritis Group

Mark as: Rejected Duplicate Not reproducible

Submit ECR

ADMIN

Revesion 3

Following

Idea for a change

Start Organisation

The Strong Hand

Invencon

Collaboration with community Pull from design repository

(This is a project development page)

Social PDM

Implement changes

Community

DeDo o Cu

In many cases there might not be a need for defining rules, as members of smaller projects would have tight communication. But if you want to allow the crowd to access you documentation without you having to monitor their activities, rules could help guide their behavior. Another case where rules could be useful is in larger more distributed projects where the organization wants to have more control of their change management. They could want to define a specific engineering change request and order process. Figure 30 illustrates a generic ECR/O process based on best practice approach from Aras.com (Aras). The process has been adapted to a community-based approach where it is possible to involve the community in the evaluation process by inviting them to the change request board (CRB). This is simple done by inviting them to comment and discuss the issue in the forum, and inviting them to the online meeting where a decision is made. The workflow is executed by using the Apps Issues (ECR) and Activities (ECO), see figure 30 and 31. Note that the name of the app could have been anything. You could might as well have called them something ells and defined them differently. To support users in defining more advance workflows, tutorials and training should be offered (part of the business model). It is believed that current PDM solutions offer better (easier) control of workflows than what has been illustrated here, but DeDoCu is minded for smaller projects requiring less in terms of strict process control.

ECR/O Process

PAGE

People invited

Person 1 Person 2

Meeting (online)

Person 3

Playground

Activity Rejects ECR

Figure 30 - change process related to the apps “Activities” and “Issues”

Change to App making notification

P rojec t M a nagem ent - The se c on d th em e

DeDCu o

DeDCu o JOHN JOHNSON My account

Organisation

Having described how to define product structes and how to create documentation core JOHN funtionality in regard to Product Data Management, focus JOHNSON is now shifted to a new overall My account theme - Project Management. The following will describe diﬀerent element regarding this theme also relating to program management. First it will be described how to create a multileveled project plan using Apps, then how to use The Monitor to define KPIs and finally how to attach a project master to your project. The Strong Hand Start Organisation Organisation

Start Organisation

The Strong Hand The Strong Hand

ADMIN

INVENCON APP Vault Forum Product Vaulr

LAYOUT

The Strong Hand

P roje c t pl a ns

This will describe how you can use the App to create project plans. Creating a multi Following levelled project plan is something that is diﬃcult in the PODIO app. Using the DeDoCu Arthritis to Group App it is easier because you can tag App entries the product structure items, letting Mech - hand you create a multileveled project plan following the levels in the product structure. Here is an example. You create an App, let us call it “Project Activities”, and add it to a project. When making an entry to the App you define: Project name | activityIFD name | COMMUNITY description | important to (category) | start date and duration | progress | responsible | notice | App reﬀ (link the structure itemArthritis the activity is related to). This structure is Hande Strong Hand” project. As the defined based in the actual project plan Mechanical used in “Th project progress, project activities are created for the individual product elements on Interfaces each project page. Opening the Project Activities app from the projects front page (top level assembly), you see all app entries for that project, see figure. Setting the layoutDigital to Physical “table” and sorting by start date you would get a Gantt chart looking overview. Sorting by level you get overview of the activities related to the individual elements of product. Power You can then export the information to excel, creating a file in the vault, and use the data to create a “normal” project plan if you want. Making a new export would overwrite the file, making it easy to update the plan using excel references.

Hold the mouse over the feature you want explained (note: not everything is explained)

PAGE

Following

Mech - hand

COMMUNITY

Modules

Arthritis

Gripper

Mechanical Hand

Design Contest ID 354 ending in 1 day Test of submodule ID 354

MOST RECENT ACTIVITIES Model X specification update

Orthosis

Introduction

Project Plan

Project Aktivities

Issues

Worksheets

Requirements

Add App

Filter: Gripper

TASKS

Review wiki update (model X, mission)

EDIT

Functional Breakdown User Survey Market Research Inactive projects

Download

Change part number ID 253

Related Discussions

| Gripper

Send Susan new things

Do this I want that I need help Are we doing the right thing? Lets have a meeting Playground

Two material extrusion Improve mobility Lower weight

CALENDER

Comment (Link to forum)

EDIT

Gripper Figure 31- a project pageBox showing where the Project DeDCu o

Button

JOHN JOHNSON My account

Organisation

Start Organisation

Invencon

Fingers

Following

The Strong Hand

Quick release

Download

IFD

Playground LAYOUT

Wrist

Box

Gripper

EDIT

Button Interfaces Digital Physical

Fingers

Wrist

Power

DATE CARD Name: Item ID 000000534 Description: Gripper fingers

Hold the mouse over the feature you want explained (note: not everything is explained)

Quick release

DATE CARD Name: Item ID 000000534 Description: Gripper fingers Parts: Top finger Introduction Buttom finger Cam

Actuator

Glove

Othoses

Control

Technology

Created: 5/3 - 2012 Responsible: George Market Projec Check out by: Jenny research plan Where used: Gripper, the strong hand

Power

Glove

Design Contest ID 354 ending in 1 day Test of submodule ID 354

MOST RECENT ACTIVITIES

-B

Model X specification update

Power

Model Y module Y,1 update ECR ID 54364 approved

Project Plan

Created: 5/3 - 2012 Responsible: George Market Projec Check out by: Jenny research plan Where used: Gripper, the strong hand

Project Plan

Two material extrusion Improve mobility Lower weight

Drive

Model X, module X team open meeting

view: all systems The strong hand - Gripper - Button - Sensor - Casing - Fingers - Top finger - Buttom finger - Wrist - Frame - Cam - Box - Drive - Actuator - Motor

Othoses

Functional Breakdown User Survey Market Research Inactive projects

MMI

Casing

APP Vault Forum Product Vault Idea Competetions

COMING ACTIVITIES Control

Actuator

Arthritis Mechanical Hand

MMI INVENCON

Drive

The Strong Hand

Mech - hand

COMMUNITY

ADMIN

Revesion 3

view

Th -G

(This is a project development page)

Casing

Arthritis Group

EXPLANATION BOX

Parts: Top finger Introduction Buttom finger Cam

Model X, module X team open meeting

Gripper Box Orthosis

Box

Revesion 3

Challenge

COMING ACTIVITIES

Arthritis Group

Hold the mouse over the feature you want explained (note: not everything is explained)

EXPLANATION BOX

Invencon

EXPLANATION BOX

Invencon

(This is a p

(This is a sub-project development page)

Issues

Aktivities

Requirements

Worksheets

Add App

TASKS Review wiki update (model X, mission)

EDIT Funding

Interfaces

Aktivities

Change part number ID 253

Related Discussions Interfaces I want that I need help Are we doing the right thing? Lets have a meeting Playground

Issues

Send Susan new things

Requirements

CALENDER

Worksh

Comment (Link to forum)

Funding

Interfaces

Related Disc

T h e Mon itor - Proj e c t KPIs

project development page) The monitor can be set to monitor project related activities and documentation. You can

use it to define project KPIs and notify in case of possible issues. The monitor can be activated in projects settings and defined by pushing its icon on the project front page. ADMIN You can have individual monitors for each project. You define the monitorâ&#x20AC;&#x2122;s settings in the monitor configuration, see figure below. INVENCON

Playground LAYOUT

PROJECT MASTER When creating a project you have the possibility to attach a Project Master. A Project Master let you define and communicate project phases and top level activities. The project masters are defined under system administration, se figure 33. When defining a project master you follow the template: Phases | Activities | Decision Documents | rules for progress. The template builds on a classes stage gate model. The example shown in figure 33 is based on the generic product development model by Ulrich & Eppinger

APP Vault Forum Product Vault Idea Competetions

COMING ACTIVITIES

w: all systems

Model X, module X team open meeting

Design Contest ID 354 ending in 1 The strong hand Gripper day - Button Test of submodule ID 354 - Sensor - Casing - Fingers Figure 32 - The Monitor configuration panel. See Appendix 17, page 47. - Top finger MOST RECENT ACTIVITIES When applying the monitor to a project a set of predefined monitoring rules will be - Buttom finger - Wrist available to activated by a push ofModel a button, see figure 32. You can also define your own X specification update - Frame rules which can be combined to measure specific KPIs. In this case the monitor shows - Camthat more than 10% of the projects related activities are categorized as not complete (here Box the monitored category is used, described Model Y earlier). moduleNot Y,1 completed update activities could be a - Drive problem if an important deadline if coming up. The monitor also shows that more than - Actuator 1/3 of the activities, not completed, are related to module 3. This could indicate that the - Motor ECR ID 54364 approved -

heets

cussions

development of module 3 is falling behind schedule, but maybe not. Organization has to define KPIs that make sense in their specific situation. You could imagine complex rules be set to measure crowd activity based on # of comments, # of changed app entries, # of issues Addcreated App etc. Defining rules are based on excel like syntax making it accessible for all. The monitor is meantTASKS to work as a supporting tool for project managers wanting to identify possible risks. The value of the monitor depends on the context in which it is used and the intelligence of the defi ned rules. e Monitor needX,tomission) be detailed further Review wiki Th update (model EDIT before it can be truly evaluated.

Figure 33 - The Monitor configuration panel. See Appendix 17, page 48.

When having attached a project master to your project you can set the phases of the projects, in the setting of the individual project. The phase the project is in will be shown in a progress panel in the project icon, see figure 34. Pushing the progress panel will let you view the defined project master. There is no link between attached project masters.

Figure 34 - DeDoCu Project ICON

Change part number ID 253 Send Susan new things

CONCEPT GENERATION

PAGE

C o - creati on

- t he th i rd a nd fi na l t h em e Now the final theme will be presented - Co-creation. It is here DeDoCu really sets it self apart from traditional PDM and project management tools by adapting to community-based development. An important aspect of this is how to define the level of openness you want to operate under. Therefore this is briefly described first, before describing the Playground and The Challenge.

D ef i ning O p en ness and Rol e Management

Four generic roles are defined in the system: Admin, member, crowd manager and crowd. Admin, crowd manager and member are roles given to organization members. The crowd are the people not part of the organization but signed-up to the platform. Giving a role to a member set predefined access settings and notification settings to the member’s profile for that organization (He/she could be a member of another organization with a diﬀerent role). The settings for each member can be re-configured under advanced settings. The Admin have access to all. The member has access to all but system administration, depending on the access settings for projects (item folders) and product documentation (file items). The crowd manager has member access but he is also in charge of “filtering” the inputs from the crowd. Exactly what that entails depends on the crowd interaction settings. The next section will describe access settings in more detail. O R G A N I Z AT I O N O P E N N E S S The following is based on the model “Degree of Openness” presented on page 27. Using this model, four generic project categories were defined: closed, crowdsourcing, open product and open process projects. These categories are used to define four sets of predefined overall configurations for process and documentation access, see figure 35. When creating a organization you are asked to define the organizations “Degree of Openness” by setting the openness lever, much PAGE

like you set the privacy settings on facebook. This will define how the organization is visible to other users of the platform and set predefined settings for “Project Openness” and “Product Openness”. P ro c e s s ope n n e s s

Crowd Inte rac t i on S e tt i ng s . This relates to how the

crowd can interact with organization documentation and members. Can they define tasks, use the forum, chat, comment on apps, take part in challenges, create playground projects, follow the blog, etc.

PRODUCT

OPENNESS

A c c e s s s e ttings for Proje c ts a nd Produc t doc um enta tion. This relates to the how accessible you want the

Can projects be cloned, can app entries be altered, are the app version controlled, can they check-out files from the vault, etc. N O T I F I C AT I O N In some cases you want to allow the crowd to add App entries. That could for example be issues or bug-reports. In other cases you might want to allow the crowd to alter existing app entries to build on documentation – the app would then be version controlled and changes be peer reviewed. When someone from the crowd interacts in these ways, notifications is sent to the crowd managers who filters input and redirect them to the right people. Individual settings could also be set for the individual apps.

Concept v. 1

product documentation to be – the product openness.

Degrees of Openness Crowdsourcing:

Openness

Open Design: • All projects are visible

• Only released products of released projects are visible • No documentation is visible • Project cannot be cloned •(Challenge activated)

Closed: • Invisible to other users of

DeDoCu not a member of the organization

(access to development) • All documentation can be downloaded • Project can be cloned • Apps can be altered but are peer-reviewed.

Open Product: • Only released projects are visible (no access to development) • The CAD files of the project product can be downloaded. • Projects can be cloned • Not possible to alter Apps

Figure 35- Four types of projects used to define four sets of predefined configurations for a organizations access settings.

The P l ayg roun d The following will explain the use of The Playground. For public organizations the Playground is intended used by followers of the organization’s projects. To relate to “Types of Open Source Participators”, users of The Playground would be “disciples” and “elves”. The Playground would set “boundaries” and create overview of that subset of a community supporting that particular organization. At the same time the functionalities of The Playground will make it easier to integrate solutions created by the community, with the designs of the organization. The Playground is based on how networks between projects are created in OSHW communities, where a few “strong” leading projects are supported by a range of smaller projects. In the 3D printer community you for example have, RepRap, MakerBot and PrintrBot acting as leading projects. By creating a Playground project you declare yourself a supporter of an organization. In return you do not have to maintain an entire product or platform and you can benefit from the attention the organization is getting. The playground will also be a nesting area for future project spin-oﬀs, projects that might take up a leading role in the community alongside the project it originated from, as it is seen in the RepRap community. For private organizations the Playground could be a place where experimental projects could be run by chosen lead users. The playground could be a way for private organizations to create a community without having to “open up” to the world. It could also simply be a place for the organizations own developers to experiment. When creating a playground project an item folder is created in the organizations Vault, just like when starting a new project. Non-organisation members can in that way be allowed to share a part of the organization’s vault and documentation. It is possible to clone an entire organization project to the playground, so if the organization has a platform project, this can be easily shared by other community members. This allow you to focus on sub functions while making sure other parts of the design are up to date. This is done in exactly the same way, and under the same conditions, as when creating Shared Projects “inside” the organization. The only diﬀerence is that the playground project will always be the slave folder. An organization can allow projects to be cloned to the Playground without allowing other organizations to clone projects. Because the shared relationship between projects and playground project are broken and restored the same ways as inter-organisation projects, you could experience issues with interchangeability. If a owner of a playground projects checks-out an IF component, the shared relationship is broken for that component. He can then make changes to that IF component that will result that interchangeability is lost in a module level. When he

checks-in the component this loss of interchangeability will not be represented in the IFD as the module Item’s ID will not be changed. It is the playground owner’s responsibility to change the revision number of the module to break the shared relationship, and show that the modules are no longer interchangeable, same as with organization members. If other community members discovers that a playground projects proclaim false interchangeability they can down-vote the project and leave comments for others to read, see figure 36. In a community setting “interchangeability” might not mean the same as in a corporate setting and communities might allow a looser definition of the term. For example “interchangeable within reasonable eﬀorts”. Playground projects with no interchangeable parts should of cause be allowed and encouraged because interesting new solutions could present themselves, but if interchangeability is proclaimed is has to be true for the term to have value. This is for example important if someone chooses to invest resources to fabricate a design from the Playground. When you check-out an item from the playground project, the shared relationship link will automatically be broken and a new Item ID given to the Item in the playground project on check-in, even if no changes have been made to the file. They Items would then show up as “diﬀerent” on the IFD although they link to identical documentation, and you would have to re-link the items. If you want to check the whole model without breaking all shared relationships, you would have to download the files to you personal hard disk. DeDo o Cu

Social PDM

DeDoCu

(This is the Playground page)

Social PDM

JOHN JOHNSON My account

Organisation

Start Organisation

Invencon

Following

PLAYGROUND

ADMIN

Filter

Start Playground Project

Featured Projects

35 64

COMING ACTIVITIES 35 64

48 33

25 43

Model Lorem X, module X team Description: ipsum doloropen sit amet, meeting consectetuer adipiscing elit, sed diam nonummy Design nibh euismod ut laoreet Contesttincidunt ID 354 ending in 1 dolore day magna aliquam erat volutpat. Ut

COMMUNITY Arthritis Mechanical Hand

CRAZY One Playground Project: This project aims to do this. Part of this Idea Competition Created by: JOHN JOHNSON

MIME One Playground Project: This project aims to do this. Part of this Idea Competetion

Test of submodule ID 354 Created By: JOHN JOHNSON

BIGGER

MOST RECENT ACTIVITIES Deriviative of: Gripper by Invencon

One Playground Project: This project aims to do this. Part of this Idea Competetion

Who liked this: Him, Her, That Susan created Model X specification a projectupdate Who downloaded it: Jenny

EXPLANATION BOX Hold the mouse over the feature you want explained (note: not everything is explained)

Playground CRAZY

APP Vault Forum Product Vault Idea Competetions

Search By Keywords

Arthritis Group Mech - hand

ADMIN

INVENCON SORT BY : Most followers | Most likes | New

Full Screen

Tom updated Model Y module his project Y,1 update Bob removed ECR ID 54364his approved project Introduction

Deriviatives

Overview

Trends

Challenge

Description: Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum. Typi non habent claritatem insitam; est usus legentis in iis qui facit eorum claritatem. Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius. Claritas est etiam processus dynamicus, qui sequitur mutationem consuetudium lectorum. Mirum est notare quam littera gothica, quam nunc putamus parum claram, anteposuerit litterarum formas humanitatis per seacula quarta decima et quinta decima. Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum.

Add App EDIT

TASKS Review wiki update (model X, mission) Change part number ID 253 Tags: Idea Compettition “Interfaces”, Aktivity Send Susan new things “Tecknology”, Worksheet “Interfaces”, Worksheet “Gripper concepts”, Tutorial “Interfaces”, Interface “Box/wrist”

CALENDER Comment (Link to forum)

Figure 36 - UI Muck-up showing the playground. On the right a open playground project is shown. Se Appendix 17, page 41. CONCEPT GENERATION

PAGE

The C ha l l e n g e The challenge process is, as mentioned, based on the Quirky and OpenIDEO processes, see figure 36. Analyzing these processes four generic steps is defined: Submit, refine, Evaluate and Select. See Appendix 17, page 46.

Only the three first steps are defined in the challenge, namely: Submit, Refine and Evaluate. Through the evaluation process people vote on the entries they like the most. The winner of the challenge will then be the entry with most votes, but that does not necessarily mean the idea will be “selected” or implemented in a design or used in any other way. It should be possible to create many diﬀerent types of challenges to allow it being used throughout the development process. The Challenge Configuration Panel is now explained to illustrate how you can create diﬀerent challenges.

4: Community Design

Based in a single idea chosen by Quirky, members a asked to propose concrete concepts - Inspiration for the Quirky team

Based on own ideas and the submitted concepts Quirky creates detailed concepts

5: Refine

Quirky ask the community to evaluate their concepts. Only Quirky concepts.

Quirky chooses which concept to push forward to branding. This phase is not part of the analysis

3: Product evaluation

Quirky evaluates the product ideas and chose which to push forward to development.

1: Idea Submission

Challenge posed by members based on Quirky’s overall challenge

Challenge

community members submit their product ideas. By submitting they give Quirky the right to the idea

2: Community Curation

The member who submitted the idea elaborate on the ideas by collaborating with the community. The community vote on which idea is the best

Refine

Submit / Inspire

Evaluate

Select

1: Inspiration

Challenge posed by sponsor based on a overall challenge posed by OpenIDEO

community members submit ideas, existing or own, based on challenge from sponsors broken down in sub questions

2: Concepting

Based on a more concrete design brief and the entries doing inspiration concepts are submitted

4: Refinement

The community is asked to focus and the short list concepts are refined

3: Applause:

The community votes on which concepts are the best and creates a short list – the ideas with most votes move on

5: Evaluation

Members are asked make a criteria based evaluation, e.g. viability and impact.

The sponsor who posed the challenge chose the ideas(s) they like the most. Everyone are free to use the ideas as well.

Figure 36 - Case analysis of OpenIDEO and Quirky, see Appendix 17, page 46

PAGE

Iterate

When you start a new challenge you can choose from a list of already defined challenges, described next, or you can create one you self. No matter which you choose you are brought to the Challenge Configuration Panel. If you choose a predefined Challenge, all the building block and setting will already have been defined. All you have to do is type in a title, a description, link any related documentation and upload a picture. If not you would have to attach the wanted building blocks and configure the settings for each step in the progress. The most important settings are the interaction settings that define how other people interact with the entries to the challenge. For example, if you chose not to allow submits you are the only person who can make an entry to the challenge. That can be used to direct focus to a few possibilities – good for decision support. If you instead choose to allow all interactions then the entries will be dynamic and changed, while people will discuss and vote – good for exploring ideas. It is important that good descriptions a written for each step to make sure people using the challenge will now what to do. Here predefined challenges can help. P re de f in e d C halle n g e s Predefined challenges entails creating templates for each step and predefined settings for how users will interact with the challenge, see figure 37. Two themes were defined to guide the creation of predefined challenges: Inspiration and Decision. Inspirational challenges emphasize the steps “submit” and “evaluate”, where decision challenges put emphasize on, “Refine” and “evaluate”. The fundamental diﬀerence is that in inspirational challenges the community is asked to submit as many entries as possible and hence support idea generation, where in decision challenges the community cannot submit but are asked to focus on specific entries and evaluate these. The two types of challenges can be used together in an iterative manner to open up and narrowing down on solutions while adding in detail. The main objectives for creating predefined challenges are to make it easy to start a challenge and guide organization members in the use of them. Stating the right challenges are important in regard to the result wanted.

Inspiration Challenge Create new Challenge

Steps

Find ideas for this Description Concept

Attach picture

Drag and drop

Steps

Submit

Refine

Evaluate

Submit

Refine

Evaluate

Submit

Refine

Evaluate

Description

How do you think we could do this? Submit as many ideas as you want – Remember to post picture 

Define Challenge Entry Text Contact Date Category Link Picture

Text: Title Text: Description

Picture: Upload Picture Link: What inspired you? Attach File: Other files?

Steps

Description

How can we make the ideas better? Comment, discuss and vote. Integrate new ideas.

Which ideas do you like the most?

Interaction

Voting Comments Sharing (Re)Submit

Duration 5 May

Duration End Date

Questions

Duration End Date

Notify

End Date 7

Notify

Map Spreadsheet Number Duration Progress Attach File Item Reference

Rules for step progress End Date Creator control

Visibility Creator Members All

Rules for step progress

End Date Creator control

Visibility

End Date Creator control

on their filtering settings). Chances are someone ells than the person tagged can answer. You receive an answer faster and or higher quality because the answers can be validated by others as well. This is the same approach used at PODIO. The forum can be used in the same way, so users must clarify when to use what. The news feed would be suitable for small queries where the forum would be used for larger discussions where there would be reason for documenting the given arguments. In traditional PDM data would be spread out on several servers when during distributed development, see figure 38. In this concept there would only be a central server and the local workstation see figure 39. This could prove a problem if people want to work on the same files. Some CAD files are rather larger and it could take many minutes to check-out a file from the network server, is the file not cached in the right version locally (depending on their internet connection). It is not seen as a big problem because the CAD is checked out on IF component level.

Visibility

Creator Members All

Figure 37- Suggested settings for an inspiration challenge, see appendix 17 page 49

D i stri bu ted P rodu c t D ev el opment All documentation is available online after signing-up at DeDoCu.com (depending on privacy settings), so people across the world can access you project as long as they own a computer, a browser application and have a internet connection – everyone shares the same folder. If users want to be able to manage the Product Vault Files (check-out) locally they would have to download and install the local files application. All kinds of communication are supported. Chat mimics hallway small talk. Forums mimic group discussions at meetings and e-mail threads. Video Conferencing mimics real-time meetings and phone call. Personal messages are the same as e-mail. Notifications and News feeds are important tools to ensure distributed located people are up to date on each other’s activities. The news feed could especially function well as a forum for making small queries. It would work the same way as making a status update at facebook. You write you question and tags the person you think can answer, then the question will be posed to all members of the organization and community (depending

Figure 38 - server network in traditional PDM systems

Figure 39 - server network in DeDoCu CONCEPT GENERATION

PAGE

O rga n i z ati on n et work s You can share a project with another organization by allowing an organization to clone your projects. Cloning a project will create shared items and files in both organizations. This could be useful if you for example want to outsource part of the development. This was the case with the Strong Hand project were development of “the drive” element was carried out by a partner, because they had more experience with developing such functions. In the strong hand case, issues were mostly dealt with in forum at meetings once or twice a month. Sharing a project at DeDoCu would allow the diﬀerent teams to follow each other’s progress on a daily basis and be notified by important events. When allowing an organization to clone your project the new project is the slave by default. This can be changed by the original organization, if for example organization 1 want organization 2 to be in charge of developing an element of the total design. Otherwise you could just as well invite members of organization 2 to join organization 1. This could also prove useful at times for example when hiring consultants. But when sharing a project between organizations you do not only share documentation, you share communities. You could imagine a situation where 4 organizations share 4 modules, each of which is controlled by the 4 organizations respectively. If one of the modules fork (changes in a slave folder), resulting in two diﬀerent versions, the system will register it and mark the new version as a derivative. You will then be able to create a map of derivatives on community level. When a shared relationship is broken between organizations, new Item ID’s will be given to all shared items in the slave folder. This is because there would be no one responsible for

PAGE

making impact analyses of the changes and determine on what level interchangeability can be re-established. The only thing indicating interchangeability would be the derivative mark on the top level assembly. This is different from when a shared relationship is broken inside an organization (or playground project) where Item ID’s (and revision numbers) would only change for the assembly to which changes was made. It is then the organizations responsibility, and in their own interest, to determine on which level interchangeability can be re-established, and change revisions numbers accordingly. There is an issue of how shared projects are documented. Most likely the different organization would have different routines and use different Apps. What if the “Activity” App is defined differently by each organization? This issue needs to be addressed, but will not be done here.

R ec a pitul ation of the c oncep t devel opmen t Now the concept have been presented and the different sub solutions been described. The concept covers many aspects so this final section will give an overview of the concepts core functionality. These are the elements that constitute the difference that matters in regard to community-based development. • The IFD definition that directs focus on the definition of modules, interfaces and systems, and the way it is embedded in the platform graphically. This allows communication and control of all aspects of a product structure, which supports the development of modular products and put focus on interchangeability and lowers the cost of integration. The approach is still flexible enough to be adapted to many different contexts because the core elements are assemblies and components. • The flat and hierarchical document structure. Because documentation (App entries) can be related to both a category and an element in the product structure, it is possible to have both a flat and hierarchical document structure. This allows documentation to be “viewed” in different ways; making is easy to get an overview of existing documentation and finding information. This overview also supports the validation of information. • The challenged based interaction with the crowd. The most important thing about the challenges is that it can communicate a very concrete task, which is easy for the crowd to engage in. Due to the well defined and transparent process, it is also easy to get overview of contributions. This allows fast and “cheap” validation of solutions and ideas, through user moderation. Because of the distinction between “inspiration” and “decision”, you can define challenges suited for many purposes. • The overview of related designs. To harvest the full benefit from having large design variety in a community it should be possible get an overview of existing designs, identify the best design, and to integrate designs as “cheaply” as possible. This is what the Playground element intents to achieve. Overview is achieved by letting all designs exist in the same repository, making it easy to browse, search and filter designs. Identification of the best designs is achieved because the overview allows user moderation of designs. Low cost of integration is achieved because product structures are communicated and easily compared using the IFD.

CONCEPT GENERATION

PAGE

C ha p te r 5 C l o sing

PAGE

The ﬁnal chapter will present an evaluation of the concept for then to sum up the project results in the conclusion. Chapter 5 content • Evaluation of the concept • Conclusions • Limitations and future work

88 90 91

CONCEPT GENERATION

PAGE

Evaluati on of the c on c ep t To evaluate the concept three activities was carried out, a benchmark analysis, design reviews with users and experts, and finally thoughts in how to realize the concept.

Ben ch ma rk A na lysi s

D esign R eview

The concept was benchmarked against the RepRap system and SolidWorks Enterprise PDM (SEP). The RepRap system is defined to consist of: RepRap.org, Github.com and the Blog of Blogs. The aim of the benchmark analysis was to gain an indication of the performance of DeDoCu. The goal specifications were used as criteria for a quantitative evaluation on which a more qualitative analysis was based. The quantitative evaluation can be seen in appendix 11. Here the more qualitative analysis is presented.

Two design reviews were carried out. The first design review was together with Peter Rosenbeck from IPU and Hand Peter from DTU. Peter is the lead developer on the strong hand project and represents a possible user of DeDoCu. Hans Peter has knowledge of PDM systems and using the IFD. The second design review was carried out with Lars Jepsen Jensen from Visma. Lars has knowledge of implementing PDM, and has many years of industry experience.

The main conclusions were:

• DeDoCu is seen to provide better and more secure data management than the RepRap system. It should be easier to ﬁnd information and linking discussion and documentation. • The RepRap system is however seen to be better at creating a “knowledge library” due to the wiki. Future development should entail a wiki on community level to allow communities to document knowledge not directly connected to a single organization, project or product. • DeDoCu is seen matching SEP in regard to data management, not including part management. • SEP is seen to have better change management because it is easier to create more embedded workﬂows. • SEP has few elements supporting community based development, DeDoCu has many

PAGE

• From a user perspective DeDoCu is still a complex system, which needs much configuration. There might be too many knops to turn for it to be adapted by single users, who just want to get started. Such users should be “directed” to playgrounds and challenge. Organizations are seen being maintained by a dedicated team with a system administrator, where playground project is for single users. A thorough step by step embedded tutorial as seen in PODIO.com, that guides new users through the initial set-up, and teaches you how to use the different elements of DeDoCu, is seen essential. (Peter) • Another issue raised was if the system could support the final stage of development where the product is prepared for production. This should be investigated further. (Lars) • Defining product structures based on the IFD definition is seen a both a good and feasible solution. (Lars, Hans Peter) • All participants of the design reviews could envision themselves working on a system like DeDoCu. • All participants also saw value in the concept and believed it could contribute to the field of comunity-based product development of tangible objects. • Functional models would need to be developed to support further evaluation. • It would definitely be possible to realize the concept, and development frameworks exist to base the development upon. The question is how much resource it would take? (Lars)

R ea liz at ion of D eD oC u An important aspect is what already exists of solutions that can be re-used in the development of DeDoCu, and what need to be developed from scratch. This aspect should be investigated further but here are some initial thoughts. The system is seen developed open source to the extent possible. Generally seen, the system consists of three elements: The database, the database management system and a front-end. The database could be MySQL a widely used open source database system. To support the development of the database management system, many open source content management systems exist. There are also many open source software frameworks for common social networking functionality, such as chats, video conferencing and forums. It should be investigated to what extent ARAS, an open source PLM solution, could be adapted. If DeCoCu could be built on ARAS much of the PDM functionality would be easier to implement. If nothing ells, ARAS could be a good testing platform for implementing the IFD approach. Another possibility is using Git as the database management system. The Git community has been approach to clarify if this is possible, but without success. Git would have to be adapted to a PDM context as it is a SCM system. There also exist crowdsourcing frameworks with could be integrated to provide the Challenge functionality, if this should not be developed from scratch. PODIO oﬀers PODIO API a complete programmable interface to all PODIO’s functionality. It should be investigated if PODIO could be the founding platform. PODIO’s cooperation is a necessity if DeDoCu should be built on their platform. Being able to do so would greatly ease the integration of the APP which is seen as the biggest obstacle for realizing the concept. A first step should be to look into which extent ARAS or PODIO could be use as a platform for development.

CONCEPT GENERATION

PAGE

C onclusions Based on thorough research of several OSHW communities and existing collaboration tools, it was concluded that there indeed is a need for a new collaboration platform. It was also concluded that current PDM and crowdsourcing solutions, should serve as inspiration for its development. Such a platform should among other things allow: • Communication and control of product structures to lower the cost of integrating designs • Easy location and validation of information in a distributed setting • Communication of project activities to the community, to make the development process transparent. These things are all aspects important for eﬃcient community-based development, but are also aspects where current OSHW community collaboration systems proves inadequate. Based on the research findings a conceptualization process was completed. The process resulted in a concept for a web-based collaboration platform, building on PDM functionality, Crowdsourcing and collaborative Project Management tools, implemented in a Web 2.0 environment. The concept takes form as a website oﬀering online hosting of development projects, making the system easily accessible. Both private and public project can be run on the platform, but where public projects can be run for free, private projects would have to pay.

The concept entails the following functionality related to the most important identified needs. • To control product structures the standard PDM approach is used, by allowing the definition of product structure in the database system. The approach is supported by a formalism emphasizing the definition of modules, interfaces and systems, which communicates all aspects of a product structure. This should facilitate the development of modular products and put focus on interchangeability. • Location of information is made easy by allowing documentation stored in the system to be related to both a category and product structure. This approach creates both a flat and a hierarchical data structure in the system, which enables overview of existing documentation. Such overview would also support a validation of information. • Project activities are communicated to the community using the same approach as crowdsourcing sites. Based on the project activities, “Challenges” can be posed to the community which are easy to engage in. The process of answering the challenge is guided by well defined steps enhancing transparency. The concept is called DeDoCu - Social PDM. User interface mock-ups of the concept was created and used for evaluating the concept. This evaluation process was supported by a case study of a NPD project, used to create use scenarios, and design reviews with users and experts. The concept proved promising. Based on the evaluation and feedback from design reviews the proposed concept is seen to bring value to the field of product development of tangible objects. The concept is seen as the first step toward realizing a online collaboration platform that supports community-based development of physical products, and thereby allow OSHW communities to eﬃciently co-create complex physical products.

PAGE

L imitations - a n d fu t u re work Looking back at the project process and the process of writing the report some limitations have been considered which might have affected the final outcome. At the beginning of the project not much was know about the task at hand. This meant that the project had to be delimited as the project progressed. Because the full scope of the objective was not truly realized until late in the process, this delimitation was perhaps not focused enough. More effort could have been put to detailing the core functionality of the concept to support a more thorough evaluation. This leads to the believed principal shortcoming of this project – the issue of validating the functionality of the concept. Although much effort was put into evaluating the concept though use scenarios and design reviews, functional models will need to be created to truly validate the concept. The concept therefore stands to serve as inspiration for future development and not as a concept ready for implementation. Some delimitation that was made, was not to focus on development of electronic hardware. The assumption was that the development of electronic hardware set the same requirements for the platform as development of mechanical hardware. This is off course not entirely true, so it should be investigated to what extent the concept supports development of electronic hardware. The outcome of the process might also have been affected by the chosen development approach. As I have a background in mechanical engineering and this is my first venture into development of software products, I chose to build my approach on how I usually develop mechanical designs. This resulted in some frustration, especially when generating and evaluating solutions. Perhaps because the object of design was a software design, the approach conflicted with the way I usually communicate concepts. The concept generation process where therefore not as systematic and structures as intended. The business and market aspect of the concept would need to be investigated further to determine a more accurate demand estimate presented in the executive summary, and to validate that the product would actually sustain a business.

CONCEPT GENERATION

PAGE

R eferences Abel, B., Evers, L., Klaassen, R. and Troxler, P. (Contributors: Paul Atkinson, Michael Avital, Bruce Mau, Renny Ramakers, Carolien Hummels), 2010. “Open Design Now. Why Design Cannot Remain Exclusive”. Creative Commons Netherlands, Premsela, the Netherlands Institute for Design and Fashion and Waag Society. Balka, K., Raasch, C. And Herstatt, C., 2009a. “Open Source beyond software: An empirical investigation of the open design phenomenon”. R&D Management Conference. 30. April 2009.

Dahlqvist et. al. 2001“PDM and SCM - similarities and differences” The Association of Swedish Engineering Industries Erixon, G 1998 “Modular Function Deployment – a method for product modularization”. Royal Institute of Technology, Sweden. Fitzgerald, B. 2006. “The Transformation of Open Source Software”, MIS Quarterly, Vol. 30, September. Pp. 587-598.

Balka, K. Raasch, C. and Herstatt, C., 2009b. Open source enters the world of atoms: A statistical analysis of open design. First Monday, Vol.14, No.11., pp. 248-256.

Fjelsted A. & Adalsteinsdottir G. 2012a. “Open Source Development of Tangible Products- from a business perspective”, Norddesign.

Bavani, R, 2009, “Critical Success Factors in Distributed Agile for Outsourced Product Development”. Proceedings of CONSEG-09: International Conference on Software Engineering, December 17-19, Chennai, India

Fjelsted A. & Adalsteinsdottir G. 2012b. “OPEN DESIGN CONSULTING How to capitalise on and adapt to open source practices for tangible products”. Master Thesis, DTU Management, Technical University of Denmark.

Benkler, Y., Nissenbaum, H. 2006, “Commons-based Peer Production and Virtue”, The Journal of Political Philosophy: Volume 14, Number 4, pp. 394–419

Hansen & Andreasen, 2002 “the concept and nature of design concepts”, Proceedings of norddesign 2002, Trondheim.

Bonaccorsi , A., Rossi, C., 2003. “Why Open Source software can succeed”. Research policy, Vol. 32, No. 7, pp. 1243-1258, Elsevier

Hansen, A & Howard, T.J. 2012, “Current state Open Source Hardware – The need for an Open Source Collaboration Platform”, Proceedings of ICoRD ’13,.

Brown, J 2011, ”The business value of Product Data Management”, Magazine, Tech-Clarity

Hippel, E. and von Krogh, E., 2003. Open Source Software and the “Private- Collective” Innovation Model Issues for Organizations. Organization Science, Vol. 14, No. 2, March–April. Pp. 209-233.

Bruun & Mortensen, 2011,”Visual product architecture modeling tool for structuring data in a PLM system” Bruijn, E, 2010 ”On the viability of the open source development model for the design of physical objects - Lessons learned from the RepRap project”, Master Thesis, Faculty of Economics and Business, University of Tilburg, The Netherlands ANR: 23.99.45 Dahlander, L. and O’Mahony, S. (2008). Progressing to the Center: The Antecedents and Consequences of Lateral Authority.

PAGE

Howard, T.J., Achiche, S., Özkil, A. and McAloone, T.C., 2012. “Open design and crowdsourcing: maturity, methodology and business models”. Proceedings of DESIGN12, Dubrovnik. Jeppesen and Lakhani, 2010. Marginality and Problem-Solving Effectiveness in Broadcast Search Organization Science orsc.1090.0491; February 1, 2010 Koch & Tumer, 2009, “Towards Open Design: The Emergent Face of Engineering - A Position Paper” , Proceedings of ICED’09, Vol.3, No.11., , pp 97-108.

ONLINE REFERENCES Kumar, R, Midha, P.S. 2001. ”A QFD based methodology for evaluating a company’s PDM requirements for collaborative product development”, Industrial Management & Data Systems, Vol. 101 Iss: 3 pp. 126 – 132 Larsson, A. Törlind P, L Karlsson, A Mabogunje, L Leifer, T Larsson, and B-O Elfström , 2003 ”DISTRIBUTED TEAM INNOVATION – A FRAMEWORK FOR DISTRIBUTED PRODUCT DEVELOPMENT”, INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 03 STOCKHOLM, AUGUST 19-21

Blog on Git. http://codingkilledthecat.wordpress.com/2012/04/28/why-your-companyshouldnt-use-git-submodules/ Manufacturing in motion: ﬁrst survey on 3D printing community http://surveys. peerproduction.net/2012/05/manufacturing-in-motion/ Openpario.net. The OSE design repository at OpenPario.net. - http://openpario.net/ projects/ose

Liu, D, & Xu, W. 2001. “A review of web-based product data management systems”, Computers in Industry 44, 251-262.

OSE Wiki. Statistic derived from wiki activities at the OSE wiki. – opensourceecology.org/wiki/Special:Statistics]

Raymond, E., 1998. The cathedral and the bazaar. Knowledge, Technology & Policy, Vol. 12, No. 3, pp. 23-49, Springer

PODIO - Podio.com

Samuels, E 1989 “THE IDEA-EXPRESSION DICHOTOMY IN COPYRIGHT LAW”, Tennessee Law Review Association, Inc. Tennessee Law Review Shah, S., 2005. Open Beyond Software. Open Sources 2. Edited by Danese Cooper, Chris DiBona and Mark Stone. O’Reilly Media: Sebastopol, CA. Smidt, D. 2009, “Exploring Innovation”, Book, 2. edition, Mcgraw-hill Education – Europe Yeongho Kim, Suk-Ho Kang, Soo-Hong Lee & Sang Bong Yoo (2001): A distributed, open, intelligent product data management system, International Journal of Computer Integrated Manufacturing, 14:2, 224-235

, http://

Reddit.com. Discussion on Reddit.com on how to make Thingiverse better –, [http:// www.reddit.com/r/thingiverse/comments/yfg01/what_would_you_want_in_a_ thingiverse_alternative/] RepRap Wiki - http://reprap.org/wiki/Standards_Development RepRap Forum – [http://forums.reprap.org/read.php?2,115519] Siemens PLM. , http://www.plm.automation.siemens.com/en_us/plm/pdm.shtml SolidWorks Enterprise EnterprisePDM

PDM

–

http://help.solidworks.com/2012/English/

Thingiverse - Thingiverse.com Wired.com. Article on wired.com on OSHW platforms –, http://www.wired.com/ geekdad/2008/11/thingiversecom/ Quirky - http://www.quirky.com/learn OpenIDEO - http://www.openideo.com/faq Makezine.com - http://blog.makezine.com/2012/09/22/makerbots-mixed-messagesabout-open-source-their-future/ CONCEPT GENERATION

PAGE