[Discuss] discuss Digest, Vol 10, Issue 28
blueback09 at gmail.com
Wed Mar 6 04:37:10 UTC 2013
Now that you explain it that way I think it makes perfect sense as a way to
distinguish between what it takes to be open, and what it takes to be an
The key discriminator seems to be scale. A business should be able to get
credit for being "fully open" as long as an individual can build off of or
replicate the project. That's not a threat to the business, and it's
actually quite a strong benefit, as recent history has shown. The business
should still be considered "fully open" even if they withhold key pieces of
information that allow the project to profitably scale up to full
production. That is technically part of what they're doing, but it is of
value only to competing businesses. An increase in scale always comes with
a capital investment, and individuals cannot possibly make enough use of a
single project to make the capital investment worthwhile. It will always be
better for them to just purchase that much scale from a business.
So maybe the best practices could mention that you're not open if you leave
out details that are required to replicate the project from scratch, but
that you are still open if you leave out details that are required to
profitably scale the project. The individual needs to be able to capture
personal value from the completed project, but they don't need to be able
to capture any additional value.
That seems like a principle that can be applied more-or-less consistently
by a lot of different people.
Awesome. Good time to hit the sack.
> Message: 4
> Date: Tue, 5 Mar 2013 18:10:15 -0700
> From: Nathan Seidle <nathan at sparkfun.com>
> To: The Open Source Hardware Association Discussion List
> <discuss at lists.oshwa.org>
> Subject: Re: [Discuss] discuss Digest, Vol 10, Issue 26
> CAHCf+Bkqr1PenSL5Eyw+KC8bpgF3QCVUJV4iojnbEyy68-g5ig at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> Hi Matt -
> > Would you extend that train of thought far enough to include processes in
> > addition to components? Like, if the connector has to be physically
> > conditioned (I'm thinking like a new baseball glove) before it will work
> > correctly, then do those details also have to be released?
> SparkFun shares a lot of its process because we think its kind of neat and
> we enjoy sharing. But withholding a process (such as how to batch program
> Arduino Fios) does not impede a person from replicating your work, it does
> however impeded their ability to build lots of an item or build an item to
> a level of quality. Rule of thumb: Is there enough shared that I can learn
> how to build my own copy? If the answer is yes, then it's open. I'd argue
> that sharing of processes are outside the realm of OSHW. Good to do, but
> shouldn't be required.
> > If so, then would you extend it even farther to include things like
> > sourcing? If there's only one factory in the world that makes the thing,
> > does the thing, and that factory doesn't advertise, then do they have to
> > release contact information to be considered more than partially open?
> > Alternatively, if it can be done anywhere, but it takes a lot of
> > back-and-forth between the project manager and the manufacturer, then do
> > they have to release their internal email traffic so that people know
> > to ask the manufacturer for?
> Ah! Great question. Supplier info is one of the things companies, such as
> SparkFun, hold more guarded. We do not obfuscate datasheets or scratch the
> tops of ICs but we have not, up to this point, listed contact details on
> BOMs. Why am I hesitant to disclose all 224 of our supplier's information?
> * We have invested lots of money/time in discovering and cultivating that
> supplier. It can be considered business advantage over other businesses.
> * We don't believe sharing contact information will help the end user be
> more successful in using our product.
> It goes back to the question: Is there enough shared that I can learn how
> to build my own copy? If it's a generic part, it's acceptable but not ideal
> to leave out supplier info.
> I'm not married to my views and welcome the debate. (But the google/digest
> thing is killing me. Hard to follow the threads. Anyone have a better
> system? Forum?)
> Nathan Seidle
> CEO, SparkFun Electronics Inc
> Boulder, CO
> Phone : 1-303-284-0979
> Fax : 1-303-443-0048
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> discuss mailing list
> discuss at lists.oshwa.org
> End of discuss Digest, Vol 10, Issue 28
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss