nice<br><br><div class="gmail_quote">2013/4/10 Pierce Nichols <span dir="ltr"><<a href="mailto:pierce@logos-electro.com" target="_blank">pierce@logos-electro.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I did! Way cool.<br>
<span class="HOEnZb"><font color="#888888"><br>
-p<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Apr 10, 2013 at 1:39 PM, Tom Igoe <<a href="mailto:tom.igoe@gmail.com">tom.igoe@gmail.com</a>> wrote:<br>
> You all saw this today, right?<br>
><br>
> <a href="https://github.com/blog/1465-stl-file-viewing" target="_blank">https://github.com/blog/1465-stl-file-viewing</a><br>
><br>
> Diffs for images can't be too far off.<br>
><br>
> t.<br>
><br>
> On Apr 10, 2013, at 12:48 PM, Matt Maier wrote:<br>
><br>
> Pierce,<br>
><br>
> Those are great examples of how hard it is to make hardware documentation<br>
> remixable.<br>
><br>
> Software can be remixable because designing and implementing it happens<br>
> entirely in the cyber domain. Hardware documentation crosses between the<br>
> cyber and physical domains.<br>
><br>
> The critical details of a software project are all just logic, so anyone<br>
> with enough time and intelligence can figure them out. The critical details<br>
> of a hardware project often involve un-digitizable things like "finger<br>
> tight." Sometimes the knowledge for an important detail is literally stored<br>
> in the unconscious processes of the craftsman. Like they know when to turn<br>
> down the speed on a drill because of how it smells or sounds or the way it<br>
> vibrates their arm.<br>
><br>
> Explaining that to someone else is impossible. If they haven't actually done<br>
> it long enough in the real world no amount of thinking about it will be<br>
> enough.<br>
><br>
> If you do find a way to explain that kind of stuff, or make it unnecessary,<br>
> then it's still really easy to forget to mention a critical detail because<br>
> it simply didn't occur to you that it might be important. Like if the<br>
> project was created by someone who happened to have an extremely clean<br>
> workspace that didn't contaminate a process, but for everyone else the<br>
> process tends to fail randomly from contamination.<br>
><br>
> Even when you can digitize all of the important dimensions, because the<br>
> physical domain is so much more complicated it might still be impossible to<br>
> follow even a perfect set of instructions. If a process needs low humidity,<br>
> and you're trying to replicated it in the tropics, then you're SOL.<br>
><br>
> -Matt<br>
><br>
><br>
> On Wed, Apr 10, 2013 at 10:03 AM, Pierce Nichols <<a href="mailto:pierce@logos-electro.com">pierce@logos-electro.com</a>><br>
> wrote:<br>
>><br>
>> The biggest lack I see in using Github for hardware is the fact that<br>
>> is lacks well-integrated diff and merge tools for hardware. Windell<br>
>> posted some decent hacks for doing this, but they're not integrated<br>
>> into the workflow and that's the problem most in need of solution.<br>
>><br>
>> There's also a more serious issue, which is how much trickier it is to<br>
>> instantiate a hardware design as compared to compiling source. Beyond<br>
>> the brute physical labor of building the thing, there are substantial<br>
>> hidden process parameters that are not readily discoverable. These can<br>
>> range from relatively obvious things like the builder's skill in<br>
>> various processes and the quality of their equipment to subtle things<br>
>> like the way a part is clamped in a fixture or the temperature at<br>
>> which it is dried after cleaning.<br>
>><br>
>> There is a good reason aerospace folks have a gigantic stick up their<br>
>> collective ass about process control and being able to trace the<br>
>> origins of all parts. You don't always know what's really important<br>
>> about a process, and if you don't control the production process, you<br>
>> are likely to get bitten.<br>
>><br>
>> -p<br>
>><br>
>> On Tue, Mar 26, 2013 at 5:30 PM, Matt Maier <<a href="mailto:blueback09@gmail.com">blueback09@gmail.com</a>> wrote:<br>
>> ><br>
>> > Windell, this was your question from another message, but I'm gonna<br>
>> > paste it<br>
>> > here so it's more relevant.<br>
>> ><br>
>> > "Can you please explain, what it is exactly about the complexity of<br>
>> > hardware<br>
>> > projects that you think Github cannot handle?"<br>
>> ><br>
>> >><br>
>> >> This is actually one of the big improvements in Eagle 6-- the XML file<br>
>> >> format. Some other EDA programs (including gEDA and KiCAD) have<br>
>> >> human-readable, diffable file formats.<br>
>> >><br>
>> >><br>
>> >> Also, github does support visual diffs for images in repositories. One<br>
>> >> of<br>
>> >> the consequences of this is that if you include a current image of the<br>
>> >> SCH/BRD with each commit, you can use the visual diff even on pure<br>
>> >> binary<br>
>> >> files.<br>
>> >> ( I've written more about this kind of stuff on my blog, too:<br>
>> >><br>
>> >> <a href="http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-diffs/" target="_blank">http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-diffs/</a><br>
>> >> )<br>
>> >><br>
>> >><br>
>> >> Windell H. Oskay, Ph.D.<br>
>> >> Co-Founder and Chief Scientist<br>
>> >> Evil Mad Scientist Laboratories<br>
>> >> 175 San Lazaro Ave, STE 150<br>
>> >> Sunnyvale CA 94086<br>
>> >> <a href="http://www.evilmadscientist.com/" target="_blank">http://www.evilmadscientist.com/</a><br>
>> >><br>
>> >><br>
>> > I am not trying to imply that there is anything wrong with Github. It's<br>
>> > a<br>
>> > specific example mostly because "Github for hardware" is a popular<br>
>> > phrase<br>
>> > that more-or-less captures the issue. Github is basically the gold<br>
>> > standard<br>
>> > (in several combined dimensions) for open source software collaboration,<br>
>> > so<br>
>> > it makes sense to want the same benefits for hardware.<br>
>> ><br>
>> > Git as a software engine provides distributed version control, which is<br>
>> > awesome and seems like a turn-key solution for ANY files, no matter what<br>
>> > they describe. Github as a web portal provides additional capabilities<br>
>> > that<br>
>> > augment Git and those are where I think it falls short of what open<br>
>> > hardware<br>
>> > requires.<br>
>> ><br>
>> > By that setup I do not mean that it's impossible to do open hardware<br>
>> > development with the current tools. Obviously, it's possible.<br>
>> ><br>
>> > What I mean is what I assume Chris Anderson meant when he wrote, "until<br>
>> > your<br>
>> > project is in a public version-control system, it’s open source in name<br>
>> > only." A project that releases all of the source files under an open<br>
>> > license<br>
>> > is an open project, but it is open in name only. To be actively open it<br>
>> > has<br>
>> > to attract new developers and inspire activity like forking,<br>
>> > generational<br>
>> > change, and interconnected dependencies.<br>
>> ><br>
>> > The (open and/or free) tools available at the moment, including the ones<br>
>> > on<br>
>> > Github, are not up to the task of tracking all of the interrelated<br>
>> > dimensions of a hardware project well enough to allow an "actively open"<br>
>> > level of activity. When we remix the digital elements of a hardware<br>
>> > project<br>
>> > we are not messing around with the project itself; we are merely<br>
>> > adjusting a<br>
>> > description of the project. It is much simpler to specify an absolutely<br>
>> > correct transition between one bit of code and another than it is to<br>
>> > specify<br>
>> > an absolutely correct transition from one physical object or process to<br>
>> > another. It is much easier to introduce ambiguity into hardware<br>
>> > definitions<br>
>> > and much harder to fight off entropy because there are so many more<br>
>> > things<br>
>> > that can be inadequately or improperly described.<br>
>> ><br>
>> > Up to this point it has only been worthwhile to tackle that level of<br>
>> > complexity when a project could plausibly become a marketable commercial<br>
>> > product. The tools to do it absolutely exist, but they are absolutely<br>
>> > only<br>
>> > worth the cost and learning curve when a bunch of jobs are on the line.<br>
>> > This<br>
>> > is analogous to the inception of the RepRap project. Dr. Bowyer didn't<br>
>> > invent 3D printers, he just made a 3D printer that cost so little, and<br>
>> > was<br>
>> > so easy to use, it covered the lowest conceivable part of the market. We<br>
>> > aren't going to invent any aspect of product lifecycle management, but<br>
>> > we<br>
>> > are trying to invent a tool that is so cheap and easy to use that it<br>
>> > covers<br>
>> > the bottom of the market. One hobbyist working in their spare time on a<br>
>> > pet<br>
>> > project.<br>
>> ><br>
>> > I believe that Github (and version control in general) can handle<br>
>> > hardware<br>
>> > projects if the information is structured in the correct way and has the<br>
>> > right user interface. That structure/interface is what we need to work<br>
>> > out.<br>
>> ><br>
>> > By way of a supporting example, I'd like to direct your attention to the<br>
>> > LifeTrac Fabrication instructions over at Open Source Ecology. I know<br>
>> > those<br>
>> > instructions are pretty good because I wrote them. But, for the same<br>
>> > reason,<br>
>> > I also know that they are dead. The label "open" can be un-sarcastically<br>
>> > applied to them, but there is no way for developers to interact with<br>
>> > them.<br>
>> > They are open in name only. Halfway through producing the unpublished<br>
>> > version of those instructions I started over because I realized that the<br>
>> > information needed to be recorded in a way that allowed interaction. At<br>
>> > the<br>
>> > time the best option I could think of was an open source project<br>
>> > management<br>
>> > program (a database with a user interface). The majority of those<br>
>> > instructions were actually generated from an OpenProj file, as described<br>
>> > here. That is better because if someone wants to modify the tractor<br>
>> > (modify<br>
>> > the build instructions) they can edit the OpenProj file, which will keep<br>
>> > track of resources and steps automatically (more-or-less). Then they can<br>
>> > generate a new set of instructions without having to rewrite all of the<br>
>> > details by hand. Better, but all that increase in capability does is<br>
>> > highlight how much MORE capability is necessary to make the project<br>
>> > truly<br>
>> > remixable. No one can read or edit the actual OpenProj file without the<br>
>> > software. No part of the file or the result can be pulled out and<br>
>> > combined<br>
>> > with anything else. It is a cathedral with a common room, not a bazaar.<br>
>> ><br>
>> > The point I got to in that documentation project is roughly the point<br>
>> > the<br>
>> > whole open hardware community is currently at. Sure, I could put the<br>
>> > LifeTrac's OpenProj file on Github, but there's no relevant way to<br>
>> > compare<br>
>> > differences between two database files. The problem is not with the<br>
>> > documentation so much as it's with the structure it has been captured in<br>
>> > and<br>
>> > the tools necessary to interact with that structure.<br>
>> ><br>
>> > To sum up: hardware projects are more complicated because more variables<br>
>> > have to be accounted for if the instructions are to be correct. It is<br>
>> > currently possible to capture that complexity and to store it on Github,<br>
>> > but<br>
>> > it is not possible to interact with it in a way that allows for the<br>
>> > project<br>
>> > to be "truly" open.<br>
>> ><br>
>> > Cheers,<br>
>> > Matt<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>
>><br>
>><br>
>><br>
>> --<br>
>> Pierce Nichols<br>
>> Principal Engineer<br>
>> Logos Electromechanical, LLC<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>
><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>
><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>
<br>
<br>
<br>
--<br>
Pierce Nichols<br>
Principal Engineer<br>
Logos Electromechanical, LLC<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>très cordialement,</div><div><br></div><div><img src="http://www.lefabshop.fr/wp-content/uploads/2013/04/etiquette-mail-Bertier2-lFS-01.png?9df020"><br>
</div>