The foundations of software: open source libraries and their maintainers

Open source libraries are repositories of code that developers can use and, depending on the license, contribute to, modify, and redistribute. Open source libraries are usually developed on a platform like GitHub, and distributed using package registries like PyPI for Python and npm for JavaScript. These repositories contain pre-written, re-usable code that developers use to add elements or features within their software projects. Open source libraries are maintained – updated, patched, improved, and so on – by people who are known, unsurprisingly, as ‘maintainers.’

That’s the simple definition, at least – but it fails to do justice to what goes on behind the scenes. The truth is that open source library maintainers are communities whose efforts support the overwhelming majority of modern software applications that we all rely on. For example, React is used widely to build user interfaces for web and mobile apps. React Native was used to build many popular apps which you may have used, including Facebook, Discord, and Airbnb. Libraries like React are sometimes supported by specific foundations, but there are hundreds, if not thousands, of libraries that rely on individual maintainers as well. 

You may have noticed that our YouTube channel recently began a new series, “Push to Talk | Meet the Maintainers.” The series highlights the work of prominent open source developers, like Andrew Gallant (the maintainer behind ripgrep), as well as giving a behind-the-scenes look into their journeys in the open source community. In this blog, we’re going to provide some context by peeling back the layers of open source libraries: how they work, why they’re important, and the maintainers that keep them going behind the scenes. 

How open source libraries work, and why they’re different from closed source libraries

Software doesn’t spring from the void. Someone – or teams of someones – have to build it in the first place, write the code, and make it run. But software is never really done. Bugs appear that need patching, new functionalities are imagined or requested, performance can always be improved. Moreover, code faces an unrelenting tide of new security threats, changes to external libraries and frameworks, updates to operating systems, browsers and hardware – all of which someone needs to stay on top of to avoid code becoming obsolete or unusable. 

In proprietary software frameworks, broadly speaking, teams of developers are employed to do this work (building and/or maintaining software libraries). However, the library’s source code – human-readable text written in a programming language which computers translate to binary, process, and execute – can only be accessed by authorized individuals, like company employees and specific partners. The company, as the software owner, retains exclusive rights, which usually stops unauthorized viewing, modification, and redistribution of code from the closed source library. That means that only the software owners can include code from the libraries in their projects, and therefore, if software built using the closed source libraries goes wrong, users can only get support through the proprietary vendor who owns the code. 

Open source development frameworks work differently. Open source libraries are usually built through community effort. Depending on the license and contributor agreement, anyone can propose a contribution to the code. More often than not, anyone can request a new feature or modification, or offer bug fixes. Maintainers lead the library, managing and moderating the community of contributors and users. Depending on the library, maintainers may look both at fine details – reviewing contributed code, deciding which bits of code end up in the library, ensuring documentation is clear and accurate – as well as the big-picture decisions, like steering the direction of the open source library as a whole. 

The maintainers of open source libraries are usually not employed to look after the framework. Instead, the work is voluntary. In some cases, individual maintainers may support their work with sponsorships or donations. In other cases, foundations – such as the Eclipse Foundation or Linux Foundation – take a stewardship approach to open source maintenance. In these cases, the foundation acts as a guardian of the project or library, rather than an owner in the traditional sense. The foundation ensures that the project remains available and supported, which may include establishing Technical Steering Committees (TSCs) to provide strategic direction and guide the codebase, acting as a mediator for conflicts within the community regarding project development, and ensuring the code is properly licensed. Most importantly, foundations can collect and organize sponsorship, helping to buy servers, increase bandwidth, and provide grants for the contributors of the project.

Open source libraries: the backbone of modern software

Open source software can be found everywhere. Our recent report, in collaboration with the Linux Foundation, revealed that globally, 55% of enterprises have adopted open source operating systems, whilst 49% have adopted open source cloud and container technologies, and 46% open source web and application development. Even if a project isn’t fully open source, it more likely than not contains some open source code, drawn from open source libraries: audits of codebases have found that up to 96% of projects contain open source code. This isn’t surprising: open access to the code means code can potentially be worked on by any number of contributors, as well as offering greater opportunities for thorough testing of the code for bugs.

Without maintainers to manage the libraries, many open source libraries would stagnate. Some open source libraries have huge numbers of contributors, whilst for others, the maintainer may be the only contributor. In the latter case, the library simply stops if the maintainer does: no more patches, no security updates, no bug fixes. 

If code needs to be continually updated and maintained to ensure that it doesn’t become obsolete, and the majority of software projects contain code from open source libraries, the effort that maintainers make to keep libraries up to date can’t be overstated.

Why, then, do maintainers do the work? 

What motivates maintainers?

As the 2023 Tidelift state of the open source maintainer report revealed, most are driven by making a positive impact on the world (70%) and the fact that the work is creative, challenging, and/or enjoyable (62%). Maintainers are motivated by belief in the software, in the community, and in the open source philosophy – broadly speaking. But what does that mean in practice?

The first episode of Canonical’s “Meet the Maintainers” series begins to reveal what these general motivations mean for the individual maintainers. The maintainer behind ripgrep, Andrew Gallant (or BurntSushi, as he’s also known) explains his earliest contributions to open source were inspired by his desire to host a discussion forum on his fan website for The Simpsons. Starting with self-described “hacking” on the proprietary forum software VBulletin, Gallant developed an interest in forum software in general. Like the motivations other maintainers report, Gallant enjoyed the challenge and creativity involved with hacking the PHP code to modify it so it will “do little things.” Two decades later, Gallant’s motivations are more community-centered: the satisfaction of creating something that is “free for everyone to use,” and “watching people use the stuff [he] build[s].” To find out more about the many libraries and projects Gallant has contributed to and worked on over the years, watch the video on our YouTube channel. 

Supporting maintainers: why it helps, and how you can do it

Financial incentives may not be the primary motivator for all maintainers; however, providing financial support helps to facilitate the work, ultimately producing stronger software, and faster code development. 

Fortunately, giving back to open source projects and libraries is simple and straightforward. Platforms like thanks.dev help you to donate to the repositories your software draws on, automatically distributing funds proportionally to how often the dependency is used. As thanks.dev suggest on their site, this makes it easier for larger organizations to “manage the logistics of supporting the thousands of projects they depend on”, including deeply nested packages and crucial indirect dependencies that may otherwise be overlooked.

Canonical began donating via thanks.dev in April of 2025. We committed to donating US$120,000 across 12 months at US$10,000 a month through the platform. You can find the full list of recipients so far at thanks.dev/r/canonical. 

Recognizing maintainers

Open source libraries are labors of love that depend on the hard work of communities and talented developers. That work often goes unseen, unpaid, and unrecognized, but – directly, or indirectly – we rely on it more than we may be aware of. 

As an open source company, Canonical is committed to spreading the open source philosophy to as many people and communities as we can. We drive our own projects, but also contribute staff, code, and funding to many more, which you can find out about on our webpage. “Meet the Maintainers” sheds light on the maintainers behind the libraries, recognizing them for their work, and, hopefully, inspiring more people to support open source, join communities, and contribute to open source libraries. 

Watch the series >