Public Lab Research note

An "open open hardware" development cycle

by warren , liz , mathew , tonyc | November 16, 2015 19:12 16 Nov 19:12 | #12416 | #12416

Greetings! Starting today, we're adopting a more open, but also more integrated development process for the Public Lab Spectrometer project.

This is an evolving process building on some of the discussions we've had about open tool development, and we hope to learn from this process and adopt it across other Public Lab projects. I'm 'coauthoring' with @mathew, @tonyc and @liz since this post is a distillation of discussions we (and other PL folks as well!) have had.

Our goals in this "open open hardware" methodology are:

  • clear instructions for contributing to a design
  • low barrier to entry for new contributors
  • predictable revision timeline: possible new release every 6 months?
  • a transparent roadmap for reviewing and integrating changes
  • regular iteration and feedback on proposed changes to help them get prepared for the next release due date
  • a "maintainer" for each project who will help coordinate contributions, as well as support and promote dialogue and transparency with contributors
  • a single, consistent, versioned, "baseline" design for the project, emphaisizing simplicity & low cost, but upon which advanced mods may be made

More on the exact steps for contributing will be documented on a new "Contributing to Public Lab Hardware" wiki page soon! But this is going to be an evolving process as we learn :-)

The Public Lab Desktop Spectrometer v3.1

As part of this process, we'll be collating and merging in a number of changes to the 3.0 Desktop Spectrometer, and collecting the design files -- as well as instructions on how to propose changes -- in the coming weeks. This will be marked as version 3.1, and will be the first in what we hope will become a fairly regular upgrade cycle.

More on this soon, but version 3.1 will focus on:

  • separating the optics from the spectrometer enclosure, to increase rigidity
  • more rigidly attaching the DVD grating to the webcam block
  • developing a better "trap" for the USB cable to reduce pull on the camera
  • generally improving documentation and piloting the iterative design process

I've already posted one update integrating suggestions and will be posting more and/or helping folks to compile and publish their modifications for the 3.1 revision in coming weeks.


Convergence vs. divergence

Importantly, this isn't an attempt to squash all the amazing variations and diversity of tool-hacking that goes on in the community. It's primarily a means to offer a pathway for such changes and hacks to be merged back into the "trunk" -- which will be the manufactured kit offered by the Public Lab Kits Initiative, as well as a reference design upon which folks can base their modifications. There are a lot of clear advantages to maintaining a cheap, more-standardized reference design. One particularly important reason is to ensure a low-barrier starting point to newcomers; another is to make co-development easier by disseminating a consistent design for easier coordination, data consistency, and troubleshooting.


I know not everyone like the name "open open hardware" - but until we have a better one, I like its reference to this methodology designed for software contributions:

And I want to make reference as well to the great guide to "Contributing to Public Lab Software" originally penned by @justinmanley:

We should have a session on this at the Barnraising!

Reply to this comment...

I've just posted a first draft "Contributing to Public Lab Hardware" here:

And added a banner to SpectralWorkbench:


Reply to this comment...

this term references a Git workflow. Still confused how we implement outside of Git, or why we use this term unless we're referring to a Git workflow we'll implement.

What Open open Source means: No --force pushes or modifying the Git history in any way.

Non-master branches ought to be used for ongoing work.

External API changes and significant modifications ought to be subject to an internal pull-request to solicit feedback from other contributors.

Internal pull-requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.

Contributors should attempt to adhere to the prevailing code-style

Reply to this comment...

Hi @Mathew, thanks for commenting! When i use this term, i don't use it in reference to git. I add a second use of the word "open" in front of open source in order to highlight the need for transparent processes around contribution. Some more recent discussions with GG et al have updated the idea of a single individual "maintainer" to be perhaps a small group of volunteers who would serve on a "research area review group" for a quarter. Serving on this group might also be a clearly defined way for new people or people with specific types of expertise to participate in Public Lab's open research process which hasn't previously been organized or publicly presented enough for anyone besides the main developer to really know how to get involved / contribute.

Here are some quickly sketched ideas of what a research area review group could do:

  • Read
  • Tag
  • Collate
  • Give research publishing assistance (where more documentation is needed for a contribution to be able to enter the research stream, also where there is a mistaken method used)
  • Identify what is ready to be, or needs to be, replicated:
    • “Ready-to-replicate” - this documentation is sufficient for someone to follow the instructions and achieve the results
    • “Needs-to-be-replicated” like does this work at all?
  • Synthesize the research area by writing a paragraph synopsis of what progress was made in the research area. To go on top of wiki page
  • Identify challenges and hanging questions

Is this a question? Click here to post it to the Questions page.

Reply to this comment...

Login to comment.