My GitHub has 52 public repositories. Some have stars. Most don’t. A few have been useful to people I’ll never meet. That’s the deal with open source. You put work out there without knowing where it lands.
How It Started
My first real open source contribution wasn’t a contribution at all. It was documentation. In 2020, I was deploying Jitsi Meet and couldn’t find a single guide that covered the full production setup. So I wrote one. Then another. Then I put them on a Docusaurus site and called it Easy Jitsi.
I didn’t plan for it to get 155 stars. I just needed the documentation to exist. Other people needed it too, and that alignment is the foundation of every successful open source project: someone scratches their own itch and it turns out other people have the same itch.
What I’ve Shipped
A few highlights from projects I’ve maintained:
Easy Jitsi and Awesome Jitsi are my documentation and resource curation projects for the Jitsi video conferencing ecosystem. Combined 200+ stars. These started from deployment notes and grew because the Jitsi community needed better onboarding material.
REST API Starter is a Go boilerplate with Chi, GORM, and Logrus. 20 stars. I use it as the starting point for every new Go backend project. It encodes opinions I’ve formed over multiple production deployments.
DonatePal is a full-stack donation management app in Go. Built it to explore server-side rendering in Go without a JavaScript build step. The entire thing compiles to a single binary.
Webserv is an HTTP server in C. No frameworks, no libraries, just sockets and recv(). I built it to understand what Nginx does under the hood.
What I’ve Learned
Documentation is a feature. A project without documentation is a project for one person. The moment I added clear README files and deployment guides to my projects, contributions started coming in. People contribute to projects they can understand.
Small tools compound. My dotfiles repo, my tax calculator for Ghana’s PAYE system, my directory sizing utility. None of these are impressive on their own. But each one solved a real problem, and together they represent a practice of turning friction into tools.
Stars don’t matter (but they’re nice). The projects I’m proudest of aren’t the ones with the most stars. 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.” That’s the feedback loop that keeps me building.
Maintenance is the hard part. Writing code is fun. Responding to issues, reviewing PRs, keeping dependencies updated, testing against new OS versions, that’s the real work. Most open source projects die not because the code is bad but because the maintainer runs out of energy for the unglamorous parts.
What’s Next
I’m interested in developer tooling and infrastructure. The compliance helper I built recently is a step in that direction. Small, focused tools that solve specific workflow problems. I’m also spending more time writing, which is why this site exists.
If you want to start contributing to open source, my advice is simple: don’t look for projects to contribute to. Build something you need. If other people need it too, they’ll find it. And if they don’t, you still have a tool that works.
That’s how every project on my GitHub started. A problem, a solution, and a git push.