Message 05912 [Homepage] [Navigation]
Thread: oxenT04761 Message: 2/2 L1 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

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

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 <>, 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

*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

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

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


Contact: projekt

Thread: oxenT04761 Message: 2/2 L1 [In index]
Message 05912 [Homepage] [Navigation]