<div>Hi there!  Just joined the discussion list.  This is a great discussion going.</div><div><br></div><div>I think Matt's summary is great.  When I make a justification to why I Open Source OpenBeam, this is the analogy I use.</div>
<div><br></div><div>We have a great food truck in Seattle, called Skillet Street Food.  They are awesome - they make some of the best poutine in town.  (For those who don't know, this is gravy and cheese curds over french fries.  French Canadian for "Heart Attack" basically).  They also publish a cookbook, and I have a copy of it (the source, you may say).</div>
<div><br></div><div>The poutine recipe calls for 5-10 pounds of roasted beef bones that's been simmered for 3 days into a reduction.</div><div><br></div><div>If I want poutine, it's not worth my time and effort and clean up afterwards to simmer my own gravy.  I'm going to get into my car and drive to find the food truck and hope they didn't run out.  If I were a competing restaurant, even with the recipe, I'll still have to market my poutine.  The most people would say is, "Hey, Terence's poutine is pretty good, it's just like Skillet's poutine".  I'm still responsible for marketing and establishing my own branding (since I can't just use the marketing term "Skillet's poutine", trade mark issues).</div>
<div><br></div><div>I think our value as an open source business is really applying economies of scale to make it "worth while" to produce the product.  I've had multiple people ask me about manufacturing OpenBeam right now - and so far no one had actually done it.  The reason being is that we run our extrusion die at multiple kilometers of extrusions at a time and multiple 10s of thousands of injection molded brackets to keep the prices where they are.  And, frankly, the margins are not great (certainly not enough for me to leave my nice engineering day job).  We therefore openly share with people the profile and the manufacturing processes, as it's a fascinating thing to be able to share (<a href="http://blog.openbeamusa.com/2012/05/18/behind-the-scenes-injection-molding/">http://blog.openbeamusa.com/2012/05/18/behind-the-scenes-injection-molding/</a> for example).  We actually try to work with all our CMs so that we can document the process involved and blog about it.  Most are happy to do so as they don't typically get to showcase their work.</div>
<div><br></div><div>Echoing Nathan's point about sharing vendor information - I think a lot of it has to do with the community you serve too.  We at OpenBeam had made a little inroad with the Reprap community and, frankly, they are some of the worst customers out there.  As such, there's no way I'd want to share my sources for all my mechanical components that I bring in to make my OpenBeam 3D printer kits or the ordering process I use to order them and bring them into the country for resale. </div>
<div><br></div><div>-=- Terence</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 5 Mar 2013 21:37:10 -0700<br>
From: Matt Maier <<a href="mailto:blueback09@gmail.com">blueback09@gmail.com</a>><br>
To: <a href="mailto:discuss@lists.oshwa.org">discuss@lists.oshwa.org</a><br>
Subject: Re: [Discuss] discuss Digest, Vol 10, Issue 28<br>
Message-ID:<br>
        <CA+S82Dqx3X_JGON7Fxff5ao7k5Q+LAjWc7aTR1XzBNbU=<a href="mailto:5WkNA@mail.gmail.com">5WkNA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Nathan,<br>
<br>
Now that you explain it that way I think it makes perfect sense as a way to<br>
distinguish between what it takes to be open, and what it takes to be an<br>
open business.<br>
<br>
The key discriminator seems to be scale. A business should be able to get<br>
credit for being "fully open" as long as an individual can build off of or<br>
replicate the project. That's not a threat to the business, and it's<br>
actually quite a strong benefit, as recent history has shown. The business<br>
should still be considered "fully open" even if they withhold key pieces of<br>
information that allow the project to profitably scale up to full<br>
production. That is technically part of what they're doing, but it is of<br>
value only to competing businesses. An increase in scale always comes with<br>
a capital investment, and individuals cannot possibly make enough use of a<br>
single project to make the capital investment worthwhile. It will always be<br>
better for them to just purchase that much scale from a business.<br>
<br>
So maybe the best practices could mention that you're not open if you leave<br>
out details that are required to replicate the project from scratch, but<br>
that you are still open if you leave out details that are required to<br>
profitably scale the project. The individual needs to be able to capture<br>
personal value from the completed project, but they don't need to be able<br>
to capture any additional value.<br>
<br>
That seems like a principle that can be applied more-or-less consistently<br>
by a lot of different people.<br>
<br>
Awesome. Good time to hit the sack.<br>
Matt<br>
<br>
<br>
> ------------------------------<br>
><br>
> Message: 4<br>
> Date: Tue, 5 Mar 2013 18:10:15 -0700<br>
> From: Nathan Seidle <<a href="mailto:nathan@sparkfun.com">nathan@sparkfun.com</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 26<br>
> Message-ID:<br>
>         <<br>
> <a href="mailto:CAHCf%2BBkqr1PenSL5Eyw%2BKC8bpgF3QCVUJV4iojnbEyy68-g5ig@mail.gmail.com">CAHCf+Bkqr1PenSL5Eyw+KC8bpgF3QCVUJV4iojnbEyy68-g5ig@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="iso-8859-1"<br>
><br>
> Hi Matt -<br>
><br>
><br>
> > Would you extend that train of thought far enough to include processes in<br>
> > addition to components? Like, if the connector has to be physically<br>
> > conditioned (I'm thinking like a new baseball glove) before it will work<br>
> > correctly, then do those details also have to be released?<br>
> ><br>
><br>
> SparkFun shares a lot of its process because we think its kind of neat and<br>
> we enjoy sharing. But withholding a process (such as how to batch program<br>
> Arduino Fios) does not impede a person from replicating your work, it does<br>
> however impeded their ability to build lots of an item or build an item to<br>
> a level of quality. Rule of thumb: Is there enough shared that I can learn<br>
> how to build my own copy? If the answer is yes, then it's open. I'd argue<br>
> that sharing of processes are outside the realm of OSHW. Good to do, but<br>
> shouldn't be required.<br>
><br>
><br>
> > If so, then would you extend it even farther to include things like<br>
> > sourcing? If there's only one factory in the world that makes the thing,<br>
> or<br>
> > does the thing, and that factory doesn't advertise, then do they have to<br>
> > release contact information to be considered more than partially open?<br>
> > Alternatively, if it can be done anywhere, but it takes a lot of<br>
> > back-and-forth between the project manager and the manufacturer, then do<br>
> > they have to release their internal email traffic so that people know<br>
> what<br>
> > to ask the manufacturer for?<br>
> ><br>
><br>
> Ah! Great question. Supplier info is one of the things companies, such as<br>
> SparkFun, hold more guarded. We do not obfuscate datasheets or scratch the<br>
> tops of ICs but we have not, up to this point, listed contact details on<br>
> BOMs. Why am I hesitant to disclose all 224 of our supplier's information?<br>
><br>
> * We have invested lots of money/time in discovering and cultivating that<br>
> supplier. It can be considered business advantage over other businesses.<br>
> * We don't believe sharing contact information will help the end user be<br>
> more successful in using our product.<br>
><br>
> It goes back to the question: Is there enough shared that I can learn how<br>
> to build my own copy? If it's a generic part, it's acceptable but not ideal<br>
> to leave out supplier info.<br>
><br>
> I'm not married to my views and welcome the debate. (But the google/digest<br>
> thing is killing me. Hard to follow the threads. Anyone have a better<br>
> system? Forum?)<br>
><br>
> Cheers,<br>
> -Nathan<br>
> --<br>
> Nathan Seidle<br>
> CEO, SparkFun Electronics Inc<br>
> Boulder, CO<br>
> Phone : <a href="tel:1-303-284-0979" value="+13032840979">1-303-284-0979</a><br>
> Fax : <a href="tel:1-303-443-0048" value="+13034430048">1-303-443-0048</a><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<br>
> <a href="http://lists.oshwa.org/pipermail/discuss/attachments/20130305/7732107c/attachment.html" target="_blank">http://lists.oshwa.org/pipermail/discuss/attachments/20130305/7732107c/attachment.html</a><br>
> ><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>
> End of discuss Digest, Vol 10, Issue 28<br>
> ***************************************<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.oshwa.org/pipermail/discuss/attachments/20130305/0350d944/attachment-0002.html" target="_blank">http://lists.oshwa.org/pipermail/discuss/attachments/20130305/0350d944/attachment-0002.html</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>
End of discuss Digest, Vol 10, Issue 30<br>
***************************************<br>
</blockquote></div><br>