The era of hidden code#

When I started my career, open source barely existed—and the little that did wasn’t on anyone’s radar. If anything, the prevailing attitude was the opposite: the more you could hide your code, the better. We genuinely believed that competence lived in the code itself, that our value as developers was somehow embedded in those lines we so carefully guarded.

There were no code reviews. Ownership was fierce—we’d put our names at the top of files, and heaven help anyone who touched “our” code without permission. It was a strange, territorial world that’s hard to imagine today.

The slow shift#

This mindset persisted for years. You could feel things gradually loosening—developers becoming slightly more open, slightly less protective—but progress was glacial. Then, as I mentioned in an earlier article, open source finally became ubiquitous.

It started to feel more natural to share than to protect, to offer than to take, to build in the open than to hide behind closed doors.

The honest truth#

Let’s get one thing straight: I don’t open source my projects because I’ve built something so brilliant that the world needs to see it. I’d love for that to be true, but let’s be realistic—the odds of anyone actually using my code are essentially zero.

It’s not about pride in my work either, or some belief that my code is particularly clean or elegant. No, the real reason is far more humble.

Publishing code as open source forces me into a rigor and discipline that makes me better—not just as a developer, but as a person.

The blank page#

The first challenge is simply starting—and the blank page has two sides. First, coming up with an idea worth pursuing. We’ve all had brilliant shower thoughts that evaporate the moment we try to articulate them. Then, the practical hurdles: setting up the scaffolding and making those first commits that feel like they accomplish nothing. Knowing the project will eventually be public adds just enough pressure to push through both.

Keeping the fire burning#

Once you’ve started, you need to keep going—often for weeks or months. I tend to go all-in on projects, sometimes working twelve-hour days for weeks at a stretch. I’m a bit obsessive that way. But regardless of your pace, maintaining enthusiasm over time is genuinely difficult.

One technique that works for me: each evening, when I’m still energized and my head is buzzing with ideas, I write a list of what to tackle tomorrow. It’s a gift from yesterday’s self to today’s: a clear path instead of a fog. I just start.

The last mile#

Here’s where most projects go to die. By my experience, finishing can take as long as the first two phases combined. It’s not glamorous work: ensuring feature completeness, extensive testing, polishing usability, writing documentation both inside the software (help screens) and outside it (READMEs).

It’s tempting to declare victory at 80% and move on to the next shiny idea. But an unfinished project teaches you far less than a completed one. The discipline of shipping—of pushing through that final 20%—is where real growth happens.

The real reward#

So yes, I open source projects that probably no one will ever use. And that’s fine, because the value was never in the adoption.

The value is in proving something to myself. In demonstrating that I can take an idea from nothing to something complete. In building the muscle of starting, persisting, and finishing.

Every completed project—no matter how small, no matter if no one ever uses it—is evidence that I can see things through. And in a career spanning decades, that evidence accumulates into something meaningful: a practiced ability to ship.

Isn’t that worth more than any number of GitHub stars?