Ballroom H Sunday Mar. 08 - SCaLE 23x

This talk explores the evolving power dynamics within open source projects, particularly highlighting the impact of major cloud providers and the phenomenon of "rug pulls". The speaker delves into how corporate interests influence project governance and sustainability, often leading to licensing changes that affect both contributors and users. They discuss case studies, such as MongoDB's shift to a more restrictive license, which serves as a key example of how initial community trust can be undermined by commercial pressures. The talk emphasizes the importance of understanding project governance, contributor diversity, and the implications of corporate ownership in sustainable open source development.

Can you hear me okay with the microphone? Okay. How about this? Can people hear me okay with this one? Okay. Check check check check. Okay, in an effort to start on start, let me just say a lot of data and link uploaded both to the speaking page of fast is my website and they're uploaded to the scale presentation. So you've already you already got the slides, they've

got the links. Um yeah, so and power dynamics and power imbalances are everywhere including our open source projects and we're all impacted by these power dynamics whether you contribute as an individual or whether you contribute as part of your job. And this talk is going to cover how rugps and contributors we embrace. So I've built a decades long career at companies like VMware and in so there

is there but rather how we use work more sustainable over those. The metrics to improve our work in open source. how the stand these power so that we can mitigate the risks associated with those dynamics. Today I will start by talking about how the power dynamics in open source have been changing with the proliferation of cloud computing and the large cloud providers along with how those power

dynamics change during rugples, forks and other disruptions. And then I'll dive a bit deeper into different types of rug poles and their outcomes, including a bunch of data about rellicensed projects and their forks. And then finally, I'll talk more about what we can do when we're selecting open source projects to minimize our risk and hopefully reduce disruptions to our work. So, we'll start with of the people.

protection. But they served under who could take away this power, no power or autonomy despite doing most of the real work. Now consequences are less extreme, but with the rise in popularity of the the open source power case we have ways to then flip that power dynamic. So here at the top we have the cloud providers with into the cloud it's become really services provided by the

cloud providers and if you need some piece of open source software you can probably cloud providers like a software and they probably have a service that you can use to create it if that's for open source projects sometimes will very little those projects. So this tends to then upset who have less power than the big cloud providers. Um and some but not all of There's a lot.

It has full battery. All right, I will I will No, it seems to be dropping in and out, isn't it? How about this one? Okay, I'm gonna try this one instead. Um, okay. So, one thing that makes these power dynamics a bit fuzzy is that many of these companies actually fit into multiple categories, right? So for example, cloud providers are also users, contributors, and maintainers of various

open source projects. And I'll talk more about this when we talk about forks. So uh this is just like it sounds, right? Companies pull the rug out from under the rest of us when they use open source to build a user base and a community before making a power play and then doing something like relicensing or otherwise disrupting the project. Open source projects that are controlled by

a single company have a higher risk of disruptions over the long term because they operate at the whims of the company holding that power and there's little recourse for outside contributors or users with less power when the company decides to go in a direction that doesn't align with the expectations of the other participants within the community. So for company originated open source projects, you can consider the

reputation of that company as a steward for open source projects. However, while you might think that a company is an excellent open source citizen and that their projects are unlikely to be relicensed or forks forked, always keep in mind that companies can change direction with little or no notice. Uh you also never know when they might be acquired by a company that isn't very open source friendly

uh which I'll talk about in a little bit. And companies can also change their strategy at some later date. And it's possible also that a company could just go out of business and abandon their open source projects. So projects are much less likely to be disrupted by rugpoles if they're under neutral, well-run foundations because those foundations encourage governance structures that create a level playing field where people

from a whole bunch of different companies can work together as equals to create something that benefits everybody. However, there are still examples of rug pulls for projects under neutral foundations, especially when most or all of the contributors are from a single company, which I'll also talk about later. Now, the power dynamics are quite a bit more complicated than the pyramid diagram that I showed at the beginning

because companies also need to answer to their investors, their boards, their stakeholders who are in a position of power over that company. whether it's a small company or even a very large cloud provider. And lately, some companies have experienced a lot of pressure from their VCs, their shareholders, their other investors to relic their open source projects to generate more license revenue. Especially when a vendor's revenue streams

rely solely or mostly on an open source project, their investors and shareholders become concerned that the vendor is not making as much profit as possible from the project. And this can be compounded if other companies, often the large cloud comb uh large cloud providers are competing for the same customers and profiting from the open source project that the vendor has put a bunch of resources into developing.

And these concerns about profitability lead to pressure from investors to put the open source project under a new license with more restrictions. Um more restrictions than would be possible under an OSI approved open source license. So these restrictions often make it more difficult for cloud providers or other companies to profit from the newly relicensed open source project. In several high-profile relicensing events like the ones from Reddus

and Elastic, for example, in the relicensing announcement, they mentioned that they were finding it difficult to sustain the company while the cloud providers were profiting from the work and taking business away from the smaller company that was driving the open source project. Now, this flips the power dynamic and increases the power associated with the smaller company while decreasing the power of the cloud providers. But this is

not the end of the power dynamic flip which you'll see when I talk about forks. Now the disruptions caused by rugples can result in forks. But we're going to go on just a a little side quest here for a quick overview of what I mean when I talk about forking. So in the days before GitHub, forks usually referred to hard forks, also sometimes called hostile forks or

variant forks. And these hard forks are created with the purpose of starting a new branch of development that diverges from the original and often competes with that original project under usually a new governance model for the fork. Now, hard forks are in contrast to the social forks popularized by GitHub, which is when you click that fork button on a repository. And those social forks are often used

for collaboration uh while someone is contributing back to that original project upstream using something like a pull request model. So I'm focused on hard forks. So throughout this presentation, all references to forks are hard forks until near the end when I have one slide about GitHub stars and social forks. Now, these hard forks are a form of rebellious collective action that flips the power dynamics in the

pyramid and allows those of us with less power to take control of our own destiny by taking back control of our open source projects in the form of a fork where we control the governance of this newlyformed project. However, it's not it's not nearly as simple as all of that, right? Forks are very hard work. So while you often hear people say that well anyone can fork

a project and run with it, it takes a significant amount of people and resources to make a project including a fork successful. And often those people and resources are often provided by some of those very large cloud providers. So I mentioned that a smaller company can rely an open source project to flip that power dynamic and gain power back from the cloud providers. But those cloud providers

can also flip that power dynamic again by forking a project and gaining their power back from these smaller companies. And this works this works pretty well, frankly, because these large cloud providers can often put a significant number of people and other resources into making a fork So, now that we've talked about the power dynamics, let's do a deeper dive into rug poles, including the forks and disruptions

that result from them. So you'll see how the power dynamics play out in a few different scenarios. So one of the most common rugpole methods over the past few years has been rellicensing open source projects. So the companies controlling these projects used open source to grow their user base and as a way for projects to become more widely used and popular. Then they moved those projects under

nonopens source licenses. So in the three cases on the slide, the result was rebellious collective action by users and one case contributors coming together to create a fork of the original project. And I'll talk about each of these examples on later slides. So I'm not going to cover them in detail here. But the important thing to remember is that rug poles are often related to licensing, not

always, but they also have consequences in the form of the forks that result. For now the research that we've been doing within the chaos project is focused on the rellicensing events that resulted in a fork of the original project. But it's important to remember that not all rellicensing events and not all rugps result in a community fork. So MongoDB for example, they created the serverside public license

and it kicked off this recent wave of relicensing events but didn't actually result in a community fork because MongoDB created the serverside public license the SSPL. There was about a say a fivemonth period of uncertainty after they relicensed MongoDB in October 2018. while we all waited to find out if the OSI would accept the SSPL as an open source license. Now, uh in March, so about 6

months later, 2019, it became pretty clear that the OSI was not going to approve it. So, uh MongoDB withdrew their request to have the SSPL approved as an open source license by the OSI. But what this effectively did is this created a cooling off period that the other companies who relicensed to the SSPL later didn't have the luxury of. So, but there are companies like Perona and

Microsoft and Amazon who were able to continue to serve their customers with alternative commercial services instead of community forks. uh in Perona's case they actually had a fork but the fork was also under the SSPL so it also wasn't really open source but it gave them an opportunity to serve their customers and the case of Amazon and Microsoft they created service services with MongoDB compatibility so again

continued to serve their customers but not with a community fork now the uh Perforce Puppet rugpole is really interesting um and not just because I used to work at Puppet many years ago before this actually happened. Um, but it it wasn't technically a relic license, but it had effectively the same result. So, uh, Perforce acquired Puppet back in 2022, but announced in November 2024 that it would

move binaries and packages developed by the team into a private location, which they they claim it's for security and stability reasons. Sure. Um, in the announcement they spent quite a bit of time explaining how this was not a relic license. Um, but they also said that they were going to be slowing the frequency of source code contributions back to the public repository. So, they were effectively moving

their development behind closed doors. But, you know, again, it's not technically a relic, but as you can imagine, this resulted in a similar scenario with a fork called Openox. And in open box the users and contributors are taking the power back after that perforce rug pull. Now uh for years Bitnami images were sort of the de facto method of running many of the most popular applications on

top of Kubernetes. The images were free to use. They were wellmaintained. They had sensible defaults um easy Helm installs. So these Bitnami images were actually baked into the deployment automation for a bunch of companies and open source projects. Now the source code remains available under an Apache 2.0 license. So these are still open source but what people were using were the container images and in short people

trusted Bitnami to continue providing this service. Now, Bitnami was acquired by VMware in 2019 and Bitnami continued to provide these freely available images to the community. Then VMware was acquired by Broadcom in 2023 and Broadcom has made a whole bunch of changes uh to how the VMware products and services uh were monetized. And in August 2025, they announced that if companies and open source projects wanted to

continue getting the images um yeah continuing continue getting images with new releases, new versions, security updates, they were going to have to get a Bitnami secure images subscription. They also at the same time conducted a series of brownouts where they removed images for a 24-hour period to raise awareness for the change. Uh but the brownouts and these restrictions essentially broke builds and releases uh causing quite a

bit of disruptions as quite a bit of disruption as companies and open source projects then scrambled to implement some sort of alternatives. Now, like with the puppet perforce example, this is one of those cases where many people relied and trusted a company because they were good open source citizens without necessarily considering what might happen if that company was acquired by someone who wasn't nearly as open source

friendly. Now, this is the same pattern of putting release images behind a payw wall, but it's different from the previous examples. So for starters, linkerd is a CNCF project. So it's a project under a neutral foundation. um all of the maintainers work for Buoyant. So the governance isn't really neutral. So So here's what happened. In February 2024, the CEO of Buoyant announced that they were putting stable

release images of the open source linkd project in the hands of the vendor community. The vendor community. So in other words in the hands of buoyant. So in this case everything everything else stays open. So they continue to make source code releases. They continue to do the development in the open but the packaged images are only available to their paying customers. Um interestingly enough at the time

the CEO of Buoyant made this announcement on behalf of the project. Uh he wasn't actually listed as a maintainer or as part of the linkard governance. Um despite making this announcement on behalf of the open source project. So, as I mentioned earlier, this is a CNCF project. So, the CNCF got involved, but the biggest change they really made was to insist that if the CEO was speaking

on behalf of the project, um that he needed to actually have a formal role in the project. So, what they did was they created a director role for him within the link governance. Um and the director is elected by a majority vote of the maintainers, but again, all of the current maintainers work for the company. Um, and then in October 2024, the CEO said that the change

has been a success for the company, allowing them to double their recurring revenue and become profitable. Um, and to their credit, they did use some of that money to hire additional maintainers and support staff for the open source lingard project. But what this does is this highlights one of the biggest issues in foundation projects, which is getting organizational diversity within those projects that are donated by vendors.

So this is a complicated problem that I I don't really have time to address in this particular presentation, but the reality is that if a company is staffing a whole bunch of people to work on a project, then those people tend to get to make the decisions on the project. And while the governance documents, including the ones for linking, encourage other people to get involved, sometimes no

one else has stepped up, maybe because the contributors don't really they sort of feel like outsiders and they don't always feel welcome when all of the other contributors work for the same company, which puts projects into kind of a chicken and egg situation when it comes to recruiting outside developers. Now, open source projects are pretty complex. No two are exactly alike. So throughout the rest of this

presentation, you'll see that different types of open source projects experience different impacts depending on the situation surrounding the fork and the I'm not going to go into a ton of detail on this slide, but you can find all the data that I'm going to talk about today in the chaos repository linked from this slide. And uh, of course, we welcome feedback and contributions. If you want to

dig into the code and the data, it's all there for you to have a look at. So a lot of the data is stored in in GitHub using Jupyter notebooks. Uh but you you don't actually need any data science skills or frankly even programming skills at all to understand the notebooks. This is the thing I love about Jupyter notebooks is that you can you can just sort

of ignore the code and just look at the the text and the output and you can get a pretty good feel for the results. Now I will start by saying there is no perfect data to understand the impact that employees have um especially employees of particular organizations that they have on an open source project. So the goal of this research is not to not to have perfect

data but to get a sense or a feel for how employees of particular organizations participated in these projects. And uh frankly it can be pretty difficult to gather data about where people work. Um, so I think I've come up with a pretty reasonable solution by only gathering data about the most significant contributors. So, uh, I've defined that as those with 10 or more commits to some of

the bigger projects, elastic search, open search, and five or more commits for the smaller projects. And I was able to get employer I was able to figure out where people worked for the most of most of the significant contributors. And I filled in gaps by just talking to people who contribute in these projects who generally have a pretty good feel for where people work. So I used

I used numbers of commits as a starting point. Um but sometimes commits aren't a particularly good indicator of the amount of work. So uh most of the results also looked at numbers of lines added and deleted to get a better feel for the magnitude of the contributions. And I only focused on the primary repository for each of these projects. So there are loads of limitations but this

uh hopefully will give you a sense of of what's going on. Um but you know also anytime you're looking at open source projects so organizational affiliation data is important when looking at relicensing and forks. So I started with that um but there are loads of ways to contribute to open source projects. So you could also look at a whole bunch of other metrics um on GitHub off

of GitHub um for these projects. So I would say this is a Now let's talk about elastic and elastic search and open search. So elastic moved elastic search under the serverside public license. So again the license was created by MongoDB and they duallicicensed that with an elastic license. So these are not OSI approved open source licenses. So Elastic Search was no longer an open source project in

2021 when they relicensed. So as you'll see on the next slide uh almost all of the existing contributors to elastic search were elastic employees. So the relic license had little impact on contributors since there were just very few outside contributors. But there was a pretty big impact on some of the users of elastic search who had to decide whether they could use it under one of these

new licenses. And this resulted in a decision at Amazon AWS to fork elastic search into a new project called open search so that they could give their customers an alternative to elastic search. Now without a strong contributor community, there wasn't a strong contributor base to drive the fork. So while AWS had a few people who had contributed to Elastic Search before, they were mostly starting from scratch

with employees who were still learning the codebase. And it did take them a while to get something out and it was uh quite a bit of hard work actually. Now uh in this example I'm comparing the year before elastic search originally rellicensed. So during this first period the project was still under the Apache 2.0 license. So in the second and third periods of time the project was

under the SSPL and the elastic license. So this is during the period when elastic search was no longer an open source project. So you can see in the data that it made very little difference in this case because Elastic never really built a strong contributor base outside of the people who worked at the company. So in all of the time periods, Elastic employees were making 95 to

97% of the additions and deletions to the codebase with no more than three people from outside of Elastic making 10 or more commits in any given year. And it's not on the slide, but I also looked at six months after they added the AGPL. So when they became an open source project again, but at that point there were no non-emp employees with 10 or more commits, which

isn't surprising given that they didn't really have them before when it was an open source project. Now in this example, I'm comparing the early days of the open search fork, the first year with the final year of when open search was moved um from Amazon into the Linux Foundation and then six months after the move to the Linux Foundation. So I actually spent some time in the

open search community after the fork and it w and in that first year a lot of the work was being done within [music] Amazon. So while the code was public a lot of the discussions and decisions were still happening inside of the company. So it's not surprising that we see here in the data that most of the contributors in this first uh this first time period were

coming from Amazon employees. Now in the most recent years you can see that this has gradually shifted to bring in more contributors from outside of Amazon and they've made a lot of improvements in their governance that have allowed more people to contribute and that also then facilitated that move into the Linux Foundation which uh I think is a a great step for open search. It's also worth

noting that one individual from um Ivan made most of the non- Amazon contributions in all of these time periods but there were also significant contributors from others. So this this seems to be trending in a good direction from my perspective. I was a little surprised that there wasn't more of an uptick after moving it into the Linux foundation. Um which to me suggests doesn't prove but suggests

that starting a fork under a company and then moving it into the foundation doesn't have the same benefit as starting a fork under a foundation which you'll see in the next couple of slides. Now on the one hand most Terraform contributions were made by HashiCorp employees. So even when it was an open source open source project so from that standpoint the original project is kind of similar

to elastic search. Uh however you'll see that the fork is very different from open search. Um the open tofu fork was started under the Linux foundation. So from the start it was under a neutral foundation rather than being started by a single company the way uh AWS started open search. However, in other ways, it's a lot like the open search fork because it was driven by users

rather than people who'd been contributing to the original project. So, let's have a look at the data. Again, similar to the elastic search example, you can see that Hashi Cororp employees made almost all of the significant contributions to Terraform even before the relicensing with only one or two people outside of the company making significant contributions. So it's not surprising that the situation is the same after they

relicensed. Now Open Tofu has contributors from a variety of companies with Spacelift employees making the most significant contributions. However, it's interesting to note that none of these contributors contributed to Terraform before the So like with the open search example, these were contributors who had to learn the codebase. Now this is in contrast to Valky which I'll talk about on the next slides where over a dozen contributors

move to the fork. So this example is very different in many ways from the ones I just just talked about. So in this case there were a lot of contributors to Reddus who were not employees of the company. So when Reddus moved to non-opensource licenses these contributors forked the project and started a brand new project called Valky. So this new project like open tofu was started under

the Linux being started by a single company. And even though Valky is a relatively new project you can really see how it's different than the previous examples which we'll see in the next couple of slides. So again where the Reddus project differs from Elastic Search and Terraform is in the number of contributions from people who are not employees of Reddus. So in the year leading up to

the relic license while Reddus was still open source there were substantial contributions from employees of other companies with twice as many non-emp employees making five or more commits. So Reddus employees had more additions and deletions. Um but I looked at these and they were inflated by u a couple of PRs with uh very large change sets um due to how they merged and created releases. Um, but

you can see that employees of other companies made almost twice as many commits from about a dozen people. In the year after the relic license, all of the external contributors uh from companies like Amazon and Alibaba and Tencent and Huawei and Ericson who had contributed over five commits to the Reddus project license, they stopped contributing. Uh there were a couple of commits after the relic license uh

which looked like work in progress that just got merged after the relic license but all of the contributors who made five or more commits after the relic license were Reddus employees. Now Valky had 52 people employed at 13 companies in the first year of the fork and 22 of those people previously contributed to Reddus and are now contributing to Valky. So there are contributors from a variety

of different companies with Amazon having the most contributors. The Google data is a little bit misleading because while uh Google employees have made a large percentage of additions and deletions, uh most of those changes can be attributed to two PRs which were uh related to formatting changes. Um but there are also lots of contributions coming from companies like Alibaba and Ericson and Samsung. Uh, first of all,

I'll say I'm actually not a fan of stars and forks. Um, but because it's almost impossible to accurately measure the actual usage of an open source project, um, there's some research that Sophia Vargas and Gayorgink and others um, did that found that there is a strong positive correlation correlation between usage and GitHub forks and stars. So, this is not perfect data. Um, I'm actually not even a

fan of this this type of data, but I do think it highlights a few trends. So, after the relicicensing event for projects moving to a non-opensource license, the number of new GitHub forks and stars were at a slightly lower level than before for all of the relicensed projects, which indicates that slightly fewer people were interested in contributing to and using these relicensed projects. And when comparing the

relicens project with its hard fork um that were started uh yeah the the hard forks that were started under foundations actually have more new stars than the original relicens projects. So again this data is not perfect. Um but it does indicate that both the original project and the hard forks continue to exist together with both projects being used. However, the relicensed projects likely have a slightly reduced

usage due to some users switching to the forks and this is more pronounced for the forks that were started under a foundation. So, what can we do? Right? These rugps and power dynamics create significant issues for those of us who use and contribute to these projects. And as maintainers, contributors, and even users of open source software, we devote our most precious resource to these projects. We devote

our time And we need for projects that we spend time on to be sustainable over the long term to avoid wasting this most precious resource. And there is there is unfortunately no way to predict which projects will be sustained over time versus the ones that might experience a rug pull. But there are some warning signs and there are some things we can think about before deciding to

spend too much time on a So before I start the slide, I am I am not a lawyer. I'm going to gloss over the details because you should talk to an actual lawyer about how this works. But there are things that can increase or decrease the likelihood of a rugpole when a project is owned by a company. So contributor license agreements, CLA's create a power imbalance between

um they they create a power imbalance within an open source community where the power is tilted toward the company who owns the project and controls that contributor license agreement giving the company more power than other contributors. So for example, the power to rellic. So when projects use CLA's rugples are more common. It's worth noting that Elastic Search, Terraform, and Reddus all had CLA's. Uh projects that use

a developer certificate of origin, on the other hand, don't suffer from this particular type of power imbalance. That's not to say that there might not be other types of rug pulls um with projects using a DCO, but they aren't likely to result in a relic license. Um the type of license might also um influence certain types of rug poles. Um, that's definitely a question for an actual

lawyer. So, I'm just going to I'm going to move on before I get myself in trouble. Um, so I talked earlier about how rugpoles and power plays are more common when a project is controlled by a single company, as we just saw in several examples. So, one way to make better use of our time is by supporting projects that are under neutral foundations whenever possible. So the

CNCF, the Linux Foundation, um the ASF, Eclipse, those are all lovely neutral foundations. Um experience rugps if they're under everyone. But it's not enough just to focus on projects that are underneath. You also need to look at project governance. So while it isn't as common, rugpulse can and do still happen to projects under neutral foundations when usually when all or most of the development is coming from

the employees at a single company. So I talked earlier about linkerd but there are a handful of other other examples as well. So it can help to look for neutral governance where leadership positions and maintainers come from a wide variety of different organizations with a fair and transparent process for selecting those leaders. This creates again a level playing field where we can all participate as equals when

neutral governance is combined with neutral ownership of projects under foundations. Now I talked about neutral governance but we should also be thinking about contributor sustainability in general. Does the project have enough contributors to sustain it over time and replace the existing maintainers when they move on to something else? So for the open source projects we rely on, are there enough contributors that if one of them retired

on a beach tomorrow with no notice, could the project continue with minimal disruptions? Now, this leads directly to how organizations can help the open source projects that are important for them. I've talked a lot about the power dynamics, but companies and other organizations also have the power and resources to make real improvements and their their involvement can positively impact the sustainability of our open source projects, including

the forks. OSOs, for example, can allocate time to contribute to projects to provide funding and other other resources to help sustain those open source projects. Having people affiliated with your organization working within a project helps you understand the power dynamics that might be at play and better understand the strengths and weaknesses of that project uh while also being able to influence the project from within. Now there

are loads of other ways you can think about this the sustainability of a project and find ways to improve that sustainability from within for the projects you use. So, some of you may already be familiar with the Chaos Project. Uh, we're a Linux Foundation project. We have a series of project viability metrics models that were created by Gary White at Verizon. Um, and they can help you

think about which projects you should spend time on and which ones might not be viable over the long term. So, if you're deciding whether to embrace a project and want to dig into more details than what I just covered, uh, that would be a good place to start. And we also recently launched a practitioner guide series. So each guide is focused on a single topic. But the

real value of these guides isn't actually in the metrics despite being what that's what chaos is focused on. But the value in the guides is how to make meaningful improvements within your open source projects across several several key areas which are listed here. So if you're looking for additional ideas for improving your projects, the guides are a good place to start. We also have a practitioner guide

about assessing viability that's based on the metrics models that Gary developed. Now, as I mentioned at the beginning, the slides are already uploaded both to my personal website and to the uh scale schedule site. So, I'm not going to spend any more time on this, but you do have these resources and links later. Now with the rise in popularity of large cloud providers, the open source power

dynamics are looking kind of similar to that feudalism example that I talked about in the beginning of the presentation. But in our case, what's different is that we have ways to shift those power dynamics. A smaller company deciding to move a project away from an open source license can flip that power dynamic and gain power back from those large cloud providers. But they also shift the balance

of power further away from contributors and users at the same time when they decide to relic that project. So this encourages those who now have less power to take rebellious collective action to fork a project which again flips the power dynamic in favor of the contributors and users often including those large cloud providers as users. Now, as I mentioned earlier, there is no experience rugpoles, but we

can think about the risks and use that information to more carefully select projects. So, projects with CLA's that are owned by companies will be a higher risk than projects under foundations with neutral governance. We can also contribute back to those projects that are most important for us to help reduce those risks. And if a rugpull does occur, we are so much better off than those peasants and

surfs that I talked about earlier because we do have certain freedom that allows us to take rebellious collective action and gain power back um by forking projects when others abuse their power. So, a couple of quick thank yous before I open it up for questions. I wanted to thank the Alpha Peace Loan Foundation. So, they've funded the Chaos Data Science Initiative. I also want to thank Matt

who's been working with me on some of the relicensing and forks research um and uh he's my co-author on some papers that we're working on related to this topic. So with that I will say thank you and see if there are any questions. So, kind of continuing on with your final thought there, one of the things I've been wondering really since the latest spate of rellicensings where

everybody just kind of threw up their hands and went, "Well, they can do that legally because they have a CLA." When do we start to see open- source uh authorities like OSI start to say, "If you have a CLA that allows rellicensing to a non-opensource license, then we don't care if the license is open source. the existence of that CLA means your project is not >> Oh,

that that question feels like a political landmine that I'm a little I'm a little afraid to I'm a little afraid to address. Um I would say that that yeah uh you know that the OSI I don't think is in a position to enforce that. They, you know, they have a list of approved licenses and then people kind of do what they want with it. Um, I think

it's really up to the rest of us to sort of, you know, I don't know, put our I don't know what's what the expression is. Uh, >> what? >> Vote with your feet. Yes, exactly. So, uh, the rest of us can vote with our feet. We can, um, participate in projects that aren't owned by companies under CLA's. We can try to use projects CLA. And so I

think I think that's probably about about all we can do at this at this point. I don't know that I don't know that anybody's going to step in and sort of enforce it, but I think that I think that we all need to be a little bit more diligent about which projects we spend our time on and which projects we support. Other questions? Yes. Did you try

to develop any metrics the pos >> Can you hold it closer and louder? >> Oh, right. It's working. Yeah. Did you Did you try to develop any metrics for the abuse of that position of employing most of the contributors um in in any of these any of these projects? I mean we we know that in some cases projects which would have threatened the enterprise version sorry patches

which would threaten the enterprise versions gets sand adbacked. Did you try to measure that at all? >> No. Um, no. Frankly, there was just a lot of a lot of stuff to look at. And so, I started with with organizational affiliation. And that's kind of where um and and this is probably where I'm going to end this particular research. Um, but it is all under the chaos

project. And so, if somebody else wanted to pick it up and look at a bunch of different different metrics and look at it in different ways, I think that would be I think that would be super cool. Um, because there's there's loads of data you could dig into on this. You could look at there are lots of other metrics you could look at. You could include more

than just the primary repository which I think would tell you a very different story in particular about projects like open search where there's lots of stuff happening in and around that main repository. So I think there's loads of stuff to look at that would shed really interesting insights on this whole phenomenon. I just haven't had time to do it. Uh, can you talk a little more about

the a little more about the um collecting of which company everybody's from and like how many commits everyone has seems pretty interesting if you're looking for different projects to contribute to, but how automated you can make that. Uh yes uh the the answer is um not very automated. So uh the number of commits and the number of lines of code um that came directly I wrote GitHub

GraphQL API queries to pull that data. So that came directly from the GitHub API. So I at that point I had a GitHub user ID um associated with numbers of commits and lines added and deleted. And then from there, what I did was I was able to automate some of it because um one of the things you can look at is the the company that they currently

work for that they have in their GitHub profile. Um but most people don't fill that out or it's filled out very inconsistently. So there was a fair bit of data cleanup because um I work for Elastic. I work for Elastic Inc. I work for Elastic BV, which is the Netherlands one. Um and so that data was particularly messy. Um the other thing I used was and because

everything was associated with a with a GitHub ID um I basically looked for any commit through um you know the whole time periods that I was researching from a corporate email address. So if they had any commits not just the individual commits that I counted um from a corporate email address I basically said that they worked for that company. And because these were very um corporate projects

um there wasn't a lot of job change data. So what happened when somebody left Elastic for example um they generally stopped contributing to the project. So that was one thing that I I didn't really have to um consider because I did look at that and I didn't really see people staying around in projects after that. Um and then what I did so that was the automated bit

and so that that was all scripted and then I spent a whole bunch of time on LinkedIn. um and Google looking for people um trying to find out where they where they worked and then for the ones that I couldn't figure out that way I reached out to the people that I knew within those projects and said hey do you know where this person works um so

it was a very very much a manual process and this is similar so I when I got my PhD a couple of years ago I studied the Linux kernel and I looked at um how people collaborate within the kernel and a piece of that is what company they work for and that data was much more messy because they do change jobs and they continue to work on

the kernel. So you see people jumping from Red Hat to Intel to you know LARO or some someplace else. Um so that that data was particularly messy but again it was spending a lot of time on Google and trying to figure out where people where people worked and looking at email addresses and commits and things like that. >> So a little late. So if you had did

you have a chance um you know for a rug? I work for an organization a par that focuses on higher ed and we see a lot of times student or research or academic sort of bottom up don't have much attention. The university seems happy to let them do whatever they want. company X comes along and the tech transfer office thinks that there's a, you know, an money

to be made. I was just wondering if you had any thoughts or uh in terms of things for uh from that. >> Um no I I didn't look at that because I was really only looking at elastic search open search reddus and valky and then terraform and open tofu um which are not the kind of projects that you you just talked about. So it was just just

not within the the scope of of what I was looking at. Um, but it would be really interesting to look at at that academic perspective because one of the things that we we know is that these academic projects are very different than than what you see in some of these vendorowned projects. And so the the dynamics are different and would be interesting. It would be interesting to

know more about how those dynamics are different. Another question in the back here. >> Stephanie's gonna get her steps in. >> I know. Thank you. I appreciate it. Were there any other metadata around the like the contributors before and after that were interesting? Like for example, country like where the contributions were coming from where maybe originally it was all like Silicon Valley, New York versus like afterwards

it might have been a more global effort or anything like any other metrics along like like the diversity of the contributors before and after the licensing change. Uh, no. I honestly I just didn't didn't look at that. That that would fall into the category of lots of other metrics that would have been interesting to look at um but that I just didn't I just didn't look at.

Yeah, that data is also very hard to get um because people don't consistently put things in their GitHub profiles. So, a lot of times it's planet earth or um you know lots of you get lots of crazy things that people put in those uh in their GitHub profiles. Um and then you know because of the way people use VPNs like even IP addresses it's really it's really

hard to tell where people are from in a lot of cases. It's interesting data when you can get We have time for at least one more question. You were talking about evaluating um projects that come from foundations as being better to contribute to. Um should we be evaluating the foundations against each other as well? For instance, for perverse incentives to to graduate projects. >> Um yes, probably.

Uh yeah, the foundations are the foundations are very different and the projects within those foundations tend to be um tend to be very different and some of them are going to be more more neutral than others. You know, one of the one of the dynamics that you have particularly in some of these very large foundations like the Linux Foundation, the CNCF, Eclipse, is that they're they're effectively

what what they call in the US 501c6s. So they're member organization nonprofits. um which means they're not charities. They are basically they get money from big companies who are their members and they are their goal as an organization is to serve their members. So these you know some of these big foundations they are they are neutral foundations meaning that they're not you know giving one company preferential

treatment over another but they are effectively serving these very large very large companies. And so this is in contrast to organizations like um uh like Apache for example. So the ASF is a 501c3 um and there are other organizations like the software freedom conservancy also hosts projects. There are other charitable organizations that host projects and those will those will tend to be more neutral. Um whereas on

the other hand like the CNCF those projects tend to be less neutral because most of them are contributed by companies and it's hard to get it's hard to get other contributors beyond that company that donated it to the CNCF and so you do see different slightly different dynamics in the CNCF projects. I will also while we see if there are any other questions, I have some chaos

that I 3D print chaos earrings down here. So, if anybody wants a pair of earrings, uh, help yourself for those of you with pierced ears. >> Any other questions? >> Pierced ears. >> Any questions? Anymore? um, you new work. You're you're still publishing stuff, but uh code approvals, who's actually approving the code is an interesting metric. I it seems probably you didn't look at it yet, but

>> um no, I did not look at that. Um but who is it who is approving the code is a particularly important metric. Um it's just a lot more it's a lot more complex to um to look at because you know when you have when you have GitHub approvals for example you sorry I'll back up when you have a pull request you might have you know depending

on the processes that the project uses so like Kubernetes I think it requires maybe two approvals from um from people or maybe three depending on depending on who they are and they're from different companies and so you have to kind of you know how do How do you weight that? And it gets it gets a lot more complex. I think it's important data. It's just not it's

not data that I looked at. >> I think that's it. Thank you, Don. That was great. >> Thanks everybody for coming. Check. Check. You want to put it in your back pocket >> whatever. >> One, two, three. One, two, three. >> No. No. Thanks. [snorts] >> Mhm. >> No, I just >> I can probably roam around and >> but if you want to like me to repeat

on the stream Okay. So, this is on as well, right? >> Hello. >> Cool. >> Thank you, sir. [cough] >> Nice. All right. Well, look at us. Uh last uh presentation of the conference at least on this track and still we have more than zero uh people which is great. Welcome everyone. Um let's start. So today's presentation uh is titled Enterprises Play uh Dirty. And before we

start um I will uh actually show you some disclaimers and not really the legal kind although it's that as well. But first of all I will be naming um companies. I will be naming companies that uh uh are deemed to be not playing fair with the open-source community and I want us to understand that there are lots of great people behind these companies, great engineers, even great

decision makers and it's probably not always it's not about the person, it's more about the organization itself and sometimes the circumstances. So um so I wanted to um I wanted to make sure that that we start uh with this uh with this uh thought. It's it's nothing personal. And the second one is more legal. Um this presentation could be pure fantasy. Uh it's merely a product of

my imagination. you know facts that are presented might not uh be uh actual facts they might be totally made up I may even be insane we don't know um but the first and foremost no one especially lawyers should take any of these things seriously and of course we are going to talk about licenses and this is not going to be legal advice so um [clears throat] just

as a short intro So my name is Peter Faros. I am the CEO of Perona. Who's heard about Perona before? Any Perona customers? Okay. So uh I'm the CEO of Perona. Previously [sighs] I uh uh worked full-time as a co-founder of Farad DB, which uh by the way uh was sued by MongoDB. And by the way, MongoDB is a trademark of MongoDB Inc. This is very important

stuff. Ladies and gentlemen, uh I've spent 15 years in the open-source database world. I'm uh Hungarian and uh I'm glad uh that I can uh present this talk to you uh today. So our agenda uh we'll talk about debate and switch. uh we will have some case studies Red Hat, MongoDB and several other companies who changed the license at some point and we are going to discuss

how it happened and what were the what were the general reactions from the community or why these changes might have happened. Uh I'm going to talk a bit about perona and how the community can fight back and then we will have a conclusion as well. So let's start. Uh this microphone is very distracting but yeah I just don't have the right ear for this. Um [clears throat]

so I think many as many of us would agree that for decades we lived in simple times. As for me, when I started using open-source technologies maybe like 20 years ago, my understanding of open-source was, hey, this is something free. This is something that can be used instead of um instead of buying a Microsoft product or buying an Oracle product or just generally committing yourself to something

you don't even know much about. Uh for me, open source was the vehicle of my experimentations. You know, this is how I learned a lot about databases, about operating systems. And I'm sure that on this conference, we all understand uh what this means. When someone started talking about licenses, I I was not even interested because for the most part in my mind, opensource is a social contract.

And the understanding I have is this. there's a vendor or a community that starts building great software, maybe not so great software, but software. And if that makes sense for uh some use cases, uh then the community gets built up around it and and it helps building the software and advoc advocates for for the project. And in turn, everybody benefits from from this. Today it's not as

simple. And this presentation is pretty much about this phenomenon where as for me, I no longer think about open source as something as um simple as these statements here because what is um really happening here? So for vendors, for those who wanted to make money or wanted a sustainable project because let's not forget in order to be sustainable, you somehow need uh uh flow of resources, money

or or engineering resources or other contributions. But for most vendors, open source is all about the bigger pie. So you create a bigger pie with the help of the community. you create something way bigger than you could by yourself. Um this could be a result of uh others contributing to your code or just the adoption which comes from the trust the trust that this is open source

software and if there's a big enough community around it then then then it will be it will be uh something that you can you can you can build on in the future. And then these [clears throat] open source vendors would monetize a fraction of the pi. Um so of course with open source the expectation that I'm going to build something which is going to run on everybody's

phones or everybody's computers or be part of uh every infrastructure around the world running XY Z is not realistic. The understanding is that if you market your solution as open-source, then you're going to a small fraction of the II. But that's fine because what you realize hopefully is that even your slice would be even the slice you can monetize would be way smaller than if the than

than than if you um wanted to build uh the whole thing without the community and then you thrive. Then you monetize 5% 10% 15% of the users of of your solution and and done with it. This this is the this is the open-source way except that the part where you thrive is nowadays being replaced with trying to eat the whole pie. So if we look at uh

all of these uh companies or some of these companies, what we can find is that um they were all pioneers of their own um of their own uh uh areas. they either provided something entirely new to the market or they provided an open-source alternative like uh like Mo uh to something that was widely available as a proprietary product which is great. However, when their followership, their market,

their user base starts growing, they realize that, hey, if everybody uses our solution, if there are hundreds of millions of users around the world using our stuff, then how come we are not a 75 billion company? How did that happen? And this thinking slowly but steadily, I believe, pushes them into a situation um they might uh part ways with their open source strategy believing that what h

what is happening to them is not fair. that their their ability to monetize only 15% of their user base is not something that that could um that could put them on a trajectory which is sustainable. some companies are a bit more straightforward with uh this uh uh understanding. Let's look at Dev It E Iteria, the former CEO of MongoDB. And by the way, MongoDB of course is

a registered trademark of MongoDB Inc. very important, ladies and gentlemen. Who said we didn't we didn't open source it to get help from the community to make the product better. We open source as a premium strategy to drive adoption. And this quote is powerful because it allows us an insight into how companies and even startups like what MongoDB was back then think about open source in general

and think about what opensource is good for from their So after such a quote we can't just say hey we needed to change the license because it was no longer sustainable. What we can say is that they willingly went into this whole thing knowing that open source is just a vehicle for them to drive adoption so they can pull the rug later. The problem with this free

model is that it almost always ends with broken promises. So the premium model um has been sustainable for some companies for six, seven, eight, 10 years, but at the end of the day it almost always ended with uh crippled functionality, a change of license, change of terms and uh and things which we in the open source community did not appreciate at all. So let's look at the

first one, Red Hat. And this is this is uh uh I think one of the most interesting ones here. So when I think of Red Hat, I think of a company that pioneered opensourcebased uh distribution and and and a business built around open source in general. So for many many decades uh the deal was simple. Red had led the way with their uh with their releases of

the OS and then the community like uh uh CentOS or later Rocky and Amal Linux followed and it was a um a symbiotic ecosystem. Then in 203 in 2023 um after I think the IBM acquisition uh RED had decided to uh uh to put the source code uh behind a pay wall. So they didn't technically break the GPL. They didn't technically change the license, but they effectively

put uh the source code under a pay wall and made it impossible for uh community projects to build uh one-to-one compatibility with uh Redhead itself. What's worse though is that their communication um has been uh drastically changing over the years where words like freeloaders and other stuff was mentioned which the what I believe is that Rocky or Alma Linux are not clones of Red Hat. They are

choices for the community. They are choices for those who might have different needs or different environments or different situations that would make Redhead Enterprise well not a viable solution. And yet um and yet uh Red Hat uh decided that this choice should be taken away from the community which helped uh building Redhead's reputation and products uh for decades. So this is uh this is a um uh

a pretty uh interesting one in terms of the communication as well. So freeloaders were mentioned as a as a as a word. Um so companies like MongoDB or others would often claim that they are protecting themselves from hyperscalers AWS, Microsoft or or or even Oracle. But what needs to be said here is that these licenses and these actions would not just harm uh Amazon or Google. They

would harm the independent developments and uh developers and the internal platform teams probably even more than uh a large company with a with a lots of uh with lots of resources. Open source is not a business model. What we need to understand is open source is not a clear-cut plan for you to get rich with a with a very uh easy way of distributing your software. Um

if you need to change the rules in the middle of the match, that means that something is wrong with your thinking. It's not that the freeloaders, the community uh wanted to to do any harm to The second uh example I brought to you and this is very close to my heart. As I mentioned to you, Farad DB, my uh uh uh the company I'm a co-founder of

got sued by MongoDB after this license change. So MongoDB's path is even more interesting and it's interesting in a sense that they are the pioneers of the license change rockpool uh strategy. [clears throat] So what happened here is that in 2008ish they started developing these revolutionary NoSQL database and uh they became the number one NoSQL database open-source NoSQL database in the world and of course they felt

that if they are the most popular NoSQL database then they should be able to monetize maybe I don't know 80% of the pie or whatever. Um so after lots of developers decided to trust MongoDB as a product, MongoDB Inc. decided to change the license and it created and adopted the serverside uh public license which requires anyone offering MongoDB as a service to open or SSPL or or

well open source their entire infrastructure stack management tools everything that is required to run MongoDB as a service which means that well It it ended up not being viable for many companies out there who built their infrastructure and the foundation of their um applications that required a very different approach compared to posgress or relational databases on MongoDB and then they ended up with something that is well

source available at at best. But MongoDB went further. So in the initial months or even years, MongoDB uh claimed that that the SSP license should be an open-source license. It should be approved by the OSI and it should be something that is as good or even better as uh legacy open-source licenses is funny uh because uh it does not comply with uh any of the requirements that

uh an open-source license should comply with in terms of um in terms of not discriminating against uh any specific type of workload or user and in this case the SSPL license would do that. So the OSI did not accept the SSPL license but MongoDB maintained that SSPL is going to be the vehicle which is going to make opensource sustainable and the keyword is always sustainability. Now when

it comes to MongoDB, it is now a 20 3040 billion dollar market cap company. So I think that we they are way uh uh far ahead of the sustainability question and still uh they release their software with the SSPL and unfortunately the MongoDB uh way of rellicensing became the blueprint for uh some other uh companies. and this is the fiction part. Um, so I wanted to give

you some insight into how this works uh in practice. Um, so you would think that something that was uh licensed with an open- source something that forever belongs to the community, at least the latest release or or or the concept. But in 2021, we decided to build an open-source alternative to MongoDB that is based on Posgress. And we implemented um parts of the MongoDB API um to

make posgress compatible with MongoDB workloads. And MongoDB's reaction was uh vicious. So they sent season disease letters to us uh and even some of our users even users who did not know about Farad DB but learned about it uh uh from the letter MongoDB sent them stating that they don't approve this whole thing and that they they think that Farad DB uh is illegal. So they dragged

us to court on patent and trademark violations for Faradb calling itself MongoDB compatible. And meanwhile cloud providers like AWS or Microsoft uh and some others provided similar compatible products but they were not open source. So, MongoDB only attacked the one open-source project that implemented the API uh compatibility, which means that the their problem is probably more than just AWS or Microsoft. Um my personal opinion is that

their problem is that they want to monetize the entire pie and they don't want to let uh open-source projects or competing products to appear on the market unless these are sold by um companies like the hyperscalers who would otherwise be MongoDB partners as So this whole experience at least what it teached me uh is that going back to my one of my first slides um opensource is

not the same as it was 20 years ago. 20 years ago I don't think it would have been uh a legal risk for you to implement an open-source alternative to something. I mean at at the end of the day this is how Oracle started. This is how lots of large companies started uh that uh later thrived on the alternative they've they've uh built. But this is no

longer the case today. And another fictional part of this presentation is that someone suing you should not even be right. Their claims should not even need to stand in court because a billiondoll company is always going to be able to send you so many documents, so many letters that you will not be able to keep up uh if you are uh if you're a bit smaller than

a 2030 billion dollar So yeah, that's about MongoDB. Um, uh, Mino. as open-source users, you would think that, uh, how you, how you pick an open-source project as your next element of your stack would be, uh, the community response to it. Mino had uh, close to 60K GitHub stars. It had lots of followers, lots of contributors, I think a billion docker downloads and numbers that are pretty

impressive. And Mino as the company is also a member of the CNCF. Uh I personally met uh sea levels from Mino uh on various different open source conferences where they presented similar presentations as I do. uh when it comes to their belief in open source and and uh and uh and uh and the way uh and that the way is open. Now unfortunately Mo decided to transition

its licensing model from uh permissive license to AGPL uh in May 2021. And they stated that the reason behind this is because companies like Nutonics and Vea uh they would violate uh their attribution terms and uh and that some of these products are actually wrappers around Mino uh uh and [clears throat and cough] and after the license change uh they started uh complaining about some of the

users by name on their blog saying that they are ready to remove the apach uh to revoke the Apache license from these users simply because they don't uh comply with the terms of the license Now there is a huge debate on hacker news and other uh platforms on whether Mo is right or or not. One thing is for sure revoking the Apache license blogging about your users

specifically is not something we did 20 years ago uh in the in the open source uh open source community. um especially uh that this kind of legal shaming would not help the cause of Mino as an open-source project. So after this whole thing uh um um unraveled um Mino uh uh basically maintain the enterprise version and the community version uh in parallel but slowly and steadily started

removing features from the community edition. So what was a full-fledged UI to manage your OB object store uh quickly became something very crippled on the community side and after I think a year or so they uh abandoned the repository completely and nowadays Mino is uh a product that is only available to you uh for uh uh uh after paying a proprietary license and uh up to uh

you thousands of dollars in in in support and uh and and other costs. So if you uh built your um your stack on top of Mino, you uh definitely did not appreciate this change in in approach. The next one is the radius license change which is well I would say that's a success story from the open source community standpoint. Um, so Reddis abandoned the uh BSD license

uh um a couple of years ago and it actually adopted the SSP license stating that AWS is killing us that uh this is not going to work. hyperscalers are running radius without uh contributing anything to to to uh radius uh radius itself and they of course realized this after radius became the global de facto standard for in-memory data. This did not happen five years before. This happened

when the pi looked pretty uh pretty big uh already um by by by all So uh after this realization, Radius decided to change the license to SSPL. Uh it was pretty much the same as MongoDB. If you ran Radius as a service, then you needed to SSPL your entire stack. and they upheld this belief that this is going to be great for them for I think a

little bit over a year. And the reason [clears throat] uh this did not go on for longer is because something uh happened on the market and that that something was balky. So uh the community was quick to to uh to react and they forked uh Radius uh creating Valky which was uh um uh a collaboration uh between um lots of uh different vendors on the market large

ones and smaller ones as well. Perona was uh was uh one of them uh from the get-go. Uh and the reason I told you that I think this is a community win is because if you think about it, this did not happen with MongoDB. It did not happen with uh I think successfully with Mino either, but it happened to Reddis because the Rady's community was strong enough

to react this way and to fight back and to make sure that um that uh they are not going to be perceived as freeloaders who are now out of the game from uh the perspective of Radius Inc. so they added AGPL after seeing the success of uh Valky and there was a I think a huge market loss for them uh after the SSPL SPL move. The the

difference between MongoDB and ready is striking in a sense that they both uh adopted the SSPL license. They both named similar reasons as to why they are doing this but the reaction was completely different and it's most it's most likely different because the radius community was a lot stronger when it comes to MongoDB and contributions to MongoDB. I mean MongoDB CEO uh the quote from uh him

earlier might have been uh true in a sense that MongoDB built a lot of the MongoDB code base whereas with radius there were a lot more contributions so a lot more uh contributors felt uh familiar with the project itself to to to continue. if we are talking about sustainability, if we are talking about how uh these companies uh want to be billiondoll uh market cap uh bahamoths

on the wings of opensource, we also need to talk about how the user is hurt in the process because we hear about how they want to make sure that AWS is unable to monetize everything for free without contributing back. But what we don't talk uh or what they don't talk very often about is that if you limit the amount of vendors, if you limit the amount of

service providers for a certain technology, you're not only of course monetizing a larger uh part of the pie, if not the entire pie, but you also uh hike up prices on the market. um uh there is a slower fragment fragmented innovation uh and because that you have less options for as a service then you as a user would also be logged into a single this might be

clear to you in this room maybe it's not but the interesting thing is that if you search on SPL if you search on uh these new opensource licenses that are to fix the cloud provider problem. You have actual open-source users who would say, "Yeah, this is fair. This is great. This is the only thing they could have done." Not realizing that they are on the losing side

of the equation, that they have less options, that they have less choices, that they have less than what they had before. And it's such an interesting uh thing. Forking is also a a problematic thing because on one hand it's great that now we have Valky. It's great that we were able to fight back as a community. It's great that uh we did not let uh radies get

away with calling the community freeloaders and and and and do this whole stuff without any any any backlash. On the other hand, it splits developer energy. Those who contributed to uh to Reddius would now contribute to Valky. Uh they might be accused of uh using each other's source code. There might be lots of uh lots of uh drama around what is happening in each community which is

just a lot of energy. If we would be able to spend this energy on innovation instead of instead of um instead of splitting the community into several different pieces, it would be a better uh better uh word and also it erodess trust. So the next generation of developers, would they care to to contribute to someone's project knowing that this might end up becoming a billiondoll company who

would one day call them freeloaders for using the thing they helped to create? I mean, this is not something that's attractive as a as a a after discussing uh all of these different license changes or in the case of Red Hat uh some uh you know uh other creative uh ways of uh creating uh uh a world where there are less choices uh for users. Let's talk

a bit about how not to become exploited as a developer. So this might feel like a naive or conservative take, but if you have a good idea, if you have this idea where you can revolutionize XY Z, where you can come up with this revolutionary new database or or or or whatever that should be opensource and should be uh should be something that grows uh as an

open-source project. The thing you need to make sure you don't do is don't plan and take investment with the promise of a million% growth. Because you could be uh biggest believer of open source. You could be someone who really believes that open source is just the right thing for you to do. But at the same point, you're pushing yourself into a situation where you might not have

the decision anymore. You might have an investor or uh several other co-founders or or just uh um you know a situation where you can no longer maintain your beliefs. And this is almost always coming from the fact that you don't feel that it's fair that the whole world is running on your technology and yet you don't have a private island. if you um if you take uh

any of these companies, I bet that all of them were started with uh with um open source in mind as something that they are going to stick to. Well, except for MongoDB where there's an admission that this was not the case, but uh to each of their own. So instead of trying fight on what is fair, let's suppose SQLite, it's on all of your phones right now.

It's running on everything you own your car. Well, high chance that your car runs SQLite and uh many other things that that uh would not need a distributed higherformance database. And yet SQLite is still uh an open-source uh project and still something that is free. Um how you can benefit from your own invention, your own innovation is that if you are the number one at supporting, stewarding

and running the the product because the pie is bigger uh due to open u and you need to accept that you will not be able to to monetize all of it. How not [clears throat] to become exploited as a contributor and user. Uh and this is this is a strange one. Uh I believe that these rules of thumb changed over the years as 20 years ago you

could be reasonably sure that if there's an open source license at play and there are people who believe in open source then they will most likely stick to that and proceed accordingly. Um but as of today it is a complex decision and there are lots of factors at play. For example, if the opensource uh product uh is multi-endor that's well obviously a great thing. Uh there are

lots of service providers for MySQL for example. you can't end up in a situation where um it's only this or that who would be able to run MySQL as a service and therefore create competition for each other and posgress is an even better example because uh when it comes to posgress even the trademark and uh and the teams are well not owned by one big single entity

that is there for for profits and nothing else. Another great thing is if the technology is based on an open standard. So if you look at relational databases, most of them uh would uh implement the SQL standard which means that they can't be uh as materially different as for example how MongoDB is different from the market. In the case of MongoDB which is a trademark of MongoDB

Inc. In case you don't know, that's a very important thing. Um, they love this Uh, so MongoDB is not based on an open standard or any standard whatsoever. Meaning that uh whatever they do is going to be driven by them. It's not going to be driven by multiple vendors who belong to a standard standardization committee. It's basically them and any alternative you come up with is going

to have to play catchup uh for a long long time with MongoDB until until it becomes an open standard which hopefully it it will become. So if the technology you're eyeing is uh based on an open standard that's that's a big win has a healthy community around it. So thinking back of the examples I brought um radius if you were a Radius user you still have a

reasonable chance that you're going to be able to migrate to something that is open source because there was a strong community around it. there was willingness to change the situation and make sure that this is not going to be the end of uh the in-memory uh database that b they built their their applications uh on and last [clears throat] but not least if it's hosted by a

foundation like Eclipse or CNCF or the Linux Foundation like Valky and other uh uh um another uh factor where Valky is a good example then of course that can give you confidence that this is not going to be a decision of someone at the corporate HQ uh when it comes to the greed uh and and the pi. So if some of the above are not true then

you need to assess your your migration risk. You need to make peace with the fact that what you have today that's not something you you you might uh have uh uh tomorrow short shameless plug here uh but I think this is not a sales slide. So what Perona does uh most of you were familiar with the company is that we innovate on top of strong uh open-source

projects. What we basically do is we take enterpriseonly features such as some MongoDB enterpriseonly features or uh for posgress uh TDE and uh well contributing to Valky itself or very traditionally uh contributing to MySQL for 20 plus years. So we take enterpriseonly features, features that would have been used to take more of the Pi and release it as open-source software, which means that those who were losing

options could still get some of their options back because we are here to to um to work on opening opening uh things up. Uh, and last but not least, uh, and this is a public service announcement. So, I'm not sure if you heard about Oracle's different way of handling my SQL. As of lately, there were lots of layoffs. Uh, for example, there were uh changes in how

transparent Oracle is when it comes to the future of MySQL. So we published an open letter uh that is uh that advocates for uh uh trade association for my SQL. If you would sign the open letter of course if you agree with what we uh want to do here uh we would really really appreciate it and thank you very much if you if you if you do

that. we already have more than 500 uh signatures and we are aiming for uh a thousand. So we want to bring my SQL uh to a similar foundation as what we have for for Postgress. So with that uh thank you very much for your attention today. I know that this was a long conference. I know that this was the last session. I'm also terribly jet-lagged because I

just arrived yesterday. So, I'm hoping that what I said was uh interesting to you. And if you have any questions, please let me [applause] Okay. You were first. Thank you for your talk. Uh so my question is um if I'm understanding correctly, the elephant in the room and the bottom line that I'm getting from your presentation is don't trust open-source projects whose governance depends on a company.

>> I would say that it's a bit more nuanced than that. I think that there are many factors as one of the slides uh uh elaborated on that. I think there are fundamentally uh you know good companies you can't tick all the check boxes some of the open-source projects you choose would be single vendor or some of them would not belong to uh foundation and I think

this is all good as long as you understand your risks. I would also say there's nothing wrong with proprietary software. So we are sitting here talking about open source but probably we're using proprietary software in uh different uh uh uh instances uh different uh parts of our professional or private life and that's fine. Um transparency is is key. uh you need to understand how that project looks

like in terms of the maintainer's vision for the future. If it's not part of a foundation yet, but they intend to donate uh it to a to a foundation, that's fine as well. I mean, as long as as long as you understand where they are headed and you're not blindly going into it, then then you should be you should be fine. I think you need to trust

open-source projects. I would still want to continue living in a world where we have more trust towards open source than proprietary. I think the takeaway here um and probably it's hard to see that after all these negative things but the takeaway here is that uh you just need to assess your risks but open source is still going to prevail over anything especially for infrastructure. So, I've asked

some version of this question at conferences a couple of different times, and I guess I'll I'll say it in a little bit stronger way here. I keep wondering when do we as a community come together and start putting pressure on the license endorsement organizations like OSI to say if you have a project and it's under an open-source OSI approved license but you have a CLA that allows

you to rellic it to a non-open license then that project is not open source and we will not endorse it as such. It's a great it's a great uh well question but more like uh more like a suggestion. What I can tell you is that I was not overly happy with the OSI as this whole thing uh unfolded between Farad DB and Um, I hear a lot

of uh talk from the OSI on AI for example, but do we have open-source licenses figured out for now? I mean, is there any kind of enforcement? For example, if I say today that the SPL or the BSL license is open source, I mean, who's going to stop me? And unfortunately, if I have more money than you, then my voice could be louder than anybody else in

the room. And this is what happened with the SSP license where if you ask some people uh they would still think that the SSP license is open source even though uh even though it is not because MongoDB called it an open- source license for many many years and their voice was of course amplified by their marketing budget. So I completely agree with you. I think there's a

lot of work to be done I think by the OSI because I want to believe that we can stand behind the OSI on this and we can still trust the OSI but um I don't think that there is enough focus agreeing with you here whether the current system works whether the current licenses or the way licenses can be enforced or the way how licenses can be assumed

assumed even though there are important details ignored as the CLA um I think there's more work to be done for sure. >> So um you have >> I see a red hat shirt. >> Yeah. And disclosure I work for Red Hat. >> but you're a good person. >> You have Well, that's that's debatable. [laughter] But um you you used the term freeloaders with Red Hat a number

of times. Um, who at Red Hat ever called the community a freeloader? >> I can tell you that. Um, the source I have is pretty much the community discussion around Red Hat. >> Okay. So, that term was used >> this is the I would not expect this sentence on a corporate blog. Well, the the thing is that term was used in an article by Slate and another

article by uh the Register when Mike McGrath posted his his uh blog post about the split uh with CentOS. So, um I would just say attributing terminology like that to Red Hat is inaccurate and unfair. Uh and so, you know, do with that what you will. The second question that I have is you said that um Red Hat had put the source for Red Hat Enterprise Linux

behind a a payw wall. How much does it cost to get to that source? >> I think that is not a public information, right? >> Uh it's zero. I if you register for an account with developer.red.com that gives you access to Red Hat Enterprise Linux and also the source code. So again that's that's an inaccurate statement as >> and I fully own if there are inaccuracies and

I had a disclaimer in the presentation as well. You know it's pretty hard to understand all the nitty-gritty details when it comes to at least five license changes or you know stuff like that happening in the open source community. But let me um um let me ask something. So why do you think there was an uproar in the community after Red Hat changed uh its approach? >>

Sure. That's that's a fair question. And the uproar was because being good community members, we released all of the source code including all of the source RPMs for our flagship product for years and years and years, >> decades. >> Um yeah, decades. Um, when folks stopped using that source code as a I want to tinker and I want to make it better, but instead changed it to

I'm going to use the source code to compete directly against Red Hat. We tightened up our subscription agreement. >> What is the problem? What is the problem with competition in this? >> There's no problem with competition, >> but you just said that they use the source for competition. Um, we have asked community members multiple times over for over a decade. Um, you know, if you want to

use our source code, that's absolutely fine. We would rather you not use it to compete against us. Um, if you want to do something different and better, do it. That's what the community is about. That is why every single product that we have comes from upstream projects to which we contribute all of the source code. But um when it became, you know, instead of it being people

being in the community with, you know, best of intentions, it turned into um you know, we're going to take all the work that you've done and all of the integrations that you've done and we're going to make it so that you don't get paid for all of that work. I don't think that that's reasonable. And in fact, if you read the GNU free software manifesto and there's

an article on gnu.org that says, you know, the the assumption that you made about, you know, you're supposed to take a tiny slice. Read the documentation on the GNU website. It says the idea that, you know, you're supposed to make a minimal amount of money off of free software is a misconception. And in fact, the GNU Foundation says we recommend that folks make money off of open

source so that they can continue to contribute. That's what we do. So would you say that there is uh there was less adherence to the license over the years and this is why redhead chang >> well the license is the GPL or the Apache software foundation license or >> those are the terms right so there's no >> the commercial terms for a subscription are not related to

the license if you get a subscription for developer.redread.com redhead.com at zero cost and you download the source RPMs and you distribute them. That is absolutely legal. That is not anything that we would say, you know, you can't do that under the terms of license. >> But then why the uproar? >> Uh because people stopped getting basically free rebuilds of a a Red Hat Enterprise Linux and we

said, "Hey, we're doing the work. I think it would be really cool if you actually paid for the work." And uh and again that is in accordance to free software foundations documentation. That's I mean they're the the earliest you know free software organization out there. So uh but people got upset because they weren't getting free stuff anymore and I get that to be clear. I get that.

But you know with CentOS stream you get exactly the same build except for some minor version number differences. uh with Fedora you get what's coming in Red Hat Enterprise Linux all of those are freely available from Red Hat, sponsored by Red Hat, funded by Red Hat. So the this this whole this whole like oh you're you're obuscating the source code. No, 100% of the source code for

everything that we do is upstream. That's how we work. Now the integrations for some of the products that we do um that's not source code. That's how we build the product. That's not something that I think would be reasonably expected to be like, hey, give us give us your build system and your integration points. That's that's not what that's not part of the open >> Well, what

I want to say is first of all, I think that the community's opinion and I can only go by that would veer towards the understanding that I presented. Now you are you have a different understanding working at >> I'm biased. I'm first one to admit >> you you might be biased but you might also be more knowledgeable on the actual mechanism that needed to be fixed in

connection with whatever was right for Red Hat. What I would suggest is to be open about these points. >> I don't know how much more we can blog about it. I mean ser talk about the developer subscription. It is free, you know, zero cost. Um you can get rail today for free and run it on like 16 machines. >> I don't know. I'm not part of that.

as someone who was around when Linux just started um and a lot of the open- source licensing was just started um my uh singular observation as as opposed to a community observation is that uh I was very surprised that open source worked because in the United States it's a very capitalistic market. So I'm amazed that we've gotten this far and I think it's fantastic. Um, the one

thing I've noticed with entities that uh have built their livelihood off of some type of open-source model is they usually wind up coming into some kind of financial dire straits that forces them to change their ideals into something more business-like. And um I think that that's what you've seen with Hashi Corp trying to change their license. Uh Red Hat, I mean that they started off as a

service company and selling selling Linux on CDs and distributing those CDs and making money just on shovelware, so to speak. Not not saying that you're shovelware, just the ser the the the Um so it it's I the thing to keep a look an eye on in any open source model is how is that company doing and you know did they start with a good business model and

are they willing to to stay true to their principles in that I think you're Yeah, you're exactly right. And the license change is uh I I don't think it ever stems from a belief. Hey, we need to change the license. Hey, we need to part ways with open source because we no longer believe in it. It's usually a financial or acquisition or investment related action more often

than not, which is unfortunate. But as you said, the reality of running a running a business, I think the big question is uh can it be done in a way that is more honest with the community and maybe less disruptive? Are there ways to go into it easier and and uh and leave some some opportunity for the community to uh react like Valky did for example. Um

um I think uh you know there there's there there are always two sides and I'm really happy that I'm not sure what your name is but I'm really happy that you Thomas I'm really happy that Thomas uh came here and and and uh and um discussed uh his viewpoint probably not red hats uh but disclaimer but but his viewpoint uh so >> so uh the only the

The only uh observation that that that I have is that is that um yeah I mean there were many people in the community who who would have liked Red Hat to have continued their their model that they've had since in inception of having um the having everything open sourced as well as having commercial services to improve their financial ial outlook. It's only when uh I think they

were they were put under management of IBM that that's sort of changed. I don't know is if that was because of management of IBM. Um but >> I can just say that IBM is very hands off. >> Okay. But that's sort of changed your the business model changed after >> we still provide software% open. >> No, but the way the way that the way you have done

business has changed. >> Sure. No, we still we still offer exactly what we did when we started openource. >> Okay. Well, I'm just meant to say that there are a lot of people in the scientific software development community who have changed from using Red Hat to now using say Abuntu uh because of the change. >> Were they using Red Hat or they using >> they were using

a mixture of of both um mattering on what what it is where they have where they have it had it installed. uh but looking looking forward for for more so for the the database uh community. It looks like Perona has done a lot of development with databases. do you do you foresee that that developers will have a stake in keeping keeping a lot of the uh standards

open and keeping a lot of the um the databases open uh going forward? Or do you foresee that uh because of the financial success of companies like that things will change uh uh in a negative way. I think it changed in a negative way and that's why this presentation uh uh is is uh uh you know the one I present on the other hand I think we

might have gone to an extreme with the platforms at this point and how I see it is that more and more users realize that at least they need something hybrid if not onrem or a private cloud which means that there is appetite for open there is appetite for uh open-source technologies that would that would uh that would uh uh run uh their infrastructure. So I think that

there is a lot of hope for open source and I think if anything these actions showed us what happens if a decision like this is made and what can the community do in case this happens. Valky is a very good example where as as you you you uh uh brought it up uh developers could do something about it and did something about it and ultimately the actions

of Reddis the company that actually made that decision uh changing back the license shows that they might also agree that this was not the best uh decision they could have uh could have made which is a great thing. This is this is positive. This is a learning. This is something that we now know is possible and this is not um not uh impossible I mean to to

to react. >> Thanks for the very interesting talk and the discussion. Um is there a risk that we perfect is the enemy of good in a way right? Um, I think there's two there's two sides to this, right? On the one hand, like contributions from Red Hat is probably better than um something that's completely closed sourced. On the other hand, we need to keep these companies accountable

and say, "Okay, if you if you change the license or you change the deal, if you rock pull the community like this, that you know, you can't do that. That's not good." So, we we need to keep we need to balance these two things. And um I Yeah, that's just I'm not I don't know if you have How do we thread this needle basically? Well, I agree

with you and uh Thomas is here from Red Hat who I mean I'm I'm really happy that there is a discussion because this is how improvement happens. Um I did not have a lot of fruitful discussions with MongoDB for example even though I had many and uh you know it's it's great to see that uh that uh some of these companies would engage in conversations with community.

I totally believe from the redhead perspective that there were reasons. There are always reasons. Nothing like this would happen without a reason. The question is could this uh be done some other way in a way where the community also understands what happened and why and you might have blogged about it a lot. I mean not you but Red Hat maybe maybe it was you as well. >>

Yeah. I I would I would also say that you know remember that community is a two-way thing. Um, by that I mean, you know, Red Hat, we contribute tons to the community, you know, I mean, they're paying for me to be here to teach people how to use open source and not Red Hat open source. I I always use freely available, completely, you know, open source stuff

when I when I presented these. Um but you know when somebody who is a member of the community says hey guys you know repackaging our stuff and then you know saying that you're exactly the same when you're not but then you know saying you don't have to pay Red Hat for all the hard work that you that you've done. Um, can you like can you understand why

that would be frustrating for for a commercial company? Like, hey, all this work that we've done and we've given the source code away for free forever even though we're not required to except for our customers. Uh, and then for us to say like, hey, you know, stop doing that, please. And the community th those members of the community saying, no, screw you. We're gonna we're going to

do what we want even if it hurts you financially. um that you know that to me is a violation of community trust trust as well. Hey Red Hat, I know you've done all this really cool stuff, but you know we're going to we're going to make it so that you don't get paid for any of that work. That's not positive community interaction in my opinion. And to

be clear, I'm not speaking for Red Hat. I don't speak for Red Hat. I'm just a community member doing presentations >> No, and thank you for your viewpoint. I think uh you know you're right that the community is a two-way thing and it's predominantly it's supposed to be a collaboration on the outcome. So if red hats well let's suppose this is redat's position is that the rest

of the community which redhat is a part of was not working towards a common success and obviously that's a problem that needs to be addressed. My question here is that was there enough discussion or was there a visible discussion that was able to solve this issue before anything happens? And to me it sounds like that discussion did not happen or not happen in a way that was

enough to to um prevent the backlash. A and that's all I know. Um it's a good sign that there are two way discussions just like this one here. And you know if I can have one request for you please do a presentation on the red hat position on this. I mean it it it might be one of the most interesting you know uh decks I I I

would expect here. >> I've known Thomas Cameron a long time. You just Thomas Cameron to express his opinion on something athletic and he I did not notice such a thing. >> All right. Well, thank you very much everyone. Thanks. [applause]