An "open open hardware" development cycle

[Jeffrey Warren]

Hi, all - just wanted to share this post with you all about our plan to pilot a more open hardware development process to encourage and scaffold contributions to our projects -- beginning with the Public Lab Desktop Spectrometer. Read on!

---------- Forwarded message ----------

Public Lab contributor warren just posted a new research note entitled 'An "open open hardware" development cycle':

Read and respond to the post here: https://publiclab.org/notes/warren/11-16-2015/an-open-open-hardware-development-cycle

---

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.

[Jeffrey Warren]

Hi, Coby - indeed, even with simpler, 2d vector files, we're needing to think hard about the challenges of cross-platform editing, DXF vs. SVG, preserving scale across different editors, precision drift, stuff like that. 

But our approach is probably going to be that folks submit sub-parts as independent vector files (and the project maintainers will provide guidance and support in preparing these), which will then be merged into combined "production files" by hand once the changes are accepted. 

So most of what we're hoping to address in this process is about the communication, support, transparency part -- the all-important people stuff! -- and we're just providing redundancy in the actual files and filetypes. 

Jeff

On Sat, Nov 28, 2015 at 11:12 AM, Coby <cgl...@gmail.com> wrote:

Jeffrey,

We are getting ready to go live with our new open source robotics framework called BoxBotix, and we expect similar challenges.  We are going to start with GitHub and are considering cross-posting the project to Wevolver.  We will also plan to host our own forum, but that does not do much for proper issue tracking, versioning etc.  Our biggest issue will likely be how to merge improvements from the community back into the design.  We do all of our 3D CAD work in Fusion360, which is parametric.  But once we export to say an .stl we loose those parametric properties of the file.  We will also likely provide .stp files to help people get the most of the file when imported back into their CAD program, but I doubt it helps with the import/export/merge issue if we want to maintain parametric properties across the process.  As far as I can tell it's not an easy problem to solve with a large open source community.  If you had a small team you could all work in Fusion36 from the same project since it's hosted A360.  But the you have another barrier to entry and another niche community to manage.  And, although we do not use SketchUp, Trimble seems to have adopted a similar paradigm with Trimble Connect.  Anyway, I will be interested to follow your progress on this front.  I think you have done a great job of creating a structure to help manage community engagement and expectations, which may be the best/only way to go until we get better open source hardware collaboration tools.

R,

Coby