Help save net neutrality! A free, open internet is once again at stake—and we need your help. Learn more »

Public Lab Research note


  • 4

Ideas on opening "open hardware"

by liz with donblair , warren |

Hey folks, this is a line of thought that needs your input!

Part I: Early origins

Legend has it that two LEAFFESTs ago, @donblair suggested that each tool project could have an owner. @warren adds that the word"owner" here is used less in the sense of possession and more in the sense of a public servant charged with duties.

@donblair referenced The Tyranny of Structurelessness from the 1970's, http://www.jofreeman.com/joreen/tyranny.htm

For everyone to have the opportunity to be involved in a given group and to participate in its activities the structure must be explicit, not implicit. The rules of decision-making must be open and available to everyone, and this can happen only if they are formalized.

I just had a conversation about this with @donblair, and here is a rough summary of some of the ideas that came up:

The typical attitude in an open software project is often expressed by "If you don't like it, fork it." In software, forking and remerging are relatively frictionless and you vote by contributing. I'm wondering, to what extent does this approach not map into open hardware for community initiatives, where the messy and drawn-out process of integrating priorities from stakeholder groups is valued as a way to achieve a more broadly useful / accessible tool, and the cost to the community for maintaining multiple projects is too high?

For example, imagine three independent Infragram branches. Materially, it's unrealistic. Socially, the burden of producing guides and workshops on how to use infragrams would increase by a factor of three. Potentially, the impact of future improvements might only help the portion of users on any particular branch.

Putting more thought into what protocol we use for contributing and merging into the main project seems more controlling but may enable more openness.

Part II: Recent Developments

See the mini-manifesto about broadening "open software" beyond just a license to actually being a transparent collaborative process http://openopensource.org/

Part III: prototyping a process for opening "open hardware"

@warren describes this as

"cultural and technical norms accompanied with intermeshed/complementary responsibilities"

So here's an idea for getting to Spectrometer 3.0 this fall, and establishing an ongoing a 6 month tool revision cycle:

  • Establishing a project maintainer (early October)
  • Posting clear instructions on the tool page for “how to submit a revision” to the maintainer (early October)
  • A one month comment period of public debates, issues being kicked around, developers iterating and resubmitting, until finally all changes are agreed upon by the community (all of October)
  • The maintainer integrates the changes (November)
  • four months of regular contributions
  • Begin the integration cycle again (April)

Part IV: let's discuss this!

Please add your ideas in the comments below! Thank you!!



with:warren with:donblair


8 Comments

I really like the idea of iterating over the process in an orderly fashion.


What is described above is hardware development approached as current day software development. You have a main trunk (project lead) which is forked by different people and depending on the state of the fork and the desired integration forks are merged into the main trunk again.

This is a very good idea. However, I encourage people to leave people enough room to have different opinions. I would consider it a good thing that not everything gets merged.


I like it. Providing a process to iterate and improve open source hardware in an orderly and transparent manner is very useful. Especially for systems, structures and components of long-lived gear, where continued improvements are intended and essential.


I’m not sure how the structurelessness issue relates to the idea of open hardware development. Structurelessness certainly relates to the unconference style of running the Public Lab Barnraising, so the Joreen essay is important reading for the organizers of that event.

The major Public Lab tools (aerial mapping, spectrometer, infrared camera) have been greatly modified over the years using the fork and merge model. Many community members have improved the design of all these tools and made new versions. For several reasons only some of the forks have been merged into the Public Lab trunk.

Some aspects of the open software development model map poorly onto hardware development simply because it’s easier to fork and merge bits than atoms. Certain types of forks are easy to merge (using a different grating material in the spectrometer), but others require complete redesign (using a different slit-to-grating distance) or finding a new supplier in Asia (using a different camera).

Few community members have the same motivation as Public Lab for modifying a tool. Public Lab is focused on designs that: 1) are amenable to easy-to-assemble kits, 2) exploit bulk purchase of components to reduce cost, 3) are simple to use, 4) have a low total purchase price, 5) used repurposed material, and 6) are inexpensive to ship.

Most community members who modify tool designs are focused primarily on making a single device with improved quality. Some features of these forks are eventually merged into the Public Lab trunk, but most are not. It is probably much easier to find a community member who is creatively motivated to “make a better tool” than to find one who is excited to “make a better product” for Public Lab to distribute.

Finding the balance between those two motivations is key. I don’t know how likely it is that an unpaid community member will be the right person to do this.


Thanks for these comments everyone.

@cfastie , i agree with your points, and appreciate your incredible work making better tools! i might add that it appears that there are multiple definitions of "better" floating around PL. I wrote this note to explore the idea that a more clearly documented process for contributing -- and debating what needs to be included in the next version -- might help these various definitions of "better" to more clearly surface.

@khufkens good to hear your points also. What you refer to in a phrase as "desired integration" is the phase that we are looking to clarify and open to broader public debate. Do you by chance have any good examples from other communities of practice that you could share?

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


I remember when @donblair mentioned "owners" and I reacted negatively, because I've seen how destructive it can be for one party to "own" a development process and to do so non-transparently and non-participatorily. But I also remember pointing out that these workflows, conventions and responsiblities are well-established in the free software world, and that we might look there for inspiration. @khufkens and @cfastie note that this proposal for a process draws very heavily on those long-standing examples.

Just as a point of clarity, though, forking is not considered a "good thing," but rather a mark of collaboration and sometimes transparency failing. See Mako Hill's "To Fork or Not to Fork" -- https://mako.cc/writing/to_fork_or_not_to_fork.html

Forking has historically been viewed as a bad thing in free software communities: they are seen to stem from people's inability to work together and have ended in reproduction of work.

He additionally cites a great resource, which he also wrote -- the Free Software Project Management HOWTO -- in which he mentions:

The short version of the fork section is, don't do them. Forks force developers to choose one project to work with, cause nasty political divisions, and redundancy of work.

This is also a great all-around resource on technical collaboration, including recommendations on "how to accept patches":

This HOWTO has already touched on the fact that as the maintainer of a free software project, one of your primary and most important responsibilities will be accepting and rejecting patches submitted to you by other developers.

And great subsections on things like:

  • Bring it to the community
  • Technical issues are not always good justification
  • Common courtesy

It also has a great bibliography -- rich with other writings which are characterized by discussions of leadership, politics, and community -- if anything, more so than discussions on technical topics.


I also wanted to link in this issue I just filed based on some ideas that came out of the staff meeting -- it could list proposed upgrades for a given tool page, as well as provide a legible way to learn about contributing and a standard way to post proposed upgrades.

https://github.com/publiclab/plots2/issues/325


I want also to include this link from the open software community about making a pleasant experience for both the contributor and the maintainer http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/


You must be logged in to comment.