Beyond the walled garden of open source

Open source provides benefits to developers (publishers) and consumers (users). However, friction and controversy can sometimes arise when the principles of open source clash with realities such as funding development activities and investing in appropriate security levels. Some rebellion occurs when open source advocates and regulators try to take a clear line on open source. Greater acceptance and support of nuance in licensing and regulation would bring the benefits of openness to more users. In contrast, a lack of nuance could shrink the boundaries of the open source commons by making open source licensing impractical in more contexts.

Large-scale R&D funding is expensive, and most open source projects rely on corporate funding. But “free” (in the sense of 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 in order to secure sufficient revenue potential to sustain their business.

For example, MongoDB discovered that the freedom that open source gives users also gives competitors the freedom to behave badly. In the case of Mongo, Amazon began offering a SaaS version that was based on and compatible with Mongo, essentially taking all of Mongo’s historical R&D and mind-share development investments for free and using those investments to put Mongo under severe economic pressure. Mongo gave Amazon a baseball bat with the open source license on it, and Amazon turned around and slapped them in the face with it. In response to the outcry of some purists, Mongo retreated from a pure open source license to one that still gives users open source benefits but limits the complete freedom that potential competitors previously enjoyed. Their license is no longer considered pure open source, although most users see no practical impact of the license change. Through this mechanism, Mongo has segmented its licensees into users (open source) and competitors (commercial).

Many other companies that offer open source products tend to use an open core model, where a basic product is made available as open source but additional features are added under a commercial license. These companies divide their licensees into users with basic features (open source) and users with advanced or enterprise features (commercial).

WSO2 offers fully functional products as open source but with commercial support and maintenance. Free users get full functionality, but only commercial users get support accounts with enterprise-level SLAs, receive updates and bug fixes for a generous product lifetime, private security advisories, 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 the wide variety of ways in which companies use open source to achieve their specific goals and build a foundation for a successful business model. But that’s not the only reason a publisher might publish something as open source. A community of individual hobbyists or a consortium of organizations comes together to share the investment in developing standard solutions to a common problem. A company might publish open source not for direct profit, but to increase awareness of its brand or point of view in the industry, to disrupt a market by putting pressure on competing technologies, or to create an ecosystem to improve innovation or keep development and maintenance costs low. An individual or organization might publish as open source simply to share something interesting or to contribute to the human knowledge field—this could be a research project, testing, or a product that has finished its commercial lifecycle but is still used by certain users.

It would be beneficial for promoters of open source to consider openness in a broader context, and not to see open source as a closed garden where everything inside is considered “open” and everything outside is not. Instead, openness should be considered in a broader context and promoted as far as possible outside the officially recognized open source license context. This requires appreciating and taking into account the diversity of publisher values ​​and motives. With this perspective, new opportunities can emerge:

• Standardized license for “neighboring” open source scenarios. License standardization is a major achievement of the open source community. These benefits can be extended even further by defining and standardizing licenses that have open characteristics while being different from today’s pure open source licenses. For example, a standardized, open source-like license that guarantees users the benefits of openness but limits threats from competitors would improve the current patchwork of licenses for this purpose. Standardized licenses with varying degrees of openness up to “All Rights Reserved” could be developed, just as Creative Commons offers a range of standardized content licenses up to “All Rights Reserved.” The general acceptance that such a set of licenses brings would encourage more companies to pursue higher levels of openness in their licensing strategies.
• Standards for indicating publisher intent. While new regulations are being enacted for open source (e.g. the European Cyber ​​Resiliency Act), there is no universally accepted way for the consumer to know whether an open source product is intended for critical use in environments with security issues. The CRA requires that all products (even open source products) must perform risk assessments, provide security updates, and actively maintain the project for a reasonable period of time. This has the effect that all open source software published by companies operating in the EU must be treated with the utmost care. If these requirements are not conducive to the publishing goals, the publisher will likely refrain from publishing altogether. Instead, a clear explanation of the intent and the responsibility assumed by the publisher allows the user to select software with appropriate security features. This would prevent open source software from disappearing from the public eye, which may well be helpful in other contexts.

Jonathan has been actively involved in the development of open standards for web services specifications and represented his former employer Microsoft in the development of standards around XML, XSL and early web services specifications. In his current role, he is responsible for the implementation…

Read more from Jonathan Marsh