<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Good day Antoine,</div><div><br></div><div>This is J. Simmons, president and founder of Mach 30. I agree with your sentiment about wanting to know Mach 30's position with respect to OSHW and how that affects the service provided by ODE. And in truth, you are probably correct that for most people only time will tell. </div>
<div><br></div><div>However, I believe with a little bit of digging into Mach 30's past activities you will see we have already demonstrated a clear commitment to OSHW and ODE is a vendor neutral project hosting platform. </div>
<div><br></div><div>First, Mach 30 is a US public charity (501c3) - <a href="http://mach30.org/about/public-records/tax-exempt-status-documentation-and-process/">http://mach30.org/about/public-records/tax-exempt-status-documentation-and-process/</a>. This status and corporate structure forbids  our board from earning a profit from any and all Mach 30 activities, including the operation of ODE. </div>
<div><br></div><div>Second, part of our IRS approved nonprofit mission is to support the OSHW community. We have decided our key activities in this mission area are operating ODE so any OSHW project can have free project hosting, and openly publishing export control policies so all OSHW developers can confidently share designs without fear of breaking laws related to ITAR and other export controls - <a href="http://mach30.org/ectf/">http://mach30.org/ectf/</a></div>
<div><br></div><div>Finally, ODE is itself open source software, and users can always choose to move from our hosted service to their own installation - <a href="https://opendesignengine.net/projects/ode">https://opendesignengine.net/projects/ode</a>. Granted, some of the docs are a little out of date, but we are about to begin another round of updates to ODE and documentation is one of the items we will be addressing during those updates. </div>
<div><br></div><div>I hope some of that helps to demonstrate our position is open and neutral. </div><div><br></div><div>Yours,</div><div><br></div><div> -J<br><br>Sent from my iPhone</div><div><br>On Oct 18, 2013, at 7:55, FREE SMALL WIND TURBINE PROJECT PEOPLE <<a href="mailto:smallwindturbineproj.contactor@gmail.com">smallwindturbineproj.contactor@gmail.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><div><div><div>Hi Matt,<br></div>Sure, any fun-and-easy to use highly reliable collaborative platform, would be very helpful for any FLOSHW project. We approve. <br>
</div>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 ?<br>

</div>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.<br></div>Thanks for your sharing,<br></div>Very interesting discussion indeed.<br>

</div>Freely<br></div>Antoine<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/17 Matt Maier <span dir="ltr"><<a href="mailto:blueback09@gmail.com" target="_blank">blueback09@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>
<div class="gmail_quote"><div class="im">On Thu, Oct 17, 2013 at 11:24 AM, Mario Gómez <span dir="ltr"><<a href="mailto:mxgxw.alpha@gmail.com" target="_blank">mxgxw.alpha@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">
<div>Hi Matt! Thanks for sharing!<br><br>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.<br><br>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. </div>


</div></blockquote>
<div> </div>
</div><div> 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 (<a href="http://www.treehugger.com/eco-friendly-furniture/atfab-launches-flatpack-furniture-made-through-networked-distributed-manufacturing.html" target="_blank">AtFAB</a>). 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 (<a href="http://www.washingtonpost.com/blogs/compost/wp/2013/08/16/some-assembly-required-the-lies-of-ikea-and-beyond/" target="_blank">IKEA furniture</a>). 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. </div>



<div> </div>
<div>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.</div>



<div> </div>
<div>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.</div>



<div> </div>
<div>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. </div><div class="im">
<div> </div>
<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">
<div>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.<br>


<br>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.<br>


</div></div></blockquote>
<div> </div>
<div> </div>
</div><div>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.</div>



<div> </div>
<div>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. </div>



<div> </div>
<div>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. </div>



<div> </div>
<div>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. </div>



<div> </div>
<div>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.</div><div class="im">
<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">
<div><br>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.<br>


</div></div></blockquote>
<div> </div>
<div> </div>
</div><div>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. </div>



<div> </div>
<div>Here's an example (<a href="http://opensourceecology.org/wiki/Distributed_Collaboration" target="_blank">Distributed Collaboration</a>). 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. </div>



<div> </div>
<div>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. </div>



<div> </div>
<div>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.</div>

<div class="im">

<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">
<div><br>Regards,<br>Mario.<br><br></div>P.D.: I really like this list, I hope when the forum/wiki/etc is ready we could continue having this interesting talks.<br>
<div>
<div>
<div>
<div>
<div><br></div></div></div></div></div></div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">
<div>
<div>On Thu, Oct 17, 2013 at 8:27 AM, Matt Maier <span dir="ltr"><<a href="mailto:blueback09@gmail.com" target="_blank">blueback09@gmail.com</a>></span> wrote:<br></div></div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div>
<div><br>
<div class="gmail_quote">
<div>On Wed, Oct 16, 2013 at 8:45 PM, Mario Gómez <span dir="ltr"><<a href="mailto:mxgxw.alpha@gmail.com" target="_blank">mxgxw.alpha@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>I would say both.<br></div><br></div>Personally I always liked the idea of software repositories like PyPI (<a href="https://pypi.python.org/pypi" target="_blank">https://pypi.python.org/pypi</a>). Websites like Thingiverse, and Upverter are great but are more on focused on the design files than the whole picture of the OSHW. </div>


</div></div></div></blockquote>
<div> </div></div>
<div>Mario,</div>
<div> </div>
<div>Before you build your own solution you should check out Mach 30's Open Design Engine (ODE). <a href="https://opendesignengine.net/" target="_blank">https://opendesignengine.net/</a></div>
<div> </div>
<div>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.</div>



<div> </div>
<div>Here is J. Simmons, the founder of Mach 30, explaining how to use ODE for an example robot project. <a href="http://www.youtube.com/watch?v=COH4E_Ie1P0" target="_blank">http://www.youtube.com/watch?v=COH4E_Ie1P0</a></div>


</div><br></div></div>
<div>_______________________________________________<br>discuss mailing list<br><a href="mailto:discuss@lists.oshwa.org" target="_blank">discuss@lists.oshwa.org</a><br><a href="http://lists.oshwa.org/listinfo/discuss" target="_blank">http://lists.oshwa.org/listinfo/discuss</a><br>


<br></div></blockquote></div><br></div><br>_______________________________________________<br>discuss mailing list<br><a href="mailto:discuss@lists.oshwa.org" target="_blank">discuss@lists.oshwa.org</a><br><a href="http://lists.oshwa.org/listinfo/discuss" target="_blank">http://lists.oshwa.org/listinfo/discuss</a><br>


<br></blockquote></div></div><br>
<br>_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a><br>
<a href="http://lists.oshwa.org/listinfo/discuss" target="_blank">http://lists.oshwa.org/listinfo/discuss</a><br>
<br></blockquote></div><br></div>
</div></blockquote></body></html>