Name
Ayushman Bhattacharya
GitHub Handle
@Circuit-Overtime
Tell us about yourself
I'm 20, from Kolkata, and I maintain pollinations.ai — an open-source generative AI platform out of Berlin that 500+ community apps depend on.
I didn't grow up writing code. I made my GitHub account in 2020 and for the first year I used it the way most people use Google Drive — somewhere to dump files. The 2021 lockdown changed that. I had nothing to do and started reading other people's source code, watching old Linus Torvalds talks at 2 AM, and slowly working up the nerve to open my first PR. It was a typo fix. I sat on it for two days before submitting because I was convinced someone would point out I didn't belong there.
Nobody did. It got merged. That was the first time the internet felt like a door instead of a wall.
What followed wasn't a clean career arc — it was a lot of small things. I built a Discord bot on the Pollinations API because I wanted to use it for my own projects. The community adopted it. I started fixing issues I hadn't filed, on a codebase I hadn't written. At some point the shift happened — from fixing my own problems to caring about someone else's — and that's the moment I think people mean when they say "open source clicks." A year later I was a maintainer.
These days, alongside Pollinations, I run Elixpo (a small ecosystem of AI tooling), organize GDG on Campus at JIS University, mentor for GirlScript Summer of Code 2025, and co-hosted Kolkata's Hacktoberfest meetup with 290+ people last year. None of it would have happened without that typo fix.
Project Name
pollinations.ai
Project Repo Link
https://github.com/pollinations/pollinations
Topic: Building the Contributor Pipeline at Pollinations.ai — How a Maintainer Actually Spends Their Day
The pitch: Most "open source maintainer" talks are about the project itself — the code, the architecture, the cool features. This one is about everything around the project. The quest board that pays contributors. The bot that triages PRs nobody has time to read. The app submission pipeline that takes a community project from "I built this!" to live in our README. The model registry that decides what we ship and what we don't. The CLI we publish to npm so humans and AI agents can both talk to our API.
At a project with 4.5k stars, 779 forks, and 500+ community apps in production, the contributor pipeline isn't a side project — it is the project. I want to walk through how we built it, what broke, and what I'd tell any maintainer trying to scale community contribution beyond "label some good-first-issues and hope."
What I plan to cover:
1. The Pollen-Quest system: paying contributors, in the open
We run a quest board where contributors claim issues and get paid in Pollen credits when their PR merges. The mechanics matter more than people think — payouts tied to GitHub user IDs (so a username change doesn't break payment), status/type lifecycles on quest issues, label-gating so non-maintainers can't approve their own work. I'll walk through one quest end-to-end: open → claim → review → merge → payout.
2. The project-manager bot: triage at the scale we actually get
More issues come in than humans can read. Our triage bot short-circuits drafts so they don't pollute the active board, auto-labels by type, and routes to the right maintainer. I'll show what it catches and — more honestly — what it misses.
3. App submissions: from a community issue to live in the Greenhouse
We have a full lifecycle automation for community apps — six workflows working together: submission validation, API tier checks, automatic README and Greenhouse listing, usage metrics, tier promotion for high-quality apps, and garbage collection for dead ones. I review submissions weekly. The bot does the boring half; I do the judgment calls. I'll show the full state machine and the quality bar we actually enforce.
4. Model curation: which models we ship and why
A weekly workflow checks our model registry — flagging upstream deprecations, surfacing new releases, verifying every free-tier model still works. Adding a model isn't a config change; it's a quality gate: cost per token, latency under load, hallucination rate on internal evals, tool-use behavior. I'll walk through how a model goes from "someone asked for it on Discord" to live on the unified API — and the ones we said no to.
5. AI-assisted PR review — what works, what doesn't
We built a PR review system on top of Claude Code Router, but routed through Pollinations itself for model selection. It reads diffs, flags surface issues, and leaves judgment calls for humans. I'll show one PR where it caught something I missed, and one where it confidently flagged something that was fine. Useful tool, not a replacement for a reviewer.
6. Maintaining the Polli CLI
The CLI is how humans and AI agents talk to our unified API. Maintaining a CLI inside the same monorepo as the API surface is a different beast from a standalone package — and making it agent-friendly (so tools like Claude Code and Cursor can drive it cleanly) is its own design problem. I'll show the tradeoffs.
7. Repo structure — why a monorepo for a platform
Pollinations ships seven-plus deployable surfaces from one repo. I'll talk about how we keep that navigable, how CI knows what to deploy, and why a monorepo beat splitting it up.
8. The small things that compound
The Discord post that goes out when a PR merges. The README "Recent Apps" table. The auto-assignment of PR authors. Individually invisible; collectively, they're why contributors come back.
Why this matters now:
Every "grow your open source community" post tells you to add a CONTRIBUTING.md and label good-first-issues. That's table stakes. The real work is building the system — paying contributors, gating approvals, curating models, reviewing submissions at scale, automating the boring parts so humans can do the interesting ones. We've built that for Pollinations, and most of it is reusable. If you maintain anything with a contributor base bigger than yourself, you'll recognize every problem on this list.
Stream Date
Dates
06-15-2026
Twitter URL
No response
LinkedIn URL
https://www.linkedin.com/in/elixpo/
Additional Information
I'd love to do a live demo during the stream — I can walk through:
- A real quest going from claim → PR → AI-assisted review → human review → merge → Pollen payout
- An app submission going through the full review → deploy → metrics pipeline
- The weekly model workflow surfacing a change and how we decide to ship or skip
- The Polli CLI being driven by an AI agent end-to-end
Happy to adapt for the conversation, demo-heavy walkthrough, or a mix. I'd also like to leave time at the end for questions from anyone trying to set up something similar on their own project.
Name
Ayushman Bhattacharya
GitHub Handle
@Circuit-Overtime
Tell us about yourself
I'm 20, from Kolkata, and I maintain pollinations.ai — an open-source generative AI platform out of Berlin that 500+ community apps depend on.
I didn't grow up writing code. I made my GitHub account in 2020 and for the first year I used it the way most people use Google Drive — somewhere to dump files. The 2021 lockdown changed that. I had nothing to do and started reading other people's source code, watching old Linus Torvalds talks at 2 AM, and slowly working up the nerve to open my first PR. It was a typo fix. I sat on it for two days before submitting because I was convinced someone would point out I didn't belong there.
Nobody did. It got merged. That was the first time the internet felt like a door instead of a wall.
What followed wasn't a clean career arc — it was a lot of small things. I built a Discord bot on the Pollinations API because I wanted to use it for my own projects. The community adopted it. I started fixing issues I hadn't filed, on a codebase I hadn't written. At some point the shift happened — from fixing my own problems to caring about someone else's — and that's the moment I think people mean when they say "open source clicks." A year later I was a maintainer.
These days, alongside Pollinations, I run Elixpo (a small ecosystem of AI tooling), organize GDG on Campus at JIS University, mentor for GirlScript Summer of Code 2025, and co-hosted Kolkata's Hacktoberfest meetup with 290+ people last year. None of it would have happened without that typo fix.
Project Name
pollinations.ai
Project Repo Link
https://github.com/pollinations/pollinations
Topic: Building the Contributor Pipeline at Pollinations.ai — How a Maintainer Actually Spends Their Day
The pitch: Most "open source maintainer" talks are about the project itself — the code, the architecture, the cool features. This one is about everything around the project. The quest board that pays contributors. The bot that triages PRs nobody has time to read. The app submission pipeline that takes a community project from "I built this!" to live in our README. The model registry that decides what we ship and what we don't. The CLI we publish to npm so humans and AI agents can both talk to our API.
At a project with 4.5k stars, 779 forks, and 500+ community apps in production, the contributor pipeline isn't a side project — it is the project. I want to walk through how we built it, what broke, and what I'd tell any maintainer trying to scale community contribution beyond "label some good-first-issues and hope."
What I plan to cover:
1. The Pollen-Quest system: paying contributors, in the open
We run a quest board where contributors claim issues and get paid in Pollen credits when their PR merges. The mechanics matter more than people think — payouts tied to GitHub user IDs (so a username change doesn't break payment), status/type lifecycles on quest issues, label-gating so non-maintainers can't approve their own work. I'll walk through one quest end-to-end: open → claim → review → merge → payout.
2. The project-manager bot: triage at the scale we actually get
More issues come in than humans can read. Our triage bot short-circuits drafts so they don't pollute the active board, auto-labels by type, and routes to the right maintainer. I'll show what it catches and — more honestly — what it misses.
3. App submissions: from a community issue to live in the Greenhouse
We have a full lifecycle automation for community apps — six workflows working together: submission validation, API tier checks, automatic README and Greenhouse listing, usage metrics, tier promotion for high-quality apps, and garbage collection for dead ones. I review submissions weekly. The bot does the boring half; I do the judgment calls. I'll show the full state machine and the quality bar we actually enforce.
4. Model curation: which models we ship and why
A weekly workflow checks our model registry — flagging upstream deprecations, surfacing new releases, verifying every free-tier model still works. Adding a model isn't a config change; it's a quality gate: cost per token, latency under load, hallucination rate on internal evals, tool-use behavior. I'll walk through how a model goes from "someone asked for it on Discord" to live on the unified API — and the ones we said no to.
5. AI-assisted PR review — what works, what doesn't
We built a PR review system on top of Claude Code Router, but routed through Pollinations itself for model selection. It reads diffs, flags surface issues, and leaves judgment calls for humans. I'll show one PR where it caught something I missed, and one where it confidently flagged something that was fine. Useful tool, not a replacement for a reviewer.
6. Maintaining the Polli CLI
The CLI is how humans and AI agents talk to our unified API. Maintaining a CLI inside the same monorepo as the API surface is a different beast from a standalone package — and making it agent-friendly (so tools like Claude Code and Cursor can drive it cleanly) is its own design problem. I'll show the tradeoffs.
7. Repo structure — why a monorepo for a platform
Pollinations ships seven-plus deployable surfaces from one repo. I'll talk about how we keep that navigable, how CI knows what to deploy, and why a monorepo beat splitting it up.
8. The small things that compound
The Discord post that goes out when a PR merges. The README "Recent Apps" table. The auto-assignment of PR authors. Individually invisible; collectively, they're why contributors come back.
Why this matters now:
Every "grow your open source community" post tells you to add a CONTRIBUTING.md and label good-first-issues. That's table stakes. The real work is building the system — paying contributors, gating approvals, curating models, reviewing submissions at scale, automating the boring parts so humans can do the interesting ones. We've built that for Pollinations, and most of it is reusable. If you maintain anything with a contributor base bigger than yourself, you'll recognize every problem on this list.
Stream Date
Dates
06-15-2026
Twitter URL
No response
LinkedIn URL
https://www.linkedin.com/in/elixpo/
Additional Information
I'd love to do a live demo during the stream — I can walk through:
Happy to adapt for the conversation, demo-heavy walkthrough, or a mix. I'd also like to leave time at the end for questions from anyone trying to set up something similar on their own project.