Fwd: Open Source Hardware Documentation Jam, New York City, April 26-28

[Bryan Bishop]

From: Catarina Mota <cata...@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 <dis...@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!

Lots of details on the event's website (the Challenge page is particularly relevant): http://www.opensourcewarehouse.org

Cheers,
Catarina

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.


Check out the event’s website for more information: http://www.opensourcewarehouse.org/problem-statement/

Some preliminary work on an OSHW Documentation taxonomy: https://docs.google.com/spreadsheet/ccc?key=0AkNG-lv1ELQvdHViNEdtVHp4dHRWOU8tcDNSbXROY3c&usp=sharing


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...@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.


Thanks,

Marcin Jakubowski - opensourceecology.org

Catarina Mota - everywheretech.org

Simone Cicero - meedabyte.com





_______________________________________________
discuss mailing list
dis...@lists.oshwa.org
http://lists.oshwa.org/listinfo/discuss



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

[Bryan Bishop]

On Thu, Mar 7, 2013 at 11:08 AM, Catarina Mota <cata...@openmaterials.org> wrote:

Lots of details on the event's website (the Challenge page is particularly relevant): http://www.opensourcewarehouse.org

Who came up with that "draft entity relationship diagram"? Could we instead base it off of something more standard, like the dot deb format?

[Catarina Mota]

On Thu, Mar 7, 2013 at 2:40 PM, Bryan Bishop <kan...@gmail.com> wrote:

On Thu, Mar 7, 2013 at 11:08 AM, Catarina Mota <cata...@openmaterials.org> wrote:

Lots of details on the event's website (the Challenge page is particularly relevant): http://www.opensourcewarehouse.org

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.

 

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

[Bryan Bishop]

On Thu, Mar 7, 2013 at 2:17 PM, Catarina Mota <cata...@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?

[Catarina Mota]

On Thu, Mar 7, 2013 at 3:25 PM, Bryan Bishop <kan...@gmail.com> wrote:

On Thu, Mar 7, 2013 at 2:17 PM, Catarina Mota <cata...@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?

[Bryan Bishop]

On Thu, Mar 7, 2013 at 2:29 PM, Catarina Mota
<cata...@openmaterials.org> wrote:
> Great, link please?

Here's one about the skdb format:

http://gnusha.org/skdb/package_spec.html
http://gnusha.org/skdb/

The biggest hold-ups for this were two-fold:

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:

http://heybryan.org/om.html which were collected from
https://groups.google.com/group/openmanufacturing

as for individual projects:

tangiblebit - http://diyhpl.us/cgit/tangiblebit
thingdoc - https://github.com/josefprusa/ThingDoc
thingzip - http://spec.makerbot.com/ (which seems to be down, I guess
they aren't interested in maintaining it)
skdb - http://gnusha.org/skdb and
http://gnusha.org/skdb/package_spec.html
https://github.com/kanzure/skdb
thingscrap output format - https://github.com/grevaillot/thingscrap
cern - http://www.ohwr.org/projects/bpm-dbe/repository (oops, i was
wrong, they have no specification document)

I don't remember the other urls.

[Catarina Mota]

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.

[Bryan Bishop]

On Thu, Mar 7, 2013 at 3:58 PM, Javier Serrano <Javier....@cern.ch> wrote:

> On 03/07/2013 09:43 PM, Bryan Bishop wrote:
>
>> cern - http://www.ohwr.org/projects/bpm-dbe/repository (oops, i was
>> wrong, they have no specification document)
>

> This is just one among the ~100 projects in ohwr.org. This site aims at
> hosting Open Source Hardware designs and is indeed run by CERN. For

I am aware of this, but I thought there was a specification somewhere.
Instead, I just ended up linking to a specific project.

> The example you quoted is not a mature design. Here are a couple of
> better examples:
>
> http://www.ohwr.org/projects/spec/wiki
> http://www.ohwr.org/projects/fmc-adc-100m14b4cha/wiki

Thank you.

> 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

File format compatibility?

[Charlie]

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.  

www.rassc.org

www.lotar-international.org

http://www.asd-ssg.org/asd-ils-suite-of-specifications

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.  

Charlie 

[Nathan Cravens]

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.

Best.
Nathan

[Bryan Bishop]

Neat update from CERN about their work on Kicad..

From: Javier Serrano <Javier....@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
<dis...@lists.oshwa.org>

Replying to oshwa.org only. I usually try to not crosspost. Feel free to
redistribute as you wish.

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.

Cheers,

Javier

_______________________________________________
discuss mailing list
dis...@lists.oshwa.org
http://lists.oshwa.org/listinfo/discuss

--