Open Source projects and our values
Open source technologies like Rails are at the core of thoughtbot's history and identity. We work with clients who have built their applications with Rails, contribute changes upstream to the framework itself, maintain projects in the Rails ecosystem, and guide new clients to create new applications with Rails.
One of the appeals of open source projects is that they are distributed, democratized, and often MIT-licensed. In theory, the code exists on its own. In practice, that theory does not reflect reality. Everything is political, including code.
We run into a conflict when the maintainers or contributors to an open source project we firmly believe in and support have views or do something that is in conflict with our own values.
When faced with this conflict, we have a few ways to resolve it:
- Use an alternative
- Fork the project
- Actively support it
- Do nothing
Use an alternative
While this option is fine when there are good alternatives, we struggle when we firmly believe that the project is the best technical option. We also generally try not to go against framework defaults unless we have a good reason for doing so. Historically, the main reason why we'd do that was technical.
What do we do when we have explored alternatives, but there isn't yet something else that we would passionately pursue?
Are we willing to use an inferior alternative for non-technical issues? While we think we would like to take a strong stance, we are now faced with this for some of our most fundamental technical choices.
Fork the project
If we go this route, then we really need to be willing to follow through with it and commit to maintaining the fork long term.
Also, the level of controversy forking a project would bring would be very high. Doing so would also instigate others to fight back against it. This makes an already difficult endeavor more likely to fail.
We're not opposed to controversy if we believe it's rooted in the right thing to do, but we love open source and the communities to which we belong. We don't want to do more harm than good.
At the end of the painful process of forking, we would likely find ourselves in a place where things are fractured in our community.
Actively support the project alongside our values
In this alternative, we make our support and commitment to the technology clear. We focus our company effort and energy so that we can be active members of the community. We also put our values and what we believe out there as an alternative.
In doing this, we hope that we would provide a more positive alternative that the community can align with, without having to fork the project. We hope that with our active involvement the project gets better governance and becomes more aligned with our values over time.
One potential downside to this approach is that people in the community and even our own team members think that our active support means that we condone the values with which we actively disagree. Another is that our support of those projects legitimizes or allows them to continue.
Do nothing
In this alternative, we continue to use the project, but perhaps halfheartedly and a little unclear internally and externally about what our level of standardization, support, and values actually are.
This is probably the worst of the possible options because we know the more clear we are about who we are, what we do, and what we believe then the more successful we will be.
Our policy
Given the complex considerations above, we're faced with several imperfect options. In addition, people and organizations change over time. We can find ourselves in a situation where new conflicts emerge after we're already deeply embedded with a technology. As such, there probably isn't a blanket policy we can have, but instead we need to evaluate these conflicts as they arise.
In the case of Ruby on Rails, we have been deeply involved in the Rails community for years and we firmly believe it is still a great default choice for most web applications today. We also firmly feel that Turbo and Stimulus (and Hotwire) are a better choice than alternatives when you're building on Rails.
And yet, the views and actions of David Heinemeier Hansson and Jason Fried, and their company, 37signals, are not aligned with our own. Additionally, they're not necessarily good community open source stewards when they unilaterally and privately make decisions inside 37signals and then force changes through without discussion.
Upon evaluation, we feel that our positive presence in these projects is the least bad of the imperfect options.
Rails governance has improved somewhat over time, and we hope that it continues to do so and that this is also the case for the other projects over time. We hope that our active, positive contributions help to speed that improvement along.
We have published this to hopefully make it clear that we do not support the values, views, and actions of DHH, Jason Fried, and 37signals, and that we have reconsidered our involvement in the communities in which they participate, and tried to make considered choices despite the complexity.
This is the conclusion we've come to for Rails and the other open source projects created by 37signals. We'll continually reevaluate this decision as time goes on. We also anticipate that other projects and maintainers that need to be reconsidered will come up over time, will need to be considered on a case by case basis, and we may come to a different conclusion for that project.