Links - 15^th January 2023

You’re reluctant to create new projects, because you know it will just increase your maintenance burden. In fact, there’s a perverse effect where, the more successful you are, the more you get “punished” with GitHub notifications.

You can still recall the thrill of creation, the joy of writing a new project from scratch and solving a previously-unsolved problem. But now you weigh that joy against the knowledge that any new project will necessarily steal time from old projects. You wonder if it it’s time to formally deprecate one of your old repos, or to mark it as unmaintained.

You wonder how much longer this can go on before you just burn out. You’ve considered doing open source as your day job, but from talking with folks who actually do open source for a living, you know that this usually means permission to work on a specific open-source project as your day job. That doesn’t help you much, because you have dozens of projects across various domains, which are all vying for your time.

What you want most of all is to have more projects that maintain themselves. You try to follow all the best practices: you have a CONTRIBUTING.md and a code of conduct, you enthusiastically hand out owner privileges to anyone who submits a high-quality PR. It’s exhausting to do this for every project, though, so you’re not as diligent as you wish you could be.

You feel guilty about that too, since you know open source is frequently regarded as an exclusive club for privileged white males, like yourself. So you worry that you’re not doing enough to help fix that problem.

More than anything, you feel the guilt: the guilt of knowing that you could have helped someone solve their problem, but instead you let their issue rot for months before closing it. Or the guilt of knowing that someone opened their first pull request ever on your repo, but you didn’t have time to respond to it, and because of that, you may have permanently discouraged them from open source. You feel guilty for the work that you do, for the work that you didn’t do, and for not recruiting more people to share in your unhappy guilt-ridden experience.

One reason this situation is so frustrating is that, increasingly, I find that issue triage takes time away from the actual maintenance of a project. In other words, I often only have enough time to read through an issue and say, “Sorry, I don’t have time to look at this right now.” Just the mere act of responding can take up a majority of the time I’ve set aside for open source.

I get it. Good design is hard, and sometimes we’re stuck with code that’s, um, Not So Great. Engineering is tradeoffs, and there’s no one right answer when it comes to design. DI frameworks solve design problems at the cost of increased maintenance costs and lower-quality design. Manual dependency injection solves those problems, but at the cost of spending more time passing around variables and thinking about how to structure your dependencies.

Look, I’m a professional. I get the job done. Pretty much every client I work with uses a DI framework. I’m not going to do that passive-aggressive programmer thing where I sniff dismissively and refuse to work on any code that involves a DI framework. I know how to work with DI frameworks, I do it, and I’ll even admit they make life easier. The Testing Without Mocks patterns are designed to let you not have a DI framework, but they work just as well if you do.

But I also think they’re a crutch. Next time you start a new codebase from scratch, try it without a DI framework. You’ll have to spend a lot more time thinking about good design, and that’s a good thing. You might be surprised where it takes you.

It is not uncommon to learn about non-Indigenous entities appropriating Indigenous culture but none of them are as large, prestigious, nor well-known as The Apache® Software Foundation is in software circles.

SSH is yet another example of an ancient technology that is still in wide use today. It may very well be that learning a couple of SSH tricks is more profitable in the long run than mastering a dozen Cloud Native tools destined to become deprecated next quarter.

One of my favorite parts of this technology is SSH Tunnels. With nothing but standard tools and often using just a single command, you can achieve the following:

• Access internal VPC endpoints through a public-facing EC2 instance.

• Open a port from the localhost of a development VM in the host’s browser.

• Expose any local server from a home/private network to the outside world.

Why is this so hard? Because you’re utterly habituated to steady progress — to completing things, to producing, to solving. When progress is subtle or slow, when there’s no clear way to proceed, you flinch away. You redirect your attention to something safer, to something you can do. You jump to implementation prematurely; you feel a compulsion to do more background reading; you obsess over tractable but peripheral details. These are all displacement behaviors, ways of not sitting with the problem. Though each instance seems insignificant, the cumulative effect is that your stare rarely rests on the fog long enough to penetrate it. Weeks pass, with apparent motion, yet you’re just spinning in place. You return to the surface with each glance away. You must learn to remain in the depths.