Understanding Scientific Open Source Software (OSS) Project Leadership

Imagine a world where open source software (OSS) creators and leaders are recognized as making significant contributions to science. OSS opens doors to building tools, manipulating data, re-imagining existing techniques with modern computing power, in affordable ways that can be shared with under-resourced scientists. These leaders therefore serve a vital role in accelerating scientific advancements, but their work is often not recognized or valued in research organizations.

OSS leaders, often originating as project founders, donate value and capability to the scientific community that is hard to measure precisely. When they work to grow these efforts, and invite contribution, they're often overwhelmed by the work of community, team leadership and governance. Without their generous contribution, many recent scientific breakthroughs would be impossible.

What would an intensive Open Source Software Leadership program look like?  How could it best prepare OSS leaders to learn the skills necessary to grow vibrant OSS communities?

Initiatives over the last two decades have made substantial progress in convincing institutions that research software projects and research software engineers are essential and in need of support (e.g., Software Sustainability Institute, Research Software Alliance, Research Software Engineering Society). The next step, then, should be to equip OSS leaders with the concrete leadership skills they need to build and sustain their projects. Solving this problem is particularly important for leaders in the early, formative period of project development, and for those who lack the time or money to pursue leadership training on their own.

Our motivation for writing this blog post is to summarize what we’ve learned about project leadership across our various experiences in OSS—conducting ethnographic research on project histories, governance, and sustainability; leading organizations that train software developers; and helping to activate and build OSS project communities. We’ve found that leaders are often not formally prepared for or supported in their journeys, specifically at key transition points in project trajectories. We’re actively exploring ways in which we can build support structures which can enable project leaders to grow in these skills gap areas, but we need input from others.

The goal of this forthcoming set of posts is to describe the patterns we've seen across our work in OSS, with a particular eye toward the key transition points and challenges that leaders face in navigating transition decisions.

This helps us lay the groundwork for asking:

How can the broader community of research institutions, foundations, and fiscal sponsors best support the open source leaders (and potential leaders) who drive science forward?

Four Phase Model

To begin this effort, we asked ourselves: What are the common patterns we’ve seen in the evolution of OSS projects? What decisions need to be made as leaders grow, or decide not to grow, their projects?

Based on these conversations, we put together a four phase model which fits the general themes found in the research, then worked to validate and check this model with OSS leaders in our network.

Phase 1: Problematizing

All projects, no matter the scientific discipline, originate with a scientific problem that has one or more of these motivating factors:

1. No computing solution exists

2. Existing solutions to the problem require further software development

3. Purchasing commercial software is too costly

Individuals or teams of researchers then look to develop some form of software that propels their research effort forward. In some cases, this involves building on existing OSS packages; in others, solutions are built from scratch.

The problematizing phase can lead to one-off solutions for a given scientific study. The developer may realize, however, that the solution has applicability to other problems in their own work or others' work. In the case of projects we’ve studied, leaders recognize that the tool may be useful to others (or others discover it on their own), so we'll speak mostly to the challenges such leaders face. Sharing the tool openly becomes the next logical step for these leaders, enabling others to both use and build upon the solution by adapting it to new purposes. Scientific communities small and large may then view the tool as useful and necessary over time, providing proof of concept to the project leader.

Phase 2: Choice

At this point, project leaders must make a choice: They can allow users to do what they want with the tool and/or continue to use it in their own work (“staying small”), or they can work to bring visibility to the tool and attract new users and developers (“going big”).

Leaders who choose to “stay small” often go slow and take an incremental approach. They may apply for grants to hire a graduate student or support their own time developing the tool and/or build on the tool as new research problems arise. These are typically smaller grants that are focused on specific labor and computing needs to develop the software. At this stage, OSS leaders may also choose not to update the tool or to abandon the tool altogether.  

Leaders who choose to “go big” with their project—which one leader called the YOLO (“you only live once”) approach—decide to share their creation broadly, engaging others and demonstrating the value it offers to the scientific community. Demonstrating value entails everything from going to conferences to talk about and demo the software, to seeking large grants, or actively sharing the solution on social media and in community outlets (e.g., email groups, forums, Twitter, Slack).

Attracting funding can take many forms, as funders of different types see a variety of reasons and avenues to support OSS tools. Funds can be used to start a team of developers and maintainers, grow the community around the tool, support leaders’ time and effort, or develop new use cases for the project.

Phase 3: Scaling

With sufficient funding, “go big” projects can begin to scale the effort and reach a broader base of developers and users. Scaling is where we’ve seen the biggest problems arise with regard to leadership preparation and support. We’ve identified three domains where scaling challenges persist: 1) Community growth/cultivation, 2) building and managing a team, and 3) governance of project decisions. Leaders struggle with these issues because they are deeply trained in science, not management or administration. This causes many project leaders to neglect one or more of these issues as they become stretched for time and resources, contributing to long-term issues with project and leader health.

1 – Community: OSS development at scale requires collective action from a large group of scientists and/or computing experts. Finding these community members and facilitating interactions between them—particularly when they do not work for the same organization, are geographically dispersed, and have different career trajectories and incentives—is among the most challenging demands of leading an OSS project.

Leaders often seek to hire and support a community manager in the scaling phase, an approach that is gaining more formalization and structure than it has in the past. Recent efforts from groups like Center for Scientific Collaboration and Community Engagement (CSCCE) are driving the professionalization of community management. Yet ask any OSS project community manager and they will tell you that they cannot do the entirety of community building and sustainment on their own: Project leaders must put structures and resources in place to support community managers' work to facilitate safe, equitable, generative interactions among community members.

Helping community managers to thrive requires OSS leaders to think deeply about the management techniques, policies, and technologies needed to balance structure and flexibility in community interactions. On top of that, leaders must also develop skills in measuring and evaluating community health in a very context-specific way.

2 – Building and managing a team: Aside from community-building and hiring a community manager, many other tasks must be done to support a project. Leaders likewise cannot do them all: They must work with institutions’ HR departments, find and evaluate good candidates for jobs like software development, and connect with other organizations who can support their tool. Very few (if any) scientists are trained to do these things in graduate school or even on-the-job (e.g., in building a lab team). They must therefore learn these skills on their own. Nearly all of the project leaders we have interacted with mentioned reading management and leadership books, attending generalized online courses on these topics, and seeking mentorship from those who have done it before. Yet it is a lot to learn on their own, taking additional time away from what they set out to do (solve scientific problems with software).

Many of the leaders we spoke with expressed deep regret over their decision to “go big,” owing largely to the demands of management and administration. As one leader told us, “Had I known what I was getting myself into, I may not have shared [OSS package] in the first place.” This challenge and regret can be particularly harsh for project leaders who work in a tenure-track academic job, where publications are a requirement for tenure and promotion yet less and less of their time can be spent on these efforts. Others may end up foregoing the tenure track, opting instead for staff jobs like research scientist or other affiliations within or outside of academic institutions. Scientists who use and/or develop OSS in corporate environments face different, but similar challenges in aligning their scientific pursuits with the goals of their organizations.

3 – Governance: Projects of a sufficient size inevitably begin to struggle with governance. In other words, leaders must develop structures for how to evaluate and incorporate code contributions; decide how to make decisions about the tools (e.g., becoming a “benevolent dictator for life” or opting for a more democratic approach); set guidelines for community interactions (e.g., codes of conduct and facilitating diversity, equity, and inclusion); and move the project in the right strategic direction to sustain funding and project health.

Once again, leaders are not usually formally trained on these topics. Yet not considering governance challenges early enough can end in disaster. Some possible outcomes of not thinking through governance include: infighting in the community, inability to manage a growing number of contributions, and making decisions that alienate or anger community members.

Strategies exist for averting these outcomes, but they are not readily available to OSS leaders and potential leaders. Furthermore, governance challenges are difficult to anticipate and accommodate given the time and effort needed to build a community in the first place. Thinking through and learning about these challenges earlier in OSS project evolution could help leaders to better adapt to the needs of their growing projects.

Phase 4: Institutionalizing

If the above three phases are successfully navigated, leaders must focus on sustainability and the path forward for the project. Sometimes this involves finding an institutional “home” for the project, like a university research center, institute, or dedicated arm of a company. Funding again comes to the forefront, with many leaders expressing additional regret that they spend much of their time chasing down grants or rationalizing their work to funders rather than making strategic, scientifically-beneficial decisions.

But this phase is also where many leaders find the most fulfillment and reward. They may recognize that institutionalization requires compromise and offloads some of their autonomy on the project—something that may sound negative, but allows the leader to take on more high-level work. Successfully institutionalizing also comes with the benefit of status, where scientific and computing communities recognize the accomplishments of the leader and the essentiality of the project. The focus on training leaders for the institutionalization phase should therefore be on reconciling compromises with scientific and career goals, perhaps a skill that only those who have led projects can teach.

On that note, we must also ask any OSS leaders who are reading this:

Conclusions

It has become clear to us throughout our thinking on this topic that more support is needed for leaders and potential leaders of OSS projects. Each of the phases above are amenable to courses, training, workshops, and peer-to-peer learning, yet few are available and much of the knowledge that current OSS leaders have is not being shared as fully as it might be. Beyond availability of training, we are also concerned that the enormous amount of effort to overcome phased challenges excludes many would-be leaders—those who do not have the same institutional support, networks, socioeconomic structural position, and overall privilege to endure what it takes to build and scale an OSS project. Given the importance of open source software for the advancement of science, this is a huge loss.

We’re going to be continuing to add on to this post, creating a series of posts which will color this conversation with more data (quotes and quantitative info) in an effort to flesh this out more.

If you’ve got comments, experience, feedback or suggestions, we’d really like to hear it, you can reach us at [email protected]