)
As the Chair of the OpenStack Technical Committee, I have a unique vantage point on the lifecycle of one of the most impactful open-source projects in history. OpenStack is now fifteen years old. This is immense in the software world; and over these years, as any successful software has done, the project has reinvented itself many times over. OpenStack has distinguished itself as the ubiquitous open-source cloud operating platform. It’s the only credible alternative to proprietary “black box” hypervisors and the inherent geopolitical risks in hyperscale clouds.
Yet, underneath the technical maturity, the community that builds OpenStack has been beset with a familiar phenomenon that haunts many established ecosystems: the silent attrition. My proposal in combatting this is rooted in the sociotechnical mechanics of how we value community work. I found a critical lens through the findings of an academic paper: “Invisible Labor in Open Source Software Ecosystems“ (Meluso et al., 2024). The main argument here is that as projects mature, the labor that’s involved in sustaining them becomes largely “invisible”, meaning that there’s a widening wedge between the value provided by community members and the recognition received.
The value proposition of OpenStack has undergone many shifts. A decade ago, the community was designing an open source alternative to AWS. Today, it shines as a strategic deterrence against something that I call “Technology Colonialism”. The moves in the market following the acquisition of VMWare by Broadcom serve as a visceral warning. When a foundational technology layer is controlled by a single commercial entity that could pursue short term profits, IT industries half the world over become subject to predatory pricing and forced migrations. This is a dangerous form of vendor lock-in, one that stifles innovation and erodes both revenue and independence. OpenStack has become the primary exit strategy for those who refuse to have their critical infrastructure held hostage.
The stakes are even higher at the sovereign level. Consider a nation’s IT relying on a hyperscaler originating in another country. If a government decides to enforce sanctions, unilateral tariffs or merely exercises its subpoena power under its own laws, it can effectively take control of private data and services of another country’s citizens. This is a dangerous imbalance of power where smaller sovereigns lose control over their own future. For OpenStack to serve as the foundation of digital sovereignty, the project’s governance must evolve to make “invisible labor” visible.
OpenStack is owned by no single commercial entity. It is governed by an international community across physical and geographical borders. OpenStack allows countries and corporations to control their own IT destiny without the threat of external political schisms. It is the “Linux of the Cloud” – a neutral, high-performance ground where collaboration occurs without the looming shadow of a monopoly, or despite it. However, sovereignty isn’t built with a feature we ship once. It’s continuously made possible by the people that maintain this software by keeping the CI gates passing, patching security vulnerabilities, writing helpful and accurate documentation for an operator in Jakarta or Johannesburg to deploy their clouds. As these people burn out, the anti-monopoly architecture may not collapse visibly, but would decay silently. So what we’re building is meaningful and has high stakes, and its sustenance is a derivative of the health of our contributor base.
A lot of the work in our community is “invisible”. This includes upkeep of documentation, bug triaging, community moderation, CI/CD maintenance, reviewing code, participating in design discussions, hosting developer or user group meetups, organizing meetings and the mentoring of new contributors.
Meluso et al. developed a model called Attraction-Selection-Attrition (ASA). The attraction (bringing contributors into the community) is a function of the impact of the software, the problems it solves and the Technical Vision adopted by the community. Selection (converting contributors into maintainers) is a challenging task that’s found a footing through our pillar of Open Community. In my view, we’re challenged by Attrition. As the paper posits, when a project matures, the “glamor” of building new features is replaced by the “penumbra” of maintenance. This continuous task is the most undersung one. We prominently recognize code contributors to each release and we use dashboards such as LFX Insights, Stackalytics and (formerly) Bitergia to gather code contribution statistics. Code contributors are the easiest to identify as “Active Contributors” that also qualify to participate in OpenStack election processes to govern the project. While we prioritize “visible labor”, we inadvertently alienate many people who keep the lights on. This is the source of our silent attrition. When a maintainer spends months troubleshooting issues or grooming bugs for a project team, and that work is not “seen” by the community’s metrics, that maintainer is significantly more likely to stop doing the important work, or worse, leave the project.
I want to reinforce the fact that much of this maintenance work is funded by corporate sponsors. Red Hat, StackHPC, Canonical, Nvidia and others employ engineers whose primary job is keeping OpenStack running. That investment is real and it matters. However, even within these companies, maintenance work often fails to demonstrate impact compared to adding new features. The community’s metrics and corporate incentive structures feed off each other. When the community doesn’t recognize maintenance as a first-class contribution, it’s harder for a contributor to justify that work in a performance review — and good luck getting a manager to defend headcount for it. Breaking this cycle has to be our priority.
As the Technical Committee, we cannot simply hope for better retention; we must engineer it. We need to adopt a culture where “all contributions are equal”. We’ll need to shift our mindsets regarding recognition.
1) Today, our governance tooling primarily identifies “Active Contributors” through code commits. We will need to emphasize that Active Contributors needn’t commit to repositories
2) Track contributors and reviewers of documentation that allow users to actually deploy and use our software.
3) Recognize mentors who guide new contributors.
4) Value the labor of those who manage our bug trackers and mailing lists, preventing the “tragedy of the commons.”
The Technical Committee has created a concept called “Extra” Active Contributors. This governs our current process for recognizing non-code contributors. It requires a centralized proposal through OpenStack’s “governance” repository. In the last five years, we’ve seen six Extra AC proposals across ten release cycles. Five of them were from the same SIG. Most project teams have never used the process at all. I submitted the first Extra AC proposals for TC-governed repositories this year, recognizing election officials and documentation contributors. It shouldn’t have taken this long. The friction is too high for something that should be natural. We need to move this submission process closer to where project activity actually happens. Let the project teams themselves acknowledge people doing the work; make it as simple as thanking someone for a review. Then aggregate it and roll up the distributed recognition into release announcements, community dashboards, and Summit spotlights in the same way we aggregate release notes from hundreds of deliverables into a single release.
When celebrating contributions, reward “Maintenance and Sustainability Labor.” This means that triaging a high-priority bug, maintaining the CI/CD gate, or performing a security audit must be given equal, or in some cases, greater weight than adding a new API endpoint. The “Invisible Laborers” must have a significant voice in our elections. By making this labor visible through data, we provide contributors with the evidence they need to justify their work to their employers.
As Chair, I’ve been pushing the Technical Committee to prioritize refactoring in line with feature velocity. The community-wide deprecation and removal of eventlet is touching nearly every project in the ecosystem; it is unglamorous, thankless work, and it is essential. The SQLAlchemy 2.0 adoption, the migration to secure RBAC defaults, the shift from oslo.rootwrap to oslo.privsep and many more may not be line items on a keynote slide, but each one makes OpenStack more sustainable for the next decade. Celebrate the simplification of complex subsystems and the deletion of code. This shifts the prestige from “What did you build?” to “How much more sustainable did you make us?”
While we do this, together with the OpenInfra Foundation, the TC needs to make a concerted effort to connect the most compelling sovereign cloud use cases with our community’s maintainers. Today, a contributor fixing a bug in Neutron or Manila may have no idea that their patch is what keeps a European healthcare system running on infrastructure that complies with GDPR, or that an African telecommunications provider depends on their CI work to serve millions of subscribers without ceding control to a hyperscaler. That disconnect is a problem we can solve. The Foundation collects deployment stories and case studies through user surveys and working groups; those stories need to flow back upstream to the project teams. We had great feedback when operators attended the Project Teams Gathering. We should bring that back and make sure operators know the invitation is standing. The TC and the Foundation should collaborate on a “who runs your code” page alongside governance docs — the Foundation already has the data. When a contributor who spent three months on a painful upgrade path learns that their work is what allowed a sovereign nation to keep its cloud independent, their labor ceases to be “invisible”. The contributor remains motivated and the employer realizes value out of their investment in the mission.
OpenStack is more than a collection of Python scripts and REST APIs; it is an insurance policy against the enclosure of the digital world. An insurance policy is only as good as the people who keep it going. By acknowledging the “invisible labor” that sustains us and adjusting our governance to reward it, we ensure that OpenStack remains the ubiquitous foundation of the open cloud for the next fifteen years.
Allison Price
Helena Spease
Kristin Barrientos
