Message 04758 [Homepage] [Navigation]
Thread: oxenT04758 Message: 1/1 L0 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[ox-en] Fwd: from free software to free production, difficulties and solutions

[Converted from multipart/alternative]

[1 text/plain]
should be of interest to this community:

(my own reworking of the text may be a little more easier to understand, see
above, below is the original email)

---------- Forwarded message ----------
From: Eric Hunting <erichunting>
Date: Sun, Aug 10, 2008 at 11:23 AM
Subject: Re: open design for physical manufacturing

This sounds great. I'm particularly interested in the design
characterization/presentation standards you're working on. This is something
Bryan Bishop and I were discussing a while ago in the context of how to
define a digital characterization of a design -or 'recipe' as I call them-
that was both human readable and machine readable and incorporated the
necessary programming for next-generation machine tools. I had also been
mulling this over with the proposed Open Source Everything Project under
TMP2. (a revision of Marshal Savage's The Millennial Project I've been
working on)

The Pattern Language idea seems promising but also subtly complicated. 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. I gather that the pattern schematics
on the Pattern Language page are characterizing artifacts at a very high
level so maybe that much detail about system/component relationships is not
necessary. But I did find it difficult to interpret the functional
relationships of subsystems until the diagram with the green flow arrows
added because it wasn't apparent what the rules of system
relationships/interface relative to the 2D order were. Perhaps this is still
being worked out? I'm wondering if, because of the ultimate topological
complexity, it's even possible to develop a graphic language that works at
as low a level as electronics schematics do.

Bryan and I were discussing this in the context of the design of a Matter
Compiler; a software platform intended to mediate between human and machine
modes of design and fabrication characterization so as to allow for a
standardized digital format for the global communication of fabrication
software. 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'. This procedural modeling would then
again be used at the machine shop level where the generic recipe for an
artifact is adjusted to suit topological and performance differences among
machine tools on a brand/model level before final 'compilation' to a
bytecode stream to control the actual production in the shop. (mind you, I'm
no software engineer so I can only talk about this at a high level)

But that's the future. 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.

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

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.
And with people's means and talents varying so, you have this mix of line
art, CGI art, photography, and hybrids of any of these to deal with along
with broad stylistic variations in each type. So I'm still, myself,
wrestling with that dilemma. I've assumed that, at a certain point, it would
become necessary for the Open Source Everything Project, as an organization,
to establish a staff talent pool to facilitate the standardization of
graphic styles for this. But that seems to be inherently flawed given the
potential scale of things. You could never find enough artists. I have a
hard enough time finding a few illustrators for the TMP2 project...

Eric Hunting

On Jul 31, 2008, at 10:34 AM, Marcin Jakubowski wrote:


Michel and I talked last night of setting up Product Forge. At a ready
implementation - it could be a place where PHYSICAL product or process
development efforts could host their projects. This would be analogous
to product forge. It would basically be a one-stop shop for
communicating to the world all the open source physical products that
are being developed. It will be a communications, recruitment, and
funding tool. Crowdsource funding baskets can be attached to each

We need to get our minds together to determine the design of the
website and standards of the products featured. There should be a
clear way to determine deliverables, assess progress, help out, etc.
To facilitate this, a Product Label of some sort should be defined to
make the quality/progress/needs of each project transparent. We should
define: a format for the website, standards for website entries, and
standards/assessment of products themselves.

I also think that important projects should be assisted and even
initiated, as opposed to

How to define importance, product selection, product standards? I ask
you all to help define the standards/needs/other issues further, and
come up with consensus on the website. I think we should apply for a
grant of some sort to have a full-time manager for Product Forge.

From the OSE side, we'd like to include the following ratings/standards:

1. Evaluation of open source and ecological features of product - such
as in the OSE Specifications -

2. Evaluation of economic significance of product. We have coinded a
Product Selection Metric back in last year's proposal:

3. Technology follows Open Source Technology Pattern Language -

4. Product development cycle should be refined/standardized via
Product Forge. We have an initial thoughts on a process -


The P2P Foundation researches, documents and promotes peer to peer

Wiki and Encyclopedia, at; Blog, at; Newsletter, at

Basic essay at; interview at

KEEP UP TO DATE through our Delicious tags at

The work of the P2P Foundation is supported by SHIFTN,

[2 text/html]
Contact: projekt

Thread: oxenT04758 Message: 1/1 L0 [In index]
Message 04758 [Homepage] [Navigation]