Open Source
A handful of open-source utilities I maintain on the side. TypeScript, Rust, and Go: the small tools that came out of bigger projects and turned out to be useful elsewhere.
About the project.
A handful of open-source utilities I maintain alongside client work. Most of them started as small tools inside a bigger project, then turned out to be useful enough to publish on their own. The mix is TypeScript, Rust, and Go, depending on what the tool does. I treat them like any other engagement: real issues get answered, breaking changes get release notes, and nothing is published before it is good enough for me to use myself.
What changed.
packages maintained
GitHub stars across repos
What we walked into.
Several small utilities pulled out of bigger client projects — too useful to keep private, too small to make standalone products of.
What we did.
Publish them on GitHub under MIT, with documentation good enough that a stranger can use them, and an issue queue that gets real answers (not abandonment).
What it became.
Modest stars, real users, and the discipline that comes from publishing code under your name.
My role on this project.
Solo maintainer across all repos. No co-maintainers, no sponsoring company. I treat issues like client tickets: real reply within 48h, real release notes, no breaking changes without a major version bump.
Maintainer (all repos)
Issue triage, PR review, release management. Semantic versioning enforced; CHANGELOG written by hand, not generated.
Documentation owner
README + usage examples that work copy-paste. Every flag documented. Every breaking change called out in MIGRATION.md.
CI + release engineer
GitHub Actions for test + lint + release. Automated package publishing on tagged releases.
The numbers that matter.
- TS · Rust · GoStack mixOne language per tool, picked by what the tool needs — not by allegiance.
- <48hIssue first-response timeTreated like a client ticket. Real reply, not a thank-you bot.
- SemverVersioning disciplineNo breaking changes without a major bump. CHANGELOG written by hand.
- MITLicense across all reposPermissive; nothing locked behind dual-license tricks.
What was actually broken.
Working on long-running client projects produces small, reusable bits — a parser for a specific config format, a CLI for a tedious manual step, a Rust helper that does one cheap thing fast. Keeping them private is a tax on every future project that needs them; publishing them as products is overkill. The middle path is open source with maintainer discipline — answer the issues, ship the patches, do not pretend you are a startup.
The hard surface area.
- 01Distinguishing "useful utility worth publishing" from "internal hack that should stay internal."
- 02Maintaining release discipline alongside client work — open-source maintenance does not stop because a sprint is hot.
- 03Documentation that respects the reader's time — README that actually shows the tool in 30 seconds.
Engineering wins worth naming.
Saying no to scope creep
Users will request features that turn a 50-line utility into a 500-line framework. Honest "this is out of scope for this tool" responses keep the surface area small.
Cross-platform CI without paying CI bills
GitHub Actions free tier handles Linux + macOS + Windows for the test matrix. Releases packaged + signed in the same workflow.
The decisions behind each choice.
TypeScript / Rust / Go (per tool)
- TypeScript: small CLIs and Node-side tooling where ecosystem matters more than runtime cost.
- Rust: when the tool needs to be fast and to ship as a single static binary.
- Go: when the tool needs to be fast, ship as a single binary, AND remain readable to non-Rust engineers.
MIT over GPL
- Permissive license matches the spirit of "useful utility" — no obligations on downstream users.
- Easier corporate adoption — no legal review required for someone to pull in a 100-line dependency.
What the build taught us.
- Open source maintained without discipline is worse than no open source at all. If you cannot reply to issues, archive the repo and say so.
- Small tools age better than big frameworks. The one-thing-well utilities I published in 2023 still need zero maintenance; the bigger experiment needed three rewrites.