Development

This means that we break machines down into modules, and each module can be developed in parallel with other modules. For this to happen, one must document how these modules fit together – which is the Interface Design.

Scalable, modular documentation is key to OSE’s work.

Humans have a unique capacity to learn from past experience. The invention of writing 10k years ago sharpened this skill to extraordinary capacity – enabling humans to dominate their natural environment. Seminal general semanticist Alfred Korzybski calls this ability “time-binding” – the unique capacity of humans to bind time by beginning development where another human left off. This ability depends on the availability of documentation. While this documentation may be oral, highly complex technical tasks beyond heirloom technology require written documentation.

In principle, if a project can be broken down into a large number of modules, then a correspondingly large project team can be involved in parallel – allowing for rapid development velocity. Further, if a project is open source, well-organized documentation allows new developers to orient themselves rapidly, resulting in short onboarding times.

Rapid collaborative development has been shown with open source software and Extreme Programming. We are taking these agile techniques to the world of physical products – which we call Extreme Manufacturing.

OSE’s Global Village Construction Set (GVCS) is an experiment to test the power of scalable, modular, open source documentation. What are the resulting development efficiencies? Can we develop a scalable process where a single developer can coordinate 1000 development hours of open collaboration per week? Can this be scaled to multiple teams in parallel? 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? Can prototyping of new modules – and therefore new complex machines – occur on the time scale of a week? Can this process be scaled to multiple projects? These are some of the critical questions that OSE is trying to answer.

This website shows the 50 GVCS machines and a Dashboard. The Dashboard is a unique identifier taxonomy that has been developed in the 2013 Open Source Hardware Documentation Jam, and is added to OSE documentation and embedded within the underlying internet structure (XML tags), beginning with OSHW (Open Source HardWare) – Project Entity – Product – Brief Description – Status – License – and Keywords. This taxonomy such that a search engine can find any OSHW project in the world. For the OSHW project to meet the Open Source Hardware Association Definition 1.0, the project must have a license (such as Creative Commons CC-BY-SA) that does not prevent commercial use (ie, CC-BY-NC licenses are not allowed). You can find out more about why OSE does not endorse NC licenses here.

For OSE, the general approach is to build Construction Sets for machines, not specific machines. When a Construction Set approach is taken, our designs can yield an infinite number of machines and variations. The GVCS may be broken down into these different Construction Sets:

The documentation repository for the 50 GVCS machines is at the OSE Dozuki site. Dozuki uses an open, XML-based document standard for instruction manuals, oManual. Related machines other than the 50 GVCS tools are found under Other. We use Trovebox to store all our pictures, and we upload video to YouTube in realtime.

Our Dozuki documentation platform shows the 50 machines on the main page. Each is broken into about 10 modules. Each module is broken down into about 75 development points in a development Spreadsheet:

Developers document all work as links in the Development Spreadsheet, such that the overall documentation platform becomes a one-stop-shop for finding all past work. Each machine or module typically goes through several prototype iterations. Finding the vast amount of past work is critical. With our platform, it takes 4 clicks from the landing page of Dozuki to access any of the 150,000 items that will be necessary to complete the entire GVCS. In order to make collaborative development by a large, diverse, community possible – the key is making the information easy to access: by providing excellent information architecture – such as infographics and organization – and by making information bite-sized.

OSE’s parallel development process is intended to be carried out by 12-24 person teams for each module. If there are multiple modules developed at the same time – say 6 – then a hardware project lends itself to a development team on the order of 100 people. OSE is experimenting what resources are required for a single project leader to guide such a team to rapid project completion.

For electro-mechanical devices such as those in the GVCS, a team is requires these specific functions:

• Documentation Manager – makes sure that all documentation produced is placed on the OSE platform – wiki pages, work logs, Dozuki organization, Development Template, Trovebox images, YouTube video, Vimeo archives, a Project Management Spreadsheet, and a Project Management Critical Path Diagram.
• Conceptual Designer – produces a concept design. This may be a team effort via collaboratively-editing such as Google Docs.
• Concept Animator – creates renders and animations of the machine concepts for visualization and for functional explanation.
• Systems Engineering Breakdown – Successive breakdown of machine into modules, and successive breakdown of modules into submodules, down to the smallest assembly that is a useful work breakdown for an RFP. This breakdown involves generating conceptual and technical labeled explosion drawings.
• Interface Designer – for designing how modules fit together. Starts with conceptual design and ends with Technical Design.
• RFP Producer – takes Requirement and Conceptual Design (module and interface) and writes Requests-for-Proposals.
• CAD Designer/Draftsperson – converting concepts into technical drawings in CAD. Several people can do this, assuming that parts can be imported readily. OSE uses Sketchup and FreeCAD.
• Modeling – using physical scale models of prepared and on-demand-produced laser cuts and 3D prints for developing design in parallel with CAD design.
• Scale Model Video Instructionals – Physical Scale Models, if sufficiently accurate, can be converted into instructionals that are used in the life-size build – especially for models of heavy XYZ frames. Instructionals creator takes these models and videos them to generate step-by-step videos using open source video editing software.
• Graphics/Multimedia Artist – creates language-agnostic instructionals for building a machine.
• Videographer and Archivist – takes video of build and of the social process. Interviews people to produce documentary material.
• CAM Producer – produces CAM files for laser cutting, 3D printing, torch table cutting, CNC circuit milling, and CNC routing of parts.
• Instructionals Producer – takes CAD and then stationary screenshots for step-by-step instructions on Dozuki.
• Animated Instructionals Producer – takes CAD models, screencasts, and makes animated instructionals from CAD models.
• Zero to Maker Video Editor – writes scripts, takes video, takes animations, captures screencasts, uses title graphics, and other media assets and edits into media productions. In the elite form, edits videos of the whole chain from Concept Animations, Animated Instructionals, Instructional Scale Model Videos, and Real Build Video – to create powerful edutainment video of Zero to Maker quality.
• Photographer – photographs machines, takes photos for pictorial diagrams, and works with Systems Engineer, CAD Designer, and Technical writer to produce visual diagrams.
• Production Assembly Engineer – Takes pictures, CAD, and BOM (see Lulzbot Subassembly Visual BOM) and integrates these into Visual Production Drawings.
• Technical Writer – one who produces technical documentation, such as instructionals on Dozuki – producing these in realtime with the build.
• Collaboration Architect – the elite role – requiring understanding of the whole process and reaching out to various types of collaborators from geeks, engineers, and funders, to add energy to the effort. Organizes Design Sprints on focused areas in realtime with the build.
• Process Video – video production showing the entire process from A to Z.

Economic feasibility is a validation of the effectiveness of products. Just like we are creating construction sets for machines, we are creating a construction set for enterprise.

Open documentation and development provides a good foundation for developing enterprise. The promise of open is that innovation can be accelerated to an unprecedented rate. Open makes lean operation possible, including the ready ability to invite external contributors. Open development attracts contributors because of its ethical advantage – because openness is compatible with the common good. Both an ethical and practical advantage comes to the fore when open development results in the solution of wicked problems.

With open processes, the energy spent on protectionism is eliminated. Protectionism manifests itself in competitive waste – such as poor internal communication, power struggles in organizations, use of expensive hardware and software, high intellectual property costs, and in general a higher overhead because of added complexity. These points indicate that the open source business model can be more effective for the bottom line, while meeting social objectives.

Based on the technique for documenting and developing products via module-based design, we are developing machines in an order that allows us to both dogfood the products and to generate revenue from workshops. See the status of each of the machines on the GVCS Machine Index.

We carry most of our development during our Summer of Extreme Design/Build, though we accept people year-round. In 2014, we will emphasize swarming – using a group of 24-30 dedicated developers working on a single machine or module each week. In this way, rapid development and prototyping occurs on the time scale of a week – harnessing a weekly effort on the order of 1000 development hours. University students are encouraged to participate – though anyone can join. To apply, see the Dedicated Project Visit (DPV) page. If you can help us set up the DPV program at a university – as a summer internship, alternative break program, or as a course for credit – please contact us at info at opensourceecology dot org.

Please see the general plan for the 2014 Summer of Extreme Design/Build.