Meteor is starting a sponsorship program for the people who keep this project moving. Each quarter, we sponsor one trusted community contributor, as a way of recognizing work that has been happening for free for a long time.
Where the money comes from
Earlier this year we added a Sponsors section to the Meteor repository, and companies started backing the project: Galaxy Cloud, CodeRabbit and Input Logic were the first.
That raised a question we spent a while discussing internally: what should that money actually do?
We decided the most useful thing is to send it back into the community it came from. Sponsorship revenue funds the contributors who are already carrying parts of Meteor.
How it works
One contributor per quarter. We sponsor a single community contributor for a full quarter, then rotate. The rotation is deliberate: we want this to reach more of the people doing the work over time, not become a salary for one person.
Paid monthly through GitHub Sponsors for the duration of the quarter, from Meteor’s GitHub organization.
A focus area, agreed together. At the start of the quarter, the contributor and the Meteor TSC talk about what they want to focus on. It might be something they’re already deep in, or something new they want to pick up. What matters is that it’s their call, we’re not assigning work.
A public update at the end. We’ll publish a short summary each quarter covering what the sponsored contributor worked on and how the sponsorship budget was allocated, so the community can see where this goes.
What this is not
It’s not a job. There’s no contract for services, no hours, no deadlines, no deliverables, no employment or contractor relationship. The sponsored contributor decides whether, when, how, and what to contribute, exactly as before. We don’t direct or supervise their work. The focus we agree on at the start of the quarter is a shared intention, not an obligation and not a condition of the sponsorship.
That distinction matters to us. These are independent open source contributors, and sponsorship shouldn’t quietly turn their volunteer work into something they owe us.
It’s not a bounty program. We looked hard at bounties and decided against them. Paying per issue tends to reward whoever submits fastest rather than whoever contributes most, and in a world where code is cheap to generate, it mostly produces a review queue. We’ve tried issue-based payment before and that’s roughly what happened.
What we want to support is the kind of contribution that’s harder to measure and much harder to replace: sustained attention on one part of the project, reviewing other people’s work, thinking about the long-term shape of Meteor, helping newer contributors find their footing. That comes from people who are already part of this community, which is why we’re choosing contributors rather than opening a queue.
Our first sponsored contributor
The TSC took this decision seriously, and the criterion we settled on was quality of contribution, not volume. We weren’t counting merged PRs. We were looking for work that lines up with Meteor’s pillars, contributions that aren’t small fixes or incremental improvements, but the kind of work that moves the framework somewhere it wasn’t before.
@dupontbertrand has done exactly that. His pluggable DDP transport architecture and the performance benchmark tooling he built are the kind of work that makes other work possible — they touch the foundations rather than the surface. He’s also brought well-structured proposals for ESM, Bun, PWA and SSR/SSG, and he shows up in governance and roadmap discussions with genuinely useful pushback. Anyone who followed the governance discussion saw a lot of it.
We want to be honest that the choice was difficult. There are several people in this community whose work would have justified this just as well, and narrowing it to one was the hardest part of setting the program up. This is the first quarter, not the only one, we rotate precisely so that more of you get a turn.
We’ll share what Bertrand decides to focus on once he and the TSC have worked through it together.
How this connects to governance
We recently merged GOVERNANCE.md, which describes Core Maintainers and the idea of picking a front, a part of the project you look after.
This program is the other half of that. Governance says what stewardship looks like; sponsorship is us putting something behind it. We can’t pay everyone who contributes to Meteor, and that isn’t the goal. But when we can support someone, we’d rather do it visibly and let the community see who’s carrying what.
If you’d like to be considered
For this first quarter we picked someone directly. That’s deliberate: this is new for us, it involves money and public commitments, and we wanted to keep the scope small enough to learn from it before opening it up. Starting cautiously seemed better than starting big and getting it wrong in public.
For the next quarter we expect a better and more structured process, shaped by what this one teaches us, how the focus conversation actually goes, what the reporting should look like, and how selection can be made more open without turning into a popularity contest. We’ll share that before Q1 starts.
In the meantime, the practical answer is the honest one: get involved and stay involved. Review PRs. Pick a part of Meteor you care about. Join the discussions. We’re looking at the same things the governance document values: sustained engagement, ownership of an area, judgment, and follow-through.
Sponsor Us
If you’re a company running Meteor in production: sponsoring the project now has a direct, visible path to the people building it. Meteor’s GitHub Sponsors page is the place.
Thanks to Galaxy Cloud, CodeRabbit and Input Logic for making this possible, and to Bertrand for saying yes.
, and hopefully the first of many 
