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.
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!!