open-source-jobs: a job board built from a CSV of repositories

The problem: matching maintainers to companies that pay for open source work

Most job boards index roles by title and location. This project indexes them by repository. Each row in the list pairs a company with a GitHub repository it maintains and a job page where that company hires. The README states the audience plainly: "For those who want to work on open source and get paid." That is a narrower claim than a general developer job board makes, and it changes what a useful entry looks like. A listing is only meaningful if the company actually employs people to work on the named repository, not merely sponsors it or uses it.

The unit of curation is the pair, not the company. Anchore appears twice in the README table, once for anchore/grype and once for anchore/syft, with the same careers link. Canonical appears for canonical/lxd and canonical/multipass. That duplication is deliberate: someone searching for work on a container image scanner and someone searching for work on a VM manager are looking at different codebases even when the payroll is the same. For an engineer deciding where to send a patch that might turn into a paycheque, the repository is the more useful key.

How the list is generated: repos.csv, scripts, and a static Next.js app

The repository layout is the clearest description of the architecture. At the top level there is repos.csv, a scripts/ directory, a data/ directory, and a Next.js application under app/ with components/ and lib/. The README labels the table itself as auto-generated and points readers to repos.csv for edits and to a GitHub issue template for adding a repository. So the CSV is the database, and the README table is a rendering of it.

package.json names the pipeline explicitly. There is update-repos, which runs scripts/update-repos.ts through npx tsx, and update-readme, which runs scripts/update-readme.js. Two further scripts, update-from-diff and fetch-updates, run scripts/generate-update-from-diff.js and scripts/fetch-releases.js. The presence of fetch-releases.js and a data/ directory suggests release information is pulled and cached locally rather than fetched per page view, though the README does not describe what fetch-releases.js writes. That is a gap worth knowing about before you fork: the scripts are the real specification and the README is not.

The site itself is a conventional Next.js app. Dependencies include next 16.2.11, react 19.2.0, papaparse for CSV parsing, Radix UI's select component, lucide-react for icons, and Tailwind CSS 4 through @tailwindcss/postcss. papaparse is the tell: the browser or the server parses repos.csv directly rather than querying a database. There is no ORM, no database driver, and no auth library in the dependency list. For a list of this size that is a reasonable trade, and it means deployment is a static or server-rendered Next.js build with no state to migrate.

Installing open-source-jobs and running it locally

The repository uses pnpm: pnpm-lock.yaml is present at the top level. The README does not include install instructions, so the steps below follow package.json and the standard Next.js script names it defines. Install dependencies first.

pnpm install

Then start the development server with the dev script, which maps to next dev.

pnpm dev

Next.js prints the local URL in the terminal, typically http://localhost:3000, and the board renders from repos.csv. To produce a production build, use the build script (next build) followed by start (next start).

pnpm build
pnpm start

The first real task most people will want is adding a repository. Edit repos.csv directly, or regenerate the README table from it with the update-readme script.

pnpm run update-readme

If you change the CSV and the README table disagrees with it, the README is stale, not the CSV. Note that the update-repos script calls npx tsx, so it does not depend on a globally installed TypeScript runner. Whether fetch-updates needs a GitHub token is not stated in the README or package.json; check scripts/fetch-releases.js before running it in CI.

What the data model cannot express

The schema is a company, a repository and a job page. There is no field for salary, seniority, location or remote status in the README table, and the list offers no filtering beyond whatever the site builds on top of those three columns. If you are searching for remote-only roles or for a salary band, this project will not answer that question; it will only tell you which repositories have a hiring page attached.

The freshness problem is structural. A job page URL is a link out, and links rot. The README table is generated from repos.csv, so a company that stops hiring but keeps its repository will stay in the list until someone edits the CSV. Nothing in the repository describes a check that the target page still lists an open role. The release cadence is also thin: the only release listed is v2.0.0 from 2025-11-26, and the last push to the repository was on 2026-09-11. Commits continue, but there is no evidence of a scheduled data refresh, so treat any individual row as a lead to verify rather than a live posting.

A second limitation is coverage bias. The list is curated by pull request. Projects whose companies do not know about the list, or do not want to be listed, are absent. The result skews toward companies with a developer-relations habit and a public careers page. That is not a defect in the code, but it is a defect in any conclusion you draw from the list about which open source projects pay contributors.

Compared with a general job board or a careers-page aggregator

A general developer job board indexes postings and lets employers pay to appear. This project inverts that: the index is the repository, and the job page is a link the maintainer of repos.csv chose to add. The practical difference is what you can search on. On a general board you filter by stack and location and get a list of employers. Here you start from a codebase you already know and find out whether its company hires. If you have been contributing to a project and want to know whether that contribution could become a job, that is the query this tool is built for, and a general board cannot answer it because it does not know about repository-to-employer relationships.

The cost of that inversion is scale and freshness. A general board refreshes from employer feeds and handles thousands of postings with structured fields. This one is a CSV maintained by hand plus whatever scripts regenerate it. If you need volume, alerts, or salary data, a general board is the better tool, and this project is the wrong one. The two are complements rather than substitutes: use this to shortlist repositories, then use the company's own careers page, which every row links to, to see actual openings.

Maintenance cost, licensing and what to check before forking

Running your own copy is cheap in infrastructure terms. There is no database to operate, no queue, and no background worker in the dependency list. The cost is in data maintenance: someone has to keep repos.csv accurate, and someone has to run the update scripts when the README table drifts. The scripts are JavaScript and TypeScript run through node and npx tsx, so there is no compilation step to manage beyond the Next.js build.

Licensing is the open question. The repository does not state a licence, and package.json marks the package as private with version 0.1.0, which is a website manifest rather than a published library. Without a stated licence you should not assume you can redistribute the code or the compiled list; check the repository for a LICENSE file before you build anything on top of it. This is a factual gap, not legal advice.

Upgrade risk is concentrated in the framework. The app pins next 16.2.11 and react 19.2.0, both recent majors, and Tailwind CSS 4 through a PostCSS plugin. A fork that sits for a year will face a framework upgrade before it faces a data problem. If you only want the list and not the site, repos.csv is a plain file you can consume without touching any of the code.

Editorial conclusion

Adopt it if you want a self-hosted board whose source of truth is a CSV you can edit, or if you are looking for employers that pay maintainers. Do not adopt it if you need application tracking, resume parsing, per-job salary data or an API for postings: the repository shows no such features. Before deploying, verify the licence, since none is stated in the repository, and check whether the scripts under scripts/ need a GitHub token to refresh repos.csv.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. timqian/open-source-jobs on GitHub