1. Questions
1.1. What are the resulting development efficiencies?
1.2. Can we develop a scalable process where a single developer can coordinate 1000 development hours of open collaboration per week?
1.3. Can this be scaled to multiple teams in parallel?
1.4. Can this collaboration be structured sufficiently within a chaotic process to allow for the execution of complex tasks – that are time-bound to achieve long-term goals?
1.5. Can prototyping of new modules – and therefore new complex machines – occur on the time scale of a week?
1.6. Can this process be scaled to multiple projects?
2. Research Topics
2.1. NPD process
2.1.1. Definitions
2.1.1.1. PD is an endeavor com- prised of the myriad, multi-functional activities done between defining a technology or market opportunity and starting production.
2.1.1.2. A model is an abstract representation of reality that is built, verified, analyzed, and manipulated to increase understanding of that reality. Models can reside in the mind (mental models) or be codified. “All models are wrong, but some are useful” [Box, 1979]. A useful model is helpful for making predictions and testing hypotheses about the effects of contemplated actions in the real world, where such actions would be too disrup- tive or costly to try. A useful model also provides insights otherwise available only through (sometimes painful) experience. While scientists focus on descrip- tive models, engineers and managers furthermore want predictive models, for which validation and estimation of modeling error are practically impossible [Hazelrigg, 1999]. Here, we are interested in models that help represent, understand, engineer, manage, and improve PD processes.
2.1.1.3. A process is “an organized group of related activities that work together to create a result of value” [Hammer, 2001] or “a network of customer-supplier relationships and commitments that drive activities to produce results of value.” (Pall, 1999)
2.1.2. Context
2.1.2.1. We must clearly distinguish between reality (the way work really gets done) and a model (an abstract description of the way work can or should get done).
2.1.2.2. In many aspects, complex process behaviors can be better understood by examining their rela- tively simpler, constituent parts (actions) and those parts’ endogenous and exogenous relation- ships (interactions). We refer to this as the decom- position paradigm in process modeling. While it is also at times referred to as the reductionist paradigm, we resist that description as mislead- ing: We do not mean to imply that a system can be fully understood by reducing it to a mere set of elements and relationships. However, holonic decomposition can provide an effective means of organizing a useful model.
2.1.2.3. There is always a gap between the real system and a model of it. The size of this gap is deter- mined by the model’s richness, fidelity, accuracy, “realism,” etc. In modeling, verification and vali- dation are used in an effort to close this gap. However, many models can be quite “useful” despite large gaps, if these gaps are chosen ap- propriately
2.1.2.4. Process models are built for a purpose, such as to document the way work is done, to estimate the duration of a project, etc. [Browning and Ramasesh, 2005]. Process models built for one purpose may not be useful for other purposes, although this type of misuse is common in indus- try.
2.1.2.5. Hence, in our estimation, a useful process model is the basis for and key to the effective integration of the project system models and the effective management of projects.
2.2. Crowdsourcing
2.2.1. Definitions
2.2.1.1. Estellés-Arolas; González-Ladrón-de-Guevara, 2012
2.2.2. Constructs
2.2.2.1. Crowd
2.2.2.1.1. Size
2.2.2.1.2. Diversity and competence
2.2.2.1.3. Preselection of contributors
2.2.2.2. Task
2.2.2.2.1. Rank consumers' preferences
2.2.2.2.2. Collect consumers’ creative ideas
2.2.2.2.3. Test new ideas
2.2.2.3. Recompense received by the crowd
2.2.2.3.1. Remuneration
2.2.2.3.2. Benefits from participating in the project “community” that are not available to free riders
2.2.2.4. Crowdsourcer / initiator
2.2.2.4.1. Motivation
2.2.2.5. Compensation to be received by the crowdsourcer
2.2.2.6. Online assigned process of participative type
2.2.2.6.1. Accessibility of peer contributions
2.2.2.6.2. Aggregation of contributions
2.2.2.6.3. Process coordination
2.2.2.7. Call / invitation
2.2.2.7.1. Open call of variable extent
2.2.2.7.2. Invite a specific member
2.2.2.8. Internet
2.2.3. Types
2.2.3.1. Daily Crowdsource
2.2.3.1.1. Crowdsource Design
2.2.3.1.2. Crowdfunding
2.2.3.1.3. Microtasks
2.2.3.1.4. Open Innovation
2.2.3.2. Crowdsourcing.org
2.2.3.2.1. Distributed Knowledge
2.2.3.2.2. Crowdfunding
2.2.3.2.3. Cloud Labor
2.2.3.2.4. Open Innovation
2.2.3.2.5. Crowd Creativity
2.3. Mass collaboration product realization
2.3.1. Tools
2.3.1.1. Design Structure Matrix (DSM)
2.3.1.2. Score-based DSM
2.3.1.3. DSM with rework
2.3.1.4. Degree of modularity metric
2.3.2. Definitions
2.3.2.1. Panchal; Fathianathan, 2008
2.3.3. Context
2.3.3.1. Users have evolved from passively receiving information through the web to playing an active role by forming communities, interacting with peers, sharing information, and adding value to the Internet as a result of their interactions.
2.3.3.2. In physical products, the attempts to mass collaborative product development are still in the early stages
2.3.3.3. The information flow in mass collaborative product realization adopts a ‘publish and subscribe’ model. In this model, all participants of solving the product realization problem ‘subscribe’ to the problem. Whenever a change is made to the information pertaining to the problem are made, every subscribed participant is notified of the change. Participants then react to the change that has occurred. Based on this information flow, information technology for facilitating mass collaborative product realization should facilitate:
2.3.3.3.1. Formation of the community
2.3.3.3.2. Online description of product realization problem
2.3.3.3.3. Online submission of solutions and comments
2.3.3.3.4. Notification of changes
2.3.3.4. Differences between traditional and mass collaborative product realization
2.3.3.5. The product realization process defines how products will be realized in the mass collaborative environment. A vast amount of research has been conducted on design methods, but the mass collaboration paradigm involves a fundamentally different environment for realizing products where large numbers of people are involved and where self organization could play a greater role than traditional top-down design methods. While self organization could be beneficial, it also could result in negative effects when bad solutions dominate and greatly influence the convergence to a solution. To facilitate product realization in the mass collaborative environment requires an understanding of product realization with large numbers of people. A key enabler of mass collaborative product realization is an understanding of the product realization process in a mass collaborative environment and tools that will aid organizations and individuals manage the process effectively.
2.3.3.5.1. However, models for bottom-up design processes have not been studied in the engineering design community
2.3.3.5.2. We believe that significant research on modeling mass collaborative design processes as interactions between self- interested participants is necessary for mass collaborative product realization.
2.3.3.6. Instead of a hierarchical organizational structure with a central control, a flat and decentralized structure is required for mass collaboration to be successful (Brafman; Beckstrom, 2006). The business models for such enterprises are also different (Silver, 2007).
2.3.3.7. In contrast to the traditional design, in the case of open and mass collaboration each individual is driven by his/her personal objectives that may not be directly derived from the system level objectives. Every participant has his/her own intrinsic interest in contributing to the overall effort. The overall design emerges based on the interactions of these self- interested individuals.
2.3.4. Opportunities Provided by Mass Collaborative Product Realization
2.3.4.1. While many good ideas are generated daily, few are successfully brought into the marketplace [37]. Reasons for this include the lack of a proper team and the lack of resources. In a mass collaborative environment, individuals with ideas now have the opportunity to form teams with appropriate competencies and also utilize the resources that members of a network might possess to turn their ideas into products
2.3.4.2. New technologies are constantly being invented. A key problem in utilizing new technologies is identifying areas in which the technology may be utilized. Often a technology is not utilized in as many areas as it could appropriately be used in because inventors are unaware of the application areas. Mass collaborative product realization provides an opportunity for organizations and individuals to make known or offer their new technologies to large groups of people who could identify new applications.
2.3.4.3. Organizations and individuals are limited in the knowledge that they possess. Mass collaborative product realization provides the opportunity to take difficult product realization problems that the individual entity is unable to solve and open it up to large groups of people. The probability of solving the difficult problems is hence increased as a result of many minds trying to solve it
2.3.4.4. While various methods exist for customer needs finding, mass collaboration provides the opportunity for large groups of people to voice their opinion in what they want in a product.. It provides a new means of including the voice of the customer in the design of the product.
2.3.4.5. The quality of the final design is often limited by the quality of concepts and alternatives generated for design problems. Involving large groups of people provides an opportunity to increase the quality of concepts and alternatives to arrive at innovative solutions to design problems
2.3.4.6. Mass collaboration has a self-correcting characteristic brought about by large numbers of people amending or commenting on the quality of solutions and the decisions made, thus allowing sound solutions to be arrived at
2.3.5. Coordination mechanisms for product realization process
2.3.5.1. Uncoordinated product realization process: An uncoordinated product realization process would involve designers reacting to new information and taking actions as they deem. No rules are present to limit or govern the behavior of designers in the environment.
2.3.5.2. Central coordination of the product realization process: Central coordination would involve a central manager who decides how the product realization process proceeds. The manager decides on allocation of tasks to individual designers or design teams and decides on the sequence of design tasks
2.3.5.3. Coordination based on opinion polling: This process would involve design process and product decisions being made based on the collective opinions of the group of designers involved. This coordination mechanism is similar to house-hunting in social insects (Franks et al.,, 2002)
2.3.5.4. Set-based product realization: Set-based product realization would involve concurrent development of multiple concepts (Ward et al., 1995; Sobek; Ward, 1996; Liker et al., 1996). This could involve a scenario where multiple design concepts are explored concurrently by different groups of designers in response to a posed design problem.
2.4. Open Collaborative Design
2.4.1. Definitions
2.4.1.1. An open collaborative innovation project involves contributors who share the work of generating a design and also reveal the outputs from their individual and collective design efforts openly for anyone to use.
2.4.1.2. Open source development, typically involves a large set of individuals and/or organizations sharing the workload (Haefliger et al., 2008) while the public good properties of the outcome are preserved (Bessen, 2005; von Hippel and von Krogh, 2006; Osterloh and Rota, 2007).
2.4.1.3. A community can be described as “a network of interpersonal ties that provide sociability, support, information, a sense of belonging and a social identity” (Franke and Shah, 2003).
2.4.1.4. Open Source Hardware (OSHW) Definition
2.4.1.4.1. Documentation
2.4.1.4.2. Scope
2.4.1.4.3. Necessary Software
2.4.1.4.4. Derived Works
2.4.1.4.5. Free redistribution
2.4.1.4.6. Attribution
2.4.1.4.7. No Discrimination Against Persons or Groups
2.4.1.4.8. No Discrimination Against Fields of Endeavor
2.4.1.4.9. Distribution of License
2.4.1.4.10. License Must Not Be Specific to a Product
2.4.1.4.11. License Must Not Restrict Other Hardware or Software
2.4.1.4.12. License Must Be Technology-Neutral
2.4.1.4.13. Open Hardware Licenses
2.4.2. Context
2.4.2.1. The rapid growth of open-source 3-D printing is a typical example of the broader and emerging phenomenon of open collaborative innovation.
2.4.2.2. While open-source communities are probably best known for software development, they are by no means restricted to software or even information products; as the RepRap community demonstrates,such communities are also viable for developing physical products
2.4.2.3. Innovation by user communities may be expected to increasingly compete with and, in some cases, displace corporate innovation in many parts of the economy.
2.4.2.4. Prevalence of open source in physical design projects with some degree of visibility is still very modest when compared to software.
2.4.2.5. Any description that covers more of what goes on in a typical open source community would have to acknowledge that legal tools are only a part of the norms and culture affecting the community’s be- havior (Benkler, 2006)
2.4.2.6. Formal or informal, a community’s norms and culture determine, to a large degree, the behavior of its participants. Benkler (2006, p. 110) notes that cultural norms in social exchange systems can be more efficient than the costly monitoring and enforcement commonly employed in market exchange systems.
2.4.2.7. Given that this use-related knowledge is often very costly to transfer to producers, this gives them an advantage in creating better-suited products compared to producers (von Hippel, 1995). This would help explain the dominance of users as developers in open source projects (Gacek et al., 2002).
2.4.3. Motivation
2.4.3.1. Intrinsic
2.4.3.1.1. Intellectual stimulation
2.4.3.1.2. Philosophical beliefs
2.4.3.1.3. Sense of ownership of and control over their work
2.4.3.1.4. Learning and enjoyment
2.4.3.2. Extrinsic
2.4.3.2.1. Career advantages
2.4.3.2.2. Reputation benefits
2.4.3.2.3. Possibility of customization of the products/services to individual needs
2.4.3.2.4. To help build a community
2.4.3.2.5. Expected reciprocity
2.4.4. Drivers
2.4.4.1. New technologies
2.4.4.1.1. The transition to increasingly digitized and modularized design and production practices
2.4.4.1.2. The availability of very-low-cost, Internet-based communication
2.4.4.2. Better-educated citizens capable of engaging in innovation activities
2.4.4.3. Potencial industries
2.4.4.3.1. Nascent industries
2.4.4.3.2. Industries where some potential users are not yet served
2.4.4.3.3. Industries where some users are not served adequately
2.4.5. Opportunities for existing companies
2.4.5.1. Competing innovations identify what is currently missing in commercial products, and companies may just adopt these designs and further improve them to offer better products, realize cost savings and so on.
2.4.5.2. User communities can create products that are essential or useful complements to existing companies’ offerings. In such cases, user communities may well increase existing companies’ profit potential.
2.4.6. Threats for existing companies
2.4.6.1. Direct alternatives to the products of existing companies that are cheaper or more suitable to heir personal needs.
2.4.6.1.1. Although, many products take time, skills and effort to build, so some users prefer a traditional commercial product made by an established business.
2.4.6.2. Decrease users’ willingness to pay for a commercial product, so price discipline is imposed on existing companies
2.4.7. Ways Existing Companies Can Respond
2.4.7.1. Monitor
2.4.7.1.1. Need to be able to identify users who are innovating
2.4.7.1.2. Need rules of thumb to identify which user innovations have the most potential to be seen as useful by others and spread
2.4.7.2. Attack
2.4.7.2.1. In cases where users infringe upon a company’s patents.
2.4.7.3. Adopt
2.4.7.3.1. To adopt or copy the technologies, methods or improvements developed by user communities. These can generally be obtained for free, as many innovators in user communities do not protect their contributions with patents.
2.4.7.4. Acquire
2.4.7.4.1. Key community members may be recruited to join a company and/or accept to collaborate with a company
2.4.7.4.2. Acquire startups founded by community members in order to get a foothold in an emerging market.
2.4.7.5. Facilitate
2.4.7.5.1. Can be done by methods such as online toolkits that facilitate user innovation and product modification, contests and awards, or sponsoring websites or key community members’ contributions
2.4.8. Communities that develop physical products
2.4.8.1. RepRap
2.4.8.2. Thingiverse
2.4.8.3. Open Source Ecology
2.4.8.4. Open Source Vehicle
2.4.8.5. Velocar
2.4.8.6. Sports equipment (Lüthje et al., 2002; Franke and Shah, 2003; Lüthje and Herstatt, 2006; Shah, 2005)
2.4.8.7. Scientific instruments (von Hippel and Riggs, 1994; von Hippel, 1976)
2.4.8.8. Medical instruments (Lüthje, 2003)
2.4.8.9. Industrial process equipment (von Hippel, 1988b)
2.4.8.10. Products (von Hippel and Finkelstein, 1979; Herstatt and von Hippel, 1992; Nuvolari, 2004)
2.4.8.11. Mass production of steel (Morrison et al., 2002)
2.4.8.12. Personal computer (Meyer, 2003)
2.5. Open Source Software (OSS)
2.5.1. Open Source Definition
2.5.2. Open Source Licenses
2.5.3. Open Source Licenses
2.5.3.1. Perhaps the most important function of open source licenses is to ensure non-exclusive access to the intellectual property. Moreover, reuse and improvement of open sourced products can be carried out without needing to ask for permission. This reduces transaction costs, the barriers to contribute and duplication of effort.
2.5.3.2. The most commonly applied license, the GPL3, requires that all derivative and downstream modifications are released under the same license and may be distributed freely
2.5.4. Open Source Licenses
2.5.5. Open Source Licenses
2.5.6. Open Source Definition (OSD)
2.5.6.1. Free Redistribution
2.5.6.1.1. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2.5.6.2. Source Code
2.5.6.2.1. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
2.5.6.3. Derived Works
2.5.6.3.1. The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
2.5.6.4. Integrity of The Author's Source Code
2.5.6.4.1. The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
2.5.6.5. No Discrimination Against Persons or Groups
2.5.6.5.1. The license must not discriminate against any person or group of persons.
2.5.6.6. No Discrimination Against Fields of Endeavor
2.5.6.6.1. The license must not discriminate against any person or group of persons.
2.5.6.7. Distribution of License
2.5.6.7.1. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
2.5.6.8. License Must Not Be Specific to a Product
2.5.6.8.1. The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
2.5.6.9. License Must Not Restrict Other Software
2.5.6.9.1. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
2.5.6.10. License Must Be Technology-Neutral
2.5.6.10.1. No provision of the license may be predicated on any individual technology or style of interface.
2.6. 3D Printing
2.6.1. Designers can quickly prototype their designs in order to test their viability or demonstrate them
2.6.2. Manufacturing products in small batches
2.6.3. Five years ago, users started to collaboratively develop home printer designs and to share their open-source designs on the Web.
3. Projects
3.1. Prototype stage
3.1.1. CEB Press
3.1.2. CNC Torch Table
3.1.3. Ironworker
3.1.4. Microhouse
3.1.5. Power Cube
3.1.6. Rototiller
3.1.7. Tractor
3.1.8. Trencher
3.2. 3D Printer
3.3. 3D Scanner
3.4. Aluminum Extractor from Clay
3.5. Backhoe
3.6. Bakery Oven
3.7. Baler
3.8. Bioplastic Extruder
3.9. Bulldozer
3.10. Cement Mixer
3.11. Chipper / Hammermill
3.12. CNC Circuit Mill
3.13. Dairy Milker
3.14. Dimensional Sawmill
3.15. Electrical Motor / Generator
3.16. Gasifier Burner
3.17. Hay Cutter
3.18. Hay Rake
3.19. Hydraulic Motor
3.20. Induction Furnace
3.21. Industrial Robot
3.22. Laser Cutter
3.23. Metal Roller
3.24. Microcombine
3.25. Microtractor
3.26. Modern Steam Engine
3.27. Multimachine
3.28. Nickel-Iron Battery
3.29. Open Source Car
3.30. Open Source Truck
3.31. Pelletizer
3.32. Plasma Cutter
3.33. Press Forge
3.34. Rod and Wire Mill
3.35. Solar Concentrator
3.36. Spader
3.37. Steam Generator
3.38. Universal Power Supply
3.39. Universal Rotor
3.40. Universal Seeder
3.41. Universal Welder
3.42. Well-Drilling Rig
3.43. Wind Turbine
4. Organizational
4.1. People
4.1.1. Marcin Jakubowski
4.1.1.1. Founder
4.1.1.2. Came to the U.S. from Poland as a child
4.1.1.3. Ph.D. in fusion physics from the University of Wisconsin
4.1.1.4. Graduated with honors in chemistry from Princeton University
4.1.2. Chris Reinhart
4.1.2.1. Architectural Lead and Construction Manager
4.2. Community
4.2.1. Anyone can join. Foucused on
4.2.1.1. Farmer
4.2.1.2. Builder
4.2.1.3. Entrepreneur
4.2.1.4. Maker
4.2.2. Allow people with little prior experience to generate sophisticated results – using an integrated, interdisciplinary development process
4.2.3. Develop
4.2.3.1. on site at Factor e Farm
4.2.3.1.1. Immersion workshops
4.2.3.1.2. Intership
4.2.3.1.3. Alternative Spring Breaks
4.2.3.1.4. Dedicated Project Visits and Group Visits
4.2.3.1.5. Residency Program
4.2.3.2. remotely via
4.2.3.2.1. Design Sprints
4.2.3.2.2. Requests for Proposals
4.2.3.2.3. University collaborations
4.2.4. Organize
4.2.4.1. University Lectures
4.2.4.2. OSE Chapters
4.2.4.3. Team Projects, Senior Projects, Capstone Projects, Design Teams, Competitions, Social Enterprise Challenges
4.2.4.4. In-Kind Donations
4.2.5. Support
4.2.5.1. True Fan
4.3. Headquarter
4.3.1. Maysville, Missouri, USA
4.3.1.1. 30 acre parcel of land 1 hour away from the Kansas City International Airport in Missour
4.3.2. Socio-technical experiment
4.3.2.1. Natural ecology
4.3.2.2. Industrial production
4.3.2.3. Experimental research and development
4.3.2.4. Immersion education
4.3.2.5. Transformative lifestyle
4.3.3. To thrive, and determine whether it is feasible to use abundant local resources to create industrial civilization, up to semiconductor and metal production
4.3.3.1. On the scale of a parcel of land
4.3.3.2. 2 hours of work per day
4.3.3.3. Using local resources
4.3.3.4. Regeneratively
4.3.3.5. Achieving a modern standard of living.
4.3.4. Constructions
4.3.4.1. Workshop
4.3.4.2. HabLab
4.4. Foundation
4.4.1. 2003
4.4.2. Motivation
4.4.2.1. To work globally to stop material constraints from determining the wellbeing of humans, thereby eliminating production as an issue of control and power.
4.4.2.1.1. Few giant corporations have the production control
4.4.2.1.2. The products are expensive
4.4.2.1.3. The disigns are secrety
4.4.2.1.4. The companies engineer their products to fail
4.4.2.1.5. The amount of money and energy spent on protectionism
4.5. Strategic Planning
4.5.1. Mission
4.5.1.1. The mission of OSE is to create an open source economy. An open source, libre economy is an efficient economy which increases innovation by open collaboration.
4.5.1.2. Develop a set of open source blueprints for the Global Village Construction Set
4.5.2. Vision
4.5.2.1. A world of innovation accelerated by open, collaborative development – to solve wicked problems – before they are created. We see a world of prosperity that doesn’t leave anyone behind. We see a world of interdisciplinary, synergistic systems thinking – not the isolated silos of today’s world.
4.5.3. Value
4.5.3.1. Open collaboration
4.5.3.2. Efficiency
5. Development Process
5.1. Customer requirements
5.1.1. Robust
5.1.2. Modular
5.1.3. Highly efficient
5.1.4. Optimized
5.1.5. Low cost
5.1.6. Made from local and recycled materials
5.1.7. Last a lifetime
5.2. Intellectual Property
5.2.1. OSE Licency for Distributive Economics
5.2.1.1. Access to technology blueprints
5.2.1.2. Access to outside participation in development
5.2.1.3. Access to enterprise blueprints
5.2.2. Creative Commons CC-BY-SA 3.0