Calendar
| « January 2009 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Today | ||||||
RSS Feeds
Links
Navigation
Social Bookmarking
Open source has flourished because software is "infinitely-reproducible".
Physical objects are not so easily reproduced but the information for making them is.
ProtoForge.org
The Problem of Open Hardware (Part 1)
A few intrinsic aspects of software development have been key to the success of opensource software:
In the case of open software it is only necessary for an individual or group of individuals to donate their time to a project in order for it to be successful and useful to others. Often the payment for these individuals' time is simply a sense of contribution to the common good whereas some institutions have opened their sourcecode in the hopes of increasing the usage and the quality of the software according to point 3.
Also, in the case of software development the division of labor can be easily managed with a simple versioning system such as CVS or its younger brother, Subversion. The fact that software has no recurring manufacturing costs makes it unimportant for the developers to come to a clear agreement on what the software is to do before development begins. It is sufficient to have some general consensus on the purpose and desired functionality and allow the software to evolve throughout the development process. If the software ends up with much more functionality than what was originally intended it is irrelevant because there is no extra cost for downloading those extra features.
Hardware development on the other hand differs greatly in points 1 and 2 and point 3 becomes a great deal more important for the success of a project.
With hardware it becomes clear that more than just the developer's time is going to be needed in order for a project to be successful. This is "the problem of open hardware". What is it that we need in order for open hardware projects to be successful? How can we establish a well managed process for the division of labor?
Stay tuned for the answer in Part 2.
Posted at 02:57AM Jan 24, 2008 by Aaron Schultz in General | Comments[2]
Hey Aaron. I was thinking about point #3 in your open source hardware list. Do you think that there might be a peak in the graph of number of developers vs. quality? It seems to me that there is a maximum number of people working on something, beyond which the system gets mucked up -- something like "too many cooks spoils the broth." What do you think?
Posted by Kirk on January 28, 2008 at 07:18 AM MST #
Hi Kirk, thanks for the comment.
I believe that in a situation where all the participating parties agree on and abide by a strict set of well understood rules as well as participate in the enforcement of those rules the problem of "too many cooks" goes away. It may be true that the more people you have involved in a project the more likely it is that those people will ignore the rules in order to obtain their personal goals. But as long as the great majority of the people involved in the project believe in and participate in the rule system then "the more, the merrier" becomes the status quo.
Take wikipedia for example, it has done very well and attained very high quality because there are so many good people involved in checking and balancing. Another example would be the United States constitution. As long as everyone believes in it and abides by it we have seen that a system of laws has been developed to govern as few as 4 million citizens (1790 census) to as many as 285 million (2000 census).
Protoforge is meant to provide a similar environment for engineers where the rules that define how a large group of people interact to make decisions and document the design of a system are hard coded in the software. As long as the great majority of the project members attribute value to this rule system and use it in order to pursue the end goals of the project rather than their own personal goals I feel that point 3 will remain valid no matter how many people are involved.
Posted by Aaron on January 30, 2008 at 06:55 PM MST #