Tag Archives: open source

Field Trip: Bell Labs Technology Showcase

Bell Labs

Bell Labs in Murray Hill, New Jersey is one of the sites that should be on every geek pilgrimage itinerary.

Bell Labs 004

Their Technology Showcase is a enshrined in a small exhibit area off of the main lobby. In the center of the exhibit, on a pedestal of its very own, is the first transistor. It looks like a very small piece of mixed media abstract sculpture, with geometric forms and wires bent in wonderful angles. If that were the only thing to see, it would still be worth the visit.

Bell Labs 003

Nearby, the first MOSFET sits in an impressive array of other firsts, including an early CCD and a micro-mirror array.

Telstar at Bell Labs

Telstar, the world’s first active communications satellite hangs overhead. This one is a flight backup unit that was never used.

Glass for fiberoptics

These fiberoptic preforms were placed under a polarizer so that the optical qualities of the cores would be more apparent to visitors.

There are many more beautiful objects, as well as interactive wall for exploring many world-changing developments that happened at and through Bell Labs.

Huge thanks go to Drew Fustini of Pumping Station: One for organizing our post-Maker Faire pilgrimage via twitter and driving us all up to New Jersey.

Coming soon: Visual diffs for 3D models

Cube Hero Screenshot

After reading our post on Improving open source hardware: Visual diffs, Wil wrote in to to tell us about Cube Hero:

I have a demo up of visual diffs for 3D printable models. Here you can see a specific model, and … you can see diffs as I changed the model.

We’re excited to see new tools for collaboration like this being developed. Besides visual diffs, the project aims to provide visual versioning, 3D object sharing, and bill of materials integration. Cube Hero is looking for interested possible users, so go check it out–they’re accepting signups for updates and launch invitations.

The 2012 Open Source Awards

open source awards

Congratulations to the recipients of the Open Source Awards announced today at OSCON: Bradley Kuhn, Elizabeth Krumbach, Massimo Banzi, Christie Koehler, and Jim Jagielski!

lightbulb in eggbot

We were honored to participate in the creation of the awards which were given out this year. Using an Eggbot, we plotted the Open Source Award design onto lightbulbs which were integrated into the awards which were given out on stage. Additionally, the award recipients are each receiving an Eggbot. It is exciting and fitting that this year’s award is itself open source hardware which works on open source software and was created using open source tools.

lightbulbs and eggbot

Top photo by Sarah Novotny.

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.