How should open source projects build a competitive moat?
Redis creator Salvatore Sanfilippo’s 2024 essay reignited a core debate over open source sustainability, pitting his 'control the ideas' philosophy against the trend of restrictive licensing. Where…
Redis creator Salvatore Sanfilippo’s 2024 essay reignited a core debate over open source sustainability, pitting his 'control the ideas' philosophy against the trend of restrictive licensing.
Where it happened
In a July 2024 blog post titled “Control the ideas, not the code,” Salvatore Sanfilippo (@antirez), the original creator of Redis, articulated a clear philosophy for building sustainable open source projects. The post served as a direct response to the growing trend of open source companies, including Redis Ltd. itself, adopting more restrictive, source-available licenses like the Business Source License (BSL) or Server Side Public License (SSPL). The essay became a focal point for renewed discussions on platforms like Lobsters and Hacker News, crystallizing the central strategic disagreement in modern open source.
Side A: Control the ideas, not the code
This position, championed by Sanfilippo, argues that the only durable moat for an open source project is its intellectual and community leadership. The core argument is that legal restrictions on code usage are a fragile defense that ultimately harms the project. Proponents believe that a project's true strength lies in its “soul”: the core team’s vision, the pace of innovation, the quality of its documentation, and the vibrancy of its community. These elements create a gravitational pull that makes the canonical project the most attractive version to use and contribute to.
Sanfilippo writes, “The only way to win is to be better, faster, more aligned with the users' needs.” According to this view, when cloud providers or other large companies offer a competing service, the correct response is to out-innovate them, not to retreat behind a restrictive license. Such licenses are seen as a sign of weakness. They risk alienating developers, discouraging contributions, and, most critically, inviting community forks (as seen with Valkey, the Linux Foundation’s fork of Redis) that can fragment the ecosystem and offer a permissively licensed alternative.
Side B: Restrictive licenses are a pragmatic necessity
This side argues that the competitive landscape has fundamentally changed, requiring a new licensing playbook for survival. Companies like Redis Ltd., MongoDB, and Elastic have all moved away from permissive licenses after concluding that large cloud providers were exploiting their work. Their argument is that hyperscalers would take the open source code, sell it as a managed service for significant profit, and contribute little or nothing back to the project's development. This practice, often called “strip-mining,” starves the core project of the revenue needed to fund its own R&D.
In its announcement, Redis Ltd. stated its goal was to “unify our licensing under a source-available model that will continue to make our source code available and allow us to double down on our permissive-licensed client libraries.” Similarly, when MongoDB introduced the SSPL, it was framed as a defensive measure to ensure that companies offering the software as a service must contribute back to the community. For this camp, source-available licenses are not an abandonment of open principles but a pragmatic evolution required to build a sustainable business that can continue to steward the project in a world dominated by cloud giants.
What's underneath
The two sides are not just disagreeing on licensing tactics; they are operating with different definitions of the core “product” and its primary threat. Side A defines the product as the entire ecosystem, including the community and the core team's leadership, which is inherently difficult to copy. For them, the biggest threat is community fragmentation and the loss of developer goodwill. Side B defines the product as the code itself, a commercial asset that is trivial to copy. Their biggest threat is financial starvation at the hands of a much larger, non-contributing competitor. Both want the project to thrive, but they fundamentally disagree on where the value lies and how best to protect it.
The investor read
This debate signals a critical juncture in open source monetization. The shift toward BSL and SSPL licenses is an attempt by venture-backed companies to create more defensible, SaaS-like revenue models around formerly open source projects, de-risking them for investors. This strategy aims for predictable licensing revenue over less scalable support contracts. However, it introduces a new, significant risk: the creation of a viable, permissively-licensed fork (e.g., Valkey from the Linux Foundation) that can capture developer mindshare, community contributions, and downstream commercial opportunities. Investors are now watching a live experiment on whether a license moat or a community moat is more durable for generating long-term returns.
Pull quote: “The only way to win is to be better, faster, more aligned with the users' needs.”
- Control the ideas, not the code ↗
- Redis Adopts Dual Source-Available Licensing ↗
- MongoDB is Now Released Under the Server Side Public License ↗
Every claim ties to a primary source. See our methodology.