[Open Manufacturing] Open Design Aphorisms
Bryan Bishop
Adaptations of Raymond's Aphorisms on Effective Open-Source Development
http://www.engr.uky.edu/psl/omne/OpenDesignAphorisms.htm
"These aphorisms were derived from a larger set of aphorisms compiled
by Eric Raymond in his paper title "The Cathedral and the Bazaar" [1].
In this paper, Raymond hypothesizes that the Open Source approach to
software development is successful because it capitalizes upon certain
"truths". Several of his aphorisms are more generally applicable and
especially applicable in Open Design. Therefore, the following list
was compiled to provide an inspirational guiding-hand to Open
Designers.
1) Every good design starts by scratching a developer's personal itch.
2) Good designers know what to design. Great designers know what to redesign.
3) Plan to throw away one design. You will, anyway.
4) If you have the right attitude, interesting design opportunities
will find you.
5) When you lose interest in a design, your last duty to the design is
to hand it off to a competent
successor.
6) Treating users as co-designers is the least-hassle route to design
improvement.
7) Release designs early. Release modified designs often. And listen
to the customers.
8) Given a large-enough beta-tester and co-designer base, almost every
deficiency in a design will be discovered quickly and the fix will be
obvious to someone.
9) If you treat co-designers as if they are most-valuable resources,
they will respond by becoming your most valuable resource.
10) The next best thing to having good concepts is recognizing good
concepts from your co-designers and users. Sometimes the latter is
better.
11) Often, the most striking and innovative designs come from
realizing that you were solving the wrong problem.
12) Perfection is achieved when there is nothing more to take away,
not when there is nothing more to add.
13) Any design should be useful in the expected way, but a truly great
design lends itself to uses you never suspected.
14) To solve an interesting problem, start by finding a problem that
interests you.
15) Provided that a design coordinator has a sufficient medium for
sharing designs (like the internet) and can lead without coercion,
many heads are inevitably better than one.
References
[1] Raymond, Eric S. "The Cathedral and the Bazaar". Presented at
Linux Kongress '97. The paper is available on-line at
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/. The paper is
also included in a larger work: The Cathedral & the Bazaar, Musings on
LINUX and Open Source by an Accidental Revolutionary. O'Reilly and
Associates. Copyright 1999."
ESR's essay had quite the impact:
"The essay helped convince most existing open source and free software
projects to adopt Bazaar-style open development models, fully or
partially — including GNU Emacs and GCC, the original Cathedral
examples. Most famously, it also provided the final push for Netscape
Communications Corporation to release the source code for Netscape
Communicator and start the Mozilla project."
marc fawzi
Provided that a design coordinator has a sufficient medium for
sharing designs (like the internet) and can lead without coercion,
many heads are inevitably better than one.
>>
In summary, the first issue is whether to have N people work on 1 design at a time or N people work on N designs. The second issue is whether to let emergent cognition/experience of a shared reality decide the outcome (works great per my experience) or if you actually force a decision subtly/diplomatically or coercively (doesn't work per my experience)
Massimo Menichinelli
http://www.airoots.org/?page_id=419
1. NEED IT: Necessity is the mother of invention. What do you need, as an individual and as a community? It is not for master planners to guess what people need. Stakeholders should speak up.
2. GET IT: No need to reinvent the wheel again. Lets find what works elsewhere and adapt to the local/present needs and then expand it.
3. DO IT: You don't really understand the problem until after you start implementing the solutions. It doesn't have to be an all out "redevelopment", we can start small and gradually build knowledge and best practices. This will develop the social and cultural capital of the community.
4. BE OPEN: With the right attitude, interesting (and unexpected) issues will come up and make the plan & development better.
5. SHARE: Do not feel proprietary about the plan. Or rather, let other people feel proprietary about it as well. The common goal is to have the best/optimal solution for all.
6. CONTRIBUTE: Residents should be co-planners and co-developers. The concerned population is the biggest asset for and of planners.
7. COMMUNICATE: The plan should be publicly accessible to all concerned parties at all times. Updates should be frequent so everyone has access to the latest information and can react immediately. Say what you have to say and listen to what other people have to say and immediately incorporate it. It can always be modified/adjusted along the way.
8. CONVENE: If we have enough people looking at different aspects of the plan, any issue can be recognized and addressed quickly. Finding the issues is the biggest challenge. Once identified, someone will have an idea about how to solve the problem.
9. INCLUDE: Finding an efficient way to get everyone's input is more important than the inputs themselves. A lot of time and attention should be spent to cultivate the community's active participation.
10. ACKNOWLEDGE: If participants are treated as the most valuable resource of the plan, they will become the most valuable resource of the plan. Contributions should be acknowledged and valued.
11. PROCESS: We should strive to activate the collective intelligence of a community, which also means processing, selecting and incorporating good inputs into the plan. This may or may not be the task of a sub-group of people acting on behalf of, and accountable to, all stakeholders.
12. BE CRITICAL: Realizing that our concepts are wrong might lead to the most striking and innovative solutions.
--
Massimo Menichinelli
openp2pdesign.org