There’s a gap between knowing how to write code and knowing how to build software that other people will actually use. Most professional environments never bridge it: you work within a closed scope, on an imposed stack, for a known and captive set of users. Open source, on the other hand, exposes you to the entire craft all at once: the technical side, but also product, quality, communication, and the simple fact of being held up to the judgment of the whole world. To me, it’s the best playground to grow as a Software Engineer.
Its strength lies in a rare characteristic: anyone can take on challenges at their own pace, choosing their level of commitment and the topics they want to grow on. Here are the five dimensions on which it has made me, and continues to make me, better.
Building skills on topics out of reach day to day
The professional setting is constrained by nature: you use the technologies the context imposes, rarely the ones you dream of exploring. Open source lifts that limit. Want to understand how a parser works? Dive into Rust. Drawn to application security? Projects like NodeSecure offer a concrete entry point. Want to touch both frontend and backend? Nothing stops you.
The key is to aim wisely. Open source isn’t a headlong technological rush: it’s the chance to deliberately pick the topics and stacks you genuinely want to go deep on, then put yourself to the test on code that matters.
Collaborating with the best, on high-impact projects
This is probably the most underrated benefit. Working in open source means finding yourself, directly or indirectly, in contact with some of the best engineers in the world, on projects with very high impact.
For me, Effect has been and remains that opportunity: exchanging and collaborating with the cream of the TypeScript ecosystem, from TypeScript core contributors to the Effect core team. You don’t learn the same thing reading exceptional code as you do writing your own code off in a corner. Being exposed to that level of standards, seeing how the best reason, design, and decide, is an acceleration no training can reproduce.
Having real impact, at scale
Building something useful and watching it get used by thousands of people you’ll never meet changes how you relate to the craft. skott, the tool I’ve been working on for several years, is now downloaded between 30,000 and 40,000 times a week, on the order of 140,000 downloads a month, and used all over the world.
Beyond the numbers, what stays with you is the thanks: people who take the time to tell me the tool was useful to them. Bringing value to an endless number of people, sometimes with a few hundred lines of code, is a satisfaction of a different order than shipping one more feature into a backlog.
Developing your Product and Marketing skills
Open source is often boiled down to pure engineering. That’s a mistake. Even if the money-making possibilities stay limited, an open-source project is also a training ground for two skills engineers neglect far too often: product and marketing.
A project is a product. You have to know how to showcase it, explain what it solves, and care about its documentation and onboarding. And you have to know how to talk about it: get the project known, grow its adoption, go find your first users. These are muscles most professional environments never exercise in a developer, and that open source forces you to develop if you want your work to meet its audience.
Practicing Craftsmanship, Agile, and Lean
Consumers of open-source projects are demanding, far more than a captive internal user. The quality of the project isn’t optional: it directly determines adoption, and even more so the ability to attract contributions.
Want your project to be used? You have to target the need precisely, iterate efficiently, and maintain a high level of user satisfaction. Concretely, that means quickly adding a highly requested feature, or shipping a critical fix without dragging your feet. That healthy pressure is an excellent driver of discipline.
skott has been the best ground for me to continuously practice Test-Driven Development, a lot of refactoring, and real day-to-day agility. The result speaks for itself: zero bugs. The only issues reported actually correspond to features not yet built, never to regressions. It’s that level of standards, imposed by the very nature of the project, that pulls quality upward.
The side effects that surprise you
Open source also holds surprises. If someone had told me I’d get the chance to present skott on the international stage, I probably wouldn’t have believed it. These side effects (visibility, opportunities, encounters) can’t be planned, but they flow naturally from building in public, seriously and consistently.
In closing
To those who manage technical teams: encourage your engineers to take part in these projects, give them the time and space to do it. They’ll come out better, on the technical side and on everything else.
And to those who write code every day: take the time to explore open source. Turn your curiosity loose on the projects you use every day. And don’t hesitate to open-source the little tools you’ve built for yourself, they might just be useful to many others. That’s often where it all begins.