7 min Applications

Breaking down the walled garden of open source

Breaking down the walled garden of open source

Enterprise open source technology has been on an arguably pretty tough journey in recent times, not least because of its sometimes-fractious record in licensing, its open (or not so open) approach to repository ‘distro’ (aka distributions) access, its newly adopted status by previously proprietary behemoths and its perhaps-inevitable evolution since Linux first emerged some 30+ years ago now. Given the state of the open nation, how far do we need to peer behind the walled garden that surrounds open source technology today and, crucially, are there new seed beds still sprouting green shoots to enable this liberal approach to technology to remain market-fresh for the years to come. Techinze Europe spoke to Jonathan Marsh in his capacity as vice president of strategy at API-centric application development and identity & access management (IAM) technology company WSO2 for the inside track.

Openly stating that, at times, friction and controversy can arise as the core tenets of open source come up against realities such as funding development activities and investing in proper levels of security, Marsh is sanguine about exactly how open source has certain advantages for both creators (publishers) and consumers (users). He acknowledges the occasional uproar that occurs between open source advocates and regulators, but insists that he believes greater acceptance and support for nuances in licensing and regulation could provide more of the benefits of openness to more users.

Reserved revenue reservations

“A lack of nuance could result in shrinking the borders of the open source commons as open source licensing becomes impractical in more contexts,” advised Marsh, in a somewhat plaintive call for more simplicity through lack of nuanced niggle nightmares. “Funding of extensive R&D is costly, and the majority of open source relies on businesses for funding. But our notion of ‘free’ (either as in free beer or as in freedom) often sits uncomfortably 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.”

As a working example here he cites MongoDB. In offering open source to users, Marsh reminds us that the company found out the hard way that 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 investments and using these investments to turn around and put significant commercial pressure on Mongo. With the open source license, Mongo gifted Amazon a baseball bat and then Amazon turned around and smacked them with it. In response, Mongo retreated from a pure open source license (to some outcry by purists) to one that still provides open source benefits to users, but restricts the full freedom previously enjoyed by potential competitors. Their license is no longer considered purely open source despite the fact that 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.)”

Open core technique: basic open, advanced commercial

Marsh further states that many other companies providing an open source product have gravitated towards an open core model, which provides a basic 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.)

At WSO2 the team offers fully functional products as open source, but commercialies support and maintenance… rather like Sun Microsystems always did back in the day.

Free users get full functionality, but only commercial users get support accounts with enterprise-grade SLAs, receive updates and bug fixes for a generous lifespan of the product, private security advisory bulletins, expert advice, cloud hosting and other services. Through this model, it has segmented its licensees into “as-is” users (open source) and fully-supported users (commercial.)

Adamant that these examples illustrate wide diversity in the ways that companies use open source in order to achieve their specific goals in providing a foundation for a successful business model, Marsh points out that this isn’t the only reason a publisher might have for releasing as open source. 

“A community of individual hobbyists or a consortium of organisations come together to share the investment of developing common 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,” he said.

We can see here that an individual or organisation 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 certain users.

A broader view of openness

“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, consider openness in a broader context and encourage openness as much as possible outside the context of officially recognised open source licensing. To do so requires appreciating and accommodating the diversity of values and motives of the publisher. With that viewpoint, new possibilities can arise,” commended Marsh, hoping perhaps for some sort of new wave of open epiphanies to arise.

Among those ‘new possibilities’ referenced here are standardised licenses for open source-adjacent scenarios…but what does this mean? The suggestion here is that license standardisation benefits can be broadened by defining and standardising licenses that exhibit open characteristics while still distinguishing them from today’s pure open source licences.

Open source-adjacent 

For instance, a standardised open source-adjacent license that guaranteed the benefits of openness to users but restricted threats from competitors would (according to the WSO2 team) be an improvement over the current patchwork of licences for this purpose. 

“Standardised licenses with varying degrees of openness, up to and including ‘all rights reserved’ could be developed just as Creative Commons provides a range of standardised content licences up to and including all rights reserved,” proposed Marsh. “The general acceptance implied by such a set of licenses would encourage more companies to pursue greater levels of openness in their licence strategies.”

We can also table the notion of standards for indicating the intent of the publisher here. 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 for 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,” clarified Marsh.

Free as in speech, not as in beer

He concludes his commentary by saying that where these requirements are not conducive to the goals for publishing, the publisher is likely simply 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, he surmises, would prevent the disappearance from the public sphere of open source software that may be quite useful in other contexts.

As already alluded to above, there’s open and then there’s open… and there’s free as in speech, not free as in beer… we may need to sit back and think about the fact that there is a licence as in free license, while also realising that there is licence as in free and open license, if indeed we haven’t done that already.

Free image: Wikipedia Commons