Open-source software continues to win over developers and enterprises. A recent report found that 92% of applications use open-source components, and open source is the de facto standard for software development.
The report, which was conducted by managed open-source company Tidelift, found open source exceeds proprietary software in technology flexibility and extensibility, developer satisfaction, total cost of ownership, development speed, quality of code, security, functionality, and performance and stability. The only area open source did not outperform proprietary software was under reliable support and consulting services, but it was a close fight with 36% of respondents saying open source was better in this area and 38% saying proprietary software was better.
While open source seems to be dominating the industry, Dries Buytaert the creator of the open-source project Drupal and founder/CTO of the SaaS company Acquia, believes the only other place open source hasn’t won yet is in creating a business model. “Successful open-source businesses are extremely rare. Figuring out these business models around open source is the last hurdle that prevents open source from taking over the world. It has already won with developers, but hasn’t won as a business model yet,” he said. “Cracking the code would be really valuable because it allows us to solve problems that exist in the world that are very hard to do now.”
Open-source business models are ways companies try to create revenue around free and open-source software. Some models include providing support and services for projects, creating advertisement partnerships, adding paid additional features, and selling cloud-based software as a service.
Open source as a business model
According to Buytaert, the reason why successful open-source businesses are so rare is because as an open-source project and its adoption starts to scale, it becomes harder and more complex to maintain. Some of the ways the Drupal project deals with the growth of the community and project is by assigning roles and responsibilities as well as providing contributors and maintainers with the tools necessary to complete those roles. For instance, there is a security team assigned, which is given access to security tools to perform things like audits.
Donald Fischer, co-founder and CEO of Tidelift, said there are three things companies, or even individuals, who want to be successful using and commercializing open source should pay attention to: security, licensing and maintenance.
When it comes to security, open-source users need to be able to trust and verify who the source code is coming from as well as identify any security vulnerabilities. It’s also important to understand whose job it is to find security vulnerabilities within the project and how fast the project responds to those threats.
Licensing is also a complex topic in the open-source word, Fischer explained, and it requires speciality knowledge. Some things open-source users should understand are: what license policies make the most sense for them, what licenses does the company use and can be used, and if those licenses are compatible.
Lastly, maintenance and quality have become a big issue. In the old days, software came from vendors like Microsoft and Oracle who ensured certain standards and support. In today’s modern era where businesses and individuals are utilizing open source, not all projects have maintenance or support in place, Fischer explained. This is troubling because those looking to utilize open source want to make sure projects have longevity. It is important to look at how the software keeps working and evolves as well as visibility into the actively maintained versions. Project owners should communicate and provide advanced notice when things retire so open-source users are not left stranded.
“The ability of businesses to move faster is dictated by their ability to maintain, comply and secure their systems,” said Kevin Wang, founder and CEO of FOSSA, an enterprise open-source management solution provider. “Just understanding what third-party software they depend on, and how they can strategically use that to improve their business is crucial. In order to be really fantastic modern software companies, you have to be really good at using open source.”
However, VM Brasseur, director of open-source strategy at networking and cybersecurity company Juniper Networks, warns against viewing open source as a business model. According to Brasseur, open source is just one of many tools that help execute business models. She worries thinking about open source as a business model will make people think that the fundamental definition of open source needs to be changed in order to add a revenue stream.
Open-source software in the cloud era
Another concern open-source businesses have is how to transform business strategies as technology evolves.
Towards the end of 2018, a new license sparked major controversy among the open-source community. The Commons Clause was drafted to put “conditions” or “limitations” on open-source software.
The controversy was that this was not an open-source license, and went against the definition of open source by adding restrictions to open-source software.
“Through the past decade of open-source history, there has been this huge stigma generated around any attempt to license software in a not purely open source way. The purpose of the Commons Clause in the beginning was basically to give a super lightweight alternative,” said FOSSA’s Wang. “It was this thing in between proprietary code and open-source code.”
At the time, Juniper’s Brasseur stated: “By restricting people from making money from a project where it is applied, the Commons Clause directly violates Item 6 in the Open Source Definition. As the Open Source Definition is no longer applicable to those projects, they—quite literally by definition—are no longer open source. At best they can be called ‘source available.’”
However, the Commons Clause was created to address a larger problem in the community which was to close the “cloud loophole” where cloud providers were taking advantage of open-source projects without giving back to the community or giving credit to the project.
“What has happened in the last five years is the rise of cloud computing, and in particular cloud computing providers who have made very successful businesses of taking successful open-source projects someone else invested most of the research and development, and then harvested most of the revenue via cloud offerings,” said Ajay Kulkarni, CEO of Timescale, a time-series data company. “Essentially, what we realized was in order to be a successful open-source business in the cloud era, we had to think about things a little differently.”
Kulkarni went on to explain that the cloud era has changed the way software is consumed, and cloud providers like Amazon are now able to download open-source software and run it for users in the cloud at a price.
Following all the controversy surrounding the Commons Clause, many other open-source projects started to change their licenses. Timescale developed the Timescale License, which aims to prevent cloud and SaaS providers from hosting a database-as-a-service version of TimescaleDB and OEMs who don’t provide value on top of the database. According to Timescale, a majority of its open-source software is still available under the Apache 2 license.
“We did not make this decision lightly, and we kind of did it because we felt like we needed to, not because we wanted to. What we saw was the software world was moving faster than the licenses could keep up,” Kulkarni said. “We believe this decision really allowed us to build towards a self-sustaining open-source business where we can control our own destiny and keep reinvesting in the product.”
Database company MongoDB created the Server Side Public License (SSPL), and actually tried to go through the Open Source Initiative (OSI) to get it approved as an OSI-approved license. After realizing that the license was not going to get the broad support it needed to be approved, MongoDB withdrew the SSPL from the OSI-approval process, but continues to use it.
“While it’s not OSI approved, MongoDB users are free to review our code, modify our code, distribute our code or redistribute modifications to our code in compliance with the license,” said Eliot Horowitz, cofounder of MongoDB.
Cockroach Labs, makers of CockroachDB, took a different approach, and adopted the Business Source License (BSL). With the BSL, source code is freely available and on the path to become open source at a certain point in time.
“We think of it as patent protection. You can decide what protections you want and for how long, and what happens is when that term is up what was formally licensed as BSL becomes Apache in our case,” said Spencer Kimball, co-founder and CEO of Cockroach Labs. “The exclusion is you can’t run Cockroach as an external database as a service. You can think of that fundamentally as an anti-AWS provision.”
Other companies in this wave of license changes included Redis, which was one of the first to adopt the Commons Clause and also introduced the Redis Source Available License for Redis Modules; MariaDB, who also adopted BSL; and Confluent, who announced the Confluent Community License.
Heather Meeker, the lawyer who drafted the Commons Clause, also created the Polyform Project, which aims to draft and make freely available plain-language source-code licenses with limited rights.
“Until now, there has been no standardization of this kind of source-code license, even though it has become increasingly common. This has resulted in confusing and overlapping licenses, which need to be analyzed one at a time. Lack of standardization has used up the time and resources of many in the software industry, as well as their lawyers. The objective of the PolyForm Project is standardization and reduction of costs for developers and users,” the project’s website states.
Timescale’s Kimball hopes one day a better way will be provided to protect open-source projects. “We are not lawyers. We didn’t want to create a license. This is not our business model, and it was a huge time stuck and had a huge expense, but it is also not our job to try to convince the open source entities to make this huge shift.”
Drupal’s Buytaert suggests experimenting with licenses and creating new licenses that can help support the creation, growth and sustainability of new projects. Licenses should encourage sharing, but discourage unfair competition, he explained.
“A lot of the open-source licenses we use today are 20 years old, and I think it is a little naive to think something that worked 20 years ago is still perfect today,” said Buytaert. “New licenses are worth exploring. It can be game-changing and provide a breakthrough for how we think of sustaining open source.”
Tidelift’s Fischer has other thoughts. “We think the bigger opportunity is around creating some net new value around the open-source software without putting additional restrictions around the use of open-source software or creating a license and debating about the open-source definition. All these things fly over the heads of most organizations trying to use this stuff. Let’s go over this opportunity to create new value that didn’t exist in the world before,” he said. “A great example of that is if there is some open-source code that folks are using but there hasn’t been commercial support or maintenance available for it, let’s start making that available for that software and if it is valuable, organizations will come and pay for it.”
Open source sustainability
According to Juniper’s Brasseur, there are much bigger problems in the open-source world that we should be worried about. While it is great that businesses are taking an interest in open source, a more important issue is being able to sustain open source for years to come.
Brasseur explained many companies and individuals will often just donate money to a project in order to help it grow because “throwing money at the problem is easy for people to do,” she explained. “We are conditioned to equate money with stability.” The problem with this is that no one follows up on those donations or sees how it was used. Project owners also don’t understand what to do with the money.
While Brasseur does understand it is important to do things like pay and support maintainers, sustainability needs to be more than just money.
“If your maintainer or core contributors ran away to join the circus, how many of those would it take to put your project in a bad position,” she said. “That is something we need to be focusing on for sustainability a lot more than we need to be focusing on just getting money into the hands of contributors.”
She suggested taking a look at the book “Our Common Future,” also known as the Brundtland Report, which examines corporate sustainability planning, and how the corporate world grows an economy while growing and sustaining the environment.
What the book does is define what sustainability is, which can be applied to the open-source world. According to the book, sustainability is “development that meets the needs of the present without compromising the ability of future generations to meet their own needs.”
The book also identifies key areas for successful sustainability and how each one is an interlocking crisis that needs to be addressed simultaneously. According to Brassuer, the benefits of having a corporate sustainability plan include a more reliable supply chain, collaboration between groups internally and externally, improved communication, increased innovation, and improved employee retention and recruiting.
“Free and open source software needs to follow the open source way, and build on the contribution from those who came before us,” she said in a keynote at PyCon Australia last year. For open source, she explained the three elements of sustainability planning are: contributing back, human environmental diversity, and community safety.
Contributing back refers to giving back to the open-source project or community whether that be in the form of time, talent or treasure. “Since the very beginning of free and open source software we have had people and organizations who use free and open source but don’t contribute back. We call them ‘free riders,’” she said in her keynote. “We use it in a very negative way and we dismiss them. They are no good. These organizations may not understand that what they are doing… is degrading the longevity and success of the free and open source software that they rely on.”
It is important to note that contributions don’t have to come in the form of code. Some ways to contribute time are by doing things like volunteering at events or helping to organize events; through talent by doing things like security audits, redesigns, or improving accessibility; or through treasure it can be donating money.
In addition, there are many different roles that go into a project, such as documentarians, designers, security, infrastructure, testing and marketing, but too often open-source guides are focused just on programmers. “It is fine as a developer to scratch your own itch and release it, but if you want your software to be usable and adopted, you need to bring people with other expertise,” she said.
“Events around open-source projects, documentations, marketing and legal advice, these are all things that go into marking a project successful,” added Drupal’s Buytaert. “Having a lens that is more than developer-centric is really important.”
Human and environmental diversity involves getting more and varied people involved in the community. This will help provide more resources, innovation and stability, because the more people involved, the less you have to worry about the bus or circus factor. In addition, diversity does not only mean gender, but can be geographic and language diversity. Allowing people from different parts of the world who speak different languages can open up the door to millions of new contributors in those areas, Brasseur explained.
And then, open-source communities can cultivate that diverse contributor base by making sure they feel safe to contribute. “As an open-source participant, you have the power. You are in a position to witness unprofessional and unwelcoming behavior and take action,” said Brasseur.
For individuals, a way to ensure community safety is to restrict any contributions to projects that don’t have a code of conduct. Project owners and maintainers should make necessary steps to enforce the code of conduct.
According to Tidelift’s Fischer, there has also been a rise of ethical licenses to promote community safety. For instance, the Hippocratic License 2.0 was just released, which follows the Hippocratic Oath in medicine, which implies first do no harm; however, Fischer notes it may be hard to get these licenses noticed by contributors.
“People are trying to have their work used in a context that they endorse from a moral or ethical standpoint, but it is really complicated to figure out how to achieve that without having unintended second-order consequences,” he said. “We are trying to figure out what those unintended consequences are, and how it works in practice. It is still a work in progress.”
Drupal’s Buytaert believes projects need not be afraid to innovate. For instance, when the project started 19 years ago, technologies like mobile and social media didn’t exist. Projects have to be able to ride different innovation waves to stay relevant.
The Drupal project tracks all code and non-code contributions to the project and gives contributors credits or points. Those points are then stacked up and ranked so others can see who participates the most. “The Drupal website gets about 2 million unique visitors a month, which is a crazy number for an open-source community website. Not only do you get leads from potential customers, but also it speaks to the expertise of the organization or individuals.”
There is also an ongoing trend where companies are acquiring open-source projects instead of starting them. According to Rhys Arkins, director of product management at open source security and license company WhiteSource, this can be a positive trend that promotes more open-source projects in the future. “The best open source is usually that which first comes out of an internal or personal need first, so if starting open-source projects was too intimidating or mostly for large companies alone, we’d miss out on a lot of innovation compared to one where small projects can flourish,” he said.
To successfully flourish under corporate stewardship, Arkins recommended company interest aligns with community goals and directs. “If there is any direct conflict between the company’s intended business model (e.g. limiting features in the open source and selling advanced features commercially licensed) then it’s unlikely to end well. If on the other hand, even long-term open source use of the project is still of benefit to the company, then it reduces the chances of conflict and increases the likelihood of a win-win situation,” he added.