The Royal “We” in Scientific Software Development

Or: A challenge to myself (and maybe others) to change how we represent community software development

There’s a delusion in academic software development: that there exist brilliant people who don’t need the help of others. This delusion says that these people operate in isolation, that they carry the sole responsibility for their projects, that they are pulling strings, architecting. This delusion says that the only valuable contribution is innate intelligence, that the “idea” is the only metric by which individuals can be valued.

This delusion is insidious not only because it is self-perpetuating, but because it so blatantly favors the people who are the face of the work and the public contributions that are easily measurable, like source code commits. And some of us benefit from that more than others.

I’m enormously fortunate. As part of my work, I have had the opportunity to engage my passions for problem solving, for communicating, for following my scientific curiosity, for pursuing my creative urges, for coding, for visualizing, and for getting to do it with some of the most brilliant, insightful, warm, kind and creative people I could ever hope to meet.

Some of these opportunities have come however, because I do work that is easy to assign credit and value to.

I’m proud of the work I have done. About ten years ago, I wrote the first line of code in what is now a reasonably (but not overwhelmingly) well-used piece of software in the astrophysical community called yt.

In the time between then and now, there have been periods of time (and sections of the code) that I can largely take credit for the initial implementation, the design, and some of the debugging. And while I am proud of that work, there are numerous times when I have not contributed code, when I have not participated in the community, and there are many components — both modules and infrastructure — which did not come from me.

yt is both an application and a library, but much more the latter. It’s meant to be used to write scripts that conduct analysis or create visualizations, and to be extended to conduct more types of analysis and visualization. There are readers for data formats, indexing systems, derived product generation, analysis modules, visualization components, and many, many other components. Depending on the functionality they present and the level of abstraction at which they are found, they are of varying criticality to the overall software. Some, like “code frontends,” live at the top-most level, providing crucial functionality for individuals loading data, but which don’t have a large degree of interconnectedness. Others, like the array system, or the selection system, are deeper into the code base and are called more frequently. This does not make them more important.

Code is not the sole metric of a successful project. In fact, it might be one of the worst metrics. It’s a problematic metric in a lot of ways, but I would highlight two in particular: it’s incredibly reductionist (as well as difficult to measure accurately) and it favors far too strongly the “first movers” over the much broader collection of influences that guide and support a project. (For more on how this may disproportionately impact individuals from underrepresented and minoritized groups, see the incredible article “The Ethics of Unpaid Labor and the OSS Community” by Ashe Dryden.)

The way individuals, particularly in science, engage with software does not start with a consummate reading of the code, or evaluation across many different technical metrics. It begins with discovery, hearing about software from a colleague, a competitor, from a website or a talk. This often leads to documentation, including advocacy and tutorials as well as both narrative and reference documentation. Often, installation or inspection come next, followed by following tutorials or examples, or interacting with a graphical interface. And this can then be followed up by engaging with the community, asking questions, suggesting or implementing changes, and perhaps even advocating in turn. In academia, many of these activities can be supported by grants or indirect funding, but oftentimes they are not — they are provided on a volunteer basis by peers. And amongst people developing or participating, there is often communication, personal and professional disputes to resolve, and even issues of governance and project direction.

If we only look at “who wrote this line of code,” we ignore all of these other aspects — aspects which are arguably far, far more important. People who took risks on unproven software, who advocated for it, who contributed ideas, bugs, corner cases, documentation, who instructed students and cited it in papers, and who supported it in so many difficult to quantify ways.

And even worse, if we delude ourselves that the technical merits of a project are typically tied to one or a handful of people, every other code contributor is immediately marginalized.

There are people in the yt community who simply do not get recognized for the incredible amount of work that they do. This work isn’t always in the form of code, although that does play a large role. It’s in their advocacy, their training, their devotion to producing something we can all be proud of, that I see their dedication.

This article didn’t come out of nowhere; in fact, I confess that I am writing this because I am trying to make amends for some recent failures. I was discussing this with someone recently, and they said something that I think is incredibly astute. It was in the context of a couple comments that I made that overplayed my contribution, where I bought into the idea that code was supreme. To be honest, I am intensely embarrassed. It is something I should have known, something I should have recognized, and something I should have worked against. Paraphrasing:

“Like it or not, people look to you when they think of the project. As such, it falls on you to make it clear that we are not just helping you. You know what people think every time you say ‘we’ did this.”

They’re right. And what’s more, when I don’t explicitly reject this perception, I am subtly reinforcing it. As the person who has this role, I have to elevate the perception of the contributions of others, because I’m the one who benefits when they aren’t elevated. It is inappropriate to let others think I am using the “royal we” when I talk about the code, and this requires actively addressing that perception.

If you’re reading this, and you are part of a collaboration around scientific software, I challenge you to think very carefully about how you present your involvement. Too often I have been cavalier in that presentation. I’ve allowed an implicit assumption of the audience that I am the responsible party to be unchallenged, if not reinforced. I’ve shown names, but not faces, or I’ve shown names without calling them out. And the people that have suffered as a result are the ones who are the most crucial to the community’s success. They are the people I consider myself grateful to work with, and I owe it to them to steward them as best I can.

Before you use the royal “we,” I challenge you to think about it. I challenge you to present your role explicitly and say what you have been involved with, rather than presenting it in an undifferentiated way. Perhaps most importantly, don’t function under the mistaken belief that credit is a zero-sum game, where giving it to others diminishes your own role.

I want to end by recognizing many of the contributors to yt who have contributed in so many different ways. yt has a model in place for recognizing contributions that go beyond code; individuals can be designated “members” of the project to indicate that they have been recognized by project peers as having made substantial contributions to the project. An alphabetical list of these people can be seen on the website, although even this does not tell the complete story. And I would like to take this time to say thank you to both the members of the project as well as everyone who has contributed time, thoughts, code or communication.

[Thank you to Britton Smith, who was instrumental in the development of the thoughts behind this essay, and in the development of the yt community as a whole. I’d also like to thank Tracy Teal, Carly Strasser, Titus Brown and Ethan White, who provided feedback on a draft of this article.]