- TOTEM: learning by experimentingPosted 7 days ago
- Google Assistant Voice Controlled Switch – NodeMCU IOT ProjePosted 4 weeks ago
- Water Softener Salt Level MonitorPosted 4 weeks ago
- Sparkly Air SensorPosted 4 weeks ago
- Ultra sonic distance finder with live statusPosted 1 month ago
- Windows interface to have total control over lampsPosted 1 month ago
- Smart AquariumPosted 1 month ago
- Wearable ProjectionPosted 1 month ago
- Write programs with the Arduino Web EditorPosted 1 month ago
- PRO MIDI 1284P developer’s boardPosted 2 months ago
Why You Should Document your Open Source Hardware project
It’s just few months that I’m strongly involved in the open source hardware movement and, despite I still not have a clear idea of how this community is composed.
I’ve got some impressions, especially by talking with lots of fabbers and makers, one of them is, luckily, my brother in law that built a CNC milling machine basically from scratch in his garage. I often enjoy talking with them, trying to know what are their plans, interest and attitude towards the community.
First, the oshw community is really vertical, with people focused on their own projects, industry or interest: they often want to build and stop talking. Especially when you start, you only want to build the thing and this often ends up in fairly unplanned activities that make building stuff a fascinating though challenging experience where you learn a lot.
Second, my impression is that creating an open source hardware project is terribly time consuming and leaves no or little room for other, side, activities. At some point by the way, often when one finishes the first iteration of a given machine, what a maker does is building a second one, often dismantling and reconstructing (with refined parts, new materials) the creation from scratch.
This specific moment, that moment when you start working on the refinements of a product to create the second version, could be a great moment to document your invention.
In fact, when you start again the production process, you already know how to do things, and also, you know what are the most complicated moments in the building process and you could leverage on this information to create compelling guidelines for folks interested in replication.
I know: unless you are really committed to sharing, documenting your project is something that you, as most of the makers out there, don’t really love to do.
Software developers have been fortunate for years: software is modular and you can easily get into the details of the implementation thank to the fact that software can be inspected. Think about the fact that software actually embeds comments and is based on standard interfaces (making it basically self documented). You don’t need to take pictures of “how to mount different classes together” because it’s part of the programming language you use.
There are several platforms to create (like Wikis or Blogs) or host the documentation of your project: platforms like Knowable, Instructables, Alchematter. Also we have several approaches to documentation like those used by Sparkfun, Adafruit, Make and others. This specific issue was part of the discussion we had at the first Open Source Hardware Documentation Jam looking for more standardized approaches.
But, independently from the platform you choose, there is an intrinsic aspect of documenting your project that is indeed important, and makers shouldn’t forget. When you document your design, invention, project, you end up generating an actionable piece of knowledge that will be, no doubt, useful to some other folk (the ecosystem is getting wider and there’s an increasing chance you’re working on something that other people are looking for).
At that point in time, what is likely to be sparked – as for my experience that, by the way, might be different from yours – is a, very likely, act of collaboration and a social interaction between you and other peeps that share your very same interests. Someone could just bump and say: “I’m working on something similar why don’t we meet or just hangout online”, another could say “I want to reuse this clever solution” or even “I was looking for a co-founder for my company”.
You shouldn’t underestimate the potential of these interactions: these people might become, within time, your advisors, co-developers, team mates or even, as said Co-founder, as the perspectives in making innovative hardware are growing every day. There are big opportunities about creating businesses around open source hardware projects and, typically, doing this requires a lot of different skills: you need social media expertise, web development, PR, maybe crowdfunding know-how and the web is the right place to find it.
You might not be already thinking about the possibility to become an oshw entrepreneur but maybe your very same project resonates with the vision of other people and a joint venture between you and them could end up in your next job.
At least you could made new friends. That’s how a community grows, by sharing.
Sharing more, having more contexts for discussion, even in face 2 face, real life events (we are thinking about launching these kind of format for the OSHWA, as part of my International Branches Chair involvement, very soon) will create more opportunities.
The promises of open source hardware are still way too far from their potential and we need to grow more community around that, community means opportunities, and we shouldn’t let them go.