Public Lab has spoken a lot on Idea Lab about building “recursive publics,” in which people are knowledgeable about and can reshape the structures that bring them together. But how do you build such a public in practice? Is Public Lab succeeding in building such a project? How should one measure that? What is participation in Public Lab?
Over our spring retreat, Public Lab staff began to ask ourselves such questions to formalize our goals for the next year of organizational development. This discussion circled around three main topics: the emerging structure of our organization, the structure of our website, and the process of developing and using our research tools. Central to each of these issues was the question of how to continue to foster, support and structure participation in this organization we increasingly recognize as hybrid: an emerging non-profit structure and a community of voluntary online and offline participants.
These two structures are inherited from our mission of fusing open-source production with an environmental justice and health research mission more common to a non-profit organization. They also come with different structures, expectations and processes for organizing actions.
Each of the staff members were feeling the frictions from, and emerging possibilities of, blending these organizational forms: For instance, how could we open up tool development to community participation and remain true to our organizational mission?
Non-profits are legal entities bound by the formal conditions of 501c3 status, which requires a hierarchical organizational structure led by a board of directors. Free software communities, or an online public beyond the structure of paying for and maintaining a website, don’t necessarily require such formal hierarchical structures. The promise of distributed, affordable, DIY and accessible research tools relies in great part on the formulation and the continued existence of a voluntarily public community who are actively creating Public Lab.
However, publics, particularly online publics, are not necessarily able to reliably maintain a funding structure and seek funding from public or private sources. There’s also no requirement for such a community, or public, to maintain a particular goal.
So how were we to blend a hierarchical non-profit support structure and a non-hierarchical open-source public and remain true to our mission of developing affordable tools for DIY environmental research?
goals for tool development
Our discussion began with a brainstorming of current issues, interests and findings. These were documented on Post-it notes. One realization we came to was that “research notes” had become a core means of participating in Public Lab projects — a core product in our open-source hardware development projects. A research note is akin to a blog post that documents a Public Lab member’s activity on project. We concluded that research notes are vital to tool development and participation, therefore facilitating and structuring the process of these entries was vital to growing open-source hardware development.
Furthermore, we noted that there are a range of research notes, from highly speculative ideas and background research, to notes on workshop activities, circuit diagrams and reports on research findings. This suggested to us the need to think of a tool-development cycle, which produces different modes of research notation.
Before the meeting, we had defined a provisional set of stages for tool development: early adopter, in development, and field tested. However, we’d developed no clear sense, and certainly no formal process, for distinguishing between these categories and how a tool could be said to move between them.
Focusing on a tool development cycle, we began to analyze the stages of each tool’s development: What were particularly pivotal moments, where were tensions experienced, where had tools become stuck or begun to flourish, and what significant questions were unaddressed? Through silent, individual reflection, each staff member brainstormed their notes on Post-its, then we attempted to generate a vertical map of them, from early to late stages of tool development.
Here’s a MapKnitter map of the tool development chart we made that day. Discussing each Post-it as we added it to the chart, we began to distill a process and structure that could help make clear steps toward our goal of solidifying a recursive process of tool development.
We discussed, for instance, how is a tool project started? Who can start a project? How can we ensure it stays on mission? In answer to these questions, we developed the concept of a “sandbox” stage of development. This is where early ideas could be developed and a foundation laid for how the tool relates to Public Lab goals. Within the sandbox, we described a feedback cycle that leads to a project’s formalization. We drew this out as a triangle of feedback between a technical idea, background research, and an environmental problem.
To move a project to an “in development” stage, we discussed the need for organizing a small group or subset of lab members interested in working on the topic. This depends on the clear illustration and discussion of the project in the sandbox and is signaled by a “Tool page.” It also required some engagement in the process of prototyping.
An advanced “in development” or “prototyped” project thoroughly documents the prototype so that others are able to try their hand at making it. Public Lab’s barnraisings or hackathons are other forms of collective research that might be significant at this stage.
We discussed how an RISD class-based workshop which documented the thermal flashlight prototyped by Kyuha Sim, followed by a series of workshops in New York, spurred the maturation of this tool into a functional prototype.
A ‘hello world’ moment
A functional prototype can be recognized, we noted, by a “hello world” moment where an individual uses a prototype to illustrate an experimental result, such as the use of the VOC circuit by Byeongwon Ha to detect a gas leak in his home, the first thermal images, or successful Near Infrared images. These, when well-documented, can attract a set of interested participants. Interestingly, these participants may not actually be the same as the community interested in using the tool.
Moving beyond the prototype into a distributed development process, we discussed how it can often be vital to draw in the expertise of those who have formal experience with non-DIY versions of Public Lab tools — even if those communities are removed from Public Lab’s mission of environmental health or justice. Public Lab’s Jeff Warren described, for instance, how sharing the DIY spectrometer with knowledgeable amateur communities interested in aquarium health was vital to creating a technical community invested in developing the tool. This process was supported by the circulation of prototypes, even though they still faced significant design issues. The first spectrometers circulated, for example, were not calibrated — each produced their own data that may or may not relate to data produced by the other spectrometers. Rather than ceasing development or solving this problem independently, the spectrometry community solved it together by using the same fluorescent bulb and comparing their resultant spectra.
A collective “hello world” for an open hardware project was this kind of moment — a moment when a collective begins working together and sharing their results.
The sharing of these results is greatly fostered by the possibility of shared data repositories where participants can compare and contrast their results — Spectral Workbench helped produce this for spectrometry and our archive for Grassroots Mapping.
The tool-development timeline
It’s important to note that while we conceived of this tool-development timeline in a linear fashion, many of our projects had well-developed aspects of this idealized process and not others. Based on this brainstorm session, we’ve begun to formalize this tool life cycle as both diagrams for organizing research and as a means to shape the redesign of our website and staff roles to support aspects of this structure.
We also mocked-up descriptions on our wiki and tried to locate each of our tools in this cycle.
Based on these diagrams, we’ve begun a collaborative redesign of our website to reflect this tool development cycle with the goals of:
- facilitating conversations across projects in similar stages of development, so they might share knowledge;
- fostering the development of new projects not initiated by staff;
- creating coherence in tool development and ensuring that our mission of developing low-cost tools for environmental monitoring by communities is met;
- defining more clearly staff roles for maintaining this structure, such as helping develop how-to guides, curate research notes, and community formation.
True to Public Lab’s goal of participatory development, we’ve opened all the processes up to the Public Lab community. Community members can comment on the redesign processes that are afoot on Github, as well as aid in actually mocking up redesigns of the website.
In this redesign, all of the tools in a particular stage share a common access point. In the next stage, we’ll begin to identify and create meta-knowledge around shared problems at each stage of tool development. For instance, a hallmark we discussed of a tool moving from the “sandbox” phase to a prototype phase is a “proof of concept” experiment. Could the staff assist projects in developing such proof-of-concept experiments in order to foster coherence and learning across our various research projects?
After an explosive and fascinating year of experimentation, we’re collectively embarking on the next stage of formalizing novel structures and processes that support open-source hardware development of environmental research tools.
