(This post is part of an OSHW DOCU Project)
(Update: I created a project where we develop a simple prototype experimenting this idea. See how far it has grown.)
Last week i met Jérémy Bonvoisin. Jeremy is researching at the IWF in Berlin on IT-solutions for documenting and collaboration on open design. We talked only for a minute but he said something really interessting. „Open structures“ he said „that ist he only guy who really has a model for open collaboration.“ He would have probably explained this, if we had more time.
But, Yeah! I like that thought. Open Structures is: „a modular construction model where everone designs for everyone on the basis of one shared geometrical grid. It initiates a kind of collaborative Meccano to which everbody can contribute parts, components and structures.“
A shared grid. (!)
The Input-Process-Output model i want to promote and experiment in my open-source-hardware-documentation and collaboration project has similar qualities.
The idea is, that the surface grid for documenting any peace of hardware, design or process is a table with 3 columns: Input | Process | Output
The process-column is individual and could be different for every object or process. Add some files, descriptions, links etc. For the carrot-soup a step-by-step tutorial could be good here. The final peace of software could work here like wordpress: different plugins available to fill this column. Whatever is needed.
|peel the carrots;
|water & pepper to a pot
|cook it 20min
Maybe the output-column is the interessting turn in this approach. Here you list all of the outputs the process has. Cooking carrot-soup does not only produce soup but also steam and carrot-peelings.
|peel the carrots;
|water & pepper to pot;
|cook it 20min
The clou is the modularity or connectability of that design: Every output could become an input for another process. Feed the pigs with the carrot peelings or use the steam to heat up some dumplings on top of the pot.
F E E D t h e P I G S
|feed the pigs
|. . .
|. . .
|. . .
The different tables can be connected linear via linked Outputs and Inputs!
But this also means, that every item in the input-column has potentially other tables describing how it got produced. The carrot-soup table has also a description of the production of carrot-peelings and steam in it. If you use carrot-peeling as an input for another table you can go back to the carrot soup table to studay where the peelings potentially come from.
Every table (lets call them „process-modules“) describes a process. For most people the main-outcome of the sketched process-module above would be the carrot-soup. And as well as carrot-soup can become an input for another process-module (e.g. a „dinnerparty“) every input-item of the carrot-soup-process-module could be described with an own process module. carrots are produced with earth, a seed, water and time in a growing process.
You can connect and combine modules in different ways and create with them very simple as well as very complex descriptions. But you always use a the same module strucutre for your description.
If you have a complex project or object you could use a lot of simple modules and connect them (the engine, the breaks, the doors, the window, the tires of a car have own modules). Or you could just put everything into one module (you describe how to make a rubber tire in the same table/module where you describe how to put the whole car together). But if you have issues with individual items in your input-list, just create an individual module for them. By that you reduce the complexity within the main module.
This allows you to go as complex as you want. You can keep it simple and say in the input-column just „motor xy, bought in hardwarestore z“ and end it there. But you can also add a motor-module, and describe the building of that motor.
But everything stays connected with this simple grid ..output=input-p-output=input-p-…
(And as for closed material cycles: You have in every module with the output-column the build in feature, question and possibility for closing material cycles. (Which provides even more ways to connect, locate and invent things.))
Jeap, this works like open structures. Transforming everything into a process-modul and all process-modules can be connected to each other – open and decentralized!
. . .
I will meet Jeremy tomorrow morning, hope to discuss this with him.
UPDATE: Meeting Jérémy was great! Amongst other things we discussed the model above. I add here some things found to be key for understanding the concept.
First of all, keep in mind that the goal is to build a decentralized system as described in Posting #1. We don’t want to have centrlized platform. We prefer free flying and copied documents. The software should work somehow like wordpress: open source and distributed.
With this in mind:
Most products are a combination of other products. So you can go back the chain and reduce the complexity of one module by linking to others. Maybe the other modules are made by others. That enables an decentralized collective documentation process.
Different projects host their modules on their own servers and in their own versions. But others can copy (download) them and modify them. Like on GitHUB this creates a new version number for the module. If you like, what others do with your module, you can merge back in their changes into your module.
There is no obligation to use the module of the motor created by others. If it is to complex for you or you don’t like the wording, just change everything or create a new module. Or if you have no need for the module at all don’t use it. Having just „motor xy“ in the input-list is probably enough anyway. Because the system has no limitation, how complex you create, gather and arrange your modules, you have to do a cut somewhere anyway.
Memes! Think of this as a decentralized meme-creation. In a centralized system you have to force people to use the same word for the same thing. This is not the case here. Everyone can use an own wording – call the „motor xy“ „butterfly“ for example or what ever. But good modules get copied. And when others copy the module, they also meet the chosen words and will probably adapt them. This allows a decentralized process of evolution (mutation & natural selection). New words and solutions appear and the best words win and spread and also the best modules. The power of open innovation with utmost freedom for everybody.
Evolution of the tool: „… a great tool lends itself to uses never expected.“ A good tool is easy to use and useful. But it leaves room for creativity and for reinventing itself. Think of Twitter. The 3 things that make twitter today basically what it is are (1) retweeting, (2) @replys, (3) and the use of #hashtags on twitter. All of this was invented by the users of twitter and not planned or forseen by its inventors. Those behaviours or techniques emerged out of the tool. Solving the problem of open hardware documentation and collaboration is a big task of our time. And an easy to use tool that provides utmost freedom for creative adaption and focuesses on networking/connecting things pushes the odds for emergence and is probably a good starting point to move fast forward in solving the documentation and collaboration problem. And three column table modules that can be connected in many different ways looks like an interessting condidate for that in my eyes.
Ok. So far for now. Jeremy want’s to write down his ideas from our meeting – make an own version of this. Great! So the idea developes. I am really looking forward to read, what he will write. Hands on solving problems people!
I want to suggest a name for this: IPO, or IPO-tables, or IPO modules (Input, Process, Output)
UPDATE: There is a webpage and project on this now: http://ipotables.net
A little comment on this: when an ecological economy is the future and open source is the method for communication for this, we still have to figure out, how the communication will look like exactly. And i think IPO is an interessting approach.