Upstream recap: Maintainer state of the union panel

On June 7th, for the third year in a row, we hosted Upstream, a virtual, one-day celebration of open source, the developers who use it, and the maintainers who make it. It was our biggest Upstream yet, with hundreds of attendees joining us in discussions about the current state of open source and how to make it better for everyone. 

In the final panel of the day, co-hosts Tidelift Upstream Chair and Senior Demand Gen Lead Amy Hays and Senior Product Marketing Lead Kanish Sharma sat with open source maintainers Jason Coombs, Gary Gregory, and Ceki Gulcu, to discuss the open source software supply chain, open source software standards, what maintainers would like from its users, and more. 

Below we share highlighted answers to a few of the questions posed by our co-hosts. To watch the talk in full, click here.

Thoughts on the overall health of the open source software supply chain

Gary: I see things pretty positively. I say this because it’s never been easier to start an open source project, to get it off the ground, and get things publicized. We’re so far beyond bulletin boards and mailing lists. It feels like a new open source project can take off and spread through the ecosystem pretty quickly. 

For projects like the ones I maintain that have been around for decades, maintenance can be an issue. I see that there are two broad areas of issues. First, security—the code gets old. The other issue is the ecosystem itself, the platform it relies on, is progressing and moving along. These both require active maintenance, otherwise projects get forked, they get dumped, or other unintended consequences. Overall positive but needs a lot of babying. 

Jason: In the ecosystem it feels like overall things are going great. The CI/CD is available and easy to adopt; the ecosystems are getting simpler but also more sophisticated. Users can get in and do a lot more now. Though, one concern I have is the barrier to entry because it used to be, you learn a source controlled system, you write some code, you push that code up, and that was all you did. Then there came CI/CD, linting systems, and it goes on. There is a lot to learn and to get that hello world out there takes a lot of work. I’d like to work on allowing a contributor to focus on their core value, whether that’s writing docs, writing code—writing value into the system without all of those other concerns. 

Regarding security, I feel like it’s fairly robust. There’s a healthy interest in improving security. In the Python system they’re adding 2FA to PyPI and I imagine that’s happening in other ecosystems as well.

Ceki: Things pile up especially if you have a project with a lot of users. Overtime, the maintenance burden is quite high. Each new report takes a lot of time to understand what’s going on. So the burden keeps piling up. Regarding security, what I see now is that there’s this circus about security. There’s a lot of noise and the signal-to-noise ratio is not good. There are serious bugs and vulnerabilities which are found from time to time, but most of the reports I get are not serious and it takes almost just as much time to analyze them. The decision to see if a bug is serious or not is a difficult one. You cannot discard security issues off-hand, but at a certain point you have to take a stand as well, which takes some courage.

How organizations can help open source software maintainers

Jason: I'd like to see the organizations that rely on open source and who profit contribute back in some way. Whether that means financially sponsoring the projects that they use or finding some way of feeding back into the projects that they use, ideally, in some proportion to how they use them. But also contributing to the emotional support—the community. Give your staff meaningful time to contribute. That contribution may not be code contributions, it may be taking the good culture that you've developed in your office and bringing that out to the open source community and modeling that for others and showing how to work through difficult problems.

Ceki: I think one of the ways of helping open source is sponsoring or funding projects, and this is very rare. There are individuals who sponsor projects on GitHub, but we're talking about very, very small amounts of money. Still, when somebody does the effort of sponsoring, even if it's five dollars, it's quite pleasant, but you can't live off that. I know for a fact that there are organizations with really significant amounts of funding, and they're still hesitating to fund open source projects. Their excuse is, how do we know which projects to fund, there are so many of them? This is an excuse not to do anything.

Thoughts on bringing standards into open source software

Jason: I don't particularly follow them all, but because I'm a lifter with Tidelift, I've been invited to be more involved. I’ve been incentivized to look into standards and these changes and see how they might affect projects. I'm approaching it with a little bit of skepticism. I want to be cautious not to add too much process, because right now I have a very small margin of time to work on the projects. If all of that time is spent on addressing a secure software development framework, it's going to leave the rest of the project essentially abandoned, and I don't want to do that. I need to find a good balance, a way to be compliant, and to give feedback to the process. 

Yes, we all care about security—we're not going to do anything that puts security at risk. We're going to take some measures, practical steps, that would be fair for any project to accept at the scale that it operates. I'm interested in helping there and I just want to find reasonable steps to improve the security that minimally impedes the productivity of the project.

Gary: I have a very pragmatic view on this kind of stuff, which is, if you care about something, give me a tool; give me something that's not going to suck up my time. At some point a couple of months ago, people were saying SBOMs [Software Bills of Materials] are important. Well, okay, great. I have found there's an SPDX Maven plugin and there's a CycloneDX Maven plugin—which one should I use? I don't know, so I use both. 

If you want something, it's got to be something very specific. Not vague rules of development or guidelines. If something can be enforced at build time so that I can validate a release, but also equally important, so that I can validate pull requests just the same way. If your pull request breaks whatever current development practices and checklists we have—great, that is less work for me to do and all I have to do is describe the project requirements to the maintainers and to the people who submitted the PR [pull request].

This recap is only a sliver of the eye opening perspectives on what it means to be an open source maintainer in post-Log4Shell landscape. You can watch the entire Upstream talk on-demand, revisit the other Upstream talks, learn more about government and industry standards and how they relate to open source, and explore the partnership between Tidelift and open source software maintainers.