Introduction
I have wanted to work with open source since I first heard the term. I’ve always had a philosophical view of it — the idea of software being shared with the intent of being useful to others, the ability to contribute to projects from all over the world, and knowing that something you built can positively impact people you may never meet in person.
In my career I always wanted to be useful and produce useful work. Open source makes me feel that way.
I’m Cezar Augusto, and I created Extension.js, an open-source tool that makes it very easy to create cross-browser extensions.
Open-source journey
I started contributing to open source by triaging bugs and writing or translating documentation — mostly for projects related to front-end development and browsers, which have always been my core interest. I’ve always been fascinated by how browsers work, and that obsession led me to contribute to projects like MDN and the iconic Front-End Developer Interview Questions, which I later helped maintain.
At the time, I wasn’t very confident in my code. But once I gained that confidence, I started looking around ways to contribute code to an open-source browser. These were the early days of the Brave Desktop Browser, which gave me my first meaningful contribution and my first real contact with browser extension development.
Extension.js
Browser extensions have existed for a while, but surprisingly few people know how they work or how to build one. Once I got familiar with the ecosystem and started teaching colleagues and friends, I realized that depending on the browser and the context where your extension runs, things we take for granted in web development — like live-reloading or importing static files — aren’t easily supported.
Back then, you could rely on boilerplate projects to get started, but they required too much configuration. If you wanted to use a modern stack like React, you’d have to learn tooling that felt disconnected from most web workflows. That made learning browser extension development a frustrating experience.
Developing browser extensions shouldn’t feel like stepping back a decade in tooling. Extension.js changes that. It brings modern, zero-config tooling to the world of browser extensions — so anyone using TypeScript, WASM, or frameworks like React, Svelte, or Vue can build once and ship to all major browsers without compromising the developer experience.
Used by hundreds of projects, Extension.js is a tool I’m proud to see helping other developers build browser extensions with ease.
Challenges
Extension.js began as a solution to a personal need, and it’s continued to grow alongside my career. But it needs to evolve. Maintaining an open-source project taught me something no book or job ever could: progress often happens quietly. The most important work is often invisible — reviewing issues, refactoring silently, or managing expectations. It’s not glamorous, but it’s what keeps projects alive.
As a maintainer, I’m constantly balancing shipping with listening, and personal growth with community needs. I’m often eager to ship a feature or fix a bug, but the project is now bigger than me — and that means being more thoughtful about the impact of every decision. It’s not easy, but it’s deeply rewarding.
AI
Artificial Intelligence empowers developers in ways that make projects more accessible to build, allowing individual maintainers to ship features, debug issues, and write documentation at a pace that once required a full team.
It also makes contributions from both seasoned engineers and newcomers equally impactful, which is a huge help for solo maintainers or small teams working on larger open-source projects.
The next generation of open-source projects won’t be built by teams — they’ll be orchestrated by individuals augmented by AI, opening doors to diverse contributors and lowering the barrier to innovation in ways we’ve never seen before.
Advice
You don’t need permission to make a difference. Open source rewards curiosity, generosity, and consistency. Whether you’re a first-time contributor or a seasoned maintainer, your work matters — and it’s often the quiet commits that make the loudest impact.
For developers looking to contribute: if you want to work with open source because you believe you can do a good job in service of something greater than yourself, do it. Don’t expect recognition or compensation. The biggest joy I get from working in open source is knowing the impact my code can have.
For contributors and maintainers: make your project easy to contribute to, and take the time to understand the people who use it — they are your biggest contributors. Your code is open to everyone, and there’s always a chance someone might copy or rebrand it. That could be an unoriginal developer or a large corporation. Assume this is a sign of great software — and potentially the best compliment your work can get.
For everybody else: acknowledging good work is one of the simplest, most meaningful actions you can take to honor someone’s effort. Whenever you can, contribute — whether with code, knowledge, promotion, or anything you’re good at — to your favorite projects and developers.
To all my fellow maintainers and open-source contributors: thank you — your quiet dedication powers the tools, ideas, and communities that move the web forward.
Read stories shared by other maintainers.
This story was published under CC BY-SA by the author.