Category Archives: Open Hardware

Makerspace Launch

The Makerspace program is a joint effort by O’Reilly’s Make division and Otherlab to put dedicated space and tools for hands-on making into high schools. They describe their aims on their about page:

By creating makerspaces in an educational context, students can have access to tools and equipment that they might not have otherwise; they can collaborate on projects that are driven by their own interests, and by doing so, develop the capacity and confidence to innovate. We see making as a gateway to deeper engagement in science and engineering but also art and design.

On Monday, September 10, we’ll be attending the Makerspace launch event at the College of San Mateo. We’ll be demoing a few kits and are excited to have the opportunity to meet educators interested in bringing making into the classroom. If you’ll be attending, please stop by our table and say hi!

Version Control for Stuff

compdiff

Today at Wired, Chris Anderson draws attention to one of our favorite problems: Version Control for Stuff. We wrote about this last fall in our article, Improving open source hardware: Visual diffs.

In his article, Chris introduces the big ideas (using our article for an example) and discusses a couple of the current efforts towards “source code” repositories for hardware.

Instead of such expensive and closed commercial systems, we need open Web-based repositories for design files, filling the role that GitHub, Sourceforge, and Google Code have for software. (You can already use the existing code repositories for design files. And some, like GitHub, already have good ways of comparing images. But none of them were designed for CAD or PCB design, so you can’t understand the contents of the files and manage them the way you’d manage text.)

I’m not sure to what extent the latter part is truly relevant. Version control for software projects isn’t necessarily context aware, so why should we expect hardware to be?

That is to say, when you commit a new revision of your code to GitHub, do you expect it to recognize— and tell you in a diff —that a given block of code represents a loop or class definition? (Likely not— just as it doesn’t understand that another loop draws an integrated circuit footprint.) And, version control is already used on files that are not particularly human-readable, whether those files are ultimately used in a hardware or software context.

One might even argue that hardware is more amenableto simple diffs than software, because our eyes can take in so much information, so quickly.

But in any case, he’s right on the big points: we need those visual diff tools. And yes, as version control tools do evolve to become more context aware, we’ll increasingly need them to be aware of the differences between hardware and software.

Link: Wanted: Version Control for Stuff @ Wired

OSHWA – The Open Source Hardware Association -Coming soon

oshwlogo

The Open Source Hardware Association is Coming Soon!

OSHWA will be a non-profit
organization (status pending) working to spread the love of open source hardware. We’re still deep in the process of
working out all the details, but please bookmark oshwa.org, and check back there for
upcoming news.

OSHWA’s first project is a survey, “to better understand the Open Source Hardware community.” Catarina Mota has lead this project and created a survey along with David Mellis and John De
Cristofaro. The aggregate and anonymous results will be made publicly available in May. If you’re involved with the OSHW community, we’d invite you to take the survey.

Improving open source hardware: Visual diffs

pcbdiff

As the open source hardware movement matures, it’s worth taking a moment to consider the issue of version control.

Collaborative software projects make heavy use of version control– tools like Subversion and Git, and project hosting sites like SourceForge, GitHub, and Google Code –to organize and manage the contributions of many developers to a project. But as we begin to consider open source hardware, can we use these same tools and sites for effective collaboration on hardware projects?

The short answer is, “yes”– after all, people are already doing it. But the reality is that we could do much, much better. Some people think that we do need a separate “SourceForge for hardware.” That’s hard to say. But it is the case– perhaps against conventional wisdom –that existing tools can be used, today, for meaningful hardware version control.

It’s certainly possible to take any old binary file (say from a CAD program), and store it in a version control system. This is, in fact, how many of today’s open source hardware projects are managed. However, a “diff” (direct file comparison) to see what’s changed between two versions of a given file is all but meaningless.

For design files in plain-text (“ascii”) file formats, such as Inkscape‘s SVG or KiCad‘s .brd, a diff is possible and is in principle meaningful, but it is usually all but useless in practice, because CAD is a graphical sport, and we need to treat it like graphics.

An example: Suppose that you found the following snippet in the difference between two SVG files:

 <path
       sodipodi:type="arc"
       style="fill:#ff00ff;fill-opacity:1;stroke:#ffa6a6;stroke-width:0.18000001;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
       id="path2816"
       sodipodi:cx="237.14285"
       sodipodi:cy="328.07648"
       sodipodi:rx="160"
       sodipodi:ry="84.285713"
       d="m 397.14285,328.07648 a 160,84.285713 0 1 1 -319.999997,0 160,84.285713 0 1 1 319.999997,0 z" />

You probably wouldn’t recognize that (at least not quickly) as a big magenta ellipse. While it’s perfectly legible as source code, a diff result like this would be all but useless in practice.

The obvious solution, is to add in some visual diffs in order to make sense of changes between design files. On the bright side, making these is remarkably straightforward, and– with a little bit of effort –practically supported by existing version control systems.

In what follows, we’ll walk through some examples of visual diffs– with bitmaps and PDF files –and discuss what you can do to help make version control work better for CAD files, and to make CAD files better for version control.

Continue reading Improving open source hardware: Visual diffs

The Open Source Hardware Logo

open source hardware logo

Following the public vote announced several weeks ago, the design above by Macklin Chaffe was selected as the v 1.0 logo for Open Source Hardware. We hope that this will, in time, become a recognizable mark indicating open source hardware projects and products.

Part of what will help to spur adoption is making the design available in a variety of formats, ready for use in different contexts. Already, we’ve seen versions in OpenSCAD (for 3D fabrication) and KiCad (for circuit board design).

To those examples, we’re adding our own: the OSHW logo, ready to use in gEDA PCB, our favorite software for circuit board design.

open source hardware logo

Here’s how the logo might look on a printed circuit board, as rendered in gEDA PCB.

open source hardware logo

We’ve also rendered it in a few sizes and styles– filled or not, and losing the text as the logos get smaller. You can download this set of examples for gEDA right here ( 82 kB .zip archive).

Open Source Hardware logo: Up for public vote!

oshw logo candidate

After an initial round of judging 129 entries (Whew!), The effort to establish a logo for open source hardware has moved onto the next stage. We’ve narrowed the field down to ten finalists. And, voting has been opened to the public, so go vote!

We’re putting our own vote in for “#95,” the geared logo by Fred PRATE, shown above with variations. It’s one of the few that suggests both mechanics and electronics, and it will look darn good milled into a hunk of metal or silkscreened onto a circuit board.

Open Source Hardware Logos

Hey internet: You’ve got some good artists out there, and we could use a little help, right now!

Today is the last day to submit entries for the new Open Source Hardware logo — There are over 100 entries so far, and you can enter your own sketch by posting it there in the forum.

The official requirements are that it is (1) easy to print/see on a circuit board or schematic document and (2) that it signify “open-ness.” To part (1), I’d add, it should be easy to carve/see milled into a block of aluminum– open hardware isn’t just about electronics! –and to part (2), I’d add that locks and keys aren’t always the best way to indicate that something is “open.” (Locks are often shut. There are plenty of things that never are– Klein bottles come to mind.)

So, now is the “last minute” — and time to send in your own entry. We’ve got a whole lot of entries that won’t look good on a circuit board (or milled into aluminum), and a whole lot of entries with locks and keyholes that don’t necessarily send the right message. Care to lend a hand?

Open Source Hardware Definition, v 1.0 released

It’s a big day for Open Hardware.

Following September’s Open Hardware Summit, we’re pleased to help announce the release of version 1.0 of the Open Source Hardware Definition.

While this is a “1.0” release, Open Source Hardware is an evolving field, and future releases are expected. The real milestone here is that we now have a first benchmark for evaluating possible open source hardware licenses– and we look forward to being part of that process.

Moving forward from here, some steps if you’d like to get involved:


  • Endorse the definition, if you’d like to put your weight behind it.
  • If you have feedback, please join the mailing list to talk about it. Hopefully a version 1.1 will be coming in the near future.
  • Help out with the OSHW logo selection process. You can submit a new one, or look at those proposed.
  • Show your support for OSHW by applying the definition to your projects

See also, release announcement at openhardwaresummit.org.

Advancing open hardware with a few clear words.

2313Card - 2

Over the last few years we’ve been excited to be part of the rapidly growing open-source hardware community. One of the recurring issues in this community has been the lack of agreement on what constitutes an acceptable license for open hardware. For open source software, there’s a common language to start with: the Open Source Definition. But where is the analogous root document for us hardware folks?


Of course, there simply isn’t one. Or rather, there hasn’t been one until now.


Over the last few months, we’ve been helping to hammer out a draft definition of what it means to be open source hardware, in collaboration with open source stars including folks from Chumby, Bug Labs, Sparkfun, Arduino, Adafruit, MakerBot, Eyebeam, Make, and Creative Commons, amongst others. It’s a modest but important step in defining what it means for a project to be open hardware.

The current draft definition is labeled version 0.3, and hopefully we’ll be advancing it towards a 1.0 in the coming months. There’s an Open Hardware Summit scheduled to take place before Maker Faire NY. As things advance we’ll be working on ways to connect to actual licenses and to the other needs of our community. If you have the inclination, please check out the draft and see what we’ve been up to.