Open Source & More - Blog | Tidelift

Open source citizenship panel: What do we owe each other?

Written by Josh Simmons | July 27, 2022

While working at Google open source in 2018, Cat Allman and I partnered with the world's most respected leaders in enterprise open source and the rich nonprofit ecosystem of open source foundations. We surveyed how companies were showing up for open source. We asked foundation leadership what kind of help they needed and spoke frankly about the gaps that remained.

Now, ever since, I update that snapshot of open source citizenship at conferences around the world. And I was honored to do that, again, at Upstream in early June, with an esteemed group of panelists including Al Gillen of IDC, Alyssa Wright of Bloomberg, Duane O’Brien of Indeed, Rob Underwood of Goldman Sachs, and Deb Nicholson of the Python Software Foundation. 

My goal is to take the guidance from these fine folks and help others cultivate a culture of open source citizenship at their own companies. 

Here’s a snapshot of one of my questions and the answers the panelists provided. If you’d like to watch the whole panel, you can do so here.

The theme for this year's Upstream is what we owe to each other. What does that mean to you in the context of open source?

Al Gillen (IDC): More and more organizations have to be focused on actually giving back to open source software and allowing that upstream community to be healthy. The majority of organizations today are using open source software, but not necessarily giving back to open source software in an upstream sense.

The security and the reliability of upstream projects is really becoming very important. It's becoming more obvious to the world, at large, that gee, we actually have to worry about this stuff because if it breaks or it's compromised, it affects a lot of organizations, potentially, including my own. 

Rob Underwood (Goldman Sachs): Like any large enterprise nowadays, we run our tech stack on tens of thousands of open source projects and libraries, especially when you take into consideration transitive dependencies. 

 Our engineers are enabled to be able to contribute back and patch and add features to the projects that we consume. We participate in standards committees, working groups, and the various activities that happen across the different foundations. It's about contributing back and earning a seat at the table to provide input to the collaborative shared roadmaps of open source projects that are earned through code contribution.

Alyssa Wright (Bloomberg): I think authentically giving back, sometimes, [is viewed with] the baseline as a certain amount of financial contribution. But I think a much more authentic conversation when we think about these communities that are making the technologies and the projects that are part of the supply chain is how do we contribute back in a way that is just as valuable and maybe more sustainable that goes beyond money? 

So, being part of governance boards and being part of collaborative shared roadmaps, earning a seat at the table so it's not just about code contribution or you paid your way, paid to play, but that you're authentically being part of a community's long-term, long-term success and health. 

Duane O’Brien (Indeed): There's really two facets of this theme that I want to challenge people to think about. One of them is for your own organization, figuring out what is reasonable to set as a target for you to give back to the open source community, and how you're approaching that. And what your framework is for deciding what's fair.

We know what unfair looks like, or we know what maybe bad citizenry looks like. But when you try to step into good citizenry, how do you know what's appropriate? How do you decide? And do you have a decision making framework? Are you picking a number out of the air? Whether you approach it by setting aside portions of revenue, or developer seat licensing, sort of frames of thinking for what you want to give back, that's a hard problem. And you're going to have to wrestle with it. 

The second aspect is that if we frame this as what we owe to each other, I think we're selling the entire problem and ourselves short. Because we are all part of the organizations that we're in for a very limited amount of time, and everyone in this industry moves around a lot. What we owe to each other today means something completely different in two years because all of the seats have changed. 

We need to think about this, also, as what we owe to ourselves. Because if we want the ecosystem of open source to be healthy and therefore, long-term, that is as much about making sure we are taking care of ourselves as much as taking care of each other. 

Deb Nicholson (the Python Software Foundation): It’s nice to have metrics on how much your company should be doing and how much you owe to this ecosystem, but I think it's worth thinking about how people are individuals. And if you are lucky enough to have someone who is embedded in a technical community that's really important to you, then you sort of have to let them lead. They might say, hey, I signed up for this working group or this committee, it's going to be like two or three hours a week for a year. But it's our turn, and it's my turn as an individual in the community to take on this extra responsibility. 

Duane: There's no shortcut for getting your hands dirty. If you really want to show up, you have to roll up your sleeves and dig into your dependency usage, how important it is, how healthy it is. And what leverage you have within your own organization that you can throw to encourage people and get them involved in these conversations. I think a lot of the dependencies that sort of fall into unmaintained status, it's because the work that's left to do isn't fun. 

Al: Over time, people will move on to the next exciting project. If we don't have a plan and a process for maintaining these projects, we wind up with old projects that nobody is paying attention to, which is potentially catastrophic for open source software. And that's something we can't afford to have happen in the industry. 

Deb: We need to teach people how to delegate and mentor new people. They need to be looking for probably four newer people that want to take on a quarter of the work they're not going to do in a year or two. But we don't have a good language about teaching that delegation and that passing the torch, so that you can go off and work on the new thing and leave it behind. 

Alyssa:  The goal should be that we want you to walk away, and have the project survive and grow far beyond you. But the janitorial work of keeping a project alive when excitement has faded—there's a lot for us to learn and to grow there.

Rob: There's some connective tissue here between the discussion we're having around open source contribution and open source security. If a project starts off with five maintainers that are roughly able to review five pull requests per day, then becomes three maintainers, that could be a leading indicator that the capacity to monitor and remediate bugs has probably lessened to some degree. Rather than making open source security only a matter of waiting for vulnerabilities to appear and then remediating them, how do we start to anticipate that this project looks like it is in trouble, and they need more resources.

Want to hear the rest of the questions and responses? You can watch the whole panel on demand here.