Talk:Development Strategy
Taking Open Product Development to the Next Level
http://blog.opensourceecology.org/?p=567
We have previously introduced an open collaborative product development process. Developing an effective open source product pipeline – as a worthy competitor to corporate research and development (R&D) – remains one of the hottest topics of the peer-to-peer economy. We know of no other comprehensive product development pipelines, with well-defined, applied methodology - outside of our own. That’s sad but true, and we welcome insight if we’re missing something here.
We have begun a process to get to world-class, open product R&D with the Global Village Construction Set – a set of infrastructure technologies for building the world’s first, replicable, off-grid, open source Global Village.
This process is in its infancy. The problem statement of reinventing the essence of civilization is not a light task. It’s a topic equivalent to hundreds of Ph.D. theses, combined with the hands-on work of thousands – nothing short of a social movement. It’s a social technology and process that massages existing technology into a more human-friendly form – also in harmony with natural life support systems. To us at Factor e Farm – developing an effective process for collaborative product development – is the most pressing issue that society faces today. That is because it is a tactical approach whereby people actually share. This concept has been discussed previously in scripture, pick your book.
Believe it or not, we’ve begun a template for directing such research in the open source context, and we have it on our wiki, since about 2 years ago, as the Development Work Template. This has to date remained an obscure methodology. We will be upgrading that page, as we apply a complete cycle of this process to our first product release – the Compressed Earth Brick press. We have hardly followed this development template ourselves – because it is a lengthy process and includes the production of real products, requiring a combination of global research and local labor, capital, and skill – not to mention a facility, tools, and other physical infrastructure for carrying out this task. The open source physical product development process is leagues beyond the open source software development process in terms of complexity and cost. We simply did not have the resources to carry out the process in a thorough fashion, so we just took the key points – such as design, some review, prototype, and testing – but many of the enabling details are still not easily accessible.
We begin with an assumption that the product choice is sound. Without getting into the details of product selection, we note that each product has been graded by replicability and economic significance criteria – as a point score - outlined in the Product Selection Metric discussion in the 2008 OSE Proposal. The 40-item Global Village Construction Set is open to change – so if you think that another worthy product is not included in the list, then please take the following steps:
1. Read the Product Selection Metric discussion 2. Calculate a rating score for your proposed product based on the product selection metric 3. Document the score at Product Selection Metric Scores for Other Technologies 4. If your proposed score is indeed higher than our other selections, then email us.
Assuming that we agree on the product choices for the Global Village Construction Set – what are the steps required to produce a given product in the open source framework? Take a given product, like the CEB press. The overview of our latest procedure and strategy that we came up with (as of this week) involves taking a few of the key steps in the Development Work Template, and adding several key, tactical strategy points. We look at the following diagram of the Collaborative Product Development Cycle and examine it in detail.
The design rationale is the key to the entire process of making a certain technology transparent to the point that it becomes replicable. If one is presented with a design rationale, one should be able to convert it into a conceptual drawing and a 3D drawing.
We need to clarify what design rationale implies from the open source product design perspective. We begin with the standard definition of design rationale from Wikipedia:
A design rationale is the explicit listing of decisions made during a design process, and the reasons why those decisions were made. It’s primary goal is to support designers by providing a means to record and communicate the argumentation and reasoning behind the design process. It should therefore include:
* the reasons behind a design decision – (DfD, lifetime design) * the justification for it – (OSE Specifications) * the other alternatives considered, * the trade offs evaluated, and * the argumentation that led to the decision.
We extend this standard definition to the particular context of open source product development. We call this the Open Source Design Rationale (OSDR) – a description that not only shows the standard design rationale, but additional details that make the design transparent to any entry-level student or developer of the technology in question.
In order to achieve this extension, we must consider that open source developers are nonspecialists functioning as technological integrators - or open engineers. As such, these open engineers do not possess many of the assumptions, biases, or ‘curses of knowledge’ of the specialist, and are able to take a more ‘innocent’ view of the technology. Therefore, the open engineer may not know some of the details of rigorous engineering design, so these details must be filled in.
This may seem like an onerous burden on the extent of the design rationale. However, there are two features of good design that make the creation of Open Source Design Rationale tractable. First, optimal technology is one with absolute simplicity. Second, the underlying concepts of how things work are often intuitive and explicable – not to be shrouded by mystery by the technological elites. Indeed, open source design rationale is the most important step to technological literacy of the population.
To sum up OS Design Rationale– it should be specific enough, and all the design freatures should be outlined – such that a nonspecialist would be able to come up with a conceptual drawing, and even a detailed 3D design – just by careful study of the OSDR itself. It should be noted that this is not what is found in patents. Patent claims document features in the most general fashion possible, while still making explicit claims on the technological or process domain. Patent claims are in no way sufficient for one to produce an exact implementation of a given device. Patents typically cover concepts or small parts of devices or processes – so one is left with much missing information towards being able to replicate a particular technology.
The design rationale should be complete up to the point that it allows one to create particular instances of physical form. Indeed, this design rationale should include sufficient detail, such that two distinct people attempting to convert a design rationale into reality would come up with identical implementations.
One should be able to convert an OSDR into to a digital 3D drawing. One should then be able to examine the 3D drawing, and be able to come up with a parts list for fabricating the object. The key to the 3D drawing is the ability to determine whether the design fits/functions as it should. It should also be possible to come up with a ready bill of materials from a 3D drawing.
The bill of materials (BOM) determines the cost performance of the technology. At this point, if the cost is unacceptably high, the design should be examined for possible materials/design changes. Only when specific materials/sources are considered can the changes be made. It is important to draw up a BOM, because without looking at different choices, it is impossible to evaluate the overall ratio of performance to cost. The arrow pointing back from the 3D Drawing & BOM step back to OS Design Rationale reflects any design rationale changes based on conclusions obtained from drawing up the BOM. It should be noted that this feedback loop is critical, as liberatory technology is one that optimizes cost performance – if one assumes that cost is related directly to the amount of effort required to produce something.
Before we move forward, we should note that product specifications precede OS Design Rationale, and are not included in the simplified Collaborative Product Development Cycle diagram above. We do not include it because it is assumed. We assume that we have selected one particular instance of product specifications, and moved forward to build this particular instance. There are inherently several instances for the general product specifications (see http://openfarmtech.org/index.php?title=Specifications) because of the scalability, modularity, or other features embodied in general product specifications. For example, a steam engine of two different sizes may be included in the general steam engine specification, but the OSDR must reflect that a particular size was chosen. In this sense, OSDR can be seen as an explicit continuation of the product specifications, and is not included in our Collaborative Product Development Cycle diagram for sake of simplicity.
Next we take the design to the peer review stage. This is similar to the peer review process of academic journals, where the community verifies content to make sure that it holds true under closer scrutiny. The equivalent for us is to submit the design for review to acknowledged experts, forums, and others. We list the possible reviewer under a Resource Map on the wiki, which is a list of possible reviewers and bidders for fabrication. Every review informs any OSDR changes, and we iterate this process until a design is finalized.
As an example, you can view the specifications for the os lathe here (sorry, the wiki is not as well organized for the prior work on the CEB press), the 3D Drawing and BOM for the open source lathe are here, and the reviews are found here.
As the development process continues, we post increasingly useful reviewers on the Resource Map, and we ask them to be reviewers in future work, to assure continuity for the project and to generate further involvement from the broader community. We then ask the reviewer for bids or suggestions on other bidders. When we identify 3 bids, we select one and invite the potential fabricator on-site to build. Factor e Home Team’s role is to document, as described at the Development Pipeline wiki page.
There are several keys to this process. By involving third party review, we aim to prove to stakeholders that the design is sound. By securing bids, we produce an explicit list of deliverables, and the capacity to deliver on time and to specifications by inviting experts. The barrier to this process is funding – but if we have sound design, an expert to make it happen, and Factor e Home Team to document – we should be able to generate crowd funding to pay for the development. It is as simple as ‘here is a guaranteed product, now contribute so you can see it happen.’
What exactly is the product? A demonstrated prototype and open design that can be replicated via DIY means, or purchased from us when we complete the development cycle through prototyping and testing up to product release. The value that we provide to stakeholders is at-cost production. People do not pay for the R&D costs in the product price – just the cost of the product itself. Remember that we already paid for the fabrication facility with crowd funding, so we are well on the way to at cost production, where we capture value of labor to allow for economic sustainability of the production process. This has potential to become a dominant method of production, simply because the end-user obtains the highest value and best service. The service is provided via an open source support community and open access to all relevant information.
That’s all for now on the topic. Please comment. We will be holding our first conference call to organize around the OS Design Rationale, where we will attempt to mobilize a directed team of researchers to tackle particular design and development points of the GVCS. Please go to the OSE Development Network for more information if you would like to participate in the teleconference, to be held this Friday, 9-10AM Central Time, USA (GMT –5).
