From: Catarina Mota <catar...@openmaterials.org>
Date: Thu, Mar 7, 2013 at 11:08 AM
Subject: [Discuss] Open Source Hardware Documentation Jam, New York City,
April 26-28
To: The Open Source Hardware Association Discussion List <
disc...@lists.oshwa.org>
We're still wrangling the registration process, so if anyone is interested
in participating or contributing in another way, please email me!
Open Source Hardware Documentation Jam, New York City, April 26-28
The power of open source hardware lies in the ability to build upon others’
work and good documentation is the key to making this happen. We believe
that open source hardware will become a new economic engine of innovation,
efficiency, sustainability and collaboration. As the number of open source
hardware projects continues to grow, it’s important to generate
clearly-findable, modular, remixable documentation that can not only
improve the quality of projects - but also enhance cross-project
collaboration. Our goal is to make it easy to contribute to a common pool
of hardware knowledge.
This 3 day event is intended to generate motion on the much-discussed
‘Github for Hardware’. We intend to release a minimum viable prototype for
immediate beta testing by open hardware projects. The event will be based
on a mashup of well-known co-design formats - Design Jams and Hackathons.
The goal is to identify problems, propose solutions, and synergize on
execution.
What we need from you: Do you want to participate in the Jam and if so in
what role? Do you want to help organize? Do you want to run a parallel
event in another location? Can you review the materials that we have so
far? We have not yet secured a venue. Can you help with a venue, tools,
staff, stuff, travel, rewards, and other support? What else? Please respond
to Simone, our Facilitator - at simone.cic...@gmail.com
Due to practical matters, the number of participants will be limited, so
please let us know by March 18 if you would like to join us. Unfortunately,
we currently don’t have funding to support travel costs.
On Thu, Mar 7, 2013 at 2:40 PM, Bryan Bishop <kanz...@gmail.com> wrote:
> On Thu, Mar 7, 2013 at 11:08 AM, Catarina Mota <catar...@openmaterials.org
> > wrote:
> Who came up with that "draft entity relationship diagram"? Could we
> instead base it off of something more standard, like the dot deb format?
Simone created that document. But everything we produced should be
considered a seed to be re-factored, remixed, edited, etc. So feel free to
go ahead and make a new version.
On Thu, Mar 7, 2013 at 2:17 PM, Catarina Mota <catar...@openmaterials.org>wrote:
> Simone created that document. But everything we produced should be
> considered a seed to be re-factored, remixed, edited, etc. So feel free to
> go ahead and make a new version.
I already did, but nobody seems to know about it. Open source hardware
packaging formats like tangiblebit, skdb, mcad (which had a slight
packaging aspect, although that wasn't the original goal), thingdoc,
thingscrap, thingzip, cern's repository format, that thing/javascript/repo
mirror format, and a long list of others have a suspicious absence in any
of these email threads and it is perplexing. Naturally, these formats
aren't complete solutions and still need review and more contributors, but
either propose an alternative (even a proof of concept) or submit
patches... right? what's the hold up?
On Thu, Mar 7, 2013 at 3:25 PM, Bryan Bishop <kanz...@gmail.com> wrote:
> On Thu, Mar 7, 2013 at 2:17 PM, Catarina Mota <catar...@openmaterials.org>wrote:
>> Simone created that document. But everything we produced should be
>> considered a seed to be re-factored, remixed, edited, etc. So feel free to
>> go ahead and make a new version.
> I already did, but nobody seems to know about it.
Great, link please?
Open source hardware packaging formats like tangiblebit, skdb, mcad (which
> had a slight packaging aspect, although that wasn't the original goal),
> thingdoc, thingscrap, thingzip, cern's repository format, that
> thing/javascript/repo mirror format, and a long list of others have a
> suspicious absence in any of these email threads and it is perplexing.
> Naturally, these formats aren't complete solutions and still need review
> and more contributors, but either propose an alternative (even a proof of
> concept) or submit patches... right? what's the hold up?
Can you share a document with us with a list and links to everything you
have (or know of) so we can bring those into the discussion?
1) not enough people have opted to review it, suggesting edge cases,
proposing alternatives, etc. I think perhaps the best reviewer was
Smári McCarthy, because he went off to instead build tangiblebit since
he disliked python a great deal... and then he stopped working on
that. This was one step ahead of "use dpkg for everything!" and it
seemed to work, at least a little.
2) CAD integration, which, in retrospect, is a big project to chew
off. I ended up with piles of code for nurbs manipulation that doesn't
work, and then lots of opencascade junk laying around. Thankfully, the
brlcad crew has been working very hard with the STEP format lately
through Step Code Library (an ISO 10303-2xx implementation) and also
on their nurbs support. So that's nice progress..
The advantage of this is that there is code available in git
repositories. I wouldn't mind scrapping it, if there was a better
alternative.
>> Open source hardware packaging formats like tangiblebit, skdb, mcad (which
>> had a slight packaging aspect, although that wasn't the original goal),
>> thingdoc, thingscrap, thingzip, cern's repository format, that
>> thing/javascript/repo mirror format, and a long list of others have a
>> suspicious absence in any of these email threads and it is perplexing.
>> Naturally, these formats aren't complete solutions and still need review and
>> more contributors, but either propose an alternative (even a proof of
>> concept) or submit patches... right? what's the hold up?
> Can you share a document with us with a list and links to everything you
> have (or know of) so we can bring those into the discussion?
Here are some links to some email threads all the way back to 2008
discussing hardware packaging formats:
Excellent! We're collecting links and info about all existing efforts
regarding documentation and will bundle them together in a format
accessible to everyone - probably a list with brief descriptions and links.
On Thu, Mar 7, 2013 at 3:43 PM, Bryan Bishop <kanz...@gmail.com> wrote:
> On Thu, Mar 7, 2013 at 2:29 PM, Catarina Mota
> <catar...@openmaterials.org> wrote:
> > Great, link please?
> 1) not enough people have opted to review it, suggesting edge cases,
> proposing alternatives, etc. I think perhaps the best reviewer was
> Smári McCarthy, because he went off to instead build tangiblebit since
> he disliked python a great deal... and then he stopped working on
> that. This was one step ahead of "use dpkg for everything!" and it
> seemed to work, at least a little.
> 2) CAD integration, which, in retrospect, is a big project to chew
> off. I ended up with piles of code for nurbs manipulation that doesn't
> work, and then lots of opencascade junk laying around. Thankfully, the
> brlcad crew has been working very hard with the STEP format lately
> through Step Code Library (an ISO 10303-2xx implementation) and also
> on their nurbs support. So that's nice progress..
> The advantage of this is that there is code available in git
> repositories. I wouldn't mind scrapping it, if there was a better
> alternative.
> >> Open source hardware packaging formats like tangiblebit, skdb, mcad
> (which
> >> had a slight packaging aspect, although that wasn't the original goal),
> >> thingdoc, thingscrap, thingzip, cern's repository format, that
> >> thing/javascript/repo mirror format, and a long list of others have a
> >> suspicious absence in any of these email threads and it is perplexing.
> >> Naturally, these formats aren't complete solutions and still need
> review and
> >> more contributors, but either propose an alternative (even a proof of
> >> concept) or submit patches... right? what's the hold up?
> > Can you share a document with us with a list and links to everything you
> > have (or know of) so we can bring those into the discussion?
> Here are some links to some email threads all the way back to 2008
> discussing hardware packaging formats:
> So far we have just used common sense ("the least common of the senses",
> I know!) and published everything needed to view, modify and manufacture
> the boards and test them.
> We are quite happy about:
> - The functionality ohwr.org offers.
> - The response from companies which commercialize these designs.
> - The legal framework provided by the CERN Open Hardware Licence.
> Of course, everything is perfectible and I am following discussions in
> this list with interest!
> What we are focusing our OSHW effort on these days is design tools. We
> are contributing to Icarus Verilog and Kicad [1]. I think this is the
I am curious, does that mean CERN has someone specifically allocated
to verilog and kicad? That would be really exciting news.
> biggest hurdle for effective sharing right now, and I hope this year and
To add to what Bryan already said, which I largely agree with, there are some other things that you may want to consider. For instance, many items in the OSHW Documentation Taxonomy have already been defined in ISO 10303 (a.k.a. Standard for the Exchange of Product models a.k.a. STEP). There are industry-led efforts going on that use ISO 10303 and related standards for hardware documentation.
LOTAR is advancing STEP AP242, which contains mechanical CAD geometry and associated product manufacturing information such as Geometric Dimensioning and Tolerancing according to ASME 14.41. For non-shape information such as Product Data Management (BOM) and archiving Meta-data, LOTAR is using AP239 Product Life Cycle Support (PLCS). The AP242 schema is freely available from the CAX-IF, which develops recommended practices for implementers and conducts test rounds for translators. There is a legacy standard for Technical Data Packaging, AP232, but that is being largely superseded by AP239 implementations. The AIA/ASD Integrated Logistics Support (ILS) S-series specifications cover related information for product support. Most of the S-series specifications that are in development are using PLCS.
OpenCascade is challenging, but the FreeCAD, OpenPLM, and IfcOpenShell projects have been able to build usable open source tools based on it. While I agree that BRL-CAD source code is better managed, both could be useful for open source hardware documentation development, as can commercial tools.
On Thursday, March 7, 2013 1:48:33 PM UTC-7, Catarina Mota wrote:
> Excellent! We're collecting links and info about all existing efforts > regarding documentation and will bundle them together in a format > accessible to everyone - probably a list with brief descriptions and links.
> On Thu, Mar 7, 2013 at 3:43 PM, Bryan Bishop <kan...@gmail.com<javascript:>
> > wrote:
>> On Thu, Mar 7, 2013 at 2:29 PM, Catarina Mota
>> <cata...@openmaterials.org <javascript:>> wrote:
>> > Great, link please?
>> 1) not enough people have opted to review it, suggesting edge cases,
>> proposing alternatives, etc. I think perhaps the best reviewer was
>> Smári McCarthy, because he went off to instead build tangiblebit since
>> he disliked python a great deal... and then he stopped working on
>> that. This was one step ahead of "use dpkg for everything!" and it
>> seemed to work, at least a little.
>> 2) CAD integration, which, in retrospect, is a big project to chew
>> off. I ended up with piles of code for nurbs manipulation that doesn't
>> work, and then lots of opencascade junk laying around. Thankfully, the
>> brlcad crew has been working very hard with the STEP format lately
>> through Step Code Library (an ISO 10303-2xx implementation) and also
>> on their nurbs support. So that's nice progress..
>> The advantage of this is that there is code available in git
>> repositories. I wouldn't mind scrapping it, if there was a better
>> alternative.
>> >> Open source hardware packaging formats like tangiblebit, skdb, mcad >> (which
>> >> had a slight packaging aspect, although that wasn't the original goal),
>> >> thingdoc, thingscrap, thingzip, cern's repository format, that
>> >> thing/javascript/repo mirror format, and a long list of others have a
>> >> suspicious absence in any of these email threads and it is perplexing.
>> >> Naturally, these formats aren't complete solutions and still need >> review and
>> >> more contributors, but either propose an alternative (even a proof of
>> >> concept) or submit patches... right? what's the hold up?
>> > Can you share a document with us with a list and links to everything you
>> > have (or know of) so we can bring those into the discussion?
>> Here are some links to some email threads all the way back to 2008
>> discussing hardware packaging formats:
The 'OSHW Documentation Taxonomy Items' document is a great push
forward for establishing open hardware standards. The jam will no
doubt be very fruitful with all the excellent people involved with the
OSHWA so far. I see this institution as setting the greatly needed
industry standards to come. Also, the website can provide a good place
to find top products and producers of the highest standards of free
and openness, while encouraging the evolution of product components to
become all the more free and open.
After viewing some of the discussion concerning identifying openness,
the subject of labelling comes to mind. I'd like to suggest a ranking
order, where the most open producers are rewarded with the highest
praise (with an award ceremony?) and website promotion, encouraging
the product network to open up, and the like, while providing a model
for others that are becoming increasingly open or interested.
Starting in reverse order, with each step incorporating the features
of the levels below it, from base entry to highest ranking:
1. OSHWA Red Label. An elected committee would evaluate a particular
product to deem it worthy of approval. When so, the stamp can be used
to promote the product, and OSHWA can in turn promote it on its
product/agency list page. Fees (or commitments) for these services and
others can be decided by the same elected committee. Obviously, there
will and should be ongoing debate on what makes a product 'open
source'. In my view, with today's constraints, a Bill of Materials,
documentation: like code and schematics, where to locate subcomponents
(for purchasing or otherwise), and easy to understand assembly
instructions, are enough to constitute a product as 'open source',
even if all subcomponents are proprietary. Then comes determining and
maximizing ways to encourage producers of subcomponents to also become
affiliated with the OSHWA, removing existing constraints, to make
product details as transparent and easy to self-assemble as possible,
with membership rewards, like material price discounts between
members, or better, materials sharing. Extending the features of OSHWA
in that way would be very valuable for everyone, helping further blur
the line between producer and user.
2. OSHWA Silver. More than half of product subcomponents are under the
OSHWA Red Label.
3. OSHWA Gold. All subcomponents are under the OSHWA Red Label.
4. OSHWA Platinum. A majority of subcomponent items are gifted by
partnership agreements to make a more affordable product.
5. OSHWA Diamond. A free and open product with the exception of
shipping and packaging costs, including the shipping and packaging
costs of subcomponents. This level is achieved by having materials
gifted by member contract with volunteers or robots fully assemble a
product or robotically produce subcomponents, likely from a single
location, for the user to assemble using commonly available tools,
ideally, or referral to the nearest hackspace workshop for guest
access for final assembly.
6. OSHWA Double Diamond. A truly free and open product using robotic
vehicles to deliver the product for free using a reusable shipping
container.
Some may consider these labels too forward looking, but with robotics
and the components to make them becoming increasingly more capable and
affordable, notably contributions to ROS doubling yearly, sensors
rapidly increasing in resolution and reducing in cost, with
pick-and-place robots now easy to train without programming knowledge,
namely, Baxter, equalling the cost of a Chinese worker, along with the
increasing popularity of 3D printing, notes a few elements in the
production ecology better enabling automated and localized production.
OSHWA, with many other efforts, will help make physical and
intellectual production a free resource in the long run. Lobbying or
reformation of governments for the purpose of IP, and eventually,
legal protections for physical common property arrangements, along
with an accompanied 'public resource user interface' (elegantly
(simple and relevant) presenting how a product is made, where
materials come from, including real-time views of a product during
assembly and delivery, for example) extending the 'GitHub for
Hardware' analogy are also vital to enabling truly free and open
products.
I see the OSHWA topping the list of potential contenders at present to
spearhead such efforts.
From: Javier Serrano <Javier.Serr...@cern.ch>
Date: Thu, Mar 7, 2013 at 4:39 PM
Subject: Re: [Discuss] [Open Manufacturing] Re: Open Source Hardware
Documentation Jam, New York City, April 26-28
To: The Open Source Hardware Association Discussion List
<disc...@lists.oshwa.org>
Replying to oshwa.org only. I usually try to not crosspost. Feel free to
redistribute as you wish.
On 03/07/2013 11:25 PM, Bryan Bishop wrote:
> On Thu, Mar 7, 2013 at 3:58 PM, Javier Serrano <Javier.Serr...@cern.ch> wrote:
>> What we are focusing our OSHW effort on these days is design tools. We
>> are contributing to Icarus Verilog and Kicad [1]. I think this is the
> I am curious, does that mean CERN has someone specifically allocated
> to verilog and kicad? That would be really exciting news.
So far we have only contributed by asking companies to do development.
You can grep the iverilog and Kicad sources for CERN copyright notices
to see where we have contributed. And this year we had the opportunity
to bring a student using CERN's technical student program. He has only
been with us for a week, and he's planned to work full time on Kicad
this year.
>> biggest hurdle for effective sharing right now, and I hope this year and
> File format compatibility?
Yes, that and market fragmentation and long learning curves. Our main
source of inspiration is Free Software. Software people never asked
themselves if other people could read their sources and use them and
modify them easily. They had gcc and vi/emacs from day one.
