Beyond the Walled Garden of Open Source
Open source offers creators (publishers) and consumers (users) advantages. However, at times, friction and controversy can arise as the tenets of open source come up against realities such as funding development activities and investing in proper levels of security. Some uproar occurs as open source advocates and regulators try to work from a bright line for open source. Greater acceptance and support for nuance in licensing and regulation would provide the benefits of openness to more users. In contrast, a lack of nuance could shrink the borders of the open source commons as open source licensing becomes impractical in more contexts.
Extensive R&D funding is costly, and most open source relies on businesses for financing. But “free” (as in free beer or freedom) often conflicts with the need to generate self-sustaining funding. Companies find various ways to mix or limit their commitment to open source to reserve revenue potential sufficient to sustain their enterprise.
For instance, in offering open source to users, MongoDB discovered the freedom users are granted with open source also grants freedom for competitors to behave badly. In Mongo’s case, Amazon started offering a SaaS version based on and compatible with Mongo, essentially leveraging for free all of Mongo’s historical R&D and mind-share development investment and using these investments to turn around and put significant commercial pressure on Mongo. Mongo gifted Amazon a baseball bat with the open source license, then Amazon turned around and smacked them with it. In response to some outcry by purists, Mongo retreated from a pure open source license to one that still provides open source benefits to users, but restricts the complete freedom previously enjoyed by potential competitors. Their license is no longer considered purely open source, even though most users see no practical effect from the licensing change. Through this mechanism, Mongo has segmented its licensees into users (open source) and competitors (commercial.)
Many other companies providing an open source product have gravitated towards an open-core model, which provides an essential product as open source but adds other features under a commercial license. These companies segment their licensees into users of basic functionality (open source) and users of advanced or enterprise functionality (commercial).
WSO2 offers fully functional products as open source but commercialized support and maintenance. Free users get full functionality, but only commercial users get support accounts with enterprise-grade SLAs, receive updates and bug fixes for a generous product lifespan, private security advisory bulletins, expert advice, cloud hosting, and other services. Through this model, we have segmented our licensees into “as-is” users (open source) and fully-supported users (commercial.)
These examples illustrate wide diversity in how companies leverage open source to achieve their specific goals and provide a foundation for a successful business model. But this isn’t the only reason a publisher might have for releasing it as open source. A community of individual hobbyists or a consortium of organizations come together to share the investment in developing standard solutions to a shared problem. A company might publish open source not for direct profit but to build industry mind-share around their brand or point of view, to shake up a market by putting pressure on competitive technologies, or to incubate an ecosystem to improve innovation or keep development and maintenance costs down. An individual or organization might publish as open source simply to share something of interest or to contribute to the sphere of human knowledge — this could be a research project, tests, or a product that has ended its commercial life but is still in use by specific users.
It would serve those who promote open source to consider openness in broader terms, beyond viewing open source as a walled garden in which everything inside is deemed “open” and everything outside is not. Instead, openness should be considered in a broader context and encouraged as much as possible outside the officially recognized open source licensing context. To do so requires appreciating and accommodating the diversity of values and motives of the publisher. With that viewpoint, new possibilities can arise:
- Standardized license for open source “adjacent” scenarios. License standardization is an outstanding achievement by the open source community. These benefits can be broadened by defining and standardizing licenses that exhibit open characteristics while distinguishing them from today’s pure open source. For instance, a standardized open source-adjacent license that guaranteed the benefits of openness to users but restricted threats from competitors would improve the current patchwork of licenses for this purpose. Standardized licenses with varying degrees of openness, up to and including “all rights reserved,” could be developed just as Creative Commons provides a range of standardized content licenses up to and including “all rights reserved.” The general acceptance implied by such a set of licenses would encourage more companies to pursue more significant levels of openness in their license strategies.
- Standards for indicating the intent of the publisher. As regulations emerge concerning open source (e.g., the European Cyber Resiliency Act), there is no generally accepted way for a consumer to know whether an open-source product is intended for critical use in environments subject to security challenges. The CRA mandates that all products (including open source ones) perform risk assessments, provide security updates, and actively maintain the project for a reasonable lifetime. The effect is that all open source software published by companies doing business in the EU must be treated with the highest level of care. Where these requirements are not conducive to the goals for publishing, the publisher is likely to refrain from publishing at all. Instead, by providing a clear statement of the intent and responsibility accepted by the publisher, the user can choose software with proper security characteristics. This would prevent the disappearance of open source software from the public sphere, which may be pretty helpful in other contexts.
