Recap: Maintainer state of the union panel

On June 7, 2022 Tidelift hosted an event called Upstream, a one-day celebration of open source, the developers who use it, and the maintainers who make it. All of the talks are available to watch at upstream.live.

At this year’s Upstream we focused on the question: What do we owe each other? Further, what does this question mean in the open source community and how do we continue to support each other?

Lyn Muldrow, maintainer advocate at Tidelift, led a panel discussion with members of the open source community to discuss what this question means to them. (Make sure to check out Lyn’s other Upstream talk, Lift up: Building a contributor to maintainer pipeline.) The panel included John Leider of Vuetify, Reinier Zwisterloot of Project Lombok, Brian Douglas of GitHub (formerly), Alex Clark of Pillow, and Jordan Harband of Coinbase (formerly). 

What are the highlights of your day-to-day life? 

Alex: The highlight is helping people, first and foremost, because that’s how my project started and that’s how open source projects typically start. I still enjoy that aspect of it, and in Pillow’s case, seeing a global user base means we’re helping people.

Brian: On the maintaining side, the highlight is bringing someone else into the fold. I know there’s a big mantra around “good first issues and contributing to the projects you use.” I find that is kind of disingenuous for the broader developer community because not everybody can contribute to ESLint or all these other projects [already] represented. There are so many other projects that need help. What I love to do is become friends with new projects that need help and that can use a scrappy pull request. I love party planning and connecting folks to these projects, because at the end of the day, once you learn how to do a pull request, you can do it anywhere.

The challenge is that you have to teach the basics and it’s hard to do that when you’re trying to board a steamship that is flying to the moon, attached to three Teslas.

"The challenge is that you have to teach the basics and it’s hard to do that when you’re trying to board a steamship that is flying to the moon, attached to three Teslas."

- Brian Douglas

Those projects do need help, but they need a very specific kind of help. I’m trying to divert traffic basically.

John: I started [working in open source] in 2017 full-time. So a lot has changed in the landscape as Vuetify has grown. First, I get to work with really experienced and smart people—way smarter than me. It’s like I get to be elevated to their level by having them around.

Second, even though it hasn’t been a thing in the last couple of years, it's starting to come back: in-person conferences. One of the best things for me is being able to geek out on something I was part of and helped build. So being able to interact and see the difference that the product can make in the community is very nice.

Jordan: I want to react to something Brian had said actually. Brian mentioned that not everyone can contribute to ESLint or larger projects, which is completely true, but I think that there’s a huge intimidation factor that is not accurate around that. Newcomers think they can’t do anything on these larger projects, older projects, or more complicated projects, and so they don’t tend to try as much.

I think that open source projects are 'a journey of a thousand miles begins with a single step' kind of situation.

I maintain hundreds of projects and that’s because I started with one. I kept working on it and eventually the maintainer was like, “Here, you do it.” Then I maintained a project and it just kept growing.

There’s nothing I want more than a co-maintainer on any of my projects with the stamina to do it for the foreseeable future instead of for just an internship period, a summer break, or a weekend. I want a lifetime co-maintainer on every one of my projects, but it’s hard to find those people. And it’s not for lack of looking. I am on the lookout for ways to encourage people to go outside their comfort zone and try to become a maintainer on these projects that seem intimidating, by just doing a little bit at a time and continuing to do that in a consistent way. I think anyone can be a maintainer on these projects.

"I think that open source projects are 'a journey of a thousand miles begins with a single step' kind of situation."
- Jordan Harband

Alex: You need to get [newcomers] in on a big project. You can recognize these people coming in and look at them like, “This person is going to contribute and they’re possibly one of those lifers like [Jordan] had just described.”

That idea relates to me too. I'll take a half dozen, a dozen, two dozen JavaScript [projects]—I don't even know JavaScript—but I'll take those projects and maintain them. That aspect is attractive, and I'm sure I'm not alone.

Lyn: I think personally one of the things that I have experienced as an open source contributor is a lack of diversity within the open source community that provides this barrier of entry and this lack of confidence. As a Black queer woman, is my pull request going to be seen or heard? It's kind of a homogenous community. Not seeing yourself represented within the community provides that lack of initial confidence to really jump in there and feel confident that your pull request is going to be seen, recognized, or integrated within the code and that you can consistently add to the open source community in a way that really feels impactful.

Is diversity for you a pain point and do you see the open source community moving toward a more diverse space and how?

Jordan: I think a big part of that is because in order to contribute to open source you often have to do it in your free time outside of your job. Having free time is a huge privilege not everyone has.

Many people have multiple jobs, they have family to take care of, they don't have good internet at home, or whatever it is. This is more of a systemic problem, but as far as you were talking about, Lyn, wondering how your contribution will be received or the reception you'll get, the only ways that I know of to sort of telegraph in advance that it is a safe place for anyone to contribute are things that can easily be seen as performative. Like a code of conduct or using main instead of master, things like that. Besides those and building up a track record of good behavior in that regard, I don't know how I can signal to folks that folks from all backgrounds are welcome. And so, if anyone has any ideas, I'd love to hear those.

"I think a big part of that is because in order to contribute to open source you often have to do it in your free time outside of your job. Having free time is a huge privilege not everyone has."
- Jordan Harband

Alex: I think you just said it. You do everything to make it inviting for everyone, and you treat everyone respectfully. I agree with Jordan in that I would join existing efforts for diversity to support whatever I could in that regard. I would hate to see anyone struggle with confidence in terms of joining projects and doing PRs. I think you also need a welcoming community. I feel fortunate that I had a background with this community of CMS developers. It was a rare introduction to open source, and that's probably where a lot of my confidence came from, a nurturing type environment. Perhaps some diversity nurturing groups or something like that.

Reinier: There's a Dutch guy who wrote a book recently. He's trying to move beyond the idea that a white male is privileged. He identified seven different things. It's white male, heterosexual, one rich parent, university study, grew up in an urban area that's fairly European-oriented, I think, and two others. I think I qualify for all seven. His theory that you are more or less sponsored by society or to put it in a different way, if you say something or do something and it is not particularly well accepted by whatever community you introduce it to, your first thought is not, “It's because of the color of my skin or who I am.” We're privileged. If somebody doesn't like my idea, it's, “OK, there's something wrong with my idea. Maybe I need to adjust or adjust my expectations or change my idea.” If you do not have these seven checkboxes, then maybe your first thought is, “Maybe my idea is fine, but I'm not accepted in this community for things that are completely outside of my control”’

If somebody contributed and they don't have all the seven checkboxes, [you could] thumbs up on the GitHub issue or give a slight clarification. It shouldn't be necessary, to be clear. If the idea is good, the idea is good. I think open source tries to espouse a meritocratic model. I'm not sure how you guys are, but as a seven checkbox person, I get this for free. I get this everywhere I go.  I'm always OK. I'm always vouched for simply by who I am, which I completely observed, so I owe it to everybody else that I vouch for them. I'm there for them. I'm not sure how we can get that message out, but that might be a place to start, right? Then we can move beyond the performative aspects.

And to be clear, I think the fact that everybody is renaming their master to main is a good thing.  It's hard to send signals. Anything will help, even if it is the fact we all notice, but we do it because we want to. I like that. What's the next step after the performative stuff is all done for? That might be a place to start.

Lyn: I definitely think it's that follow through and action after the performative things, which are greatly appreciated, but there are more things. Like you said, vouching for folks and instilling that confidence. Brian, I'm curious to hear your thoughts on this conversation.

Brian: I 100% agree with what everybody has said about privilege and access, but there is opportunity. There’s a talk I give about [Historically Black Colleges and Universities] and how that was a pathway for Black Americans coming out of slavery to learn trades. It's like a weird way to conflate this in an example, but folks were taught how to work in hospitality as a means to pull themselves up by their bootstraps, by actually giving people boots. My whole thing is if you hang around the communities enough, you eventually learn how things work and how to uplift yourself in open source.

Even with free time, I don't even do open source nights and weekends. I only do it at work, and I've done that since I was an engineer at my last company and before, and that’s because I do have small children and I'm a single income household as well. I try to put myself in a place where I can do on-the-job learning and training and stuff like that.  And when folks give me opportunities, I’ll say, “Yes, I'll triage your issues, give me six months.” I'll learn and eventually get a commit into the release. That's the approach I've been using in onboarding folks in open source in my communities. Put them in a position where they can at least see the process and see the privilege. Eventually, if they have the bandwidth, they'll jump in. If not, I'll nudge them a little bit more. If they don't, they'll move on. It's like having a framework to bring people in is the biggest thing. It might start with code of conduct and contributing, but it might also lead into, “OK, now you can label issues.”

Lyn: I think there are a wealth of things that we can collectively do, as was mentioned here, to increase diversity in open source and to make sure the packages we represent are open to newcomers and integrate, as Brian mentioned, some different ways for people to level up, learn, and be a second-in-command.

Check out All in Open Source, see what's being done to increase diversity in open source and make these pathways more accessible.

What do we owe each other?

Lyn: I want to move forward into talking about what we owe each other. Now this is such a loaded [question], why do we owe each other? Who owes anybody anything, right? I want to talk about how, in terms of your ecosystems, the people who come in and use your tools, say, enterprise-level clients or people that integrate your packages into their larger projects, what do they owe you in terms of standards, in terms of tooling, in terms of support? Are there things that you feel people using your packages kind of owe you, so that you can provide the best kind of support in things outward to them?

Jordan: I have a couple answers here. “Owe” is a tricky word because that sort of implies an entitlement, but open source tries to create a world that has a different socioeconomic driver than the world we live in, which is driven by capitalism. In the open source world, I would say nobody owes me anything but respect, and I don't owe anyone else anything but respect.  Literally in the license it says “I owe you nothing. You owe me nothing.” That's it. Because we operate in capitalism in real life, people's income can be affected by bugs in my software. My time fixing those bugs costs me money in some way. It affects my life in some way, right? It's time I'm not spending on maintaining my home, spending with my family, or earning income and so on.

I think it's a reasonable argument to make that if you're making profit off of free software, you on some level owe some sort of reinvestment of that profit back into the staff on which you depend. The U.S.'s legal concept of fiduciary duty speaks to that as well, but I think the word “owe” is a tricky one to apply because this implies an obligation that doesn’t exist. There might be an ethical one, but I probably wouldn't use that term [owe] to describe an ethical obligation.”

Alex: What I wrote for my answer is bug reports because I know this may sound like an oversimplification, but I've many times had the experience of using someone else's thing and coming across something that was small, but I knew was an improvement. Sometimes I did something about it and sometimes I didn't. I think all the time we owe open source developers our bug reports to try to make their thing better. I've had it done for me and I appreciate it. That is, again, perhaps an oversimplification, but still significantly important in terms of the difficulties of, “What do I owe?”

Reinier: At the end of the day, look around you and look at what the community does. Take Lombok, which 20-30% of all Java projects use. If there's another major open source project that makes it hard to integrate in tools, I say, “Look, you're going to have to file reports with them”. There are limits on how far I'm willing to go to support them. But I love getting contacted to make projects easier for users, even if I don't personally use their product or they don't use Lombok. I feel I owe some effort to the users of Lombok to take [issues] that aren't exotic. If 40%-50% of our user base wants something and I don't personally need it, I still feel more or less obligated to at least take it seriously, which I think most of us do, but that means reciprocating to other open source projects.

If you feel the same way, don't go, it's their [the other project’s] problem to solve. Talk to them and we can figure it out. I think we can do better on that. I tend to assume, “Oh, they've done a really poor job of integrating with Lombok so far, they probably don't care.” I need to train myself not to do that, to just talk to them because I'm sure I'm making it hard for other open source users. That's something I think we owe each other, assume the best and communicate a little bit more. That's maybe more something I should work on myself, but it's something I would love to see more of in the open source community.

John: I'm full-time open source. Primarily, I only contribute to the Vuetify ecosystem. I've kind of looked at myself like a politician over the years. I don't really feel that anybody owes me anything. As far as what I owe to them, it's just to do my best. Because Vuetify is so large, there's always going to be someone that's upset. Usually for me, I approach it as, they're probably having a bad day. They're just having a bad go at it and you're the target.

Earlier, there were a couple mentions regarding the equity and development contribution. From my point of view, in the past six years, I've really only ever seen it happen once, where somebody felt that they were disparaged based upon something to do with them. From my perspective and my community, it's not really something that I've encountered. It's my job to go out and reach people to get the resources that I need. I would owe to manage these things in a way to keep the project going.

Lyn: I want to thank each and every one of you for being here, for sharing your voice, for sharing where we are in the ecosystem as open source maintainers within the open source community. I deeply appreciate this time, and I hope you have gained a lot out of our conversation, so thank you so much for tuning in.

You can watch the full panel on-demand at upsteam.live.