Funding and Sustainability

For OSS within science and beyond, funding and sustainability are of continuous concern. Championing openness above profit, projects often struggle to maintain funding, have majority-volunteer maintenance teams, or have to spend a large portion of their time fundraising. Participants reported that grants are particularly challenging: institutions take percentages of grant money as high as 60%; grants are usually limited to a single idea or feature; grants are typically focused on ‘newness’ rather than long term stability, so many projects can get funding to get started but not to keep going. Despite this being a well-known issue in the OSS community, our research revealed intricacies and considerations that come up in SROSS projects in particular.

Sustainability considerations depend greatly upon project size and scope. A spectrum of projects exist in the ecosystem: On one extreme, “niche” projects can secure funding to support a specific research question, and on the other, large, foundational tools are almost too vital to the ecosystem to face project-ending circumstances. Participants warned of the difficulties and the potentials of these extremes.

Interestingly, the most “niche” projects we spoke to – ones in which only one person built and maintained a piece of software and the project served a very specific, niche purpose – did not have as much of a maintenance and sustainability burden as slightly larger projects. The “in-between” projects are trickier because, as one participant described: “people have a particular ambition and get a grant to make something, then the money runs out and things struggle to continue growing or even staying at the level they were.” Understandably, projects cannot maintain their level of development if all of a sudden their maintainers go from paid to 100% volunteer. Either they settle for volunteer maintenance and hope to attract more contributors, or they have to search for more money.

Slightly bigger or perhaps more well-known or established projects also struggle with sustainability and stress about funding, but one participant urged a reframing of the problem. This person told a story of asking a maintainer who was anxious to find new funding, “‘What, what would happen if you guys just stopped?’ And he said, ‘Well, I think the users would probably pick up the software and would keep it going. Because there’s a lot of different user groups that depend on it.’" So to them, “the challenge is less ‘can we keep the same people working on the same software?’ but rather ‘can we create software that can be passed to whoever is willing to maintain it so we don’t have to start again?’” This approach speaks very much to the ethos of both Open Source and science, in which work progresses based on the contributions and work of those that came before you. This also suggests an awareness of ‘succession planning’ for OSS but was not explicitly talked about by our participants. This approach, of course, is easier said than done when people are relying on project funding as their primary salaries or as part of their academic work.

Large projects with the ability to be adapted to many different uses appear to have the least trouble with sustainability, both because so many types of users rely on the software, and because the breadth of use opens up possibilities for business partnerships that smaller projects don’t have as much access to. Some projects of this kind attribute such flexibility to being Open Source; OS enables them to be used flexibly. With commercial partnerships, OS enables clients to build upon an open package and make it work for their needs. It is often simply faster for companies to pay the core maintainers to do their adjustments rather than figure it out themselves.

To suggest an explicit example, projects such as jupyter Notebooks and Wikipedia are ‘too big to fail’. In that an existence where these project may cease to be supported in the ways in which they are currently known could be viable (in that they could feasibly cease to be financially supported in the ways they are now) but the essential service would not ‘cease’ to exist without a rallying of OSS community effort in order to either maintain at a reduced capacity or to gracefully sunset and grow a new alternative.

Sustainability concerns affect both how projects choose to prioritize work and their likelihood of incorporating design practices.

One respondent said that their project prioritizes issues and features based on if it is “something that seems like it’s going to increase the sustainability of the software by bringing in funds that will actually let us keep working on it.” This speaks to a kind of desperation that funding forces onto these projects. Funding also makes certain activities, like design, seem “unimportant”: “I don’t feel like I’ve ever worked on anything that’s been large enough and well enough funded that [design] was a part that we thought was important.”

Over reliance on students as maintainers of OS projects can, however, present a sustainability challenge.

For obvious reasons, if students are key maintainers of a project housed within a university, that project is likely to lose a maintainer after a couple of years. Projects are therefore wary of overreliance on student work, but also noted that they sometimes source new contributors from academic institutions because students are eager to learn and apply their skills to real-world issues.