[Discuss] Translation to Spanish for "Best Practices for Open-Source Hardware"

Thu Oct 17 21:15:43 UTC 2013

On Thu, Oct 17, 2013 at 11:24 AM, Mario Gómez <mxgxw.alpha at gmail.com> wrote:

>  Hi Matt! Thanks for sharing!
>
> It seems very complete tool, definitly we must try it! It would be really
> helpful for doing project management. I'm going to suggest it to Emilio.
>
> However one of things that I personally like about distributed versioning
> systems like git and using a "simple" template is that you don't depend on
> a system or platform to share and collaborate. I mean, if GitHub goes belly
> up tomorrow you still can work, collaborate and share your changes latter
> by other means.
>

 Well, like most things in life there isn't one best way to do something,
there are just tradeoffs. A simple template is great if the project is easy
for the participants to understand. That's a function of the objective
complexity of the project and the ability of the participants to deal with
it. Even something as seamingly simple as a chair can grow into a complex
project (AtFAB<http://www.treehugger.com/eco-friendly-furniture/atfab-launches-flatpack-furniture-made-through-networked-distributed-manufacturing.html>).
And even when you have an entire customer service department dedicated to
creating extensive, validated instructions for assmbling a chair, there
will still be people who don't understand (IKEA
furniture<http://www.washingtonpost.com/blogs/compost/wp/2013/08/16/some-assembly-required-the-lies-of-ikea-and-beyond/>).
In an open source project, the core developers are capable of handling a
lot more complexity than the casual tourists. You can have a simple
repository, where you just dump all the files, and a core developer can
figure out what each file does and how to use them; but because the
repository has no structure ONLY the core developers can understand the
project. The more structured the files are, the lower the barriers to
entry, and the more people can participate.

It's the same documentation challenge as always. A repository with a lot of
structure is self-documenting, but it does increase the overhead which does
take some time away from pure development. At the beginning that might seem
like an inefficient use of resources because the only participants are a
few core developers, who don't need a "complex" repository. But in the
future, when the project wants to attract more participants and scale up,
the "complex" repository is what will allow new people to understand the
project enough to join it.

That's particularly important for hardware projects because they require
inherently more investment than software projects. Someone can try to run a
program, see that it doesn't work correctly, and move on with their life.
But actually building a piece of hardware, only to THEN find out that it
doesn't work correctly, is a much larger cost. Participating in a hardware
project is a larger risk, so there is more value to investing in a
"complex" repository to ensure the project is easy to understand.

Therefore, it makes sense to use more infrastructure-dependent services,
even though that increases the risk that the project could suffer from the
service disappearing in the future.

>  The idea of having just a simple template is that everything is inside
> the repository. I mean, the repository it's not a part of the project like
> in ODE and other project management tools but the whole project itself is
> tracked by the repository.
>
> May be it's because my programming background, but for me, at the end,
> OSHW is just source code that helps you to replicate physical things. So I
> don't understand why in most cases we like to keep design files,
> documentation, and everything outside the repository. For me every
> different piece in the project is just "another kind" of source code, even
> the documentation is just the source code that is going to be used for
> compiling ideas on own people's minds.
>

I totally agree with that metaphor :) but I think it's the need for a human
mind to do the "compile" step that results in hardware projects being
fragmented. When the whole project is digital (software) it's possible to
automate everything. The human can just make some selections, then sit back
and let the computer do everything. Not all projects are like that, but it
is at least a possibility for all software projects. Hardware, however,
does not have that option. A human needs to be able to access and
manipulate the digital files in a way that THEIR brain understands; it
can't be automated.

Also, again, hardware not only costs more, it requires more costly tools.
So people tend to get one toolchain working and want to stick with that
since standing up another toolchain would require a significant investment.
It's a lot harder to be sure that people are understanding and working-with
hardware in identical ways than it is to be sure they're using software
identically.

Since hardware costs more, and hardware tools cost more, that means that
changes and alternatives cost more. The core team might build a great
project using Metric parts. Then new members create a version using
Imperial parts. If the core team introduces a change to the design do they
need to test it in Metric AND Imperial? Maybe, but odds are they won't.
Implementing the change in Imperial will be left up to the people who want
to use Imperial, but it doesn't really justify splitting off into an
entirely separate project. Still, there might be unforseen complexities in
the conversion, like there not being room for a slightly different fastener
size, or the editing tools making it difficult to shift holes in the
necessary way. That means the Imperial team will have to do some
development work of their own. If they're sharing a "simple" repository
with the Metric version they will quickly confuse what used to be a simple
project (like with crazy long file names and new README instructions). So
instead they'll make their own little respository somewhere else, just for
the work they need to do for the conversion.

And that's just one example off of the top of my head. Hardware projects
frequently justify working in different locations because changes and
alternatives require different tools, and different people, which cannot be
replicated by all participants.

A "complex" repository can provide organized space for those different
people/tools. That way they can work in a "different" place while still
working in the same place.

>
> I would say that we can easily treat the template just as a basic building
> block, that fills the most basic needs and doesn't need any external tool
> to be useful by itself, and then you can share it over any tool that you
> preefer or feel more comfortable, this could be ODE, GitHub, Thingiverse,
> etc.
>

That will work right up until the project attracts new people. It's a
perfectly serviceable approach as long as the project won't change in the
future. If the project does change, then the just-a-template approach will
quickly require more documentation re-work than it's worth. At that point
the project will splinter and without a united community the project will
die...or limp along under the supervision of one or two people taking it in
different directions.

Here's an example (Distributed
Collaboration<http://opensourceecology.org/wiki/Distributed_Collaboration>).
I wrote the first (only?) instructions for replicating the LifeTrac for
Open Source Ecology. What I mean by that is I wrote the instructions three
times. Each time I had to basically start over again because the
just-a-template approach can't accomodate any significant changes in the
project, let alone in how the project is explained.

It's attractive at the beginning because developers hate documentation. It
allows the developers to technically have open sourced their project. But
it pretty much guarantees that new people can't actually utilize the
project's files, so it strains the spirit of open source.

If the project is worth open sourcing, then it's worth investing a little
bit extra in infrastructure at the beginning so that the project
(particularly a hardware project) has some hope of scaling in the future.

>
> Regards,
> Mario.
>
> P.D.: I really like this list, I hope when the forum/wiki/etc is ready we
> could continue having this interesting talks.
>
>
>
>  On Thu, Oct 17, 2013 at 8:27 AM, Matt Maier <blueback09 at gmail.com> wrote:
>
>>
>>  On Wed, Oct 16, 2013 at 8:45 PM, Mario Gómez <mxgxw.alpha at gmail.com>wrote:
>>
>>>    I would say both.
>>>
>>> Personally I always liked the idea of software repositories like PyPI (
>>> https://pypi.python.org/pypi). Websites like Thingiverse, and Upverter
>>> are great but are more on focused on the design files than the whole
>>> picture of the OSHW.
>>>
>>
>> Mario,
>>
>> Before you build your own solution you should check out Mach 30's Open
>> Design Engine (ODE). https://opendesignengine.net/
>>
>> It was built from the ground up as a hardware-specific project management
>> tool (Mach 30 wants to build open source rockets and satellites). You can
>> add whatever you want for your specific project, like a wiki, and/or a
>> forum, and/or a blog, and/or a repository, etc. You can then fill up that
>> project with all of your files and everyone can come to one place to
>> coordinate themselves. You can even fork the entire project and the new
>> project gets everything that was in the original, files, the whole forum,
>> all the comments, etc and the new project can go in its own direction from
>> that baseline.
>>
>> Here is J. Simmons, the founder of Mach 30, explaining how to use ODE for
>> an example robot project. http://www.youtube.com/watch?v=COH4E_Ie1P0
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at lists.oshwa.org
>> http://lists.oshwa.org/listinfo/discuss
>>
>>
>
> _______________________________________________
> discuss mailing list
> discuss at lists.oshwa.org
> http://lists.oshwa.org/listinfo/discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oshwa.org/pipermail/discuss/attachments/20131017/18c6e4d4/attachment-0001.html>