What to expect from open source
In 2023, David Heinemeier Hansson (DHH) made a bold decision to remove TypeScript from Hotwire and Turbo. This caused some drama in the Javascript world. DHH's decision went against the industry trend for modern frontend development of the last few years. It was an unexpected move, backed by a strong personal opinion towards Typescript from the maintainer. A part of the community felt like this was a step backward, leaving them feeling unheard, and even motivated to pressure the maintainer to reverse the decision. Regardless of the arguments in favor or against, it highlighted a deeper conversation about expectations within the open source community.
We’re open source maintainers too, so this sparked an interesting debate: What can users expect from our open source packages?
Who are we?
At Spatie, we’re big on open source. It’s not just a way of working for us, it is part of our culture. Since releasing our first package in 2015, we’ve grown to nearly 500 public packages, responsible for over 1.5 billion downloads as of early 2025. All of this with a small team that has fluctuated between 1 and 7 developers over the years.
Our philosophy at Spatie
We create packages primarily for our own use, but we open source them to help others who might benefit. This approach has proven mutually beneficial:
- Users often spot and even resolve issues we might have missed.
- Contributions from the community help to keep our docs up to date.
- Users build and contribute useful features we hadn’t even considered.
It’s a way to give back while improving our own work. However, we maintain our projects on our terms. We welcome contributions by others and encourage people to take ownership rather than demand changes. When you use a free open source package, you’re not purchasing a product with a support contract.
This means:
- We’re not obligated to resolve every issue or implement every feature request.
- We’re not responsible for helping users set things up or troubleshoot.
- We do not work with deadlines or guarantees.
- We have the right to decline pull requests that don’t align with our vision or standards.
Maintainers work on projects in their free time or as part of their job, but they’re not bound by the same expectations as paid products. Patience and understanding go a long way.
That said, we’re always happy to review and merge pull requests that address problems or add value. The best way to get changes into a package is to contribute them yourself.
Boundaries & burnout
Most people start contributing to open source because they enjoy helping others or being part of a community. That’s where they get energy. But without boundaries, that positive energy can turn into exhaustion. Maintainers don’t owe users anything beyond what they choose to give. The healthiest projects are those where maintainers have clear limits on what they’re willing to support. Everyone knows how easy it is to lose interest if the balance between effort and appreciation is off. Just take a look at your ever-growing list of unfinished side projects!
Unfortunately, not everyone understands this. While it doesn’t happen often, we’ve encountered situations where users have expectations or become rude when their demands aren’t met. This kind of behavior can drain the joy out of maintaining open source. Expressing dissatisfaction and giving a 👎 does not encourage any open source maintainer to fulfil your requests.
What can you do instead?
If you encounter an issue or have a feature request, here’s how you can approach it constructively:
-
Search for existing issues: Check if someone else has already reported the problem or suggested the feature. Often, a solution or workaround can be found here.
-
Provide context: If you open a new issue or discussion, include detailed steps to reproduce the problem or a clear explanation of your idea. This makes it easier for others to help. But do know, you're betting on someone to spend their free time replicating and fixing your issue. Why not go to step 3 instead?
-
Take ownership: Instead of waiting for someone else to fix the problem, consider contributing yourself. Start by writing a failing test for the bug you’ve found. Once you’ve done that, you might as well try to fix it yourself!
And if you have a great idea for a new feature, go ahead and implement it. Open a pull request and share your work with the community.
But what if the maintainer decides not to merge it?
While we merge many pull requests, there are times when we reject them. This could be because a feature doesn’t align with the package’s scope, doesn’t meet our needs, or the implementation doesn’t meet our quality standards. For contributors, it’s often a one-time effort, but as maintainers, we’re responsible for supporting and maintaining that code for years to come.
You still have another option: forking. If a package no longer meets your needs, you can always fork it and take it in your own direction. Instead of being frustrated by a maintainer’s decision, consider taking ownership of the problem yourself. You can even keep your fork updated by syncing it with the original project’s latest changes.
Final Thoughts
Open source is a collaborative effort, but it’s also a personal one. Maintainers contribute their time and expertise because they care about the projects and the community. By respecting their boundaries, contributing constructively, and taking ownership when needed, we can all help keep the open source ecosystem vibrant and sustainable.
