Open Source
Open by default
We build in public. Our code, our process, our mistakes — all out in the open. Here's why, and how you can be part of it.
Our philosophy
Open source isn't a business strategy for us. It's a belief about how good software gets made. When code is public, it gets better — more eyes find more bugs, more perspectives lead to better APIs, and more people benefit from the work.
Every tool we build starts as an open repo. We don't build in private and release later. The first commit is public. The messy early code is public. The discussions about what to name things are public. We think transparency about the process is as valuable as the final product.
We're inspired by the artisans of Exodus 31 — craftsmen given wisdom and skill to build something worthy. A workshop isn't a closed room. It's a place where people learn by watching, asking, and eventually building alongside you.
Our repos
A few things we've open-sourced.
flags.zig
A type-safe command-line argument parser for Zig. Inspired by Rust's clap and TigerBeetle's flags — zero runtime overhead, comptime parsing, subcommands via union(enum), and zero dependencies.
monimejs
Lightweight TypeScript SDK for the Monime payments API. Full type safety, retry logic with exponential backoff, idempotency keys, and 12 resource modules. Published on npm.
microblog
The Flask Mega-Tutorial by Miguel Grinberg, reimplemented with a modern stack — SvelteKit frontend, Go API with chi router, and SQLite with sqlx.
How to contribute
Pick a project
Browse our projects page or our GitHub org. Each repo has a README explaining what it does and how to set it up.
Start small
Fix a typo. Improve an error message. Add a test case. Small contributions are real contributions. They help you learn the codebase and they help us ship better software.
Open an issue first
For larger changes, open an issue before writing code. Describe what you want to change and why. This saves everyone time — we might already be working on it, or we might have context that changes the approach.
Submit a PR
Keep PRs focused. One change per PR. Write a clear description of what you changed and why. We review everything and try to respond within a few days.
Our standards
Clarity over cleverness
Code that's easy to read is more valuable than code that's impressive. If a reviewer has to puzzle over what your code does, simplify it.
Tests are not optional
If you add a feature, add a test. If you fix a bug, add a test that would have caught it. Tests are how we stay confident in the code.
Small PRs ship faster
A 50-line PR gets reviewed in a day. A 500-line PR sits for a week. Break large changes into smaller, shippable pieces.
Be kind
Code review is a conversation, not a judgment. We critique code, not people. Everyone here is trying to build something good.
Ready to contribute?
Browse our repos, find something interesting, and jump in. No formal application, no onboarding process. Just good code and good intentions.
Browse repos on GitHub