Open Source Software Maintainers and Organizations in Conflict – Joe Brockmeier, Percona

This is Textron tv. Hey guys, thanks for the throw. We are here with Joe Brockmeyer, who's head of community for Poona, and we're gonna be talking about the tension that exists in the open source community, and between the folks who maintain it and contributed and those who consume it.

There are some terms like freeloading tossed around every now and again, but we'll dive into that in a minute. Joe, welcome to the show. Hey, thanks for, thanks for having me on.

I think a lot of the tension that we're hearing about surfaced, and it's been there forever, I think, but it's surfaced when we had some of these recent, uh, security breaches involving open source software and folks got a little upset because maybe they thought the maintainers were supposed to, um, you know, patch these things faster for them. And then it turns out the maintainers are like, excuse me, this is my weekend. I'll be, and I'll get to it when I get there.

Um, so what is your sense of, you know, where should we strike a balance between these opposing points of view in terms of, you know, what should people who consume open source software have as a responsibility to the overall community? Um, yeah, so I think you're referring to the log for Shell incident. Actually, when that was going on, I was volunteering as the VP of marketing and publicity for the A S F, so I got a front row or second row seat to a lot of that.

Um, and yeah, there was, there's a bit of tension between people consuming open source software and having the same expectations. There's, uh, a couple of good blogs out there, one about, I'm not a supplier, right? Where basically people look at, well, this is in my supply chain as software and I'm depending on this.

And they think that everybody in that chain is like the suppliers that they're used to, like Oracle or Red Hat or I B M or somebody. And some of those may be shipping open source software, but not everybody in that chain is a vendor that's getting paid for the maintenance and upkeep of that software. So there's a lot of tension there and what organizations should be doing, I think first of all is the log for Shell incident was a really good wake up call for how much open source, uh, organizations are consuming these days, how much they depend on it and their role or lack thereof in maintaining the ecosystem that they depend on and having awareness of what they're using and deploying.

Um, I think what they should be doing kind of varies depending on the organization and how they're using it, but, uh, a larger organization should be supporting open source. If you don't have anyone, if you're a larger organization, a thousand people or more, and you depend heavily on software and you don't have anyone on your payroll who is helping to maintain open source software in some fashion, or you're spending a lot of money with the vendors who do that, who translate money into open source, then you're probably not doing enough. And it's not a ethical question, it's more of a pragmatic question of are you taking care of the ecosystem that's taking care of you that you depend on?

So supporting vendors, uh, directly supporting open source, giving people time to contribute to projects, time to contribute upstream, making it easier. A lot of corporations say they want people to contribute upstream, but the legal red tape is this thick before they can actually, uh, you know, contribute something with an open source license outside the corporate firewall. Um, and in some cases contributing infrastructure, you know, so, um, companies like I'll I'll point at Amazon, do a job where they will give a little bit of resources to open source projects so at least they don't have to scramble for money to do, to have hardware or resources and infrastructure for testing and ci cd builds and things like that Isn't feasible for organizations just to contribute money to open source projects.

I mean, ultimately developers gotta eat. So, um, you know, is that part of the thought process? Um, maybe I think is a solid answer.

So I see things like Tide lift out there, trying to figure out ways to translate money into more open source development or give it directly to contributors. Um, it really depends. This is something that the open source community may have to take a step forward, um, on for contributors to find ways for corporations and organizations to give them money.

Because if you look at larger organizations, it's usually not as simple as saying, let's write Bob a check. You know, Bob has to be a taxable entity in some location. They have to be a supplier in the system and things like that.

So it's not quite that simple, depending on what it is that you wanna contribute to. Um, and so organizations on the open source side do need to take a step forward and figure figuring out that part of the infrastructure Bob may not wanna check. Right.

Um, at the end it's true too, at the end of the day. Um, it also seems to me like one of the most overlooked areas where people can contribute is documentation. I don't need to have a bunch of folks writing code all the time.

It seems like a lot of these projects just suffer from, you know, there's only a handful of people and very few of them have time to go through the documentation. So maybe that's an opportunity for, uh, consumers of software to make a big contribution that doesn't require, uh, you know, 10 stacks of legal documents. You're, you're a hundred percent right.

Documentation and other supporting things that aren't code are a huge, uh, thing that people could be doing. You have a lot of times, um, some of the prescriptive or some of the, you know, descriptive documentation, like this is what happens if you use this option, but not the, this is how you stand up this workload kind of documentation, or this is how you get to day two operations. So documentation and other materials to support that.

Um, just showing up in forums or, or slacks or wherever it is a community lives to support users. Um, it takes a huge burden off of maintainers if some of the power users of the software will respond to questions rather than leaving them for the maintainers. I think a lot of folks also seem to think that if they got a support contract from somebody who's curating open source projects, that somehow or other that money makes it back into the system.

But it's not clear to me it does. I mean, how efficient is that as a mechanism for supporting the open source community overall? I think you have to look at the vendor for that.

So if you look at some vendors, um, so like Perona, like, uh, my former employer Red Hat, I think it's a pretty efficient system because they do a very good job of supporting that, uh, ecosystem and open sourcing all of the software. There are other vendors who basically may stand up the software and not do a lot of upstream support. So you really kind of have to take a look at the specific vendor to see how much of the money that you spend actually translates back into open source code and stuff.

Upstream. There's also a little cynicism among the consumers of open source software, at least some projects 'cause uh, the project was created by a vendor and it's basically a somewhat hobbled version of something that they then have to buy and get support for and, you know, becomes a lead gen exercise for the vendor. So, um, is that, you know, I don't know if there's any way to change that, but it sure does kind of muddy the waters in terms of some of these open source projects that are, that are not all created equal, shall we say.

Sure. Vendor driven, open source and single entity open source is, um, you know, it's, it's, it's a open core is kind of something that has given people reason to be cynical, right? Because you can have something where once you get to a tipping point of profit or you know, enough users where they say, you know, we're gonna change the license on you, we're gonna do this or that and change up the script.

Um, I'm always a little wary of a single entity in the form of a vendor having complete control over a project. The other area we see a lot of focus on is of course security. Are there things that people who consume open source software could be doing specifically to help on the security side of this equation?

'cause it's not always clear to me that the people who are developing the software have a lot of security expertise in the first place. Yeah. Helping to support audits where possible, there's some upstream, um, or, you know, efforts like the Linux Foundation's security thing.

The name escapes me open Ss SS F or something like that. The name escapes me at the moment. Or working with, um, you know, foundations like the Apache Software Foundation and Eclipse to help them sponsor it.

So if you are a f if you are a sponsor of these nonprofits, helping to put some money towards that for, um, for smaller organizations, you know, for smaller projects it's a little bit harder, um, for an individual vendor to say, we're gonna sponsor a security audit because it, it's up to the individual project of, well, do they even want a security audit? Are they gonna respond? Uh, you know, all those kind of things.

So it is, it's a little trickier and I see some, um, you know, legislation being crafted both in the United States and Europe and the UK that's attempting to wrestle with that a little bit, but it has a potential for some unintended consequences that could actually make life a lot harder and create some unfunded mandates for open source maintainers, which we should be wary of Legislation and having unintended consequences. I know, right? Um, it's, um, yeah, I know.

Um, As you, we think all this through for a minute, I think one of the issues that organizations do have is they're not quite sure how to embrace open source. I mean, there's a lot of consortiums, there's different projects, there's individual maintainers and they just don't know where to kind of, uh, plug in. So what's your best advice to those folks about, uh, how do you get started doing the right thing?

I think number one is any organization of size should probably have an open source program office where they have some experts on staff who can help them navigate that and take a look at how substantial your use of open source software is. Um, it it, it really depends on the size of the organization and how you're using software. So if you're just running a couple of websites on WordPress and a little bit of infrastructure on Linux, this may not be an exercise that you need to undertake.

If you are an, uh, organization that's deploying a great deal of open source and a great deal of your infrastructure depends on open source, then you may need to look into having an open source program office that can guide you on that. Do you think organizations really know how much open source they're consuming? Because a lot of this stuff is developers downloaded a component, shoved it into something else, I bought a packaged application, but then it turns out that there's 22 open source components in that.

Mm-hmm. Um, but if people really understand what that level of dependency really is, Not all the time, and that's a whole, I mean, that's a much larger problem for your infrastructure in general. That's when you get to that level, it's not just an open source problem, right?

It's actually just a, I don't know what's in my infrastructure problem. Um, and so you need to get your arms around what your IT shop is doing, what you're shipping and what your liabilities are. Um, you know, it's, it's not something people like to talk about as much these days, but also are you shipping things that, um, someday somebody may raise a hand and say, where's the source for this?

You know, you're shipping this G P L thing or this A G P L thing. Where's, where's the source code? Um, you know, what are your, you know, if you're shipping something that's a G P L, for example, and you're using that in a user facing stack, Do you think that government officials are gonna get more involved?

We kind of joked about it a minute ago, but there is a lot of legislation, but also seems like there's an effort on the government side to maybe coordinate some of this information flow. So, you know, are they doing the right thing, Uh, to be determined? I think that, um, I think they are starting to think and talk about it.

And I like what I saw a little bit out of the, um, conversations that happened in the United States in terms of having, um, more awareness of what they're shipping and looking at how they can impact that. But I haven't seen concrete what's going to happen. Next steps I've seen, basically they've, they've said, we need to have the conversation, we need to get our arms around this, but we haven't gotten to the steps yet that, uh, will prove success or problematic or a combination of the two.

All right, folks, you heard it here. There's still a lot of work to be done and it's important to remember that gluttony is still one of the seven deadly sins. So with that in mind, review what you're doing with open source software.

Joe, thanks for being on the show. Thanks so much for having me, Mike. I really had a, a good time talking to you.

All right, back to you guys in the studio.