Thoughts on Open Source Drama

This past month, David Heinemeier Hansson (DHH), announced that Turbo would be switching from TypeScript back to JavaScript. DHH is well-known for creating the Ruby on Rails web application framework, which has influenced the design and behavior of many other web applications frameworks ever since. The announcement was made the same day that the pull request removing TypeScript from the codebase was submitted and merged without responding to comments.

DHH’s reasoning was:

• They were spending too much time writing types to please the TypeScript compiler instead of writing code that works. (This is something I’ve experienced using TypeScript, as well).
• The type annotations in the code was making it harder to read and work with. (I also have seen this happen.)
• The compile step was adding a non-trivial amount of time to their development cycle and removing it sped up development. (All of my projects do not involve a compile step for this same reason.)

As with any sudden, significant change to an open source project, removing TypeScript from Turbo was met with angst, anger, and frustration online. Already-open pull requests written in TypeScript could no longer be merged, existing users were frustrated that type definitions would be removed, and people were claiming all kinds of horrible things would happen as a result. But that isn’t the point of this post.

As a longtime open source maintainer, myself, I’ve been on the other end of firestorms because of decisions I’ve made. It’s not unusual for parts of the tech community to pile on (especially on Twitter/X) over decisions that one influential person disagrees with, leading to days and days of additional comments meant to bully someone off their position. I ran afoul of the online TypeScript bullies when I announced that the rewritten version of ESLint would not be written in TypeScript. (ESLint has never been written in TypeScript nor has it ever provided types, but you’d think that I swore an oath that all puppies must die based on the response.)

So I think it’s important to take a step back and really understand the nature of open source.

Maintainers owe us nothing. The harsh truth about open source is that the maintainers don’t owe us (users, contributors) anything. All open source licenses state that the software is provided “as is” without any warranties. Just because you’re using or contributing to the project doesn’t mean you get a say in what the project does. There is no relationship between you and the maintainer other than the one the maintainer defines. They can be open and take your thoughts and opinions into account, or they can choose not to accept feedback and contributions. It’s up to them.

Company-directed open source projects. This is especially true of open source projects that are developed, maintained, and funded by a single company. Just because you’re free to submit pull requests and comment on issues doesn’t mean your opinion matters in any way. Companies have even abruptly end-of-lifed popular frameworks because priorities shifted. If you look at your stack and see a large number of company-directed open source projects, this will likely happen to you at some point.

This is the nature of open source. Before you start thinking, “this is exactly what’s wrong with open source,” keep in mind that “open source” just means that the source code is published and you are free to use it. Anything over and above that is at the maintainer’s discretion. There is no guarantee of support, ongoing maintenance, future versions, documentation, or collaboration. Popular projects take different approaches and they are all okay. Sometimes projects are forked when there is disagreement over the direction they should head in. That's the beauty of open source: as long as the source is out there, anyone can fork it and create their own version.

If you care, contribute. And what if there is a project that you’d like to gain some influence over? The best (but not guaranteed) way is to contribute. There are a lot of people who like to complain online about projects to which they don’t contribute. It takes a lot of work to maintain a popular project, and everyone has an opinion about what the project should do. Unless you are helping maintain the project in some way, your opinion carries very little weight. If you show up in the project and ask how you can help, you’re a lot more likely to affect the course of the project in the future. Every current and former ESLint team member began as contributors, and in doing so, they earned my trust and respect as well as the invitation to shape the project.

Because open source is so ubiquitous these days, it’s very easy to forget exactly what open source is. It may or may not be run by someone who is open to feedback, and that’s okay; it may or may not provide support and ongoing maintenance, and that’s okay; it may abruptly shut down or make incompatible changes, and that’s okay. As long as you’re using software written by someone with whom you have no relationship, you’re always at the mercy of their decisions, and sometimes, their whims. It’s okay to be disappointed, but let’s not pretend that it’s anything more than that.

Key Takeaways

• Open source projects, and their maintainers, aren't obligated to run the project in any particular way.
• You are more at risk when an open source project is company-directed, because their priorities can shift abruptly.
• Open source is wonderful. There's a lot of great, free software out there. Let's all act a bit less entitled and outraged when things don't go exactly as we hope.

💻 Free e-book: Managing Your Interrupt Rate as a Tech Lead. Last month, I wrote three blog posts about managing your interrupt rate. Due to popular demand, I've compiled those three posts into a short e-book with a new frequently asked questions section for each post. If you're a tech lead who's having trouble dealing with constant interruptions, you can download it for free.

Stuff I've Enjoyed This Month

🎬 Animate between states with the View Transitions API by W3C
View transitions just shipped in Chrome, and people are very excited about it. This short video gives you an overview of what you can do with view transitions, both with and without JavaScript.

🎬 View transition debugging by Jake Archibald
Continuing with the theme of view transitions in this newsletter. In this short video, you'll learn how to use the Chrome DevTools to debug view transition-based animations that aren't working correctly.

📝 Managing the chaos of context switching by Addy Osmani
You might have heard that multitasking and context switching are bad for your productivity. This article digs into the details, including why we are driven to multitask and some suggestions for how to reduce context switching at work.

📝The worst programmer I know by Dan North
I write frequently about what it means to be a multiplier, someone who helps other people become even better. This post is a good example of a multiplier who was providing value that wasn't able to be tracked by the organization's metrics.

📚 Do Hard Things by Steve Magness
In today's instant gratification world, it can be hard to work through difficult situations. This book is a guide to dealing with those hard things. It explores how top-level athletes overcome doubts and physical limitations to succeed, and extracts those lessons for use in every day life.

What I'm Working On

🏠 Real Estate: My latest BRRRR property is finally getting the hail damage repairs it's been waiting for. After a lot of waiting around for insurance, we are starting work on a new roof, new siding, and new gutters. I'm excited for how this property will finally turn out after all of this work. Follow my Instagram for photos.

💻 Open Source: I released a new version of Env (v3.0.0), which is a JavaScript utility to safely use environment variables. This version throws custom errors when there are validation problems, which makes it easier to use a try-catch to identify those errors. (You can also override the custom error types to throw your own, if you so desire.)

💻 ESLint: The past month has been all about planning for ESLint v9.0.0. We are finalizing the tasks we want to include, and I wrote a blog post about the changes coming to the rule API. I anticipate several more blog posts explaining different aspects of what's coming in ESLint v9.0.0.