“Cloud vendors do not care about monetizing FOSS projects, they are about getting more workloads running on their infrastructure — hence, to be the preferred destination for such workloads,” said CloudBees’ co-founder and chief strategy officer Sacha Labourey.

Confluent created a new community license, and MongoDB announced its Server Side Public License (SSPL) to combat cloud providers. In January, Elastic announced it would move its Kibana and Elasticsearch open-source projects to a dual license under the Elastic License v2 and SSPL. 

RELATED CONTENT: Open source is a community, not a brand

However, these new licenses that companies are switching to are not considered open source by the Open Source Initiative’s standard, leaving many in the industry to wonder where these companies now stand with open source.  

“These new ‘source available’ licenses contain restrictions to prevent cloud infrastructure providers from building a service out of their code. Early efforts like the commons clause limited ‘commercial use’ broadly and users found that the license language ‘created some confusion and uncertainty.’ Recent efforts by Elastic and others are more surgical. They simply attempt to restrict users from standing up the software alone as a service. The goal of these new licenses is to continue to capitalize on the widespread availability of the software and its source code to gain future customers while shutting out competing SaaS services based on the same code,” Justin Colannino, director of developer policy and counsel at GitHub, wrote in a post. 

According to Stephen O’Grady, principal analyst and co-founder of the developer analyst firm RedMonk, while it can be upsetting, the cloud providers are not actually abusing open-source projects if they are still abiding by the rules of the open-source license. “If project owners don’t want certain parties to be able to use their software, they shouldn’t be using open-source licenses,” he said. 

MongoDB argues that under SPPL, developers are still able to access, use, modify and redistribute its code. “We adopted the SSPL license to protect our right to build an innovative business in the Cloud era. We wanted to counter the threat of hyperscale cloud vendors taking our free product and offering it as a service without giving anything back,” said Dev Ittycheria, CEO and president of MongoDB.

Tomer Levy, CEO of Logz.io, a cloud observability platform provider, argues that changing licenses shakes the entire foundation of the open-source philosophy and shows that those in control of popular projects have the ability to take these projects away from the community at any time. “We were disappointed to hear about Elastic’s decision to change to a license which is not truly open source. This is a slap in the face to the engineers that helped build the community and make the open source software the staple that it is today,” he said. 

O’Grady added that changes like these have the potential to blur the definition of what is and isn’t open source, creating more uncertainty in the space. “If these companies genuinely want to protect open source, they would actively and aggressively maintain a bright line of distinction between their source available, proprietary licenses and genuine open source alternatives.,” he said.

Elastic made the decision to no longer refer to Elasticsearch or Kibana as open source and instead refer to the project’s as free and open. “While we have chosen to avoid confusion by not using the term open source to refer to these products, we will continue to use the word ‘Open’ and ‘Free and Open.’ These are simple ways to describe the fact that the product is free to use, the source code is available, and also applies to our open and collaborative engagement model in GitHub. We remain committed to the principles of open source — transparency, collaboration, and community,” the company explained in a post. 

Red Hat’s Haff actually thinks it can be a good thing if a project is successful and popular enough that a big public cloud provider is going to try to compete with it. “There’s a saying in the open-source space that your biggest challenge isn’t to be competed with, it’s to have no one know or care what you do,” he said. 

Some ways to combat the cloud providers, other than changing your software licensing model, is to form innovation partnerships with the cloud vendor so there’s a window where they can’t just steal your functionality and hopefully during that window the project innovates and moves past the threat. 

Drupal’s Bryon thinks creating a form of Creative Commons for open source could help categorize open-source projects into projects that are free to use, projects that require attribution and so on and so forth. “That sort of thing around open-source licenses could be really interesting to explore, because it would allow the expression of what these different projects are trying to do, but through the singular lens of this organization that has proven its importance and it’s credibility within the community,” she said. 

She also suggested creating social pressures on these companies to do better. WSO2’s Newcomer thinks we are already seeing Amazon react and change. In response to Elastic, the company created OpenSearch, an open-source fork of Elasticsearch and Kibana, and it is working with the industry to support and maintain the project long-term. Additionally, New Relic recently contributed Pixie, the open-source project for Kubernetes-native observability, to the Cloud Native Computing Foundation, and expanded its relationship with Amazon to run Pixie on AWS. 

Amazon “is the lead right now in this market. They have the capability to just take a leadership position in solving new problems through collaboration and open source,” said Newcomer. “What we need is more standard ways of interacting with them, standard platforms that all cloud providers should implement to solve the problems in the way of people so they’re not in this situation of having to pick and choose, which is difficult for everyone.”

The post The battle of open-source licenses appeared first on SD Times.

As open source has become increasingly more popular, companies have begun to adopt open source for the brand, but then try to go against the purpose of open source, according to Gordon Haff, a technology evangelist at open-source company Red Hat. “I’ve definitely been on a lot of calls where one of the first things I’ll ask business leaders is why do you want to be open source, and often the answer is: because our customers seem to like that, but we don’t want Amazon to compete with us. We don’t want someone else to compete with us. We want to be able to maintain some proprietary parts of our software,” he said.   

RELATED CONTENT: The battle of open-source licenses

Open source itself has never gotten away from its meaning, according to Vicky Brasseur, author of the book “Forge Your Future with Open Source.” The problem, she said, is that people haven’t bothered to learn or understand the true meaning of open source. “They make up their own definitions of open source, or they do it via the telephone game…and so the definition they’re working under in no way relates to what it actually is,” she said. According to Brasseur, the Open Source Initiative (OSI) defined open source over 20 years ago, and that is the one true meaning there is.

The Open Source Initiative’s definition of open source

OSI’s open source definition states that open source goes beyond just accessing the source code. To be open source, the software must comply with the following 10 criteria: 

1. Free redistribution, 
2. Source code, 
3. Derived works, 
4. Integrity of the author’s source code, 
5. No discrimnation against persons or groups, 
6. No discrimination against fields of endeavor, 
7. Distribution of license, 
8. License must not be specific to a product, 
9. License must not restrict other software, 
10. And the license must be technology-neutral.

“That is the one, the only, the worldwide recognized standard,” said Vicky Brasseur, author of the book “Forge Your Future with Open Source.” “Standards are very important because otherwise we can be using the same words and mean completely different things, and from a business perspective, that can be devastating for people to be using different words or the same word open source and meaning different things. There is no other definition of open source.”

Creating a business model around open source

According to Robin Schumacher, vice president of product at open-source monitoring solution provider Netdata, the reason why open source has been so successful is because of the social aspect of it. Unlike proprietary software, it’s collaborative. It’s community-oriented and community-driven.

There are ways for a business to successfully use open source to their competitive advantage while staying true to the nature of open source, but open source shouldn’t be adopted just because it makes a company look good. “Your primary responsibility as a business owner, as a founder, as a manager of an organization, of a business, of a company, is not necessarily to open source. It is to your business,” said Brasseur. “If you are starting from open source and then trying to reverse engineer a business out of that, you’re coming at it from the wrong direction.” 

RELATED CONTENT: Making open source work for you and your business

A business should be looking at what the user needs, what the environment is they are targeting, what the trends are, whether or not they can meet those user needs or do it better than someone else, and then decide if it makes sense to use open source or release software to open source, Brasseur explained. If open source makes sense for the business goal, then companies need to put the effort into building the community around open source and understanding what the goal of releasing to open source is going to be. “If you don’t know your business goals, you won’t be able to maintain and guide that open-source project in a way that you can actually meet your business goals,” said Brasseur. 

According to Sacha Labourey, co-founder of enterprise software delivery company CloudBees, there are a number of models and tools today to make sure organizations are able to properly manage and govern the use of free and open-source software (FOSS). “We talk a lot about FOSS, but the reality is that it has been incredibly stable in how it operates and the value it provides. What has really been evolving fast are the various business models around FOSS,” he said. 

One of the best and most proven models out there is the open core model, according to Schumacher. In the open core development model, vendors open-source a portion of their software, but surround it with proprietary offerings. While it is valid from a business model perspective, Red Hat’s Haff noted that it’s important to recognize the open core model makes things a lot harder for the community to do collaborative open development.  

It takes a lot of time for people to figure out how to use the code, set it up properly and then maintain it, explained Angie Byron, core co-maintainer of the Drupal project, an open-source web content management framework. What companies like Acquia, a digital experience platform built around Drupal, and Red Hat do is provide a cloud platform that takes all the guesswork out for users and provides users with professional services and a support system. 

When projects and vendors commercialize open source, they have to understand there are various levels of commitments and contributions they are going to get from the community. It’s not always about code contributions, Schumacher said. There are other ways the community can help out;.for instance, by doing testing, quality assurance, performance testing, bug reports, feature requests, forum contributions, meetups, and sharing best practices and pitfalls.

Giving back to the open-source community

Technology giants like Google, Red Hat and others have been the most successful in the open-source world because they embrace the developer. “The love of the developer, the understanding that the developer is the set of ground troops that takes the technology into a particular enterprise, ingrains it into the lines of business, then it begins to bubble up to the higher-ups who see the benefits of what’s going on or just the proliferation of this software, and have no choice but then to make a commitment to it,” said Netdata’s Schumacher. 

A successful open-source vendor will provide a very smart and qualified developer relations staff, he explained. “You are going to need people who understand the spirit, mindset and everything of the developer community, of open source in general…” he said. 

Schumacher has three pillars for a successful developer relations staff:

1. Community managers who are active in the industry and evangelizing the software, participating and scheduling meetups and events, are present on social media, and are broadcasting the benefits of projects to the open-source community
2. Skilled technical members who are responsible for helping the community implement the open-source software and providing best practices, jump-starts, sample apps, and code contributions
3. Lastly, you need an educational aspect that goes beyond how to use the software and talks about the next steps in terms of how to utilize the software to the user’s advantage. This area should include videos, written content and other resources to provide users with a pass to success. 

“The developer relations staff is absolutely critical for any vendor that wishes to work with open-source software, commercialize and be successful,” said Schumacher.

However, author Brasseur warns that while developer relations and open-source program offices can be beneficial, you have to make sure you are hiring the right or qualified people. “There are great people out there for this, but there aren’t nearly as many experienced people for this.” You can’t just hire internally because a developer contributed to an open-source project once, she explained. 

Other ways organizations can give back or get involved in the community include getting involved in industry initiatives or open-source foundations. Organizations “have to change their mindset from, we’re just going to develop what we think we need to be competitive to let’s help develop what the industry needs,” said Eric Newcomer, CTO at WSO2, an API management company. “One of the reasons open source is so successful is because people can collaborate on a shared vision of a common problem that everybody has.”

It’s not as easy as telling organizations to give back though, Drupal’s Byron explained. She said you have to incentivize companies to give back.

At Drupal, the project created a contribution record where contributors and committers can show how they are helping to sustain the project and the Drupal Association. “Hammering on that is probably the best way to do it because companies are probably not going to contribute out of the kindness of their heart. They need to have an incentive that matches with their return on investment,” Byron said.

She also explained that contributing to open source not only helps solidify an organization as an expert in their field, but it helps gain and retain talent because many developers want to work for companies that make time for open source. Contribution credits can help weed out the true open-source experts from the pretenders. “If you are selling yourself as an AWS vendor, but you have no record of ever contributing to anything around the AWS ecosystem, it’s sort of like, well did you just take a test and now you’re calling yourself an expert versus if you can see the trail of this person making contributions, writing blog posts and such, it’s easy to choose between the two. One is literally establishing themselves as an expert,” Bryon added.

The challenges facing open source today

Vicky Brasseur, author of the book “Forge Your Future with Open Source,” sees three main issues plaguing the open source landscape today. 

1. The influx of open-source projects: According to Brasseur, there has been a flood of new projects being released. While that can be a good thing, it can also be problematic if organizations are just releasing things into open source to be trendy. She explained it makes the signal-to-noise ratio off-balance and makes it difficult to find useful projects. “It’s contributing to this age-old problem of reinventing the wheel, rather than perhaps contributing back to the existing wheel that’s already there,” she said. It’s tempting to want to release something rather than contribute to something, but you don’t necessarily have to start everything from scratch. Support what’s already out there, fork it, or take it into a different direction, according to Brasseur. 
2. Lack of knowledge: Knowledge should go beyond just the definition of open source and free software. Businesses and developers need to understand the copyright and licensing details that go behind open source. Developers that “play fast and loose” with the laws, Brasseur said, make it difficult for companies to use their software because they have to take the time to figure out what the license is and how they can use the software. Too many hours are wasted just talking about and chasing down licensing information.
3. Monocultures: Brasseur sees a number of monocultures plaguing the open-source ecosystem through fiscal sponsors, tooling and foundations. “These monocultures are a problem. All you need to do is watch Twitter on any day when GitHub is down. All of open source screeches to a halt. That is a huge problem. People equating open source with GitHub, that is a problem… I like GitHub, they do good things, but from an ecosystem point of view, that’s a problem. Projects that assume the only place I can go to have somebody support me from a foundational level is the Linux Foundation, that is a problem. There are lots of different options. The Linux Foundation does a very good job in many ways, but it’s not the be-all and end-all. Companies that think in order to participate in open source, I have to pay to become a member of a foundation, that is a problem,” she explained.  — Christina Cardoza

Open-source software in the enterprise

Red Hat’s 2021 State of Enterprise Open Source report found 90% of IT leaders are using open source in the enterprise, and 79% expect their use of enterprise open-source software for emerging technologies (edge, IoT, AI and ML) to increase over the next couple of years. The main drivers for adopting open source are infrastructure modernization, digital transformation, higher quality software, access to latest innovations, and better security. 

This year, the company decided to ask respondents whether or not they look to see if a vendor contributes back to open source when looking to implement a new solution. Surprisingly, the report found that IT leaders not only care, but they are much more likely to choose a vendor who contributes. “That means the IT leaders are starting to appreciate the virtuous cycles that you have in open-source development,” said Gordon Haff, a technology evangelist at open source company Red Hat.

But barriers still remain with respondents citing level of support, compatibility, and lack of internal skills as top challenges to adopting open source. 

Software solutions provider Perforce, which recently released a report on open-source opportunities with Forrester Research, believes that while open source has cemented its role as a critical agenda driver in the enterprise, not enough organizations are taking the necessary steps to optimize their OSS strategies. 

“Without comprehensive and optimized strategies that govern the critical pillars of running OSS, organizations risk missing out on the benefits it can deliver, including greater flexibility and better efficiency, time to market for products, customer and employee experiences, and more,” the report stated. 

While free and open, open source can be complex and require expertise to maintain, support and operate. According to the Perforce report, it’s important to partner with industry leaders to maximize open-source success through migration help, ongoing management and support. Additionally, an open-source strategy that can clarify the open source initiatives, governance, role of internal resources and external support can help pave the way for open source in the enterprise. 

“Finding success with open-source software as an enterprise organization requires a fully formed strategy – especially as it applies to critical areas like support,” said Rod Cope, CTO at Perforce Software

The post Open source is a community, not a brand appeared first on SD Times.