By Jay Faulkner, Open Source Software Developer
A big challenge for mature open source projects is technical debt, the implied future cost of potentially re-coding and debugging hastily created software.
Untangling some of the early-made solutions can be extremely time consuming, especially when it involves reworking foundational pieces of the system architecture.
Taking on the large, arduous task of paying back that technical debt is part of the unavoidable – and invisible – work of being a good open source citizen.
OpenStack is built on top of several foundational software libraries. The technologies that were used to start a new project in 2010 don’t always match up to what’s done in a 2025 world though.
Many of these projects are starting to show their age with the acceptance of new coding paradigms and practices that render the old approach inefficient, maintainable, or worse, inoperable.
Eventlet
Eventlet is one such aging library.
Eventlet uses green threads to permit cooperative multitasking completely in user space. This allows developers to patch built-in Python libraries to become non-blocking even if they were designed to block.
In 2006, when eventlet was first prototyped, it was a boon for Python developers, but now, with the introduction and mainlining of asyncio, it represents a relic of how things used to be done.
On top of the eventlet approach being dated when viewed through a modern Python lens, the library itself was unmaintained – having had no commits in months and minimal activity. This culminated in a crisis: eventlet didn’t support Python 3.12 but OpenStack could not trivially migrate from it.
Building Consensus
The first step to changing a foundational part of a large open source project is building consensus – getting people to agree it’s a problem and start working together for a fix.
So, I sent this email to the OpenStack mailing list making a technical and business case for why the removal of eventlet was a good idea. This was successful, as the community agreed we needed a new way forward, and community members were given the charge to shore up eventlet in the short term and find a path off in the longer term.
A year has passed since that email was sent and we faced that crisis and we’ve made tremendous progress.
First of all, the previous maintainer was gracious enough to grant maintainer privileges to more active developers – including the developers from the OpenStack community. That was the start of a flurry of activity to get eventlet maintenance back on track – since then, over 100 changes have been made. These changes include fixing test suites, adding CI, fixing various bugs and updating the code for new Python versions.
However, this was only the beginning of the effort to repay this technical debt in OpenStack – we are now faced with a larger issue: removing our dependency on eventlet altogether.
Beyond Eventlet
Mapping a path off of eventlet has not been easy. Developers had to introduce a new eventlet hub based on asyncio, allowing asyncio-native code to run alongside eventlet-native code.
Now, using the new hub and a more stable eventlet base, OpenStack developers have begun work on excising the use of eventlet from our code.
Currently, we’re still early in this process – OpenStack has a set of libraries used by most projects to do common tasks like logging, service management or RPC messaging – these libraries are in the process of making their use of eventlet optional. Once this is complete, work can begin in earnest to remove eventlet dependencies from the various OpenStack services.
We are likely still another 12 months or more away from a release which has no eventlet. The OpenStack community will continue the invisible work of paying down tech debt and modernizing our foundational pieces to help ensure OpenStack deployments stay secure and stable for years to come.
