2026-07-17 –, Thomas Swain Room
Most scientific python maintainers build for users who will pip install the code. In civic tech, your community members are policy researchers, journalists, or NGO advocates who may never touch a Python environment. This cross-disciplinary context changes maintainership: traditional open source practices serve double duty as engineering and social infrastructure. I'll share lessons learned in maintaining the CIB Mango Tree, a civic tech Python toolkit for detecting inauthentic behavior in social media. I’ll show how in civic tech context familiar practices, like release cycles and continuous integration, can be repurposed to surface the otherwise invisible developer work to the broader community.
I'll start by briefly introducing the Civic Tech DC, a non-partisan, non-profit community of volunteer technologists, policy thinkers, researchers, designers, and community leaders passionate about using open-source technology for public good in the Washington, DC area. I'll point out the unique aspect of community design centered around the biweekly in-person project nights.
The double duty of open source maintainership in civic tech
Drawing on my experience as a maintainer of the CIB Mango Tree project, I'll discuss three examples of familiar open source practices. I’ll highlight how in the civic tech context each of these serve a social function in addition to the engineering purpose.
Release schedule as community planning. A regular and frequent release cycle primarily streamlines code distribution for the users. But there is a community angle to it as well: it boosts the visibility of ongoing volunteers who see their contributions ship when they can't commit long-term. Similarly, versioning code streamlines conversations about project development across diverse team members: saying v0.10.0 becomes as much a reference to code version by maintainers as well as a community signal by project managers to coordinate around for future plans.
Continuous integration as progress visibility. Among developers, continuous integration (CI) primarily ensures ongoing code integrity. In our project, CI also helps us with external progress visibility to the broader community beyond maintainers alone. We use CI to build executable previews of the development version. Our project and product managers can thus try out new features right as maintainers put them into the development branch.
Dependency selection as onboarding policy. Choosing right-sized dependencies is primarily about balancing code complexity and performance, but equally about right-sizing the onboarding ramps for volunteer contributors. Choosing a dashboard framework that does not offer production-grade capabilities but comes with a simpler mental model to navigate makes it easier for new volunteers to get up to speed and contribute. When volunteer bandwidth is fleeting and turnover rate high, this becomes a non-negligible decision factor.
Learning from the design constraints of volunteer civic tech
In civic tech, code and technical choices serve the broader community from the start. The civic tech lens forces a much more explicit and continuous emphasis on the community needs than I anticipated coming from the scientific Python background. This led to realization that collaborative open source practices we all know need not be siphoned away as invisible labor and can form a stronger bridge between the work of the developer and the broader community.
Kristijan Armeni is a research scientist with doctoral and postdoctoral training in computational neuroscience, investigating language processing in the human brain (EEG/MEG) and in artificial cognitive systems (language models). He is an advocate of open science and maintains an interest in public interest technology and civic tech. He currently helps building the CIB Mango Tree project, an interactive open source tool for analyses of social media datasets.