Fellowship for Technology and Society: Mozilla Foundation Fellows Program 2026 — $75K–$100K Stipends plus $25K Project Grants

If you care about technology that serves people — not corporations — this is one of those rare opportunities that actually pays you to think, build, and speak. The Mozilla Foundation Fellows Program 2026 will support up to 10 leaders with significant financial backing, coaching, global platforms, and a cohort of peers. Whether you are a technologist, researcher, artist, organizer, or policy advocate working on privacy, AI accountability, climate justice, creator rights, community data, or open infrastructure, this fellowship is designed to help you move from great ideas to visible, repeatable work.

This is not a fellowship that asks you to shrink your ambitions. It expects you to produce something others can use: tools, curricula, benchmarks, policy frameworks, or creative work that models a different way technology can exist in public life. And it pays for it — either a $75,000 stipend plus $25,000 for the project (Track I), or a $100,000 stipend plus $25,000 project budget (Track II). That kind of breathing room matters. You can hire help, run pilots, travel for community engagement, and document your work so it actually spreads.

The program also has constraints you must reckon with. Payments arrive from a US nonprofit (so you need to be able to receive ACH or wire transfers from the US), and selected fellows agree to release code and non-confidential content under open licenses set with Mozilla. If your institution insists on owning IP, you’ll need to sort that out before you apply. Read on — this guide breaks down who should apply, how to craft an application that reviewers will respect, and practical next steps so you can submit before the January 30, 2026 deadline.

At a Glance

What This Opportunity Offers

Mozilla’s fellowship is a rare mix: meaningful money, public amplification, and community. Financially, the stipends are built to let you focus on single-minded work for roughly a year. The extra $25,000 project budget is deliberately flexible — use it for contractors, travel to communities, research stipends for participants, or specialized infrastructure. The larger Track II stipend is aimed at people who need a bigger living allowance to be truly independent; Track I is structured for embedded fellows who are already attached to a host organization and need support for a focused project.

Beyond cash, the fellowship gives you access to Mozilla’s platforms: festivals, education programs, and channels that reach technologists, policymakers, and civic groups. That publicity matters. If you want your toolkit, dataset, or curriculum to be used by others, having Mozilla amplify the launch is a multiplier. There’s also structured professional development: workshops, coaching, and cohort learning. That isn’t fluff — good coaching accelerates projects and helps you think through messy trade-offs like sustainability, governance, and ethical risks.

Finally, the value of the cohort can’t be overstated. Fellows become part of a network of people who share similar priorities and can become long-term collaborators, referees, or advisors. If your plan includes community-run data sets, locally governed AI, or a new protocol, you’ll want allies who’ve tried similar things and can help you avoid predictable pitfalls.

Who Should Apply

This fellowship is for practitioners who are already doing substantive work at the intersection of technology and society and who can show a clear plan for a 12-month project that others can adopt or adapt.

If you are a technologist building privacy tools for marginalized communities, a researcher auditing AI systems used by government services, an artist designing systems to help creators track and get paid for their work, or an organizer building community-owned data initiatives — you should consider applying. Mozilla explicitly prioritizes applicants from the Global Majority, and Track I Embedded Fellows are expected to be based in specific regions (Kenya, South Africa, Brazil, MENA, Mexico, UK, US, or EU). If you are attached to a host organization that will provide context and support, Track I may be appropriate. If you need full independence to pursue a highly personal or radical approach, Track II offers greater stipend flexibility.

Examples:

• A community researcher in Nairobi proposing an open auditing toolkit for local government procurement algorithms. Embedded in a civic tech host, you already have relationships with local councils and a pilot contract.
• An artist-technologist in São Paulo designing a consent architecture and licensing model that helps street musicians retain economic rights for sampled work.
• An independent technologist in the UK building small language models that can be owned and governed by indigenous communities.

You’re a fit if you can demonstrate two things clearly: you can execute the work within 12 months, and the outcome will be useful to others (reusable code, documented methodology, datasets with governance, policy playbooks, or educational materials).

Insider Tips for a Winning Application

This section is the practical part. Read it, then actually do these things.

1. Start with the problem, not the technology. Reviewers want to see that you’re solving a concrete problem for real people. Spend your first project paragraph describing a specific harm or gap (e.g., small newsrooms being flooded by disinformation during elections) and why current tools don’t help.

2. Be ruthlessly specific about deliverables. Replace vague verbs like “research” with exact outputs: “a working auditing script for evaluating model bias on named-entity recognition, three documented case studies, and an open-source reproducible notebook.” Tangible outputs make it easy for reviewers to assess feasibility.

3. Show community engagement early. If your project involves communities, include names, letters, or notes showing consent and collaboration. A short quote from a local partner explaining why this matters is more convincing than three paragraphs of mission statements.

4. Budget with logic. The $25K project budget is flexible, but justify every line. If you plan to pay community participants, state rates and number of participants. If you need a contractor for two months, give their role, rate, and why it’s essential.

5. Address IP and open licensing proactively. Because fellows keep IP but must release code and non-confidential materials under open licenses, explain how you’ll satisfy institutional policies (if you’re university-affiliated) and still retain open access: a signed host agreement or a pre-approved open license plan helps.

6. Make a clear timeline with milestones. Break the 12 months into quarters, and specify what success looks like at each milestone. Example: Month 1–3: community co-design and data collection; Month 4–6: prototype release and public testing; Month 7–9: iterate and produce documentation; Month 10–12: publish toolkit, host webinar series, measure adoption.

7. Prepare a short two-paragraph elevator pitch and a one-page project summary. Fear reviewers who skim. The first 200 words should make a reader nod and want more. Use plain language; assume reviewers are smart but may not share your specialty.

8. Use previous impact as credibility. You don’t need tons of publications, but show track record: “I led a pilot that reached 4 community groups, reducing access errors by 40%” is stronger than “I have experience in community research.”

9. Plan dissemination beyond Mozilla. Show you have a plan to make the work durable: documentation, training modules, simple governance templates, and a sustainability plan for maintenance or community stewardship.

10. Practice a short public talk. Fellows are asked to share knowledge. Being able to quickly describe your project in 5 minutes demonstrates leadership and influence.

Put bluntly: reviewers want to fund someone who will finish, share, and cause others to copy or build on the work. Make that obvious.

Application Timeline (work backward from January 30, 2026)

This fellowship requires nomination — start early.

• 8+ weeks before deadline (early December 2025): Decide which track fits (Embedded vs Independent). If you need a host organization, secure their confirmation now and ask for a short letter of support or a 1–2 paragraph statement of commitment.
• 6 weeks before deadline (mid-January 2026): Complete first draft of project narrative, timeline, and detailed budget. Circulate to 2–3 critical readers: one in your field, one outside it, and one practical reviewer (e.g., someone who has managed grants).
• 3 weeks before deadline (early January 2026): Finalize letters of support, confirm payment logistics (can you receive ACH/wire from the US?), and double-check legal ability to enter a grant with a US 501c3. Resolve any institutional hurdles.
• 1 week before deadline (January 23–29): Polish, proofread, and submit the nomination. Nominate early in the week to avoid last-minute submission system issues.
• Post-deadline: Expect selection decisions within a few months. If not selected, request feedback and iterate.

Submitting early is strategically superior. Systems fail. Lawyers take days to sign host agreements. Don’t leave this to the last minute.

Required Materials

Mozillas’ application wants a clear project narrative and supporting documents. Prepare these items well before you start filling forms.

• Project Narrative (3–5 pages recommended): Explain problem, goals, methods, timeline, risks, and how the project will be shared. Include measurable outcomes and success indicators.
• Detailed Budget and Justification: Show how you’ll use the $25K project fund and, separately, how the stipend will cover living costs. If you’re embedded, show host contributions (office space, access to networks).
• Letters of Support or Host Confirmation: For embedded fellows, a short letter from the host organization outlining responsibilities and expectations is essential. If you’re independent but working with partner communities, include letters showing willingness to participate.
• CV or Biosketch: Focus on relevant roles, prior projects, and leadership in technology and civic domains.
• Examples of Past Work: Links to code, reports, portfolios, or media that demonstrate your ability to complete similar projects.
• Payment and Legal Info: Be ready to confirm bank account and tax documentation, and that you can sign a US grant agreement.

Treat the budget narrative like storytelling: it should make clear how money translates to deliverables. If part of your project involves paying community members, show the math and ethical considerations for compensation.

What Makes an Application Stand Out

Reviewers evaluate across five areas: Fit, Project, Values, Impact, and Leadership. To score well in each:

• Fit: Choose the right track. If you’re embedded where regional nuance matters and you can show a host’s support, pick Track I. If independence and full-time focus matter more, choose Track II.
• Project: Deliverables must be concrete, feasible in 12 months, and replicable. Include technical feasibility (tools, datasets, technical partners) and a realistic staffing plan.
• Values: Mozilla’s language about technology “built with care, powered by people, and fueled by imagination” translates to demonstrable ethics: consent, privacy-by-design, inclusivity, and documented community governance plans.
• Impact: Give both qualitative and quantitative metrics. Don’t say “we will help communities.” Say “we will train 20 community researchers, publish two open datasets with governance metadata, and produce a toolkit that reduces false positive rates in X by Y% in pilot tests.”
• Leadership: Show how you will keep momentum after the fellowship — training partners who will maintain the project, published documentation, and plans to attract follow-on support.

An outstanding application links these five areas consistently. The narrative should feel cohesive: the person (you), the project, the community, and the outcomes should all fit together logically.

Common Mistakes to Avoid (and how to fix them)

1. Vague deliverables. Fix: Replace vague phrases (“research outcomes”) with a list of concrete artifacts and the format they’ll be published in.

2. Ignoring payment logistics. Fix: Confirm you can receive ACH/wires from the US before you apply. If your bank will not accept this, you’ll need a host or fiscal sponsor.

3. Skipping community consent. Fix: Get written confirmation from community partners that they agree to participate and describe their role. Ethical projects require consent and clarity about benefit sharing.

4. Overambitious timelines. Fix: Create realistic milestones and a fallback plan. If a method may fail, explain a backup path in the narrative.

5. Sidelining sustainability. Fix: Explain briefly how the project will be maintained or handed off after the fellowship, whether via community governance, host institution, or follow-up grants.

6. Not addressing open licensing. Fix: Provide a plan for licensing code, data, and content that aligns with your institution and Mozilla’s expectations.

Avoid these traps and you’ll improve your odds substantially.

Frequently Asked Questions

Q: Who can be nominated? A: Candidates from countries where Mozilla can legally make grants are eligible, with priority for applicants from the Global Majority. Nominations are typically submitted by peers or organizations; check the nomination form for specifics.

Q: Can organizations apply or only individuals? A: The program is structured for individuals (fellows), though many applicants are embedded within host organizations. If you’re embedded, include a host confirmation letter.

Q: What if my institution claims IP? A: Fellows retain IP but agree to release code and non-confidential materials under open licenses. If your institution insists on owning IP, resolve this conflict in writing prior to nomination or seek a host/fiscal sponsor that allows open licensing.

Q: Are international applicants paid? A: Yes, but fellows must be able to receive stipend disbursements via ACH or wire transfer originating in the United States. Confirm with your bank that this is possible.

Q: Is the fellowship remote? A: The fellowship supports both embedded and independent fellows. Track I requires specific regional locations for embedded fellows; Track II is broader. Expect cohort activities and some events that may be scheduled globally.

Q: What does “work in the open” mean here? A: It means regular public sharing of progress, open-source code releases, and documentation so others can replicate or build on your work. Mozilla will coordinate licensing with fellows.

Q: When will applicants be notified? A: Notification timelines vary. Plan on several weeks to a few months after the January 30, 2026 deadline. If not selected, ask for reviewer feedback.

Q: Can I reapply if not selected? A: Yes. Use reviewer feedback to strengthen a subsequent nomination.

Next Steps — How to Apply

Ready to move forward? Do these six things this week:

1. Decide your track (Embedded vs Independent) and confirm that you can receive ACH/wire payments from the US.
2. If embedded, secure a short host confirmation letter that states the host’s role and support.
3. Draft a concise two-paragraph elevator pitch and a one-page project summary that lists deliverables and milestones.
4. Build a simple budget showing how you’ll use the $25K project fund and, separately, justify your stipend needs.
5. Gather CVs, links to previous work, and any letters of support from partners or community collaborators.
6. Nominate using the official form early — do not wait for the last day.

Ready to apply? Visit the nomination page and full program details here: https://mozillafoundation.tfaforms.net/184

If you want help polishing your project summary or budget, say the word — I can help edit a 200‑word pitch or line-by-line budget justification so your application reads like it was written by someone who’s done this before.