Governance

What is governance in open source? What unique understandings, perspectives and applications do science and research OSS and designers have on governance?

Governance is typically expressed in OSS projects as a set of rules and shared norms and responsibilities across the project. These can be enforced at various levels, from casually and socially to formally and legally. Licensing and code of conduct are parts of the broader term ‘governance’ but different OSS projects may or may not use that term when describing how the open source is built, maintained and, in certain cases, ‘owned’. Science and Research OSS has a few unique values that are considered when governance is either implicitly known or explicitly stated, though smaller-scale, early stage projects tend to lean implicit and larger or more time-mature projects lean towards explicit governance. These unique values can be found better explained throughout part one of this findings document as well as in part two under prioritization. The value that comes into play most strongly for Science and Research OSS is openness that encourages and promotes reproducibility and replicability via use of the scientific method as well as openness by way of access to as many interested people as possible so that both of these might lead to better, more robust and impactful scientific and research knowledge and discoveries.

Design and designers are rarely part of conversations about the governance of Scientific and Research OSS and therefore, don’t get to participate and advocate for design, designer, usability and user focused needs in governance processes.

There are many possible reasons that could explain design and designers’ lack of involvement in governance. This could be due to designers often being brought in at later stages of a project, after governance discussions and decisions have been largely made. Designers not having a culture of governance in its operations and education processes that leads to not being knowledgeable about governance generally until encountered in OSS. Or design and designers being a misunderstood and less-valued part of software builds by OSS culture generally. Regardless of the combination of factors involved in design and designers being omitted from governance, the comments made by our participants about how important design methods are to the strategic direction of an SROSS was evident when they described specific situations such as wanting user validation and feedback on what should be improved in the SROSS before moving forward with a technical development.

A designer who works out of a university lab across multiple Science and Research OSS projects, including a data cleaning and transformation project, details below aspirations of how users’ voices can be included consistently and explicitly through a revamped governance initiative.

“In 2023: want to revamp governance and try to have what they want to call an “ambassador council” — 10 to 20 people to represent the community that meets 1-2 times per month to give feedback from the major user groups and have the people who understand the project and can represent the community, and also start to make introductions to new communities or groups of people. still need to hammer out the details”

To illustrate the frustrations that those coordinating contributions on projects can express, a community manager for a Python based interactive data visualizations tool told us the following:

“That original design choice of [OSS project]…it’s a millstone around the library’s neck. Because the design choices that were made because of [OSS project], they make no sense. Right now, we’re having this crazy fight about annotations and hours. And it’s… the reason this function exists and has 15,000 knobs, because that’s how it was implemented in [OSS project].”

In this example, the participant makes a direct reference to an interface element (annotations and hours being a UI function that has many ‘knobs’ or configurable buttons associated with that UI feature). We can clearly hear the confusion at how and why certain design choices have been made in the OSS project and the conversations and arguments that can linger when there is not clear direction on design and informed user needs at a respected level in an OSS project. Including design and user perspectives and respecting those perspectives can go a long way to settling disagreements better and clarifying decisions with tangible and applicable user research.

The same community manager goes on to describe a connected problem when trying to bring design, or any ‘non-code centric’ perspectives into an OSS project space, where non-code rules and functions are seen as ‘less technical’ and often less valuable by association. This makes finding and keeping a seat at a decision making table difficult and time consuming.

“Everyone says, like, just keep all arguments technical, it’s like, nothing is only technical. Right?”

This often means that designers involved in OSS are at risk of spending years trying to assert their relevance to a project and eventually exit a project. This community manager wisely identifies that problems and their solutions are rarely ‘purely’ technical in nature, which can be difficult for many coder-centric OSS projects to come to terms with.

Conclusion

In this section we focussed heavily on the aspect of governance that most impacts design, designers, usability and user voice. However, there are many broad and complex challenges with governance that were not captured here that also impact on these design aspects. What we can assert is that If design is not given a seat at the governance table, or has to fight for an extended time, under relentless questioning, many are likely to seek more inclusive and accepting spaces where they can offer their valuable contributions and be welcomed and appreciated. This also stops people who do not identify as designers from participating in design processes and practices which are often collaborative in nature.

A community manager speaks to the lack of processes in SROSS projects contributing to the problem of users to contributors conversion challenges “If we had better processes, I think that people like our users who could be developers, but we don’t have the processes in place, and policies, we don’t have the processes in place. Why is it? because we have this kind of weird gatekeeping around who is what?”. They have stumbled on a discovery around gatekeeping and what contributions are valued by the systems of governance (code) and what is not (non-code) where the suggestion of, perhaps not all users who could be contributors would want to contribute as a developer - perhaps they would want to contribute design or other non-code contribution. Here, if it was explicit in the values and governance system of this project that design and non-code contributions are welcomed then perhaps more users would become contributors.

And finally a researcher working on a citizen science science platform by and for autistic individuals states how the design of governance itself is an important piece of an open science project: “In academic and citizen science projects: governance design is really important.”