Message: 1<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Tue, 26 Mar 2013 20:32:34 -0700<br>
From: Windell Oskay <<a href="mailto:windell@oskay.net">windell@oskay.net</a>><br>
To: The Open Source Hardware Association Discussion List<br>
<<a href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a>><br>
Subject: Re: [Discuss] discuss Digest, Vol 10, Issue 101<br>
Message-ID: <<a href="mailto:D1E06A8E-4315-46A1-93EC-60F3379586C1@oskay.net">D1E06A8E-4315-46A1-93EC-60F3379586C1@oskay.net</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
On Mar 26, 2013, at 5:30 PM, Matt Maier <<a href="mailto:blueback09@gmail.com">blueback09@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
I must disagree with you on this. I see a difference between "open" and "active."<br>
<br>
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.<br>
<br>
<br></blockquote><div>Fair enough. I see a difference in that the license applied to a project that nobody ever does anything with is irrelevant, open or not. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 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.<br>
<br>
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.<br>
<br></blockquote><div>I must not have been clear enough. That sentence was not intended to mean that nobody ever physically builds anything. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 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 au<br>
tomatically (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.<br>
><br>
> 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.<br>
<br>
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. </blockquote>
<div><br></div><div>Then we disagree about another point of "openness." Unlike software, certain electronics, or 3D printable parts, the LifeTrac was not completely designed in a computer. It wasn't even completely planned out. The design evolved after metal touched metal and those instructions merely document a stable phase. They were already out of date when they were finalized, but they do describe a complete version of the machine. As far a I'm concerned, that qualifies a "open" because that's all anyone needs. Unlike the places where open source is most popular, structures and mechanisms do not always depend on digital files. Blueprints and sketches and cardboard prototypes aren't any good to anyone else. What everyone else needs is an after-the-fact description of how the project actually works, not a before-the-fact description of how it might work. Even if the "original" files exist in any meaningful way they are only useful to satisfy historical curiosity.</div>
<div><br></div><div>I don't interpret "open source" as referring to the original files but, rather, to the most current source files from which the item-of-value is derived. If the public instructions are sufficient to reproduce the project then it's open. What form those files take depends on the project.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br>
</blockquote><div><br></div><div>It was a counter example. My point was that it's open because the files are available, but it's not "truly" open because it doesn't go far enough to make the instructions available in such a way that they can be remixed. It's open, because it satisfies one or more definitions of open, but it's "merely" open because it just barely meets the threshold. If someone wants to modify a piece of software they just fork it, make their edit, and leave everything else alone. If someone wants to modify the LifeTrac (lets say something simple like make it longer) they basically have to start the documentation from scratch. Maybe it's relative to what options are available but it seems like that dead instructions like that don't really capture the spirit of the term "open." At least, not for me, for whatever that's worth.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div><div>By "open the files" do you mean the CAD files? If so, then I'm right there with you. I complained about that at the time but all anyone could/would give me was one file with (most of) the whole tractor in it. But the CAD files aren't actually necessary to fully describe the tractor. It's big but it's actually pretty simple. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
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.<br>
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. </blockquote><div><br></div><div>Yeah, my bad again. I was referring to the current state of poor documentation options that I keep rambling about; not to the lack of LifeTrac CAD files. I agree that they should have been release, although I will reiterate that I suspect they were (and still are) out of date, so they would be of highly questionable value.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br></blockquote><div>Haha, yeah look at that. It's nice to see OSE using something other than the wiki. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> To sum up: hardware projects are more complicated because more variables have to be accounted for if the instructions are to be correct.<br>
<br>
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.<br>
</blockquote><div><br></div><div>Fair enough. I do try to phrase things carefully to account for the fact that software and electronics are complex. However, I stick to the assertion that hardware is more complex, and I offer as evidence 1) the fact that there is no obvious solution to the hardware documentation problem except for 2) incredibly expensive tools that are expensive because hardware projects are more complex.</div>
<div><br></div><div>Complexity might not be the right concept. In my mind the biggest factor is that it's harder to get away with mistakes in hardware projects. So, it's not that there are inherently more factors than in software, it's that more of those factors are relevant because they can cost you a significant amount of money. Maybe it's just money that's the issue. It's possible to build a whole website devoted to teaching people software and let them actually try it right there in the browser for free. If you want to teach someone hardware they have to go somewhere and put on safety goggle. It's possible to capture the benefits of software that was created five minutes ago on the other side of the world, without even having the software. The same cannot be said for hardware.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<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></blockquote></div>