My GitHub has 52 public repositories. Some have stars. Most don’t. A few have been useful to people I’ll never meet. You put work out there without knowing where it lands.
How It Started
My first open source contribution was documentation. In 2020, I was deploying Jitsi Meet and couldn’t find a single guide covering the full production setup. I wrote one, then another, then put them on a Docusaurus site called Easy Jitsi.
155 stars was not the plan. I needed the documentation to exist. Other people needed it too. That alignment is the foundation of every useful open source project: someone scratches their own itch and finds others have the same one.
What I’ve Shipped
Easy Jitsi and Awesome Jitsi: documentation and resource curation for the Jitsi ecosystem. 200+ stars combined. Started as deployment notes, grew because the community needed better onboarding material.
REST API Starter: Go boilerplate with Chi, GORM, and Logrus. 20 stars. My starting point for every new Go backend. It encodes opinions formed over multiple production deployments.
DonatePal: full-stack donation management in Go. Built to explore server-side rendering without a JavaScript build step. Compiles to a single binary.
Webserv: an HTTP server in C. No frameworks, no libraries, just sockets and recv(). Built to understand what Nginx does at the socket level.
What I’ve Learned
Documentation is a feature. A project without documentation is a project for one person. Clear README files and deployment guides are what turn a private tool into something others can use and improve.
Small tools compound. My dotfiles, my Ghana PAYE tax calculator, my directory sizing utility. None are impressive alone. Each solved a real problem. Together they represent a habit of turning friction into tools.
Stars don’t matter, but feedback does. The projects I’m proudest of aren’t the most-starred. They’re the ones where someone opened an issue saying “I used this to deploy video conferencing for my school” or “this saved me a week of setup.”
Maintenance is the hard part. Writing code is the fun part. Responding to issues, reviewing PRs, keeping dependencies current, testing against new OS versions: that’s the real work. Most open source projects die because the maintainer runs out of energy for the unglamorous parts, not because the code is bad.
What’s Next
Developer tooling and infrastructure. Small, focused tools that solve specific workflow problems. More writing, which is why this site exists.
If you want to start contributing to open source, don’t look for projects to contribute to. Build something you need. If other people need it too, they’ll find it.
A problem, a solution, a git push. That’s how everything on my GitHub started.