Devtools must be open source

Five years ago, most software engineers the author spoke with had no programs they had written for themselves. That question was not idle: it came up while the author was trying to understand how Tailscale could fit into engineers’ daily lives. The pattern was consistent. All day, every day, engineers used programs written by others to write programs for others. Customization happened, but mostly at the edges—config files, plugins, extensions—while the tools at the center of the workday remained someone else’s product.

When someone did have personal software, it was an unusual find: bespoke code behind a blog, home automation, or a homelab, instead of an off-the-shelf static site generator or a Zigbee appliance that was almost the right size. That scarcity was not a mystery to the author. Writing software for yourself has always had a questionable return. You can only write so much in a day, and something else always looked more important. Personal tooling competed with paid work, team deadlines, and the inertia of tools that already “mostly” worked.

That imbalance is technical as much as cultural. Engineers already operate a stack of other people’s systems and then layer local customization on top—configs, plugins, extensions—rather than owning the core of the tool. The same people often use software they shipped for others, as end users, without a matching habit of shipping software for their own workflow. Devtools sit in that gap: they are the programs that shape how other programs get written, yet they are often closed enough that the only lever is configuration, not ownership of the tool itself.

For builders, that matters because the daily craft is mediated by tools you do not control. If your editor, build system, debugger, or infrastructure glue is closed, your productivity is bounded by what the vendor ships and what its extension surface allows. Open-source devtools change the unit of investment: instead of only writing private one-offs with weak ROI, you can inspect, fork, and adapt the shared layer everyone already depends on. That is a different economic bet than building a private blog engine or a home lab script that only you will maintain.

The market context is the familiar split between “almost right” commercial products and rare personal systems. Off-the-shelf generators and appliances win on time; bespoke software wins on fit but loses on maintenance budget. Tailscale’s interest in how tools sit in engineers’ lives points at the same pressure: networking and workflow products succeed when they feel like part of an engineer’s own stack, not only another SaaS surface. Devtools that stay closed push customization to the periphery; open tools invite the core of the workflow to become shared infrastructure.

Watch whether engineers treat open-source devtools as the default place to invest personal engineering time—forking and contributing rather than only configuring—and whether closed tools keep forcing “almost the right size” workarounds. The practical test is simple: can you change the tool the way you change your own code, or are you limited to plugins while the real system stays behind someone else’s release train?