Re: discuss Digest, Vol 10, Issue 101

[Matt Maier]

Windell, this was your question from another message, but I'm gonna paste it here so it's more relevant.

"Can you please explain, what it is exactly about the complexity of hardware projects that you think Github cannot handle?"

This is actually one of the big improvements in Eagle 6-- the XML file format.  Some other EDA programs (including gEDA and KiCAD) have human-readable, diffable file formats.


Also, github does support visual diffs for images in repositories.  One of the consequences of this is that if you include a current image of the SCH/BRD with each commit, you can use the visual diff even on pure binary files.
( I've written more about this kind of stuff on my blog, too:  http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-diffs/ )


Windell H. Oskay, Ph.D.
Co-Founder and Chief Scientist
Evil Mad Scientist Laboratories
175 San Lazaro Ave, STE 150
Sunnyvale CA 94086
http://www.evilmadscientist.com/

I am not trying to imply that there is anything wrong with Github. It's a specific example mostly because "Github for hardware" is a popular phrase that more-or-less captures the issue. Github is basically the gold standard (in several combined dimensions) for open source software collaboration, so it makes sense to want the same benefits for hardware.

Git as a software engine provides distributed version control, which is awesome and seems like a turn-key solution for ANY files, no matter what they describe. Github as a web portal provides additional capabilities that augment Git and those are where I think it falls short of what open hardware requires.

By that setup I do not mean that it's impossible to do open hardware development with the current tools. Obviously, it's possible.

What I mean is what I assume Chris Anderson meant when he wrote, "until your project is in a public version-control system, it’s open source in name only." A project that releases all of the source files under an open license is an open project, but it is open in name only. To be actively open it has to attract new developers and inspire activity like forking, generational change, and interconnected dependencies. 

The (open and/or free) tools available at the moment, including the ones on Github, are not up to the task of tracking all of the interrelated dimensions of a hardware project well enough to allow an "actively open" level of activity. When we remix the digital elements of a hardware project we are not messing around with the project itself; we are merely adjusting a description of the project. It is much simpler to specify an absolutely correct transition between one bit of code and another than it is to specify an absolutely correct transition from one physical object or process to another. It is much easier to introduce ambiguity into hardware definitions and much harder to fight off entropy because there are so many more things that can be inadequately or improperly described. 

Up to this point it has only been worthwhile to tackle that level of complexity when a project could plausibly become a marketable commercial product. The tools to do it absolutely exist, but they are absolutely only worth the cost and learning curve when a bunch of jobs are on the line. This is analogous to the inception of the RepRap project. Dr. Bowyer didn't invent 3D printers, he just made a 3D printer that cost so little, and was so easy to use, it covered the lowest conceivable part of the market. We aren't going to invent any aspect of product lifecycle management, but we are trying to invent a tool that is so cheap and easy to use that it covers the bottom of the market. One hobbyist working in their spare time on a pet project. 

I believe that Github (and version control in general) can handle hardware projects if the information is structured in the correct way and has the right user interface. That structure/interface is what we need to work out. 

By way of a supporting example, I'd like to direct your attention to the LifeTrac Fabrication instructions over at Open Source Ecology. I know those instructions are pretty good because I wrote them. But, for the same reason, I also know that they are dead. The label "open" can be un-sarcastically applied to them, but there is no way for developers to interact with them. They are open in name only. Halfway through producing the unpublished version of those instructions I started over because I realized that the information needed to be recorded in a way that allowed interaction. At the time the best option I could think of was an open source project management program (a database with a user interface). The majority of those instructions were actually generated from an OpenProj file, as described here. That is better because if someone wants to modify the tractor (modify the build instructions) they can edit the OpenProj file, which will keep track of resources and steps automatically (more-or-less). Then they can generate a new set of instructions without having to rewrite all of the details by hand. Better, but all that increase in capability does is highlight how much MORE capability is necessary to make the project truly remixable. No one can read or edit the actual OpenProj file without the software. No part of the file or the result can be pulled out and combined with anything else. It is a cathedral with a common room, not a bazaar.

The point I got to in that documentation project is roughly the point the whole open hardware community is currently at. Sure, I could put the LifeTrac's OpenProj file on Github, but there's no relevant way to compare differences between two database files. The problem is not with the documentation so much as it's with the structure it has been captured in and the tools necessary to interact with that structure. 

To sum up: hardware projects are more complicated because more variables have to be accounted for if the instructions are to be correct. It is currently possible to capture that complexity and to store it on Github, but it is not possible to interact with it in a way that allows for the project to be "truly" open. 

Cheers,

Matt

[Windell H. Oskay]

On Mar 26, 2013, at 5:30 PM, Matt Maier <blueb...@gmail.com> wrote:

> What I mean is what I assume Chris Anderson meant when he wrote, "until your project is in a public version-control system, it’s open source in name only." A project that releases all of the source files under an open license is an open project, but it is open in name only. To be actively open it has to attract new developers and inspire activity like forking, generational change, and interconnected dependencies.

I must disagree with you on this. I see a difference between "open" and "active."

I'd like to encourage active projects, but I wouldn't say that a project becomes "less open" if it falls out of favor or less work is being done on it. (Amongst other things, that could also mean that it's reached a stable status of development.) I'd even love to see thousands of already-dead projects from industry released under open source hardware licenses in the future.

> When we remix the digital elements of a hardware project we are not messing around with the project itself; we are merely adjusting a description of the project.

I'm afraid that this doesn't agree with my experience either. There are *a lot of us* here that do remix the elements of hardware projects, not just their descriptions.

> By way of a supporting example, I'd like to direct your attention to the LifeTrac Fabrication instructions over at Open Source Ecology. I know those instructions are pretty good because I wrote them. But, for the same reason, I also know that they are dead. The label "open" can be un-sarcastically applied to them, but there is no way for developers to interact with them. They are open in name only. Halfway through producing the unpublished version of those instructions I started over because I realized that the information needed to be recorded in a way that allowed interaction. At the time the best option I could think of was an open source project management program (a database with a user interface). The majority of those instructions were actually generated from an OpenProj file, as described here. That is better because if someone wants to modify the tractor (modify the build instructions) they can edit the OpenProj file, which will keep track of resources and steps automatically (more-or-less). Then they can generate a new set of instructions without having to rewrite all of the details by hand. Better, but all that increase in capability does is highlight how much MORE capability is necessary to make the project truly remixable. No one can read or edit the actual OpenProj file without the software. No part of the file or the result can be pulled out and combined with anything else. It is a cathedral with a common room, not a bazaar.
>
> The point I got to in that documentation project is roughly the point the whole open hardware community is currently at. Sure, I could put the LifeTrac's OpenProj file on Github, but there's no relevant way to compare differences between two database files. The problem is not with the documentation so much as it's with the structure it has been captured in and the tools necessary to interact with that structure.

According to our current community standards, the LifeTrac Fabrication instructions would generally not be regarded as an "open" part of the tractor's open source hardware release because you have chosen to not publish the original design files. So as a "supporting example" to argue that releasing the design files alone isn't enough to be considered "truly open," it doesn't provide much support.

In any case, from what you are describing, it sounds it would have been a really good idea to open the files for this project, so that someone could generate a new set of instructions (say, after modifying the solidworks files) without rewriting all of the details by hand. And it's even written in free software. It's sometimes better to write the instructions in poor/inappropriate but free software than to do so in appropriate but extremely expensive software.


You say that this is "roughly the point the whole open hardware community is currently at." But, I'd like to think that we're beyond that.
Most of us claiming to do open source hardware really are releasing our design files, even if one sometimes has to work at it to make use of them. Case in point: the actual hardware designs for the LifeTrac *are* on github, even though a pricey chunk of software is required to modify them.

> To sum up: hardware projects are more complicated because more variables have to be accounted for if the instructions are to be correct.

This argument is equivalent to "Hardware is harder/more complex than software." My personal opinion is that this is an unfair generalization. Both software and hardware can become incredibly complex projects, and involve the need to keep track of many simultaneous changes between stable, functional releases. You can break a codebase so that it won't compile, and you can introduce mechanical interferences so that a machine can't be assembled. The total number of variables isn't necessarily bigger or smaller in software or hardware.

It also reminds me of a strange interaction that I had this year with a fellow who was making a hardware derivative of another OSHW project (yes, a real derivative, not just "adjusting a description" ) who said that he didn't need to follow the "share alike" part of the CC-BY-SA license, because the circuit that he was copying was "too simple." Of course, it all depends on perspective: one person's complex is another's simple.

[Bryan Bishop]

Windell,

Could you also send that to the other mailing list? I feel like
there's two worlds colliding here, and your message is really valuable
and needs to be seen by both groups of people.

Second, where the heck is that git repo of lifetrac models? I wasn't
aware of this and would like a link.

- Bryan
http://heybryan.org/
1 512 203 0507