David Mellis Suggestion

• The key technical challenge is making it easier to track, view, and merge changes to hardware designs.

• Build on top of existing technology (e.g. git and github).

• Encourage text-based file formats. The XML file format in newer versions of Eagle is a good example; encouraging or creating text-based file formats for other software tools or types of hardware would be one good project to work on.

• Work on import / export between different tools (e.g. Eagle import / export in Kicad if there isn't one already).

• Use images (e.g. PNGs or PDFs) as a common format for viewing changes. GitHub, for example, provides good built-in tools for showing diffs between images (https://github.com/blog/817-behold-image-view-modes). Automatically generating some PNGs or PDFs on every commit of an Eagle file, for example, would make it much easier to see the changes.

• Collaborate with CERN on their open-hardware repository (http://www.ohwr.org). For example, OSHWA could help mediate in cases where it's not clear if something is open-source or not.

• Engage with other partners. For example, Hod Lipson is working on an effort to define a new interchange format for 3D designs (http://amf.wikispaces.com).

• Encourage participants to be clear about what they're trying to accomplish.

• Include planning for future work (after the event) as part of the process.

• Distinguish between the actual source (design files) for hardware from documentation about open-source hardware practices and projects. The current site seems to use "documentation" for both, which gets confusing.

• Where possible, focus on best practices and examples rather than formal rules. For example, in trying to expand the scope of open-source hardware, I wouldn't try to write an explicit definition of what counts. Instead, give examples that show the diversity of what exists.

• Embed taxonomies and standards in tools and platforms rather than trying to impose them externally. For example, it makes sense to have a taxonomy embedded in a repository of open-source hardware but it's not clear what value one would have on its own. Similarly for labels / fields: it makes sense to have a standard set of fields in a repository but I'm not sure it makes sense to suggest one that people would use on their own websites.

• Try not to get side-tracked by overly philosophical conversations (e.g. "what are the limits open-source hardware?", "how much of a project needs to be open?", etc).