I’ve been a software engineer most of my life. I still remember the particular joy of it: the feeling of building a thing that didn’t exist the day before, the small victory of seeing it finally compile and run. For a long time, I thought that was the job: writing code.
Then I became an open-source maintainer, and I learned that maintenance is a different craft altogether. A maintainer’s day isn’t spent writing. It’s reading other people’s contributions with care. It’s reviewing the work of a stranger five time zones away and finding the kind way to say “not like this.” It’s carrying the weight of everything and everyone who depends on you, knowing that if you accept the wrong change, someone else pays for it. At Medic, that’s the hundreds of thousands of health workers who rely on the Community Health Toolkit to deliver care at the last mile — often on old phones and offline. When your code is part of how a family gets a home visit, “maintainer” is no longer a technical role. It’s a promise you keep, release after release, year after year.
Why we keep that promise in the open
People sometimes treat open source as a licensing detail or a pricing strategy. But for us at Medic, it’s the answer to a question every health system eventually asks: who owns the thing we depend on?
When software is open, a ministry of health can own what its community health program runs on: inspect it, adapt it, host it, sustain it. It means trust isn’t built on faith: anyone can verify the code, which is precisely what you want for a tool that helps decide which family gets care today. When software is open, it outlives any single vendor or grant and, for national infrastructure, longevity is non-negotiable. When software is open, the values of its community permeate every layer, from the code itself to how decisions are made, whose voices count, and what the tool refuses to do. More importantly, those values are transparent, and those decisions can be collectively reviewed rather than enforced by someone else, somewhere else.
That’s what open source unlocks: a community health system that truly belongs to the community it serves. It’s why the idea of “owners, not renters” landed with such weight when Mozilla CTO Raffi Krikorian shared it in our recent conversation for Ground Truth, a new series exploring the emerging technology reshaping our world. Open source is how that ownership becomes technically true, not just aspirationally so.
But here’s the part that gets forgotten: none of it works without maintainers. Open code that nobody tends to isn’t a commons —a resource a community owns and tends together—it’s like an abandoned plot of land. It can only bear fruit when someone, somewhere, continues to care: by reviewing contributions and upholding standards. Keeping that promise.
When AI started writing the code
Somewhere in the last two years, writing code — the thing I fell in love with, the craft that took me years to get better at — became something a machine does in minutes.
There was real wonder in that, and I won’t pretend otherwise. But every maintainer I know saw the other side just as fast. Our inboxes began filling with contributions that were clearly machine-written, sent by someone who never really understood the problem they were trying to solve. The pull request is enormous, the tests pass, it looks right — and yet no one can honestly say they’ve read it. The promise and the dread of this new era arrive together.
So the question I keep reflecting on is: what does it mean to be a maintainer in a world where code can be generated in minutes?
The part of the job AI can't do
Here’s where I’ve landed (at least for now): the part of the job that got automated was never the most important.
Generating code is now cheap. Judging it is not. Knowing whether a change belongs in a system a health ministry depends on — whether it respects the offline constraint, whether it will survive a CHW’s daily lived reality, whether it quietly breaks a workflow a health worker in another country relies on — none of that emerges from a model. It comes from fifteen years of context: deployments that failed and taught us why, forms redesigned because they didn’t match how a care visit actually unfolds, and trust built slowly with the people who use the tools and the governments that own them. A machine can write the code. It cannot know what the code is for.
Raffi put it in a way I keep returning to: you don’t have to read every line anymore — but you have to be able to. That is the maintainer’s new job description in one sentence. Ownership moves from writing the change to owning the spec, tests that prove it works, and the judgment about whether it should ship at all.
And here’s the turn I didn’t expect: AI doesn’t make open source less important. It actually makes it more crucial. The trouble with machine-written contributions isn’t that we cannot read them. It’s that reading them has become hard. While openness gives you the right to look inside the code, it doesn’t give you the capacity. And an open repository drowning in unreviewed, generated code is no more trustworthy than a closed one — it’s just transparent about its abandonment.
Openness, then, is necessary but not sufficient. What completes it is people with the context to judge, standing behind what they merge, caring about the people it reaches. When anyone can produce plausible code in minutes, the scarce thing becomes the judgment to verify it. Closed systems ask you to trust them. Open systems let you check. Maintained open systems mean someone actually has.
The same goes for the models themselves. Capability, as Raffi says, is a jagged frontier. Nowhere is that sharper than in speech recognition for local languages. Whether a model is “good enough” to understand a health worker’s voice note in Hausa or Sesotho is not a question someone else’s benchmark can answer. It’s one we’re just beginning to take on with partners across the CHT community — only the community that speaks the language and delivers the care can answer it — and only if the stack is open enough to test, tune, and own. Openness is what makes judgment at the edge possible at all.
What this asks of all of us
If maintainers are the keepers of what open source unlocks, then the era of generated code makes them more essential. Raffi made an argument in our conversation that I want to repeat here: the people maintaining the world’s critical open infrastructure need to be treated as essential workers and funded like it. In global health, we celebrate the impact made possible by open tools, but we’re quieter about resourcing the unglamorous, year-after-year work of keeping them trustworthy. The two are the same investment.
So when people ask how Medic is responding to AI, the honest answer is: the way maintainers do. We use the new tools to their strengths: drafting, generating, and accelerating. That’s the thinking behind CHT Agent, our multi-agent system that helps create CHT features, and the no-code tooling we’re building so non-technical people can directly shape the CHT. AI does the producing, and a person with deep context owns the judgment.
And we hold the line: every change still ships with a spec someone owns, tests that prove it works offline on the phones health workers actually carry, and a person accountable for deciding it belongs in the CHT. The judgment about what’s “good enough” is still made by the community keeping the promise, because that’s the one part no machine can generate.
Code can now be written in minutes. Trust still can’t. That’s what maintainers are for, and what open source has always really been about.