opensource-br: a curated catalogue of Brazilian open source projects

One markdown table is the entire product

opensource-br is a space for publicising Brazilian open source projects, and that description is taken literally. The repository contains no code, no build system and no library to install.

What it contains is a table in the readme with three columns: the project name linking to its GitHub repository, the language it is written in, and a third column for other links. In practice that third column holds a documentation site, a project website, or in one case a Google Play listing, and it is left empty for most rows.

The format is the contribution mechanism as well as the display mechanism. Adding a project means adding a row, and the visible list of topics attached to the repository includes backend-br, brasil, community, contribution, hacktoberfest, open-source and public, which places it squarely in the Brazilian developer community ecosystem and in the seasonal contribution campaigns that run around them.

The result is a curated list in the oldest and simplest sense. There is no search, no filtering, no tagging beyond language, and no automation that assembles the table from elsewhere. A reader scrolls, and a maintainer edits a file. For a catalogue of this size, that is a defensible design, and the absence of a front end is also what keeps the repository auditable at a glance.

The language column shows what the community writes in

Counting the languages listed in the table gives a small but readable picture of the Brazilian open source scene as this project sees it.

Python leads clearly, with thirteen entries, including Serenata de Amor, Brazilian Utils, PyNubank, PyPicPay, PyFlunt, fklearn, Dateutil, Speakerfight, RastreioBot, SafeChat Slack Bot, the Vagas pra mim job search project, and the Brazilian municipalities data set.

PHP is the second language by volume with seven entries, including Corcel, i-Educar, Tainacan, Validation, Tiny Blocks, PHP4Noobs and Pancake. Then come Java with three, and C#, Rust and Kotlin with two each, plus single entries in C, Go and Elixir.

Two things stand out in that distribution. The first is that the list is not limited to web backends in one language. A C hardware information tool, a Go weather API, an Elixir language runtime and two Rust projects sit alongside the PHP and Python majority, which tells you the catalogue is not filtered by stack.

The second is that several entries carry a documentation link in the third column, which means the maintainers record not just that a repository exists but that it is documented somewhere. Validation links to its Read the Docs site, Elixir to the language documentation, and two projects link to a documentation site under the same guilherme.stracini.com.br domain, which points to a per author documentation hosting arrangement.

Three projects in the list are the kind of thing a directory cannot rank

Some entries in the table are large, established and widely used outside Brazil, and their presence tells you something about how the catalogue is curated.

Elixir appears with a link to the language documentation, and Dateutil is listed with no additional links, which means the list includes projects whose primary audience is global rather than Brazilian. The Validation entry carries its Read the Docs link, and i-Educar appears with no extra links either.

That inclusion policy matters for a directory. If the rule were projects built by Brazilian developers, then a language runtime and a date utility would sit awkwardly. If the rule were projects that Brazilian developers use, they sit comfortably. The readme does not state a criterion, and that absence is a real limitation of the catalogue: a reader cannot tell from the table whether a project was selected because of its origin, its audience, or the submitter's interest.

For the same reason the list has no ordering that a reader can learn. The table appears in no obvious language order, no alphabetical order by project name, and no popularity ranking, and the readme gives no ordering rule. A newcomer browsing the list will find popular PHP frameworks next to a Rust project and a Python data set with no signal about where to start.

That is the honest trade-off of a hand-maintained table. It is easy to read and easy to edit, and it is not queryable.

A link checker and a code of conduct guard a list of links

The repository carries more infrastructure than the readme content suggests, and the pieces are aimed at keeping the catalogue trustworthy.

There is a .lycheeignore file at the root. Lychee is a link checker, and the ignore file is where broken external links are excluded from the check. That is the single most useful piece of infrastructure for a list like this, because the third column is full of documentation and site URLs, and documentation sites rot. A link checker in continuous integration turns that column from a claim into something maintained.

The .github/ directory holds the workflow configuration and the issue and pull request templates, which is what you would expect for a repository whose entire workflow is a pull request that adds one table row.

There is also a CODE_OF_CONDUCT.md at the root. For a community catalogue that anyone can propose entries to, a code of conduct is what sets the tone of the review and discussion, and its presence alongside a contribution guide is a sign that the project takes the community side of its role as seriously as the listing side.

The licence is MIT, with the LICENSE file at the root, so the list of links can be copied and reused freely. Combined with the copyleft-free licence, that makes the table easy to fork, and forking is the more likely use for anyone who wants the list in a different form.

Contributions are pull requests against a single file

The contribution path is the one the repository was designed for, and the topic list names contribution as a first class concern.

CONTRIBUTING.md sits at the root and defines what a proposer should do, and the .github/ directory holds the templates that go with it. Since the deliverable is one markdown table, the workflow is correspondingly light: open a pull request that adds a row, keep the three column format, and let the link checker run.

The maintainers face a real editorial problem that the repository does not spell out. Every proposal asks for a row, and a table can only stay useful if entries are relevant, real and still alive. The language column and the extra links column are effectively the acceptance criteria in practice, because a submission without a resolvable repository link, or without a language, does not fit the format. Beyond that, the readme gives no rule about duplicates, no rule about whether commercial or company projects are welcome, and no rule about removing entries for projects that go quiet.

That last point is the one that matters most for a list with links in it. Projects die, domains expire, and nothing in the readme describes who checks whether the entries still work or how a dead entry gets removed. The link checker is the only mechanism visible in the repository that would catch that, and it can catch broken URLs but cannot tell you that a project is still maintained.

The repository is not archived, the default branch is master, and the last push was on 2026-10-16. There are no GitHub releases, which is expected for a repository whose content is a file rather than a package.

Editorial conclusion

opensource-br suits a Brazilian developer looking for a maintained, community-curated list of open source projects to explore, contribute to or use, and it suits a maintainer who wants to add a project rather than build something. It does not suit anyone looking for a tool, a package or a searchable index, because the catalogue is a single markdown table with no filter, no search and no metadata beyond name, language and links. Before adding a project, read CONTRIBUTING.md for what the maintainers expect, keep the entry in the existing table format, and expect a link checker run to catch a dead documentation URL.

Frequently asked questions

Official sources

1. backend-br/opensource-br on GitHub
2. Issues
3. License: MIT
4. README