Mozilla (the nonprofit behind Firefox) is rethinking the program that has trained a decade of public-interest technologists, and the rewrite is happening in the open. The fellowship itself, with its 200-plus alumni spread across AI accountability, disinformation research, and tech policy, is the visible part. The part that is more interesting, and more useful as a model, is the process: Mozilla is publishing its unfinished questions and asking outsiders to weigh in on the answers.
That last part is the bit I want to talk about. Public-interest tech (work that puts technology in service of people rather than the other way around) does not have many of the formal pipelines that private-sector software has. There is no fellowship ladder at most foundations. There is no structured scouting for the next generation of people who can both explain what a model is doing to a regulator and write the code that probes the model. Mozilla has been one of the few organizations that took that gap seriously, and the current rewrite of the program is an attempt to make the gap smaller for the next decade.
The questions Mozilla is asking in public
The post that landed in December 2024 lays out three open questions the team is wrestling with. They are worth reading in full because they are unusually honest about the limits of the current program.
- How deep should the technical skill go? The fellowship has historically mixed people with policy backgrounds, journalism backgrounds, and engineering backgrounds. The team is now asking whether every fellow should be able to read a model card (a short technical document explaining what a model is trained on and what it is intended to do) and not just write a critique of one. The shift, if they pull it off, would move the program from “people who can comment on tech” toward “people who can build the alternative.”
- How do you find the next cohort before they are famous? The current pipeline leans on the Mozilla Festival (an annual gathering in Amsterdam) and partner organizations to surface candidates. The team is asking whether that is wide enough. The honest version of the question is: are they missing people outside the usual public-interest-tech networks, and if so, what would the scouting system look like that catches them.
- What does support actually mean once a fellow is in? Mentorship, speaker training, career-stage matching, and the awkward “what happens after the fellowship year” question. The current program has been better at the first 12 months than at the next 60.
These are not the kind of questions a foundation typically publishes. They are the questions that get answered behind a closed door and announced as a fait accompli. Mozilla putting them in a public blog post is a deliberate choice, and a useful one.
Why doing this in the open is the actual product
The other thing the post is doing, underneath the questions, is modeling a process. Open source (software whose source code is published and editable by anyone) has spent thirty years arguing that the work gets better when more eyes are on it. Public-interest grantmaking has generally not adopted that posture. Foundations tend to treat their program design as proprietary, on the theory that the design is the value.
Mozilla is testing the opposite theory. The design is not the value. The cohort is the value. The way the cohort gets selected, the way the support system gets built, and the way the alumni network stays alive are all more important than the structural diagram of the fellowship. If the process of designing that system is open, then anyone who cares about the same problem can contribute: a researcher can flag a candidate the scouting team has not seen, a former fellow can suggest a support gap they hit at year three, a funder can avoid duplicating the program because they can see the roadmap.
There is a real cost to that posture. Some of the open questions will get bad answers from bad actors. Some of the suggestions will come from people who want the program to be something it should not be. The Mozilla team is taking that risk because the upside (a fellowship pipeline that is harder to ignore, harder to copy incorrectly, and harder to dismantle) is worth it.
What the rest of the field can learn from this
Most public-interest tech programs are smaller than Mozilla’s, and most do not have a global brand to lean on when they publish their working notes. That is the excuse they will reach for. It is also wrong. The lessons transfer.
- Publish the open questions, not the answers. The Mozilla post is interesting because the questions are unpolished. Reading it, you can see where the team’s thinking is incomplete, which is exactly what makes it useful to outsiders. A foundation that publishes only the polished version of its program design is publishing a brochure, not a roadmap.
- Lean on the alumni network, not the brand. The current fellowship cohort is roughly 200 people. The alumni network is the strongest signal of whether the program is working. Anyone designing a new program should ask the alumni of the older programs what the support gap looked like at year three, year five, and year ten. The answers will not be flattering, and they will be the most useful data the program has.
- Build the scouting system before the brand. The Mozilla Festival is a strong event, but it is also a filter. It catches people who can travel, who have institutional support to attend, and who already know the public-interest-tech vocabulary. The next cohort of leaders will not all be at the Festival. They will be in regional AI safety groups, in local journalism collectives, in mid-career pivots out of industry. The scouting system has to reach them where they are, not where the existing program can afford to go.
- Plan for the post-fellowship decade, not the fellowship year. A program that supports a fellow for 12 months and loses them at month 13 is not a pipeline, it is a residency. The cohort that comes out the other end needs the same level of structured support for at least the next five years, or the program is paying to seed the field once and then letting the harvest go wild. Mozilla’s open question about “what does support actually mean” is the right question to be asking first, because the answer determines whether the fellowship is a one-time gift or a permanent network.
- Admit the limits of the program before launch, not after. A foundation that publishes the open questions in the same post that announces the program design is doing two things at once: it is signaling to the field that the team is honest about what they do not know, and it is giving critics a shorter distance to travel when they find the gaps. The cost is a more fragile launch. The benefit is a program that is harder to dismantle, because the design is public and the field can defend it.
Trade-offs
Mozilla is taking a real risk with the open process. A draft post that names the program’s limits is also a draft post that critics can quote when the next cohort of fellows underperforms. The team has to be willing to be wrong in public, in a way that most grantmakers are not. The upside is that the program gets smarter faster; the downside is that every misstep is on the record.
The other trade-off is the “deepen the technical skill” question. Pushing every fellow toward being able to read a model card raises the bar, and it will probably shrink the candidate pool. Some of the strongest fellows in the current program are people whose strength is translation, not engineering. A program that requires both will lose some of those translators, and it will not be obvious for a few years whether that loss is worth the gain.
The rewrite will also take longer than a closed-door rewrite. The current post is from December 2024, and the team is still iterating. A foundation that is betting on a quick turnaround is going to be frustrated. A foundation that is betting on a decade of program design will be fine.
Bottom line
If you work in public-interest tech and you have not read the Mozilla post yet, read it. The questions are useful on their own. The way the questions are asked, in public, with an explicit invitation to reply, is more useful still. The fellowships are the visible product. The working notes are the part that scales.
I want to see more foundations do this. The first one to do it well will set the bar, and the rest of the field will copy the shape, not the substance, which is the usual failure mode. The substance is the willingness to publish the incomplete version. The bar is whether the field reads it and answers.