Moving from free software to free production: what we need

From P2P Foundation
Jump to navigation Jump to search

A reflection by Eric Hunting:

1. Moving from 2D to 4D

“The development of a modular standardized graphical language was key to the rapid advance in electronics and critical to the eventual evolution of the industrial ecology of the later computer industry, as the logical structure of the schematic language logically compartmentalized the architecture of systems which, in turn, established a hierarchy of modular components and subsystems for the electronics industry to organize itself around. The frequency of reusability of a particular component with a particular set of functional features or a ‘boilerplate’ circuit in larger systems designs could define its potential market as a mass-produced product. But electronics has generally had the benefit of a two dimensional topology. Circuits have always been assembled on a flat board and (with the more recent exception of photonics interfacing) components have always interfaced in one manner, through simple conductive wire links. While finished product engineering has required skillful optimization of the ‘layout’ of components down to the dimensional characteristics of circuit board traces and component wire leads, generally volumetric organization of electronics systems has been unimportant and the simple rule of thumb of keeping your 2D lines as short as possible has been the basic design strategy.

When one moves to the realm of electromechanical devices one confronts a much more complex topology -a 4D topology because, while the artifacts are 3D, assembly in 3D requires a prioritization of component assembly order, which becomes another additional dimension. And you have many more ways components interface; electrically, photonically, hydraulically, pneumatically, mechanically in linear and rotary manners, chemically in the form of reactive processes, and so on.”

2. From single components to full assembly

“CAD/CAM today remains in the stone age because it’s still dealing only in the simple dimensional characteristics of single monolithic components -which works because current generations of digital machine tools themselves still only deal with solitary monolithic component production. None of them can do assembly or automatically transport product between each other for staged processing. So they don’t have to understand an artifact on any more sophisticated level -they don’t have to do anything more than run byte code like a printer. But future machine tools will feature more complex integration. Machines shops will be clusters of workstations where systems hand product off to each other in dynamic order. So there needs to be a higher level of characterization -a recipe for the production and assembly process associated with the design of an artifact. A collective ‘program’ for its creation. The one solution that has come to my mind so far for doing this is simulation, used alternately by human and machine intelligence. In other words, after one develops a physical design for an artifact as a collection of components in a particular volumetric form, one must break it down into an ordered production of parts and their assembly. This is done in a virtual environment (graphically represented for human users) that simulates the processes of production based on generic representations of fabrication processes and the topological characteristics of common machines. A manual definition of the production process can be done by a human user but, given sufficient detail in the simulation, machine intelligence based on procedural modeling can also work this out on a trial and error basis in the simulation. I call this process ‘Taylorization’ (after the (in)famous Frederick Taylor) and the resulting intermediate process software ‘ Taylor programs’.”

3. From planar graphical representations via 4D motion comics to DIY Maker Videos

“How do we characterize designs and their production recipes in a standardized was in the here and now for easy human communication and collaboration? This is a very old problem. For at least as long as language itself has existed, we’ve relied on static planar graphical representations of objects as a means to develop and communicate designs. But when it comes to translating that into process we’ve long had problems with it. Being able to ‘interpret’ design drawings into a production process, largely without any formal methodology, has been a key skill/talent among trades guilds and later engineers and it was the need to leverage this skill that precipitated mass production logic. Methodology has been ad hoc. Our first formalized characterizations of process may have come with the written communication of music and cooking, which both in-turn precipitated mathematics and chemistry. But it seems that it wasn’t until the turn of the 19th century that we saw a real breakthrough in this for manufacturing through the inventions of the cutaway and exploded view drawings, time-lapse photography, and the unlikely marriage of the Do It Yourself movement and comic strips! Early hobbyist literature tends to mimic cooking literature, with the addition of simplified forms of formal technical drawings and isometric drawings as employed in architectural design. But with the cultivation of a sophisticated line-art illustration tradition among the publishers of novels there was a cross-over of talent from comics where a sophisticated temporal language had developed from earlier traditions of action or drama illustration, going back centuries but reaching peak sophistication by the early 20th century. Comics are 4D. They have this ability to communicate time and motion and to manipulate time in the way cinematography does, yet much more concisely. By merging this with the cooking recipe style of organization you arrive at the ’step-by-step diagram’ or sequential line illustration strategy of representing fabrication processes which today has seen its most sophisticated expression in the instructions for Lego and other model kits and in the artwork of illustrators like Peter Auschwenden, famous for his work with John Muir and such legendary books as How To Keep Your Volkswagen Alive - a book whose blending of DIY graphics with the aesthetics of the California rock art and underground comix movements set the standard for style of illustration for all ’soft-tech’ and ‘green’ literature since.”

Unfortunately, line illustration became a dying art past the 1970s and, though much less talent-dependent than line art for technical illustration, computer graphics remains difficult and time-consuming with contemporary tools. Once more expensive than line art, today photography is now the cheapest and most accessible means of producing sequential imagery, even though it’s not as effective because it is less concise and less flexible, if you aren’t highly skilled with the likes of photoshop.

If you look at how participants in the Make and Instructibles blogs illustrate and present their recipes today you see a preponderance of simple photography and mimicry of the basic approaches of DIY media. I’m really impressed with how well these work as systems of representation and how, collectively, these communities of Makers are cultivating ad hoc an increasingly efficient set of presentation standards, though as yet no dominant format. But I wonder how much of this P2P productivity is being held back by the ‘art quotient’; by the need for better means of representation than digital camera snapshots can offer but which are simply unaffordable or impossible for lack of any available talent pool. The limitations of photography aren’t that bad for the small artifact that anyone can readily produce. But for much larger artifacts, the need to locally reproduce a version of an artifact in order to show in photos an innovation precludes the participation in design and innovation by people without the tools and means at hand for that. The most effective Makers are still measured by talent (and a diversity of talents), not just skill, knowledge, and imagination.”

4. The problem: how to make DIY Photography and Video ‘collectively iterative’, and not just individual remixes

“today’s Maker blogs only really support P2P participation through ‘iterative’ development. In other words, like a YouTube video, an artifact recipe is the sole province of an individual user. For other users to participate in improving that artifact (or just its presentation), they have to create a new version -iteration- of that design and a new recipe. Some people may devise far superior designs or techniques but can’t present them as well, so their improvements won’t be adopted as part of a definitive version. These blogs don’t seem to have figured out, as open source software communities have, how to implement a means of collaboration on a more elemental level because the whole recipe document is the minimum element of representation for the artifact and there still is no standardization in that yet. This is no big deal for the small artifact like a novelty lamp made from a laser-cut Parmelot box or some such but what about an open source car? People will always have varying levels of productivity at different aspects of development and production. Some are better at design, others at engineer, others at fabrication, others at testing and analyzing the finished article, and others at teaching other people how to make things -just plain better screen presence. So there needs to be a mechanism that allows participation at the level of these individual elements of a recipe and allows iterative evolution of these independently of the design.”

5. The solution: we need object-oriented wiki’s

“Thinking about how all this might impact the creation of the Open Source Everything archives, I arrived at the notion of a wiki-esque platform that was more dynamically object-oriented (rather than simply hierarchical as wikis tend to be) and which could integrate a very large spectrum of media associated with an artifact recipe. The basic organization would be by ’standard models’ of a particular artifact which might optionally have an associated family of ‘variant models’ with each model having its series of iterations. Each model, standard or variant, would have its own communications channels -most likely in the form of a discussion forum with several purpose categories including reports and an automated FAQ forum- and its own set of recipe elements. Variant models can be introduced by anyone as either true variants or as ‘contender iterations’ of the standard model, being promoted to a new iteration of the standard model by community consensus. Any variant might also have its own sub-variants which likewise can be promoted up the class hierarchy, or just stand-alone. Variant models could also merge on group consensus into iterations combining incremental innovations, thus allowing both divergence and convergence -usually culminating in new standard iterations- along the evolutionary path of an artifact’s design. Recipe elements would consist of design images, formal technical drawings, associated schematics and other diagrams, component lists, engineering break-downs and analysis, software files, and fabrication and operating instructions in the form of written, graphic, audio, or video instructions. Each of these would use the same system of variant and contender iterations within the context of that particular model, wherever they aren’t already using a standard model recipe element. They get promoted with the model they are associated with if that model becomes the standard. This whole archive would be object oriented so that if an artifact is an assembly using another artifact as a subcomponent, all references to that subcomponent link to its standard or variant model front page and its component design illustrations can be incorporated in media for the model using it.

I’ve also assumed this archive would need to include an archive of technique in addition to specific artifact recipes. This would essentially be courseware associated with particular tools and would be composed of a package of instructional media for a particular tool or technique with an associated discussion forum and again employing that same strategy of standard iterations and variant and contender iterations.

This seems to largely parallel the approach with things like SourceForge so this might not be so far out in feasibility. But there would need to be standardization in recipe element file and document formats even when incorporating this media diversity and here, again, things get problematic with the key fabrication and operating instructions because of the inability in establishing any definitive standard in sequential illustration without imposing a minimum standard on artistic quality and, hence, talent overhead. Trying to impose a specific style, like that of Lego, becomes a stumbling block if everyone can’t produce line art on that level of sophistication.”