Valuing work “on the ground”: making the hidden work visible in open hardware

Photo credit, William Murphy

Julieta Arancio, Drexel University and University of Bath post-doc.

Open source origin stories are often associated with the joy developers get from learning, from being creative to solve problems (1,2). They continue with more excitement when other people find out what they can do with the new code or hardware design, and how a community starts emerging around better tech.

These stories often lead us to think of collaborative development as a non-coordinated effort that magically results in better-performing technologies. In part this is possible because technical contributions to a project can be easily tracked through collaboration platforms (3). Using tools like Gource (4), for example, one can produce an awesome visualisation of a project’s history of collaborative development. A simple YouTube search shows Gource videos for projects like the Linux kernel, Python, TensorFlow and more. Colourful bubbles representing technical contributions emerge in branches, and little users float around connecting to each other throughout project history.

Gource videos are really cool. However, they show only one side of the collaborative development process. What makes it possible for the floating contributors to find and interact with the project effectively? How are decisions made and work organised, how are conflicts between people solved? This key glue work (5) takes place in the background and is difficult to measure and therefore hard to identify and give credit for.

The work of transmitting sticky know-how

FOSS researchers have been studying these questions for almost a decade (6,7). Organisational work is key to FOSS success, changing when projects scale (8), or when the community begins incorporating contributions from corporate volunteers (9). FOSS experience is an important resource for open hardware communities, but key differences between software and hardware projects result in teams dealing with new tasks and responsibilities. For instance, publishing online documentation may not be enough for increasing adoption by end users who lack training in hardware, an issue documented by the Audiomoth project (10) in their work with conservation ecologists.

Probably the most studied hidden work in open hardware projects is documentation development (11,12,13). Teams often find that producing good documentation is an extremely demanding and poorly rewarded task. At the same time, they recognise the important role of good documentation in attracting new users and contributors. Although efforts towards making complex documentation easier do exist, in practice there is still not one accepted solution to this problem. This issue is particularly visible when open hardware devices become “de facto standards” for a community or field, attracting institutions’ attention. Producing good hardware documentation still involves dealing with multiple expertises, bills of materials that change through the life of a project and branches, explaining the rationale behind design choices that developers assume as given, or thinking of alternatives for components that are difficult to obtain elsewhere due to supply chain issues. The process of accepting open hardware designs into existing standards demands aligning these multi-layered interactions to fit requirements conceived under a different ontology; for example one that doesn’t consider multiple versions coexisting at the same time.

Documentation is key because if you want to adapt an open hardware design, you first have to be able to build the device. But unlike software, where you download and run the code to see how it works, there is tacit know-how involved in building a material device. Translating this sticky information (13) into written instructions is really hard; it requires — among other things — that you understand whom you are documenting for. As a result, the burden of writing documentation often falls into the already overloaded, more experienced members of a project. Or in the words of an academic hardware developer “I feel I’m the only one who can do it, otherwise it would involve me doing double work: first explaining it to someone, then checking what they wrote.” (personal communication, 2020). Better documentation often results from ongoing interactions between developers and end-users of a device throughout the development process. Documentation can be a useful tool itself to generate dialogues with the end users, as they can make their expectations and questions explicit, guiding the know-how sharing process.

The work of talking to each other

As projects attract users and contributors, another stream of work starts taking its toll on developer teams. Growing a community requires, among others, having a system in place for triaging feature requests or fixing bugs (14,15). Therefore it requires discussing who makes the decisions in the project, which is an often overlooked task until it’s too late (16,17). In open hardware a community can involve experts (in software, design, electronics), scientists but also manufacturers and users. Reaching agreements between people who bring in such different expertises can be daunting. Taking an ecosystem view (18), mapping these multiple expectations as early as possible and involving generalists/facilitators who can help build a common language (19) are some strategies towards identifying consensus and dissent.

This situation is clearer in open hardware for community-based research, where an impressive amount of work is performed by knowledge brokers (20). These “people of all trades” dominate enough technical language and at the same time community expertise to bring them into dialogue. They build the narratives and common language necessary for facilitating agreements that make it possible to move forward together. These roles are often played by community organisers and academics who taught themselves enough technical expertise to understand project activities.

Although this work is key to increase adoption of a device and in the best scenario fulfil a community need, recognition does not follow (21). Universities and funding institutions understand community science as outreach, education or participatory research; making technology work in a particular context is less appealing than novelty or discovery (22). In a problem that is shared with other disciplines (23,24), it is extremely difficult to measure and communicate the impact of this fuzzy work.

Learning from others

Open hardware is still an emerging phenomenon, and as such even credit for technical work is complicated to obtain (25). As organisational work is often assumed as given, recognition is even more complicated (26). In academia it is often performed by early career researchers on precarious contracts, who find it hard to capitalise on it for career progression; outside academia it often falls on women and other underrepresented groups.

There are many lessons open hardware can learn from FOSS experience. But when it comes to valuing work “on the ground” equitably, open hardware can also learn lessons from a long-lasting tradition of community based participatory science (27,28,29,30). Unpacking these hidden works is the first step. Recognising who is performing them comes next: are the women in our project always in charge of taking notes and organising people? Is it always the postdoc who replies to emails and forum messages requesting tech support? Some problems are systemic and require collective action to change. There are however some strategies that we can put into place in the meantime: implementing protocols for fair citations in academia (31), rotations so unrewarded tasks don’t always fall on the same people, making visible organisational work and ensuring proper credit is given to those “in the background”. Making this key support work visible and designing strategies for rewarding it is necessary if we aim towards sustainable open hardware.

References

1. https://www.prusa3d.com/page/about-us_77/
2. https://docs.python.org/3/faq/general.html#why-was-python-created-in-the-first-place
3. https://docs.github.com/en/rest/metrics
4. https://gource.io/
5. https://doi.org/10.1177%2F0091552108314756
6. Nadia Eghbal. 2016. Roads and bridges: The unseen labor behind our digital infrastructure. Ford Foundation.
7. Self-organization of teams for free/libre open source software development — ScienceDirect
8. The Labor of Maintaining and Scaling Free and Open-Source Software Projects
9. Benjamin J. Birkinbine. 2015. Conflict in the Commons: Towards a Political Economy of Corporate Involvement in Free and Open Source Software. The Political Economy of Communication 2, 2 (2015). http://www.polecom.org/index.php/polecom/article/view/35 Number: 2
10. Bonvoisin, J., Mies, R., Boujut, J.-F., & Stark, R. (2017). What is the “Source” of Open Source Hardware?. Journal of Open Hardware, 1(1), 5. DOI: http://doi.org/10.5334/joh.7
11. Bonvoisin, J., Molloy, J., Häuer, M., & Wenzel, T. (2020). Standardisation of practices in open source hardware. arXiv preprint arXiv:2004.07143.
12. Miljković, N., Trisovic, A., & Peer, L. (2021). Towards FAIR Principles for Open Hardware. arXiv preprint arXiv:2109.06045.
13. “Sticky Information” and the Locus of Problem Solving: Implications for Innovation
14. https://ieeexplore.ieee.org/document/8565942/
15. https://press.stripe.com/working-in-public
16. https://doi.org/10.1080/14680777.2021.1890183
17. https://communityrule.info/about/
18. echopen.org/
19. https://www.appropedia.org/GSTC_Toolbox
20. https://doi.org/10.1016/j.respol.2014.01.007
21. Open Science should not be a hobby
22. “Research Software Sustainability: Report on a Knowledge Exchange Works” by Simon Hettrick
23. Counting Care Work: The Empirical and Policy Applications of Care Theory | Social Problems | Oxford Academic
24. Universities’ reliance on free labour is unsustainable — Research Professional News
25. https://physicsworld.com/a/high-spec-open-source-microscopy-for-all/
26. https://thessaly.github.io/phd/discusi%C3%B3n.html
27. https://doi.org/10.3167/ares.2014.050102
28. https://cogentoa.tandfonline.com/doi/full/10.1080/09505431.2022.2035710
29. https://www.sciencedirect.com/science/article/pii/S1462901115001057?via=ihub
30. https://doi.org/10.1300/J125v09n01_01
31. https://civiclaboratory.nl/citational-politics/