Rich Bowen – Plan to fork (So you don't have to fork) #FOSSBack

This talk discusses the importance of creating a forking plan for open source projects, highlighting how proper preparation can mitigate potential issues that arise from dependencies on open source. The speaker shares insights gained from years of experience advising teams in a large tech company on how to sustainably engage with open source communities. The session covers the various triggers that may necessitate a fork, such as governance imbalance, license changes, and slow contributions. By promoting active participation and building trust within the community, teams can better navigate the complexities of open source collaboration and avoid the pitfalls of forking.

Hi, so I'm I'm Rich and uh I work for a large tech company you may have heard of. And uh my job is to advise our teams about how to use open source correctly, how to work with open source communities, um how to get the most out of their open source investment, and how to figure out how to give the right amount back to open source projects.

And uh a conversation that uh I had several years ago changed the way that I think about how I talk with teams about interacting with open source projects. Now, if you have worked with open source for more than about 5 minutes, you begin to recognize that it does not move at your pace. It moves at the pace of the community, and that will vary radically from one

project to another. And you have to earn trust. You have to put in the time. You have to invest in these projects in order to make changes. And so uh several years ago a team came to me and said, "This project isn't moving fast enough. We're going to fork it." Um and this was a very well-known open source project, and uh I reacted with absolute horror because

if they had forked it, it would have been reputational suicide. And also it would have failed pretty well. and during the course of that conversation where I said, "Don't do that. It would be terrible and you should feel bad for asking." it sort of came out in this conversation that that's not how you talk to business people. You have to make case for it. Um so this

has evolved into something that I do today where when a project when a uh organization within my company works with an open source project, I proactively tell them write a plan to fork. And that's what this presentation is about. Plan to fork, so you won't have to fork. It turns out that this is much more effective for a number of reasons that I'm going to go into.

So first of all, who are you? I'm hoping that within this audience are people that work like myself work with large organizations that depend on open source. Uh that's sort of the audience that I'm targeting here. And who are in a position to influence how your company interacts with open source, and give them good advice that will result in success for them and for the projects on

which they rely. So I'm talking to engineering teams, but also marketing teams uh you know, understand that that collaborative software development can be frustrating. And that that's that's part of the process because you're working with users, you're working with developers to arrive at consensus. And arriving at consensus is something that in the long term helps your customers because they are part of this group of people that

are consuming the software. So we're going to talk about the strategic and technical and cultural aspects of preparing to fork an open source project, not because you actually want to fork it, but because it helps you understand what's actually involved in running an open source project, that you're not simply consuming it, but that you're part of that collaborative community, that you're part of the development community. several

years ago back when GitHub first launched as a business, they took this word fork and they redefined it in a way that is confusing to those of us that older. you know, in the old days when you forked a project, that mean that you were compete creating a competitive thing that was going to have a separate life and diverge from the original. so when I use the

word fork in my company, that's not how it's heard. It's heard it's heard as the the GitHub fork, the GitHub fork where you make a copy and work on it in order to order to contribute back. So I use several different terms. I talk about a contributing fork, which is a good thing. This is how we do open source. But the the other thing is a diverging

fork or perhaps a competitive fork, sometimes we call it a hostile fork, uh depending on who your audience is. And that is a fork that is intended to diverge. So these are these are the two terms that I use. Um might call it a GitHub fork if you're talking about something that's collaborative, that is contributing. And uh within AWS, we have a GitHub organization called Amazon contributing.

And so when you make a GitHub fork, when you make a contributing fork, that's where we stash it to clearly communicate this is a thing that we intend to give back. And that is the positive model. That's what we encourage people to do. you should think of your forking plan as a disaster recovery plan. That's that's sort of how I pitch this. So when one of my

when one of my constituents, one of my teams takes on a dependency for an open source project, I encourage them to write a disaster recovery plan. What are you going to do if this project goes away? What are you going to do if this project changes its license to something that doesn't allow you to consume it anymore? What are you going to do if it moves in

a direction that is not what we need in our service? So that's that's what writing a forking plan is. It's less about actually wanting to do a fork. It's more about assessing the project, assessing the risks around the project, and the sustainability of the project. And then there is my uh my alternative motive here, which is to get these teams to think about what they can do

today to address those risks with rather than waiting for it to catch fire. So that's that's the part where I'm sort of uh doing some some uh social manipulation in my teams. Don't tell my manager. Um I I want to help them figure out how to to work now to plan future crises, so that these crises that they plan for, they're actually being a productive member of

the community to make sure that those crises never happen. So let's talk about the triggers. There's a number of things that could trigger the need to fork. And there's you know, there's an infinite number of them, but I I feel like they fall into several buckets, you might say. Um so what you want to do is look at the and consider all of the aspects of how

that project runs, and think about how each one of them could go wrong. So these are these are what I think are the major categories. Uh one of them is a governance imbalance, and that that looks like a single entity that often looks like a single entity that is controlling the direction of the project. Maybe it's malicious, maybe it's not. Maybe it's a single vendor project where

all the decisions are made by one company, and the only people that get their pull requests merged are from that one company. On the other hand, um friend of mine Justin McLean introduced me to a new term last week that I I'm really fond gravity. This isn't vendor control. This is the fact that in many projects, there's just simply one place where all the expertise lives. And

so when somebody becomes an expert, that's where they want to go to work. And when that company grows, they look for the experts and they hire them up. This isn't malicious. It's not it's not vendor dominance, it's vendor gravity, and they look a lot the same to an outsider. You can only really tell which is happening when you're deeply involved in the All right, so one of

the big one of the big triggers uh that might trigger a fork is a license change, and we've seen a number of these in the last few years. I'm going to talk a little bit more about license change uh in a minute. Um As one of the big elephants in the room that that tends to consume open source projects, um you know, be aware that if you

are a big cloud vendor, it might be your fault. You might be the reason why the license change happened. And do things now that will prevent that from being the case later on. Uh slowness to accept contributions, maintainer silence and project inactivity, these kind of look a little bit the same where you you uh you get all excited about your feature and you throw it out there,

and there's just silence for 6 months. What do you do then? Eventually, you might be forced to fork in order to serve your customers. So let's talk about balance. Uh if the perceived problem is balance is vendor imbalance, you need to prepare for this. There's several ways that you can prepare for it. The first is that you need to do your research. If you're going to take

on a dependency, then you should go watch the community and understand who the major players are, who they work for or if they're independent and doing it as a hobby, are they all from one employer? How long does it take somebody from a different employer to achieve maintainer status? And that can be difficult to figure out. If a project is, for example, at a foundation that has

very formal ways of recognizing maintainers, like the Apache Software Foundation has a committer status, and it has a date associated with it. So, you can look at somebody's contribution records, and you can say it took this person a year to become a committer, and then it took them another year to become part of the technical steering committee, the project management committee. And that's something that you can

do if something's at Apache or the CNCF. It's something that's harder to do if it's just sort of a free-floating GitHub project. But do your research, and try and get numbers around this. As part of the community, actively oppose and contradict messaging that says this project belongs to this Um that can be really destructive in a project in a open-source project community. Um you know, there's a

number of examples that I can point to. I'm a member of the Apache Software Foundation. There's a number of projects there where everyone knows this project belongs to such and such a company. And that can be very damaging messaging. It can really discourage community community members who are not part of that company. And so, be part of the positive messaging. Be part of the people that are

saying, "No, that's not really the case. That's in an independent foundation." Um advocate for more transparent governance and decision-making. Advocate for documentation around what it takes to become a committer. Um there can be a tendency when you're trying to join a project community and you see it dominated by one player to say, "It's too hard to get in there." In this wonderful book by Margaret Margaret Wheatley,

Perseverance, she says, "The answer to community problems is always more community." And so, if a community appears to be restrictive in some way, the answer is to bring in more people. So, you as a participant can be an active uh recruiter. Go out there and recruit in more people to this community. You don't have to be a maintainer to do that. You just have to be passionate

about the technology, about the community. You have to advocate for it. Investing in community growth is the path to reducing single-vendor imbalance. It's also a way to grow your own trust within the community. People will look at you and say, "Oh, this vendor really wants to grow the community. Maybe we should extend a little trust to them." And then, you know, there's the uh the uh commercial

side of this. It also grows your own funnel of potential customers. So, there's always in open source, it's always enlightened self-interest. It's always about uh scratching your own itch and solving your own problems. And so, look at it as a marketing exercise as well. All right, the next the next trigger is a license change. there was a a talk yesterday where there was some discussion of license

changes, sorry, I went to a lot of talks yesterday. I'm trying to remember, but the speaker said that there's very few people who go into an open-source project with the intention of changing their license later. Yeah, there's some malicious people that might have that as their business model, but that's not normal. Usually, somebody changes the license because they recognize that their business model is starting to fail,

and that is usually because um you know, Google or Amazon or Microsoft is consuming all of their product, all of their community, without giving anything back. So, if you are one of the big elephants, like my employer, when you get involved in an open-source project, be sure that you are contributing commensurate to what you are taking. Otherwise, you're probably going to kill the golden goose. I uh

I was involved in the fork of OpenSearch, and later on in the fork of of uh Redis. And these two things look very very differently when you look at the different community experiences. Um I'm being recorded here, right? I I think it I think it's safe to say that the Elastic fork to OpenSearch was largely the responsibility of Amazon. And you know, looking back six years and

seeing what we could have done differently is part of why my department was created in the first place, to make sure that that these sort of things didn't happen again. Um looking at the Redis fork to Valkey, that was a very different community situation where we were actively involved and the problems were elsewhere. But you know, it's right and proper to look at yourself and see how

you could be the problem, but more importantly, to look at yourself and see how you could be the solution. If you are consuming more than you're taking, then don't be surprised if that project changes its license. And you know, be be willing to admit that it's License changes are almost always in response to a vendor feeling like they're not getting a good return on their investment in

the project. so, mitigating factors other than than uh participating more is encouraging that project to go to a vendor-neutral foundation. Now, that's not always something that's in your control, but it's something that you can advocate for. And uh if you're if you're part of a a big vendor with big budgets, maybe you can help fund that a little bit. you know, that's that's another thing that that

my department um at AWS does. All right. Trigger number three, we don't feel like we have enough control. We don't feel like the things that we are doing in this project are swaying the needle. And uh this goes back to, you know, the solution to every community problem is more community. Chances are that if you don't have enough control in the project, it's that you're not investing

enough in the So, while this can be a source of a need to fork, it's much more likely that the the solution here is to get more engaged, to to begin to participate more. Um tell better stories about why your vision for the software is the right one. Don't assume that you can show up with a patch and say, "This is the correct feature because I am

Amazon." And uh you know, I work with the teams that say that. I expect some of you also work with teams that that have that kind of an attitude. Um I saw that attitude at IBM. We would show up with a patch, and we would say, "You small project, you should accept our patch because we're IBM." That's not how open source works. You have to earn trust.

You have to make the case why your feature is important, not just for your customers, but for all users, all consumers of the ecosystem. All right, I am a little bit behind schedule here, so I'm going to pick up the pace a bit. Um trigger number four, slow contributions. Having your work be ignored can be very demoralizing. And this is something that I do not have a

good solution for. Um because when you're in a project, when you're working with a project where only that guy can merge the commits, then you are completely at their mercy. Um one of the things that I do recommend here is that you have members of your team show up to to do the grunt work. Triage the tickets. Review the the pull requests. Test the pull requests. Merge

them into your test branch and make sure that they all work. Do the review work. Get it leave intelligent constructive comments on reviews. These are the only ways that is causing that other maintainer to not have time for your PR. And so, show up, do the work. Um thank people publicly when they do the work. Make sure that you're recognizing all of the people to make them

feel like they're part of the community. Understand that you're part of a community when you take when you take ownership. You're part of a community when you show up and be part of the community, not necessarily when somebody gives you permission. That's one of the joys of open source. Another variant of this is when you have the the single developer model where you're you're concerned that the

entire project is is on this one individual that uh is doing all of the work on nights and weekends. And and you know, here again, you mitigate this by showing up and taking ownership and doing the work that they don't have time to do, rather than sitting back and complaining and saying, "Well, that guy doesn't have the time, so we're just going to fork and go on

our own." All right, next we're going to talk about the plan. Make sure that you have an actual written plan. If that project gets turned off tomorrow, what are you going to do, and what's it going to cost? And most importantly, which parts of that can you start doing today so that you don't have to ramp up overnight. Um how many engineers would it take to maintain

this project if it was all your problem? Maybe hire a couple of them today. Or work with other peers, other companies that are in this space and encourage them to hire these people or even you know, go splits on hiring a contractor. If if you're not an Amazon, if you're a small shop, you can support someone through through GitHub sponsorship so that they can split the load

across multiple vendors to do this. because when you fork, you are now suddenly responsible for the whole thing and you have to assume that if you fork, nobody's going to show up to help you. That has to be your base assumption. So, it's all your fault at that point. You must assume that there isn't going to be any help. What would that take? Start building that capacity

today, a little bit at a time you know, build a situation where if this project catches fire, you're prepared. You're you're working ahead a little bit. But also remember that open source is not just software developers. And we tend, you know, those of us who consume open source projects just sort of assume that the community will do that other stuff. If you fork, it's all on you.

You're going to need technical writers, project managers, marketing, event coordination, recruiting, documentation, legal, design, testing. All of this is on you now. What can you do today to start filling this gap, building the community? Some of this is recruiting community members. Some of it may be hiring people. And you need to make sure that you are prepared, but more than that, you need to make sure that

you are aware of what the actual cost is. Because as long as there are hidden costs, there's risk. Uh if someone else is picking up the tab for a project that you're that you're involved with, what happens when they stop doing that? Make sure that you are aware of what's going in to sustaining a community. Um support, documentation. Once you support, you're the you're the support team.

Sorry, once you fork, you're the support team as well. Do you have somebody that has sufficient expertise in the project to answer those support calls? If you don't, then you should be getting involved today. And the way to get involved there is to join the support forums and over time, start answering the questions. If you see a question asked today, take note of the answer and when

somebody asks that same question next week, jump in there and give that answer. Build that expertise. on the software development side, the best way to build expertise is to review other people's pull requests in parts of the code that you don't know anything about. And that will gradually build your expertise in those technologies that are peripheral to you. Most organizations when they participate in open source, they

focus on their little corner of the code. And they become pretty good at that, but they're all unaware of the rest of it. And so I actively encourage the teams that I work with to to get actively involved in parts of the code that they have never seen before. All right, I'm being told that I'm further behind schedule than I thought. Marketing is an important aspect of

open source that most of us don't think about because the community is doing it. If you're forking a project as a corporation, as part of your product, now you have to figure out how to market that involvement in a way that will sell it to your your management and your stakeholders. you have to be able to do customer messaging. Why would your customer stick with this new

fork that you've just created when they already know this other thing? They already trust this other thing. And now you've got this new why are they going to trust that? So you need to figure out what your messaging is to your customer that will persuade them that you did the right thing by forking. Um so don't just fork because it seemed like the right thing to do.

Um messaging to your customer, but also to the community. The community is only going to come along with you if you have if if your cause is righteous, shall I say? If you have forked for a good reason. Um we've seen a number of cases recently where a company has changed the license on an open source project and a community fork has sprung up and the community

has moved along with them to support them because their cause was correct and right. We've also seen some where there's been a fork and the community's gone, yeah, we don't know who you are. You don't have any trust in this in this community, so why would we follow you? Recruiting new contributors is now your problem as well when you fork. So make sure you have somebody that

has earned trust in the community that can speak about the technology and about the needs and the road map and bring new contributors on. Um governance is an important thing to think about. The advice that I tend to give is if you're going to fork, make sure that your governance is at least as open as the community that you're forking. If you take a project that is

that is open community and you fork it and you say only members of my company can contribute to this, you're not going to get any new contributors. That's the obvious case. But there's a lot of gray area between these. open source is not free. Make sure you figure out your budget. Make sure you figure out who you're going to have to hire to do this work. Uh

are you going to have to buy CI servers? Are you going to have to have a private GitHub account for the bits that you're doing elsewhere? You know, there's there's a whole budget aspect of this. Uh the Linux Foundation report that came out a few weeks ago talks about the return on investment on open source, talks says that it costs two to five ti- I think I'm

quoting this right, two to five times as much to run your own fork as to simply participate in an existing open source project. Um I I've only read the report quickly. I would encourage you to I'm going to read it better, but you know, I'm not sure where they derived these numbers from, but but they tend to do their research pretty well. Um figure out what your

milestones are. Uh if the project burns down tomorrow, what are you going to do Monday morning? What's the first thing that you're going to do? What when do you have to have a functional project community set up in order to be successful? What is your timeline before you start losing a bunch of money and all your customers go to your competitor? and I have 1 minute left,

so I have one more slide. I'm going to talk about naming. If you're going to name a new open source project, don't make your new name a joke about the old name because that and you know, you've you've all seen this happen, right? Um that way you'll always forever be tied to the branding of your competitor that you've just created. And so make sure that you have

a name that encapsulates more than simply we're not that guy. so that's it. Have a plan. Have a plan to reveal the costs and pitfalls that you're not thinking about yet. Do some research into what the community looks like, who's doing the work, who's paying for it. Uh make sure that you are working now to mitigate the pain that you're going to feel later because if you

start thinking about that today, chances are you'll never have to endure that pain. So, that's all I've got. Thank you very much for your time and attention and I think I have like 20 seconds for questions. >> [applause] >> Thanks a lot, Rick Bowen. Um yeah, I think I have to cut you short and we going to do the questions at the coffee table for you. That's

all right. >> [laughter] >> So Thank you very much. >> Thanks a lot for the inside look. [music]