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.