iTranslated by AI
A Deciphered Summary of "Corporate Open Source Anti-Patterns: A Decade Later"
This is the 8th day of the Translation of Overseas SRE-related Sessions for the Qiita Advent Calendar 2025. It's a solo Advent Calendar, but I'll do my best to complete it.
In this Advent Calendar, I translate overseas SRE-related sessions and add my own opinions, questions, and supplementary information. If there are any incorrect explanations due to my misunderstandings, please point them out in the comments.
The previous session was Translation of Automated deployments of SLOs Using Sloth and Prometheus. It was about a toolchain for developers to manage SLOs as code.
In this Advent Calendar, I will distinguish my opinions and comments from the summary using the notation below, as much as possible. However, it's not always possible to be perfectly strict, so please forgive any instances where my personal views might unintentionally mix into the summary. (Please point it out if you notice it)
About the Session Introduced
Session details: Corporate Open Source Anti-Patterns: A Decade Later - P99 CONF
This session is about open-source software, which we will inevitably rely on when performing SRE. I believe many of you reading this contribute to, own, or use open-source software. And often, we may have to re-evaluate our technology choices due to licensing or community issues. This session describes anti-patterns in open-source software.
Summary
Background and Changes Over the Past Decade
For example, ten years ago, on the podium at Brazil's FISL13, I enumerated the mistakes companies made regarding open source from the 90s to the 2010s. Looking back now, the landscape has significantly improved since then. The attitudes of major vendors have softened, and who would have imagined Microsoft creating TypeScript? Yet, in 2023, I find myself having to speak about different pains. I still don't have the perfect recipe. That's why I promised to compare notes ten years from now. Both the venue and the era have changed. OSCON is gone, and P99 CONF is open to the world online. Just as the nature of conferences has changed, open source has also become completely mainstream.
The Unique Importance of Open Source
While celebrating these changes, I will first re-explain "why open source is special." It frees human intellect from the constraints of time and space, and further incites the next wave of innovation—a chain reaction similar to Moore's Law in semiconductors, made real by the combination of the internet, distributed version control, and OSS. If we were told to remove all OSS from the past decade from today's products, we wouldn't be able to move an inch. OSS is incredibly valuable, and I want to state first that we are fortunate to be born in this special generation.
The Premise of the Social Contract
The key is the "social contract." OSS is not merely a deliverable, a developer, or a community. It is an understanding between these three parties, not a contract to be litigated in court, but one based on courtesy and mutual respect. Giving a little of what is not obligatory and receiving a little of what is not obligatory—the world's information infrastructure now stands on this delicate balance. Anti-patterns begin when this reality is forgotten. In recent years, these mistakes have become more noticeable not in traditional large corporations, but rather in "companies that build their business around OSS." This is because the more intertwined business and OSS become, the stronger the temptation to abandon half of the social contract.
Anti-patterns (2020s Edition)
- Confusing Users with Customers
The first mistake is to equate "popularity," such as GitHub stars or download counts, directly with customer value or product-market fit. While these are indeed eye-catching metrics that appear attractive to investors, popularity and monetization are completely different matters. When I spoke to a VC immediately after they invested in Docker Inc., they were confident, saying, "With this many downloads, it must be monetizable." I asked in return, "What if that popularity is actually a reverse signal that 'this cannot be monetized'?" The VC paled and asked, "Is that possible?" I replied, "I don't know. But confusing users with customers is dangerous." This is a typical pitfall that can occur the moment open source's popularity is misinterpreted as business value.
- Confusing Gross Profit with Net Profit
Another mistake is to be intoxicated by the fact that software is a "high gross profit business" and forget about net profit. Investors often praise the "wonderful gross profit of software." However, a business cannot run on gross profit alone. Real-world frictions such as development, support, marketing, and administration all impact net profit. If investors inflate company valuations based on the sweet illusion of gross profit, that pressure forces OSS companies into strategies reminiscent of proprietary companies in the 1990s, creating an unsustainable situation. Both entrepreneurs and investors are responsible. Businesses inflated by large funding rounds have collapsed without a proper revenue model. If you are involved in a popular OSS project, please keep this strongly in mind. Be cautious with fundraising. You must clearly define in advance how to build your product and how to monetize it.
- Relicensing (Shift towards less permissive terms)
Ten years ago, I cited "copyright assignment" as a prime example of an anti-pattern. That's still wrong. And the problem of the 2020s goes even further: relicensing. People who contribute to OSS projects do so under the premise that their code will be freely available under an OSS license. Companies have a moral responsibility to uphold that premise. I understand that there may be cases where sublicensing or licensing to third parties is necessary. However, the moment a company relicenses to a more restrictive, non-OSS license, narrowing usage terms, for example, by stating that "cloud providers must not use it this way," they break half of the social contract with the community. Even if a mechanism like "time-delayed open source" is introduced, where it becomes OSS after a few years, it is not an OSS license. The OSS community is built on trust, based on free usage. Relicensing destroys that very trust.
- Superfluous and Ambiguous Licenses
Even more serious are ambiguous and anti-competitive licenses, exemplified by the HashiCorp case. Their introduced license text stated: "This software may be used, but this does not include licensing to third parties for hosting or embedded businesses that compete with HashiCorp's products."
However, this wording is surprisingly unclear, obscuring the most crucial parts like "What is a product?" "What constitutes competition?" and "Where are the boundaries of hosting or embedding?" The more you read it, the more questions arise. How are acquired services treated? Under which company name is judgment made? Which features are considered "competing"?
Although HashiCorp provided additional explanations in an FAQ, an FAQ is not a license and does not legally supplement it. Users and companies averse to risk cannot confidently decide to use it due to this ambiguity. The problem is that this relicensing proceeded with little regard for the existence of the community. While the community naturally raised many questions, merely answering them individually was insufficient. If those explanations were truly important, they should have been written into the license itself, not the FAQ.
Such "superfluous and ambiguous licenses" occur when one side of the social contract is abandoned, and it is a classic anti-pattern that leads to a loss of community trust.
- Calling the Community Free-riders
Some companies call the community "free-riders," but please stop. We all stand on the shoulders of others' OSS. In essence, all of us are free-riders. The core of the problem is that companies misidentify their true competitors. The competitors should be "service providers or other players in the market," not "individual participants in the community," but companies end up competing with the community itself. If a company feels, "We are losing to the community," then that's a problem of the company, not the community. In HashiCorp's case, they didn't accept many contributions from the community and unilaterally proceeded with license changes, which caused significant backlash. The moment a company forgets that the community is not an enemy but the foundation they build upon, they fall into this anti-pattern.
- Demanding Trust After Violating the Social Contract
And finally, it's demanding "trust us" after damaging the social contract. In the OSS world, it's fatal to believe the community has "no choice." The community always has choices. The swift emergence of OpenTofu, advocating for a healthy alternative shortly after HashiCorp's license change, is vivid proof of this. Trust is broken in an instant, but restoring it takes an immense amount of time. That's why companies must not take the social contract lightly. The community always has an escape route, and if betrayed, they will quickly leave.
We witnessed this with OpenTofu. OpenTofu is great, and will continue to be great, but it was all unnecessary.
Lessons from These Anti-Patterns
The lessons learned from these anti-patterns cannot be summarized into strict rules. Rather, the conditions are always ambiguous. I myself have consulted with the community when struggling with how an open-source company should behave. What surprised me was their deep understanding of our circumstances—that is, the reality of having to build and actually run a sustainable business. In other words, there is indeed a "right way." However, executing it is genuinely difficult. There are no easy paths.
That's why, if you want to start a company centered around open source, you must first clarify one thing: What are customers willing to pay for?
Do not shy away from this question. For popular projects, many people are willing to pay. It's necessary to correctly identify where the value lies and draw a line there.
And please don't misunderstand: support and services are not "dirty work." There are excellent businesses built around support, and sophisticated products can be offered by leveraging open source. The business challenges and revenue model conveniences of a company are not the community's responsibility. Do not shift your problems to the community.
The important thing is to find a way to build a prosperous, sustainable, and healthy business while simultaneously nurturing a healthy community. It is possible, but difficult. That's why attention to detail and sincerity make all the difference.
And let's meet again in ten years. Even if it feels far away, time always passes surprisingly quickly. By then, AGI might have turned the world upside down.
Overall Comments
I've tried my best to avoid discussions about OSS, especially regarding community, licenses, and business. This often seems like an ideal, yet it's also a realistic problem, and furthermore, a legal issue concerning copyright. In summarizing this, there's a possibility that I haven't used strict legal terms correctly. I tried my best to capture the nuances, but please be particularly aware that this summary might be inaccurate and problematic.
The session also touched on the Terraform and OpenTofu discussion, which had a significant impact on my work. Other recent examples include Redis and Valkey, as well as MongoDB and Elasticsearch. More recently, MinIO also became a topic of discussion. The repeated use of terms like "social contract" and "morality" as important keywords in the session was striking.
Next time, it will be Translation of Production load testing as a guardrail for SLOs, which is about load testing in a production environment.
Discussion