Hardware Reference
In-Depth Information
as users of academic research lab equipment. Make sure you are defining terms and keep
assumptions to a minimum about what your audience might already know.
A great source for project leads is often the community: see what they have made and
if they are willing to write up a guide and share it online for future members. If you are
just starting from scratch, make what interests you; chances are, it will interest others, too.
FAQs
Frequently asked questions (FAQ) are often as important as the introduction to the project.
A good FAQ will cover the basics, from how to contact the primary developers, to the level
of skill required to start the project, the amount of time one can expect to spend on it, costs,
and tools, to more detailed information such as how people can contribute (in terms of de-
velopment or other forms of capital). It might also cover logistics such as shipping, con-
tacting founders, testing, or finding answers to more questions (e.g., Twitter handle, com-
munity forms or list, email contacts of the leading developers). The FAQ section can also
include things about your project you initially forgot in the original documentation, like
“gotchas.” Gotchas are “oopsies” that can be considered quick fixes the user can make.
Another option is to provide your users with some simple troubleshooting tips to make the
product work better (or at all). For complete troubleshooting advice, refer to
Chapter 13
.
Creating Community
A strong community depends on strong content. Community building can take as long as
building your project, often even longer. If you are lucky, your community will develop
along with your project. Power users become sort of community managers, answering
questions before the primary developers even read them. Typically, you will want to intro-
duce a group of “power users” as early as your idea is born. It is not uncommon that these
power users at some point join the primary development team.
One of the best pieces of advice I received when starting to develop open source hard-
ware projects in the late 1990s was that I should cultivate a group of people who could
shape the community in a direction that encouraged contributions, growth, questions, and
answers. The catch? I needed to find them, and I needed to invite them. I had to find
people who I could ask to participate, give feedback, and contribute before there was
much tangible work to do. In addition, they had to be somewhat knowledgeable about the
project in some aspect (e.g., code, hardware, troubleshooting, teaching). I tried to find
people who came from a broad range of backgrounds, each of whom I could count on for
some period of time to contribute to the community in his or her own ways. A program-
mer, a hardware hacker, an artist, a handful of old professors, and peers from previous
classes were all possible options.
