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?

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/