Hello, everyone, let us start the 5 PM panel session. Please take your seats. The topic
of this session is for communities and the real licensing of projects and the impact
on communities it has. So let me hand over the mic to our moderator of this introduced
our panelist. Thank you. Thanks very much, everybody. Good afternoon. Thanks for being here.
My name is Steve Wally. I work for Microsoft. I also teach at Carnegie Mellon University.
So this panel kind of evolved and I'm going to let the panelists seat introduce themselves
and then we'll set up the discussion and I'll start the questions. So, Don, can we start with you?
Hi, I'm Don Foster. I am the Director of Data Science with the Chaos Project. I've been doing
this open source thing for about three decades or so. So I've been in the space for quite
a while.
Hi, my name is Ben Ford. Interestingly, Don was kind of sort of my boss for a very short time
back at Puppet. But I've been with Puppet for about 13 years and which is a very long
time to spend at anyone company. So this year I am no longer there. I'm found in a configuration
management. Interesting community work. If you've been in the Puppet community, probably
recognize me by my hand. I'll have been for 2K.
My name is Brian Puppet. I am a manager within Red Hat's open source program office.
We are team as responsible for community data analytics. We are strong supporters of Project
Chaos and generally doing metrics around determining whether or not a community is healthy
for itself and also for us and our customers and partners. And that's what is why I'm here
today. Yes, that. I like the fact that this is better than the voices that are usually
inside my head. So this is very helpful. Thank you very much.
Thanks. And my name is Steve Walley. And so to set the frame for this discussion, we've
seen releasing happening over the last 10 years and I had opinions and I did some back
at the envelope calculations. But the reality, once I wrote about those things and what
I think the rules of successful forks are, it turns out, it dawns the data scientists
and she actually dug into this. So these relicences in these forks are often presented
as this idea that somehow the company is abandoning the community that made it successful.
And this is one of those things that I think they actually have a business model problem.
They stepped into a trap and they didn't understand the fundamental difference between
their upstream project that they own and the downstream product that they're selling and
that communities and customers are different groups of people. And so we shouldn't be surprised
that a company has relicensed. I've done a number of small companies over my career kind
of thing and you have employees to pay and customers to serve and you do this kind of
relicensing thing. And so when we actually sat around and tried to figure out how many
of these things we've seen, there's just not that many of them when you think about it.
Up until 10 years ago, there was maybe 7 or 8 forks in the entire history of open source
that were big forks, communities split. And a couple of them kind of eased their way
back together. The first one I remember was EGCS and GCC back in the late 90s. So these
are things that don't happen often. And I'm one of these people that makes up rules.
And so I said the two rules that have to be in place for a successful fork, the owner
of the IP has to put the entire community at risk. And then the second rule is a respected
member of the community, he has to put up their hand and say, I'll anchor that fork. And
those are the times we've seen this actually work out. And there's not a lot of them.
And some of them wisely knit the way back together again. And so we end up in this place
where, you know, when I said I did a back at the envelope thing on elastic. So I was at
Microsoft already when they realized. And Microsoft uses elastic search all over the place.
And so we were kind of, you know, worried, are we still allowed to do this through the
license? And so we ended up in a place where, yes, we were. And they're a good partner
and we moved on. And the back of the envelope calculation that I did, you know, you
can basically do a get summary by line and you spend some time cleaning the data. And
98% of the code base was written by employees of elastic. And so that's where this gets
really interesting is like I said, don's the data scientist. She went and did some real
analysis, not my back of the envelope kind of thing. And so actually, I want to turn it over
to Donald. Let me flip forward to this never built a contributor community, right? They had loads
of users. But vast majority of the contributors worked out the company. So when, when they
released, there was really no impact on a contributor community. There was, however, a very
large impact on their user community who then had to decide what to do now that they
released and, you know, a big user and, and frankly, a big reason for the fork was Amazon.
Or a big, yeah, a big reason for the release was Amazon. And so Amazon took it and forked
it and created open search. But they did it as a company. So what we ended up with was we
had elastic search, which was primarily driven by elastic employees. And now we had open
search, which was primarily driven by Amazon employees. So we had a fork, but it was
really, really just another company project. Now they've since actually contributed it
to the Linux Foundation. So I haven't, I haven't done the analysis because that's a relatively
recent change. But I'll be really interested to look at it after they've been there for,
you know, six months or so. But, you know, one of the things with open search, they have
started to build more of a contributor community. So even from the start, they did have some
people outside of Amazon that were contributing. So it is a stronger contributor community than
what we had with elastic search. But it's still fairly dominated by Amazon. And then, you know,
from a terraform perspective, it's very similar to elastic search. The people who were contributing
were Hashtag orphan plays. And they had almost nobody contributing from outside the company.
And then, open tofu, though, on the other hand, is a very different project than open search.
Because it was started under the Linux Foundation. And it wasn't started by one company.
But again, it's a, it's a user fork. So it's not a contributor fork. There were no, no
contributors, really, to be involved in the fork. So it was a bunch of user companies who then
came together under the Linux Foundation to create this fork. So they've had, you know, the first
year they had 31 people at 11 companies contribute to this, uh, to this project, which is pretty
interesting. And then the one that is vastly different from the other two is the Redis Valky example.
Because Redis had said that they were never going to be licensed. They would always remain
under an open source license. They had said that publicly many, many times. But the company on
Project, they can realize instead if they want to. And they, and they did, right? So a year before
the realizedants, there were, you know, about six employees. And they were making, you know, a fair
number of commits. But they had 12 people who didn't work for the company who were also making
a significant number of commits. And so when it came time for the fork, what we ended up with.
So I looked at the six months after the fork. And we had 29 people at 10 companies contributing
to Valky. And 18 of those people previously contributed to Redis. And when I looked at the six
months after Redis, there was, uh, there were no non-employees who had made any kind of significant
number of commits. So they had all sort of moved to the Redis fork. Uh, or sorry, yeah, to the Valky
So, so it's interesting to look at these three projects because these, these three examples,
because they, they are very, very different examples. It's all, all stop talking now.
Thanks, sir. And, and Ben, you've been involved with the fork around the puppet open box
fork. Can, can you talk about that? Like, kind of walk folks through what this looks like on the ground.
Sure. Um, one thing interesting about the, uh, the puppet fork here is that they didn't
actually realize them that, uh, so they are still Apache license. But what they did is they basically
closed the development. So they decided that they were going to stop publishing packages, which is
kind of a big deal. And then they decided that they were going to move, uh, all development to internal
forks. And they've promised that they will periodically push things publicly. But, you know,
that still remains to be seen. Like, the proof is in the pudding, right? But that's not really
like that. That's not how an open source project works. Like, when you can't engage with the
product itself, when you can't, uh, when you can't get the packages for it, uh, like you,
this is not a workable environment for most developers, for more, uh, most users, for most people,
that are wanting to use it. So we felt that there was no other alternative than to build our own.
And we started out by just repackaging. And then, uh, I think within a couple of days or week after
the, uh, the closed off the packaging pipeline, we had replacement packages up. So you could
still get open source puppet, uh, it would just built by, uh, the community rather than, uh,
puppet itself. And then we went from there and it started sort of had conversations about
where are we going? What are we doing? Uh, what is it that we need out of the community?
What is it that we need out of the project? What is it that we need out of the, the company?
And, uh, you did say something earlier. And I'm going to paraphrase it. I'm probably going to get
it at wrong a little bit. You said something about how, uh, the company's kind of loose track
and, uh, don't understand what they're, like, what they're market, what the community,
what they're selling, et cetera. And I do think that that's true to some point. But I also think that
there's a valid reason sometimes for, uh, for companies to diverge from what they, what their
open source users are wanting. And that makes it not necessarily like a hostile kind of
a fork. But, but more like, hey, we're going, we're going different directions. And that's what
we're trying to do with, uh, with puppet is that, uh, we're trying to engage with the company.
We're trying to stay, you know, you know, at a distance, but still best friends. And we're
working with them. We're setting up a standards, uh, committee so that, uh, our fork is not
going to, uh, we hope is not going to diverge too much. It's going to stay pretty much in sync
with the offering from the company. But we're going to be focusing on the things that our, our users,
our needing, the things that, that people are actually trying to do with it, not necessarily
on the things that big enterprise companies are opening their wallets for. And, like you said,
it is primarily, at least at this point, still a user fork. Uh, most of the people involved
are users. Um, I ran a lot of the same stats. And we only have four people who have contributed
more than 5% to the core puppet project, like in its entirety. Um, and that's, that's a thing. That's
like we have to recognize that. Um, but it's also in the place where the product had slowed
down enough to, that even with the fact that most of the people engaged with the, uh, the fork
project now aren't the core developers that the built it originally. Our velocity has already gone
up from what it has been over the last few years. So I think that that's an interesting stat.
It's, uh, it's obviously it's only a couple months long. Like, like, maybe this is like
new relationship energy here. We'll figure it out. We'll see what happens along term.
But it's a start of what we hope is a good threat. Thanks Ben. And, and, you know, Brian,
you, you've got this long experience, uh, almost almost as much gray hair as I have, um, just through
your, through your Apache experience, through your red hat experience. Like, what, what are some
of the pluses and minuses that a community is going to see in this kind of situation when fork
starts happening? And, and you can take it from either direction, you know, from the company
direction or the community direction. Right. Well, and actually, I think I have a pretty good
example of how it affects both sides. The recent forks that we've seen, the, the increasing
acceleration of forks and re-licensing has caused an interesting effect amongst contributors to our
projects and also potential customers. And backing up a step. So one of the things I did early
in my involvement with chaos was, I helped build a metric around corporate diversity. Um,
in corporate diversity, if you're not familiar with the concept is, basically, how many
organizations are involved in a project? And volunteers do fall into organization, um, as a different
entity. But our belief at red hat and our degeneral belief at chaos as well is that, you know,
the more corporately diverse a project is, the, the healthier it is because you have talent coming
in from different avenues and technology sectors potentially, obviously any kind of diversity is
good. Um, but in this sense, in the context of corporate diversity, that's what helps make a community
prosper. And so what we are seeing now of late is a lot of customers and partners come to us and say,
hey, you seem to know how open source works. Help us understand how to do it. We're like, yeah,
sure we've got stuff. We can train you. It's fun. Um, come jump in the water with us. But invariably,
we've gotten a lot of customers and partners of late who are very savvy about this and they're saying,
we don't want to join a project that only has a, you know, one big contributor in terms of an
organization or a contributor that dwarfs all the others. Um, and they're not really even thinking of it
in terms of the help standpoint that I just mentioned. They're actually just straight up thinking,
they don't want to see one of these real licensing things happen. Um, and it's actually,
it's become a little bit of a conversation we've had with people contributing to our projects too,
because it's like, well, Red Hat, you, you have a majority stake at a lot of the projects that you
steward. Yes, we do. We recognize that. We also think that that's not awesome. But they're even
saying to us what if you decide to realize, which, oh, to me is like, you know, a certain place
getting very cold and snowing. Um, but they're, if they're not familiar with who we are more
value system or, you know, they just don't trust us outright. That, that, that's entering the conversation
more often. Um, and it's really interesting to me to see this chilling effect that all of this
activity is having both from a community side and a business side. Yeah, please. Perfect.
No, no, no, you're absolutely right. Um, but, you know, the, the one thing to keep in mind with these
organizational, these organization dominated open source projects is that even if you trust Red Hat
and think Red Hat's great and isn't going to do something damaging. Um, you know, their business
environments, they can get acquired by some, you know, some awful, awful company that hates open
source. I mean, I think, I'll be honest, like, I think this is part of the problem with prep
puppet. They got acquired by purpose and, you know, now we're in the situation that we are. Like,
you could have trusted puppet. I mean, I worked there. I thought it was a pretty great company when
I was there. Um, but you never know when a company's going to get acquired. When the company's
going to go out of business or when they're just going to change their strategy and be like, yeah,
we're not working on that anymore. You know, we're going to put all of our people over into this,
this other thing. And so, so you really have to think about the fact that you, even if you do kind
of trust the company, you're not in control of these many things that can happen out from under the
project. That trust is very much a big thing, especially with the, the puppet community, that's
like, the, the fort honestly kind of has been brewing for many years before the acquisition
happened. But the, the people, the users had that trust in the company that kind of held it together
as, as public started struggling with, with its financials, honestly. And, um, the trust that the,
the users had in the company, it took it so far. And they got, even past the, the acquisition before
it finally snapped, but it really was about trust. Um, I wanted to add something. You said something
about, uh, like corporate diversity and, and like the, the fear of having like one, one company,
or one, one contributor dominating a project. And, uh, also in, in context of the puppet
fork, I found it really, really interesting that very quickly after we announced, uh, quite a few
of puppet customers came to us. And they said that they weren't interested in, uh, canceling
their license. They weren't leaving the, uh, puppet community or say, they, they weren't, they weren't
going to be not puppet customers, but they wanted to make sure that we were successful because of
that exact reason. They, they wanted there to be diversity in the ecosystem and they didn't want
to be, uh, be holding to one, basically, pride at, uh, fork of the project.
There's an audience question. Well, well, we're going to get there, but I'm happy to take
audience questions now. Of course, it's from James. To get the chance,
that's all, ask all of you the question, which is loose in my mind. So I remember when puppet
was GPLV2, and then they released relations to LV2, uh, to Apache V2. And for me, that was when
the writing was on the wall. And so I just kind of want to know your thoughts, because why don't we
start taking this seriously? Why did we go with this permissively licensed valky fork instead of
the lightly copy left fork? When are we going to wonder less and why don't we, when we do forks
make them, you know, even lightly copy left, um, and not accept CLAs because this is the only thing
that really blocks if you have no CLA, no diversity. I mean, it's some diversity of, uh, contributors,
and, uh, and, and some, at least week permissive license, excuse me, we copy left licensing,
then it will just be, well, not just be a solved problem. You can't have these evil proprietary
forks. So, so be it. Well, I can give a little bit of context about that, but I think probably
done might be the, the one to answer the question. Uh, so when, when puppet changed from the GPL to,
oh, that was a very long question to repeat. Uh, basically the, the question was that, uh,
something like a decade, a plus, uh, 14 years ago, I think it was, uh, puppet changed from,
it was originally GPL license and that it changed to the Apache license. Um, and, uh, James wanted
to know why we did that. He thought that that was kind of the writing on the wall. That was when things
started going south and wants to know why we don't as projects, uh, like, hold that off and stay
with a more permissive, uh, uh, uh, more protective license, uh, in the first place because maybe that
could have prevented this from happening in the, the first place. Um, and Valky and other projects and
everything. So, context for, for the reason for that, uh, GPL switch, Luke, the founder of puppet,
had a very strong belief that, uh, companies would not purchase, uh, licenses to a, uh, a product that was
GPL. That is the thing that drove, uh, the, uh, the, the, the, the licensing is, is that he had some
customers that were afraid of the GPL, even though, like, there, there was no binding, there were no,
uh, libraries, and they, they were just running a tool on their infrastructure. They were afraid of using
a GPL, uh, license, uh, tool. And that's what drove the, uh, the, uh, switch.
Now, that, I, I, I know Luke personally, and I was involved in some of those conversations and, uh,
he, while he is very opinionated about a lot of things, he had no opinions about that. He was just,
didn't. So, this is one of those places, uh, that when, uh, when, when you said you were,
you were paraphrasing. Actually, when I was talking earlier about projects versus products,
thought the hard thing there, and, and there was this great quote from, I don't know, it was like
2006 when, uh, Mikos was still CEO at my SQL. And, you know, this, this is the M in lamp. This was a
fundamental piece of the, the architecture that we were all using at the time. And his observation was,
communities have time and no money and customers have money and no time, and he knows who's in his
community and who he sells to. And he kept those discussions really, really separate. And that,
that was kind of a crystallizing statement for a lot of us that are trying to straddle this business
line. And so, I think that's the hard thing you're always up against is, as a company, do you
understand there's that separation between your projects and your products? From that perspective,
as we step into this and, and the motivations, like if I want to start with Don, but it is something
showing up in the data and the analysis. Now that if you were a company right now and you were stuck
with this decision, do I do I relicence or not? Is there, are there indications yetters or more
studying that you want to go do? Yeah, that's a really good question. And this is, this is a really
hard topic to study because you can't really predict the relicensing because it is such, from
us to statistical standpoint, it is such an incredibly rare event. And there are loads of projects
that have all of these exact same characteristics that never relicense and there are way more of
those than the ones that that relicense. So you really, you really can't, you really can't predict it,
which makes it really really kind of hard to study. But what I can say is I was on another panel
on kind of the same topic with James Governor from RedMonk and one of the things that he said
during the talk that we were doing was that he'd had at least one RedMonk customer come to them,
talking about how they were thinking about relicensing and they basically changed their mind
to given what they've seen with in particular the Valky fork and the open to a food fork.
So anecdotally, I've been hearing some things about the fact that the fact that these sports
have so far been pretty successful. And I think it is making companies, I hope, making companies
think twice about, about relicensing. You know, in the, the other piece, the Rachel Stevens from RedMonk
did some analysis on the financial implications for the company that does the relicense.
And basically what she found was that there really wasn't any demonstrable financial benefit
to these companies. So they relicense because they're getting pressure to improve profitability.
But the relicense doesn't seem to actually have that effect. So I also think that companies
will look at some of that data and realize that maybe maybe relicensing isn't going to get them
what they, what they thought it might. So I'm, I'm hoping it makes companies think twice about it.
But one of the things that I'm really interested to see though, you know, you look at these
forks and the forks are we more organisationaly diverse than the original project.
So what happens when some of these vendors continues to struggle? And, you know,
if one of them goes out of business then the fork is going to become more successful because
people will, that will force a switch to the fork in essence. But it'll be really interesting to
watch this data over the next, you know, three to five years and see what happens with these
projects and these the forks that result from the relicensing. Ben, Brian, anything to add in there?
Because I just love the fact, when you said if the company goes out of, out of business,
I'll get right to you. There was this moment, again, when was comp here? 2006, 7?
Yeah. Yeah. I'm looking at somebody who might have worked there. Comp here put their
entire community into a state of existential crisis and they were in that position that a lot of
folks in their community knew how the code base worked and forked into something called a
dump here. Comp here went away within a year or so, but a dump here is still running. I ran
into them just before the pandemic landed and it was like, no, they still had a rich community
of folks and it's a small community. It's not something that, you know, we encounter regularly,
but they're still out there and going strong. Yeah, so Steve and I have been having these conversations
about forks since 2006 when I work for this company. I can't help but think this touches a lot
of the more existential problems that we face in open source. These companies, I don't know what
the original reason for working open source was, is they try to get a community to support them
with the product and if you especially look at a lasting and terraform, that community didn't
manifest. So, couldn't it just be that they considered like a field experiment that just didn't
start, yeah, didn't lift off, but instead when they realized and the community shouldn't
leave us shocked by yet another important project going away and suddenly took action.
Thank you. So, I actually have opinions on this one. Go for it. No, please.
So, so I have two thoughts on that. One, I think that you have an excellent point when you say
that, you know, they're seeing, you know, they're not building the community correctly. They've
stunted the communities growth and it's led to the inevitable fork and you could say that,
yes, there's been some mismanagement there and possibly in some cases, but again, it's a little
bit anecdotal. The other side of that, which has been a little bit interesting and I've talked to
some friends and colleagues about this recently, is that maybe they knew they were going to
realize it's all along, which sounds really paranoid and cynical, but hey, whatever, you know,
it's Saturday. You can make the argument that they are actually kick-starting an open-source project
and building a community on purpose, perhaps with the intent of, you know, building that publicity
and the homegrown nature of that an open-source community enables. Now, I have no evidence of this.
I have no proof of this as a purely speculation, but I think you can go either way and with the
acceleration, I'm concerned that that might be a thing, but as Dawn says, if you sit down and look
at the evidence that she and the folks from Redmunk are doing, it's not really a brilliant plan.
So I can't say for sure if they're doing this on purpose or if they've just accidentally
stumbled into a problem. So, yes, even. Yeah, and so I'm the historian. I have too much
gray hair in this space and I always used what I love that same speech that Mikos gave where he said,
you know, communities have time and no money and marketing to them will only piss them off.
Kind of thing. He also, he uttered a fact. He said, for every customer, I have a thousand people in
community. I was just a fact, but what a lot of folks thought a lot of the VCs that were this was
that first pouring of money into open source companies. A lot of the VCs thought they heard a
conversion ratio and they all thought, oh, we need a thousand people in the community and then
we'll get a customer at the end. But the fun of it was J-Boss was still a separate company at the
time and again, they had their heart and right place. They believed in open source and they said,
well, we have a conversion ratio of one in a hundred. And Red Hat, a much younger company in those
days, not to be a done said, our conversion ratio is one in ten. And it's like, there was no conversion
ratio. That's what I mean. It's like Mikos' original statement was right. There's a discussion you have
upstream with your community in your project and there's a different conversation you have with your
customer downstream or on your product. But going back to your idea there, like I think
this personal opinion, I think the open source, the open search fork, is technically a failure,
but that's why I can't wait for Don's data over this next few years because when you look at the numbers,
98.5% of that codebase was written by elastic and employees. And this is an incredibly valuable
codebase. It's not like there's a lot of competing projects in the space. You know, they took a patchy
loose scene and they turned it into something that mere mortals can use. And the way they
realized it multiple times over a few years, never threatened the rest of their user community,
it just pissed off Amazon. But Amazon is making so much money that it is worth spending a few
million dollars to maintain that fork. That's just the cost of doing business for them.
So I think it's a really interesting place and I can't wait for Don to get to the data the next time round.
I guess related to that. Do you think it was fair for elastic search to blame Amazon's
behavior is the reason they had to realize the motivation for them seems quite different to
some of the other examples? Was that directed at anybody? Or me? I was speaking with that, that's fair.
I think it was fair the way they set it up because Amazon was seemingly the offender saying,
we're just standing up our own service. Microsoft was an elastic partner. So we were actually
working to integrate it into an Azure offering. So they were a partner. And I believe Google was
doing the same thing. So it was only Amazon as one of the three hyper scalers that was actually
saying, yeah, we're just going to grab this open source and stand up a service. Which the license
allows them to do? They weren't doing anything wrong per se. But the license says, this is where
that's what when I was saying the framing. For me, the framing's always been if you walked into
this thinking that open source is great, I'm going to base my primary customer face and value
proposition on a project that anybody can take and do anything with because of my license.
You have to be really, really, really nuanced in making sure your marketing is selling the value of
your product offering, not the value to engineers of your project.
Right.
Yeah, so this is-
So here, I'll give it a go. So to repeat the question, it was Amazon, Amazon has these services.
They have these customers and they can just continue to, they've got contracts, they can continue
to make money off of this. But it really is, if you look at the cloud computing space, the way it
is now, that is why we're seeing all of these releases as all of a sudden. Because right now,
what we have is we have these behemoth cloud providers who can offer these open source products
basically as a service that anybody can just use. I can just go to AWS and spin up an elastic
search. I can just go to Google and spin up whatever. And so what we're seeing is that not only
so companies have always been able to take advantage of open source projects. But with the
rise of cloud computing, they're able to take advantage of open source projects in a way that
pretty easily generates quite a lot of revenue for these gigantic companies. And so the little
companies that are doing all the work on these projects get pretty ticked off that these other
companies are then making all of the money. So we've got this, I think this inequity that's
driving a lot of this. And there's frankly really not a whole lot we can do about it.
Yeah, that was that. The tough thing that night that a group of us sat around at dinner table
thinking like how many forks true big forks can we name and we got to about seven or eight.
Three of them provoked by Oracle buying sun. But you know, we we got into this space and we
were trying to figure it out. And this was all though kind of the hyper scalars were not as big as
they are today. And so we were wrestling with it. And we could only think of one company that had
successfully parked an open source license on the technology that was their core value proposition
to their customer. And was seemingly doing well. And that was my SQL. They were able to
articulate the value to customers versus the value to engineers in the project. But the thing is
we'll never know, I guess, yes, they were seeing the hockey stick. And then sun took them off the
table for a billion dollars. So we'll never know what would have happened to them 10 years later,
kind of thing. So it's a hard question. I'm going to turn me into a runner now, aren't you?
Let me just talk to the show. I want to ask about the product management aspects of open source
versus a more commercial product. Because it seems to me that quite often the forks are not
necessarily driven by a license or something like that. It's driven by the fact that the community
have felt previously that they all had equal contributions to make. And they could come up with
a wildfire idea and we kind of go forwards if they put the effort in. But subsequently, it's been driven
top-dying by more cathedral type approach. Marketing comes up of ideas. We ask our customers,
blah, blah, blah, you develop or go into it. And those two cultures don't mix very well.
And it seems to me that's actually more of the reason why these forks happen than the license.
The license is just, you know, the kind of thing that sort of people fly about. But I don't think
that's really the reason. I think you're talking right at me there, aren't you?
Yeah, I think that that's very much the thing. Matter of fact, when Puppet was acquired,
I have a story that I tell about this. I was leading community and they flew me out to Boston
to give a very long presentation like describing how our community works. Like all the details
of the community to their leadership and about halfway through, they just kind of cut it off. And
they're like, yeah, but how do you make money at it? It's like, that's not the point of community.
The point of community is to build this base that you could build a company on top of, right?
But they didn't understand that. They were all about that conversion ratio that you were talking about.
How many of the conversions open sources can you convert? What's your funnel to get them into
marketing so that they turn into paying customers? And they never did understand that they were building
a company on top of an ecosystem. And then some of the things that they did were very hostile
to that ecosystem, which meant that without a fork, the ecosystem would collapse. And all
like, transitively, the company would end up probably going under without that ecosystem to support it.
But it wasn't just the acquisition. It wasn't just the big private equity company.
Puppet itself had started losing track of that direction for product reasons, just like you
just like you talked about. We started letting things kind of faster, a pull request would sit
unreviewed because it didn't, nobody was assigned that to work on that particular feature in
that sprint. And so the community for several years was already feeling unappreciated, was already
feeling like Puppet had lost track. Like they weren't paying attention to the community's needs
anymore. And that was kind of true because they weren't giving them dollars. And that's what they
that's what they were focused on. So they were already primed for what like the actions that
Perforce took. They were already primed to immediately jump to what we're done with it. And I think
that that's what happened. Yeah, and just one quick thing to add to that. There are lots of
reasons that forks happen and a lot of them are product related. We were specifically looking
at the ones that happened because of the relicence. But there are loads of forks that have happened
for the exact reason that you mentioned. It just didn't happen to be the focus of the study.
But you could certainly look at it the exact same way.
Hello, I wanted to ask about my perspective as a user and the potential contributor to projects.
I haven't started a company. Sorry. I haven't started my own company to try and have an open source
product. So I don't have experience in that and I can't speak of it. But from a potential user
and a potential contributor perspective, in the last years I've learned the hard lesson that
the license for a project isn't really the whole story. The license, the right attribution
and the contributor diversity as a whole matters a lot more when I'm evaluating what projects I'm
looking at and I want to actually invest my time in energy. I was curious from the panel
to hear what are your thoughts about this and how you actually think about this. As a bonus
question, I want to ask, do you see a world in which AGPL could ever be a license that we're using
or is that never happening? I'm sorry. We really can't understand you.
Okay. So she's asking from that user, the developer perspective. You're in community. She's not asking
from the company anymore. How do you think about is the question richer than just the license?
Do you have to as a contributor in community start thinking about things like the CLA and things
like that that goes with it? Yeah. So an example that kind of quoted through my head as we've been
talking this afternoon was the situation with Docker and that wasn't really a real licensing.
They just sort of changed their business model a little bit and closed the code,
like, you know, and the contributor. They didn't really change anything drastically.
But even that was enough to cause a chilling effect amongst, you know, contributors.
And it ended up with, you know, well, Red Hat, we went out and invented podman and other
comparable technologies. Can we have to do that? We know, I guess we could have tried to work with
Docker, but it felt like at the time we were kind of getting a little bit stiff-armed by them.
These things have a chilling effect, and it's not just for business people, it's for contributors.
The thing that I have about, like one of the things I have a problem with about like open core licensing,
which is essentially what these turn into. Even if you start from there,
I've always wondered, well, from a community perspective, what's in it for me?
Because at some point, somebody's going to invent something that's going to be a feature in the
enterprise version of that code, and they're going to be told, no, because we don't, why would the
company want it in there? And then it becomes, well, why would I even want to participate in such a
community? Yeah, and just to add to that, I think that, as a contributor, you're giving them
your very valuable time. And from my perspective, as a contributor, I look at a lot of things,
you know, is there a CLA? Because that's not great. It means they could realize it. Do they have
a robust governance model that, if I do decide to stick around and continue to contribute,
could I move into a leadership position? You know, who makes the decisions and how are those
decisions made? I think there's a lot of stuff that contributors need to think about, well beyond
like licenses and CLAs, to decide where you spend your time. Thanks. So I'm going to take one more
question, and then I'm going to ask the panel to do closing comments, because we're in the last few
minutes. Thank you. Maybe a bit of a dangerous question, please don't kill me.
Wouldn't it be time for a different kind of license that, not trying to sound like unity,
that would be more like a profit sharing license or a requirement to contribute when you're
making a profit out of certain products, just to close the gap of like certain cloud providers.
Baking of a product and baking it, hugely profitable, while the contribute is kind of
getting nothing. Sorry. There's a huge echo from the microphones over here, and we just can't
hear the questions. So the nature of the question is, is it time to start considering
a license that might be more of a profit sharing kind of license? So I have opinions too.
No. And that was my opinion. We'll talk later. But enjoy your beer.
I was going to be friendly or say, that's a fine idea, but it's not an open source license,
but closing comments. Anything that you would like people to walk away with considering either
from a community perspective, a company perspective, a data perspective, where do you want the
research to go? What would you like to say? Real quick. I know there are diverse opinions in this
room about like CLAs and things like that, but I would think in general. When you as a contributor
approach community, definitely look at its governance, look at the composition of its developer
community, and see are their paths to maintain our ship from people outside of the stewarding
company? Those are all signs that this community is healthy and may not be heading in a
re-licensing path. Don is right. There is no predictability here. We have a very small data set,
but anecdotally it couldn't hurt. None of the things I mentioned could hurt.
I have a couple of thoughts. One of them is if you're at a company who may be looking at
something like this, or if you are in a role where you get to influence community or work with
community or something, you mentioned it earlier. What's in it for me? You really do need to pay
attention to why community members get involved. Why they stay involved? What incentivizes them to
keep contributing code? What are they getting back? What are they getting out of it? Sometimes
it's just a sense of attachment, but it really is like you need to give people something back
for this, and if you keep taking it away, eventually this is going to happen. Eventually you're
going to get to the point where your community isn't going to give you anything anymore.
Plus one to what both of them said. I will just add that this was the first step in the research.
We did look at organizational diversity, and we did just look at mostly commits lines of code.
Code contributions. There are loads of other ways to contribute to a project that we haven't looked at yet,
but you were there yet. There are loads of other project health metrics that we're going to look at.
This is phase one of the research. It's not just done. We're not just looking at the company
information and then stopping, so we have a lot more work to do.
Thanks, everybody. I'd like to thank Don Foster and Ford and Brian Profit as our panelists. I want
to thank you all for your questions today. Don pulled together a set of links that are a lot of
articles that cover a lot of what we've talked about and used as a basis for this. So thanks very
much, everybody.
Listen to what the slides already are up.