Re: [ox-en] Difficulties in moving from free software to free production

Hi list!

Another older post I only now find the time to reply to. Because it is
so long ago I quote fully.

14 months (449 days) ago Michel Bauwens wrote:
> I'm not going to talk here about the difficulties related to economics and
> ownership, but rather about technical issues, by referring to the work of
> Eric Hunting <http://tmp2.wikia.com/wiki/Main_Page>.
> 
> First, I want to get one issue out of the way: that of the interaction
> between immaterial design and the physicalization of the product. There is a
> lot more feedback required in open design than in free software, because the
> physical models have to be tested in the real world and the designs are not
> immediately 'executable'. While some engineers in my lecture audiences would
> regular voice this objection to prove that open design was impossible, I
> think that the reality of current trends and the different already existing
> hardware implementations <http://p2pfoundation.net/Product_Hacking>, make
> this issue entirely solvable. I have since found plenty of engineers and
> designers who concur that open design is entirely feasible. But feasible
> does not mean 'easy to do'.
> 
> There are indeed specific problems that make 'free production' more
> difficult, and I'll be quoting a recent email from Eric Huntingfor that. The
> issues are technical and perhaps difficult to understand for lay people such
> as myself, but they are crucially important.
> 
> *1. Moving from 2D to 4D*
> 
> Eric Hunting:
> 
> "*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*."

Just to mention: AFAICS that's perfectly the stuff the car industry is
coping with. They have exactly this problem on a large scale. And they
solve it.

When formulated as a vision: The means for a peer production based
society are growing in the old one. And in this case this does not
mean the mind set of people but the fundamental technology.

> *2. From single components to full assembly*
> 
> Eric Hunting:
> 
> "*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'*."

See above. AFAICS these problems are addressed already. I'd like to
emphasize that we need to look at how things are done in the most
productive areas of *capitalism* to see sketches of the future. This
is valid for software but also for mechanical construction. Of course
this is a quite different approach from the I-set-up-my-garden ones.

> *3. From planar graphical representations via 4D motion comics to DIY Maker
> Videos*
> 
> Eric Hunting:
> 
> "*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*."

This is very much the DIY and in particular the do-it-with-your-hands
approach. This might be a nice option for experiments but IMHO it is
not a solution on a large scale basis. On a large scale basis you need
machines who integrate all steps necessary to produce something
material.

> *4. The problem: how to make DIY Photography and Video 'collectively
> iterative', and not just individual remixes*
> 
> Eric Hunting:
> 
> "*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*."

I agree. And I agree also that we need a sort of language or other
formalization for it. I would be interested in what modern industry
can do for us here. May be they are already developing stuff like
this? A car manufacturer for instance has the real problem to combine
all these parts from sub-contractors to a car.

> *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*."

Most of what Eric describes reminds me more of a version control
system like Subversion or similar. This is a tool which allows a team
of developers to track versions of their software artifacts including
branches and so on. What Eric describes as a Wiki is IMO the mere
presentation layer for the things maintained in the version system.

Seeing it that way what we really need is a language / formalization
as described above and readily available tools working on them - for
software this would be Eclipse for instance. I could imagine that such
things could even exist somewhere already.


						Grüße

						Stefan
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: [email protected]