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

Fri Oct 18 13:55:49 UTC 2013

Hi Matt,
Sure, any fun-and-easy to use highly reliable collaborative platform, would
be very helpful for any FLOSHW project. We approve.
We've just a piece of possible comment concerning mach30: how should any
neophyte people evaluate the neutral position of march30 comparing to
famous strongly neutral platform used for software - ie for example
something like savannah ?
That's a question we still have difficulty to answer with certainty. Maybe
it's just a question of time of existence ... we don't know.
Thanks for your sharing,
Very interesting discussion indeed.
Freely
Antoine

2013/10/17 Matt Maier <blueback09 at gmail.com>

>
>
> 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
>>
>>
>
> _______________________________________________
> 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/20131018/6dba299a/attachment.html>