Clearly stated goals help projects run more smoothly
State Your Intentions
"maddog" advises designers and developers to state their project goals up front and in writing, to avoid confusion and conflict later.
I am following a flame war on a mailing list about a certain piece of hardware – a design project that has been going on for a long time. I am not going to name the project, because I don't want to embarrass the people working on it, all of whom I am sure are discussing it in good faith.
This flame war, like many flame wars, has to do with a long-standing set of expectations, based on a loose dialogue between various groups of people who have joined and left the project at different times.
Some people have called the device in question an "Open" hardware device, and others have called it a "Free" hardware device. Each person has a different definition in mind as to what this particular project is and what that definition means with regard to the project.
The issue comes down to the point where one of the main drivers of the hardware project is not willing to release all of the manufacturing information of the hardware, such as the commands to the surface mount technology (SMT) machine that places the parts on the printed circuit board and other information that would make it easy for some other company or entity to copy and manufacture the design. This person is willing to release the circuit diagram and programming interfaces to the various chips and other pieces of technical information of interest to programmers. He is taking this approach because he wants to manufacture the board and perhaps make some money off it.
It is reasonable for this person to make some money off the manufacture of the board – or even to make a profit, which might allow him to recover the expense of the design of the board. Even if the design of the board is donated by volunteers, with their great expertise given to the project gratis, typically large expense is still involved in trying to get the board manufactured and working.
Most board designs today are sophisticated enough that they cannot be wire-wrapped to prototype a solution, and even if they could be, the real savings in generating boards via SMT lines is too great to ignore. Eventually, the boards will need to be manufactured on an SMT line, or else they will cost thousands of dollars rather than hundreds or tens of dollars each.
Thus, somewhere in the manufacturing time line, the boards need to be prototyped on an SMT line, which is designed to manufactured tens of thousands of boards a week. To stop a line long enough to set up a sophisticated board and buy the components to manufacture a small run (perhaps, 100 units) and test for quality, capabilities, preliminary radio frequency emissions, power utilization, and other issues is very expensive. Just buying small amounts of components from companies who are used to selling in huge numbers is difficult and expensive.
After manufacturing these few boards, you might find mistakes in your printed circuit board layout or find "hot spots" that must be corrected, which requires more programming and additional testing at the manufacturing stage. While the SMT line is being used for this, it cannot be used to manufacture other items that are known to create revenue for the manufacturing company.
Three main areas determine which products and services are produced and come to market. Simplistically, they are:
A. Is there a market value for the product or service, and can that market (called a "channel") be reached?
B. What is the cost to produce the project or service?
C. What is the cost to design the product or service?
If B+C > A, then typically a product or service does not appear.
People who contribute their time and energy to the design cut down on the design cost C, so then only A and B really determine whether something appears.
In software, the cost of B is typically minimal, wherein people contributing their time and energy can have a dramatic influence on the price, with minimal "unit" cost. Thus, A can be extremely small, or even non-existent and still be cost effective for software creation and distribution.
In hardware, however, the cost of components, cost of the SMT line, and cost of testing and certification end up being real costs that must be met another way. "Kickstarting" and "crowdsourcing" are modern ways of dealing with these costs, but the people who contribute their time and money to a project need to know exactly, and from the beginning, what to expect.
Therefore, an Open/Free hardware project would do well to have a charter from the very beginning that spells out exactly the goals of the project, including what will or will not be published both to members of the team/community and to outsiders and under what conditions.
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?