Open-sourcing my code felt like a risk, but it became the best career decision I’ve made. I’m Suhail Roushan, a full-stack developer, and I want to explain why I chose to open source my projects and the concrete lessons I learned from the process. This isn't about altruism; it's a practical strategy for growth, feedback, and building a reputation that directly benefits your work and your business.
For years, I kept my side projects and internal tools locked away, worried about exposing imperfect code or having my ideas copied. The turning point came when I built a CLI tool to automate our deployment workflow at Anjeer Labs. I realized maintaining it in isolation was a dead end—it would only ever solve my specific problems. The moment I put it on GitHub, everything changed.
How open sourcing improves your code quality
The instant you make a repository public, your relationship with the code changes. You start writing cleaner commits, better documentation, and more thoughtful abstractions because you know someone might actually read it. It’s the ultimate form of code review.
I noticed I began writing more modular, configurable functions instead of one-off scripts. For example, I refactored a configuration loader to be extensible:
// Before: Hardcoded for my use case
const loadConfig = () => {
return require('./local-config.json');
};
// After: Designed for public use
interface ConfigLoaderOptions {
path?: string;
env?: string;
}
const loadConfig = (options: ConfigLoaderOptions = {}) => {
const env = options.env || process.env.NODE_ENV;
const configPath = options.path || `./config.${env}.json`;
// Validation and fallback logic added
return require(configPath);
};
This shift in mindset—from writing code that works to writing code that is understandable and usable by others—is a direct skill upgrade.
Do you really need a perfect project to open source?
No. This was my biggest misconception. I used to think a project needed to be feature-complete, fully documented, and bug-free before sharing. That’s a barrier that kills momentum.
My rule now is: open source it once it’s useful to you. If it solves a problem for you, it will likely solve it for someone else. The first version of my deployment CLI had no tests and only supported one cloud provider. I posted it anyway with a clear “Alpha” label. The initial users weren’t critics; they were collaborators who suggested the next most-needed feature and even helped fix bugs.
Waiting for perfection means the project often never sees the light of day. An imperfect but working tool in the open has a future. A perfect one in a private repo does not.
Building a technical reputation and network
Open source is your public technical resume. It’s proof of your skills in a way a CV or portfolio statement can never be. When I began applying my open source work to my professional profile—like on my site, suhailroushan.com—I started receiving more targeted, high-quality opportunities.
Recruiters and potential clients could see exactly how I structure code, solve problems, and write documentation. More importantly, I connected with other developers who were using my tools. These weren’t superficial LinkedIn connections; they were technical discussions that led to consulting work, partnership talks, and valuable peer reviews for my other projects. Your code becomes the central point for a community of practice.
The unexpected benefit: forced documentation
Documentation is a chore most developers, including myself, neglect for internal tools. Open sourcing forces you to do it well. You need a clear README, setup instructions, and API references.
This discipline pays massive dividends. The act of writing documentation often exposes flawed assumptions and awkward APIs. I’ve lost count of the times I went to document a function only to realize its parameters were confusing and needed refactoring. Good documentation isn’t just for users; it’s for your future self. Six months later, when you return to the code, you’ll be grateful for the clear explanations you were forced to write.
Handling issues and contributions is a masterclass in product management
Managing an open source project, even a small one, teaches you product management fundamentals. You have to prioritize feature requests, triage bug reports, and review pull requests. You learn to say “no” to well-intentioned but scope-creeping suggestions and to guide contributors effectively.
This is directly applicable to running a product-led business like Anjeer Labs. It trains you to distinguish between a loud voice and a common need, and to maintain a clear vision for a project while incorporating community input. It’s a soft-skills workshop disguised as code maintenance.
Open source your work not when it’s perfect, but when it’s useful—the feedback and growth you’ll get are the fastest way to level up as a developer.