Open Source Development Pipeline Continues to Flow

How does one reinvent corporate R&D by using open source methods? We missed a couple of details in yesterday’s hairy diagram and explanation. Now it should all be clear:

Now a couple of words on the above.

Yesterday’s post covered the left part of the diagram, which includes primiarily the technical due diligence steps necessary for developing open source products. To this, we must add an ounce of strategy – with a pinch of expert involvement.

We have already concluded that our work is not so much a technology development effort as much as it is a social technology development method – simply because all the technology that we are working on already exists, and we are just trying to repackage it in a meaningful whole. This means developing the interface between people and technology, which is a question of strategy. I must admit that I am shocked at how little creative imagination is left in this world – which certainly is affecting our ability to expand peoples’ index of possibilities. The most difficult part about this work is that people tend to suck – not because they are born that way, but because they are systematically deskilled and demoralized in a world that’s racing to the bottom. I am quite optimistic about possibilities of change, where human creativity may be beat down, but the human spirit remains impossible to destroy.

The needed strategy consists of involving experts and building on past work as much as possible. Reinvent not the wheel, but step on the shoulders of giants. The Resource Map component – the part on the right hand side – has been added as a point of development strategy. The resource map contains supporting information focused on each project, such as Collaborators, Consultants, Proposal Writers, Reviewers, Publicity Support, other Developers, Fabricators, Bidders, Rapid Prototypers, Tool and Material Donors, Handbooks, Industry Standards, lists of Funding Sources, list of Stakeholders, and interested Preorders of products. All these items are not specifically the design aspects of open product development, but instead, the support pieces that can expedite open product development.

Here are some further desciptions of how some of these items work. Industry Standards are the baseline performance comparisons. If we want our products to compete in the marketplace, we must first understand the performance and design standards already delivered by mainstream industry. These industry standards reveal the commonplace way that something is done – and this may or may not be consistent with OSE Specifications of ecological design, replicability, modularity, lifetime design, localization, low cost, and flexibility.

OSE Specifications are our basic design filter and guideline. If two people consider the Product Selection Metric and OSE Specifications together, they should in principle conclude the same or similar design for a product instance – whether that instance is an integrated product ecology, a single product, or the component of a product.

Consultants from a list at the Resource Map can be tapped for rapid analysis and answers on design issues and other topics. Proposal and Grantwriters are those people that can take the information in the Open Source Design and convert it into a budget and an entire business plan or enterprise proposal. Reviewers are those experts who can verify parts of the design. Publicity Resources are those who can assist in recruiting new developers or contributors – optimally through mass media channels.

Developers are the key resource on the Resource Map. Those are the people with a considerable attention span, who could carry on development due diligence. These are the people who facilitate all the work in open product development, including adding resources to the Resource Map. Developers should feel that they are a part of a team – so a start to that is signing up with contact information and, preferably, a picture.

One of the keys to the entire process is Review – which is the only proven way for someone to actually build upon the sum of all human knowledge. If one does not expose one’s work to full and transparent review, there is little chance that one will come up with the best solution, and even less chance that obtaining that solution has come from an effective process. This is the whole point of the internet economy – the unprecedented possibility of accelerating learning and collaboration.

I understand clearly that there is an innate tendency to move forward on action without proper review – for a wide variety of reasons, internal and external – most important of which I think is indoctrination from an economic system of scarcity. Everyone tends to rush without asking what is worth doing. Not undergoing review is a design for failure – because only by a wide review can someone actually even hope to evaluate all options properly.

Lack of transparency or review is also the reason why I think that today’s major corporations will fail in the future – unless they adapt to the culture of open collaboration. It simply costs too much to derive answers in a proprietary fashion – because all answers build upon a great ocean of already discovered knowledge. Getting new answers is becoming increasingly expensive, and as more knowledge is freed up, this knowledge begins to pose a serious threat to closed knowledge. The only way that corporate monopolies survive is by stringent intellectual property restrictions – which becomes increasingly expensive as companies hold increasing amounts of proprietary knowledge. Corporate bullies will continue to look for routes to monopoly –  and they insist on increasingly streamlined IP protection schemes, so freeing up knowledge will continue to be a challenge.

Politics aside, the review process is the key to not burning holes in your wallet with failed design. It simply makes sense to ask for advice via review – and one does not have to repeat failed approaches. Given that doing physical prototypes is much more expensive than obtaining review, it makes economic sense to push review to the limit of full understanding – rather than finding out unsavory details after something is built.

It does not mean that pushing forward cannot be useful – but if one’s goal is to develop optimal products, there is additional incentive to leapfrog dead ends. A dead end may still work well, but if it is not working optimally, that’s a failure from our point of view. It’s just unnecessary resources wasted. Review, review, review – until the point where reviewers are consistently telling you things that you already know. Institutes, professors, researchers, university people, consultants, professionals, and retired people from industry are good candidates for serving as reviewers.

The resource map lists bidders, who tell you how much it would cost to produce something. The point of the development strategy – if it’s to be scalable – is to perform all the due diligence, including bids, so that a funding proposal can be written with realistic deliverables. If several bids are available, then the process can guarantee to the funders that the product can be delivered. Rapid Prototypers can be one of the parties who are asked to bid.

People may be asked to purchase on a pre-order basis once a certain product is far along in development. Stakeholders should be identified as potential funders and collaborators – on the basis of their interest in a working product – to be delivered at a predicted cost at a later date. Some Stakeholders may be willing to provide Tool and Material Donations as a form of their investment. References and Handbooks can provide supporting design details, historical studies, or any other supporting information for the entire development process.

So if you read this, and the last post – you should be ready to step up to the plate and start filling in the information on the Developement Work Templates for different projects. You’ll know the status by simply observing how much of the template is filled out. You should note that the template contains just about the identical information fields as noted in this post. This post is the latest word on the topic, so it is more fitting ot start pages with the different fields mentioned in this post. All the development should be placed on a category for a given project on the wiki. Pages should be further categorized to belong in the Resource Map category, or OS Design Rationale category, for a given project. This should become increasingly transparent as the CEB press will undergo this full treatment.

This is in no way a trivial process that we are describing here – but the fruit of a scalable development process for open hardware is definitely worth many attempts – especially if the product line is the infrastructure for the world’s first, replicable, open source, off-grid Global Village with all the trappings of modern society – minus geopolitical compromise.