Changelog Interviews – Episode #542

ANTHOLOGY — Maintaining maintainers

with Stormy Peters, Dr. Dawn Foster & Angie Byron at OSS NA 2023

All Episodes

This week on The Changelog we’re continuing our Maintainer Month series by taking to you back to the hallway track of The Linux Foundation’s Open Source Summit North America 2023 in Vancouver, Canada. Today’s anthology episode features: Stormy Peters (VP of Communities at GitHub), Dr. Dawn Foster (Director of Open Source Community Strategy at VMware), and Angie Byron (Drupal Core Product Manager and Community Director at Aiven).

Special thanks to our friends at GitHub for sponsoring us to attend this conference as part of Maintainer Month.

Featuring

Sponsors

GitHub – Harnessed for productivity. Designed for collaboration. Celebrated for built-in security. Welcome to the platform developers love.

SquareDevelop on the platform that sellers trust. There is a massive opportunity for developers to support Square sellers by building apps for today’s business needs. Learn more at developer.squareup.com to dive into the docs, APIs, SDKs and to create your Square Developer account — tell them Changelog sent you.

Sentry – See the untested code causing errors - or whether it’s partially or fully covered - directly in your stack trace, so you can avoid similar errors from happening in the future. Use the code CHANGELOG and get the team plan free for three months.

Typesense – Lightning fast, globally distributed Search-as-a-Service that runs in memory. You literally can’t get any faster!

Notes & Links

📝 Edit Notes

Chapters

1 00:00 This week on The Changelog 01:31
2 01:31 Sponsor: Square 02:54
3 04:25 Start the show! 00:47
4 05:11 Who's running GitHub Sponsors? 00:49
5 06:00 GitHub Sponsors' mission? 00:44
6 06:45 Sponsors now open to companies 01:04
7 07:49 Traction with companies? 01:38
8 09:27 What's a typical give? 00:25
9 09:52 Best has been FOSS Contributor Fund 00:42
10 10:34 Open Source pricing page 01:00
11 11:34 Maintainer guilt? Nah. 02:27
12 14:01 Serving a "Term of Service" 02:58
13 16:59 What's next for Sponsors? 01:56
14 18:55 GitHub Accelerator like YC? 04:38
15 23:33 Maintainer dashboard? 05:46
16 29:18 How do Maintainers get paid? 00:55
17 30:14 Sponsor: Sentry 04:13
18 34:27 Dr. Dawn Foster on the mic 00:55
19 35:22 PhD and the Linux Kernel 02:41
20 38:02 CHAOSS 01:11
21 39:13 Is there a score? 01:48
22 41:01 Measuring trends and who cares? 02:49
23 43:50 How is the data represented? 02:25
24 46:14 Choosing which metrics to meassure 04:26
25 50:41 Why push back on scoring? 02:38
26 53:19 How to recruit contributors? 02:13
27 55:32 Getting started with CHAOSS 00:40
28 56:12 Sponsor: Typesense 03:18
29 59:29 Is Drupal still a big deal? 01:28
30 1:00:57 Still in the Drupal community? 01:30
31 1:02:27 Adam really enjoyed episode #321 00:50
32 1:03:17 What's your maintainer story? 02:49
33 1:06:06 How did you decide "what's next"? 02:24
34 1:08:30 Licensing and "not open source" 02:31
35 1:11:01 This is where it gets icky 01:42
36 1:12:43 War for the soul of open source 08:11
37 1:20:55 Maintainer anti-burnout 03:12
38 1:24:06 Be a cog, not a linchpin. 04:10
39 1:28:16 Outro 01:43

Transcript

📝 Edit Transcript

Changelog

Play the audio to listen along while you enjoy the transcript. 🎧

GitHub Sponsors… What is the state of GitHub Sponsors?

So GitHub Sponsors is now generally available for companies, as well as individuals, to donate money to maintainers. Or give money to maintainers, not donate.

Yeah. It’s been a journey. You’ve had a couple people in charge of it, and the last time we talked to Jessica Lord, she was – just about a year and a half ago, was it?

Probably…

She came back to GitHub. She was a boomerang.

She loves GitHub so much…

I’m glad that she came back.

Yeah. She’s awesome.

She’s not still in charge of GitHub Sponsors, right?

She’s not doing Sponsors now.

Okay. Is anyone in charge of it? Who is in charge of it? How does it work?

We actually have an open job rec right now. If you would like to be in charge of it, you could apply.

Gosh… I could slay that.

But it’s actually for a team that’s going to be looking at how to change the open source ecosystem so that we fund maintainers in ways that aren’t just a paycheck.

Yeah. It’s a tough job. Who could do that job well? what would they have done beforehand to do that job well?

It’s been kind of fun trying to recruit. We really want someone who’s passionate about open source software, who has some kind of background in it.

We love open source. You know that, right?

We could pair up on that job, Jerod.

We’ve got jobs…

I’ve also interviewed people who were in insurance before, and so just in insurance models… I’ve interviewed people that were in venture capital money… We’re just kind of experimenting with who can bring new ideas to this space.

It has to begin with the desire. What is GitHub optimizing for when it comes to sponsors? What does GitHub want with Sponsors in general? What are the possibilities?

[06:11] Our ultimate goal is to make open source software successful. So that means providing ways for maintainers to have time and energy to invest in open source software. But part of that solution is helping companies understand what dependencies they have, and making sure that software is secure and reliable. So companies, some of them know they have dependencies in open source software. They really want to help make sure it’s reliable. They need someone to help them if it goes down. And they understand money is part of that solution. So how do we help them provide that, how do we help maintainer say, “Here I am, here’s how I can help you”?

Right. That sounds like a challenge. So you said it is now available to companies…

It was always available to companies, but until recently, they had to pay via credit card, which - how many people at a company can put a couple hundred thousand dollars on their credit card? So we added things like invoices, and normal corporate things.

POs, and stuff like that, right?

I see. So you greased the kids, as they say, for companies to be able to actually give at a higher clip than they could with some sort of corporate credit card.

This has been an effort in the making, because I know when we talked to Jessica, that was the plan, to get there. And you’re saying now it’s available.

Okay. How has that changed things? Has the giving or supporting gotten easier? Has the amount increased? What are the stats behind this new feature being there for sponsors?

Yeah, I think it’s worth looking at before we were generally available; in just our beta program we already had like $30 million flow through the program, so obviously, there was a high demand for it… And we just GA-ed a couple weeks ago. So I don’t have numbers, but I can tell you that there are new companies signing up for it.

Okay. Okay, can you speak to the excitement, then? I mean, there’s no traction to compare –

Oh, there’s traction.

What I mean by that is it’s so new there’s not a lot of details you can share here, because it’s fresh. What’s the response from those chomping at the bit to get access to this is? Is it a lot of companies desiring this?

I think a lot of companies want to make sure the software they use is reliable, secure, and that they recognize that they use it, that it’s kind of – I think that people at companies want to make sure they’re fair. I always say, companies aren’t people, and they aren’t motivated like people are.

Right. There’s no emotion.

Or there’s no sense of give and take the same way people have it. Say I go out of town, and I ask my neighbor to like come feed the cat every day. And when I get back into town, I’m like “Oh, she did me a huge favor, so I’m gonna take her some apples from my apple trees.” So I take apples over to her, and she goes, “Wow, this was like a lot of apples just for feeding the cat, so I’m gonna make an apple pie”, and she brings me back an apple pie. So this give and take that we take for granted as humans - someone in a company has to do that, because a company doesn’t do that.

Right. They’re profit-generating machines, so the people have to like step out of the norm in order to do that. But people do want to step out and do that.

So we’re trying to give them tools, like “Here’s your dependencies. Here’s the dependencies of your dependencies.”

Okay, so all that stuff exists now inside of – is it like inside the Sponsors dashboard, or is it just inside of GitHub’s, like…

Various tools have it. So we can help you as Sponsors, we also have an OSPO dashboard for corporations, where they can see what they’re using and what they’re contributing to…

Okay. That’s cool. So what’s a typical give out of a corporation these days?

Companies would also like to know that… We actually had one company that came and said, “I want to make sure that I don’t look like I’m giving too little.” And they were willing to give a couple hundred thousand dollars, but they were afraid it would look too little. So I think we need to establish some norms…

Right. So that’s still kind of playing out. We don’t know what the norm is.

We don’t know.

[09:52] The best indicator that has been the FOSS Contributor Fund, to some degree… And we just talked to Chad Witacre - the show’s out there - as part of this episode we did with Maintainer Month, and whatnot… And essentially, he did some back-of-the-napkin math, and it was like 2k per engineer to the software that they depend on, essentially. So if they have 50 engineers - this is a round number - 2k. You do the math.

Yeah, but you can look at it in a number of ways. You could look at how many engineers does your company have, how much soft money do you make off the software you build on it? How many different software projects do you use? You could offer up a whole bunch of formulas, and I think we probably just need to pick one and suggest something.

We had this entire conversation, Stormy… I really wish you would have heard it… I’m gonna paraphrase it. We talked about this idea of a pricing page that a SaaS company might have for them. You’ve got the free tier, you’ve got the pro plan, you’ve got the business plan, you’ve got the enterprise… And essentially, we need an on-ramp to fair funding of open source, whether I’m an individual, or a small team, or a larger enterprise. The idea of fairness, I think - they ask you all, GitHub Sponsors, “Hey, what is fair? What should I give? What’s too little, what’s too much?” There’s no real, I guess, documentation out there of what fair is. If you’re in this realm, maybe 2k per month is too much for you, but it’s at least a good place to start. Maybe 2k per month – or sorry, whatever the number is; 2k per developer… Maybe it’s more like 500; or what is a fair number that makes sense for you? How do you quantify that? Give them some sort of algorithms, basically, to sort of figure out what fair really is for them.

And it also depends on what the maintainer wants to be responsible for, or commit to; I’m not quite sure the right word there. What if I wrote it last summer, I had a month off, and I wrote this really cool library that solved a need for me, and I put it out there? I’m done with it. I did it, I put it out there. If you tell me it’s being used in hospitals and someone’s dying, I’m going to come back and help you. But I have another job, I have a family… I’m not working on it anymore. That’s a really different scenario than someone who’s trying to make a living off of it, develop the library, wants to keep improving it, wants to hear feedback, wants to help you however you’re using it…

I talked to someone last night at dinner, and he’s like “I have a job, but they’re using my software, and I try to help them… I look at their pull requests, I send them emails…” He’s in a very active role in his project. Those are different scenarios.

Maintainer guilt.

Not guilt…

He wants to.

You’re solving a problem for the world.

He wants to do it.

But he would probably have more time to do it if he got compensated more.

Right. But also he wants to do it right now, but three, four or five years from now his life changes, he doesn’t want to do it anymore… Now he gets the maintainer guilt of like “Well, all these people rely upon me. I’m burning out, I don’t want to do this. I’ve got a baby now”, or whatever it is…

That’s been a theme. That’s a theme for Maintainer month, and it’s also - it was a talk yesterday, of how do you do succession planning?

Yeah. How do you do succession planning?

I’m definitely not the expert. I could find you the speaker of that talk.

We have talked about that…

We’ve asked a few people that question…

It’s like getting to Rome. There’s just so many roads to get there.

Yeah, I think it definitely is building out your community and building trusts along the way. You have to put other people in positions of trust, so there’s someone to fill your shoes when you leave.

Yeah, that’s the easy way to do it – I mean, not the easy way, but that’s the right way to do it, I guess… Versus like one day being like “Okay, I need a successor.” Right? “But I haven’t been preparing for this day at all. But I need one right now.” And so - what, I put out a post on my social, that’s like “Someone please take over this project for me?”

“Please help.”

I think we could learn a lot from nonprofits in this space. I think they have the same problem.

Okay. How so?

So a lot of nonprofits don’t have people on salary, a lot of the smaller ones…

Yeah. It’s all volunteers.

Yeah. So if the person running it wants to leave or go do something else, they have to have a succession plan as well.

[14:01] Well, we talked about having Terms of Service, to some degree… Like, if you want to be maintainer, or you are a maintainer, or you want to bring on a contributor, a terms of service… So what you’re saying is if you need to leave, or you need to step away, the social construct should be playing for successor; invite a successor, have some sort of plan. Just don’t leave your station abandoned.

And I agree with that. That would be great, [unintelligible 00:14:25.12] and especially if other people are using it…

For sure.

But I agree with that as well. Like, it’s much easier to get people to step up to positions in your project if you’re clear about what they are. Like, “Hey, if you submit five pull requests, and I pretty much accepted them unchanged, and you’re always there when I send you an email or a DM, then I’m willing to consider you for this role.”

Right. And if you accept it, when you leave - which is cool - please help me find somebody who might be suitable.“And the please might be more “You have to”, versus just simply please.

Can you say that though?

Well, what I’m asking, I guess, is should we – there’s no perfect way to do this, but maybe the version that gets deployed in most cases is like if you accept a position on a project that has, I don’t know, some usefulness, some threshold of usefuless, and you are a crucial person because you’ve accepted a role as a maintainer…

Maybe you agree to mentor a certain number of people, or something.

Yeah, exactly. Something that says “I care about my team, my other maintainers and this project enough to accept the role, because I like it… But also, if I need to step away, some sort of responsibility to ensure non-breakage”, you know?

So one of our GitHub students, [unintelligible 00:15:45.09] GitHub Education shared with me a tip that he learned yesterday, which was instead of – you know, someone submits an issue; instead of just writing code and solving it and doing your own pull requests and closing it, they suggested writing out like the whole problem, and how you saw the solution. It would take as long as just solving it, but writing it up and describing it, and then putting it out there for someone else to be able to pick up is a good way to grow your project.

Oh, yeah. Don’t repeat yourself.

That’s so forward-thinking though… It requires discipline and forethought… It’s hard to do that all the time, where you’re just like “Well, I could just fix it real quick…”

Especially if you like writing code and you like your project.

Yeah… “I like to write code, I don’t like to write prose very much… I started this because I like coding… I’m just gonna cut this up real quick.” But you do that over and over again, and eventually it’s just a recipe for disaster; as your life changes, as your desires change…

But you could write prose for the problems that are kind of boring to you, and then save the interesting ones for yourself.

Yeah. Just don’t tell anybody that’s what you’re doing. [laughter] “Here’s a bunch of boring issues, guys… You guys handle those. I’ll take all the fun stuff.”

It might not work to grow your project…

Companies can now contribute to open source via GitHub Sponsors in new ways, not just credit cards… POs, larger checks, etc. What’s the next major thing for Sponsors? What are you working on? What does the Sponsors team, or this new leadership - what’s the next plan for GitHub Sponsors?

Yeah, so I think there’s still features we can add in the product. We talked about being able to see all your dependencies, and all those dependencies, and contribute with one click… There’s things like that we can add. But we also have a couple other programs that we’re experimenting with, and we’re bringing them into one group… So we have an accelerator program that’s going on right now. It’s a 10-week program, we have 20 people in it in this round, $2,000 a week. And they meet a couple times a week, they get like mentorship, they get to meet each other… And these are people that want to take their project to the next level. And so we’re figuring out what do they need, what can we offer them, and then hopefully what can we build into Sponsors and the GitHub product to help all maintainers who want to take their project to the next level?

We also have the GitHub Fund, because it’s really hard to get venture capital money when you are writing your company’s code in open source. Venture capitalists like to think you have a secret sauce. And so we have the GitHub Fund that actually funds open source software projects, that are companies, startup companies.

[18:17] Interesting.

And that’s GitHub proper that funds it, or they’re pointing to other people’s money? How does it work?

It’s a partnership with Microsoft’s M12 venture capital fund.

How does a project get selected? Is it an application? Who gets funded, how do they get funded?

Most stars…?

The accelerator program is –

Yeah, most stars…8

[laughs] Yeah, most stars… The accelerator program is an application. So someone who’s interested in taking their project to the next level applies, and we selected them. On the GitHub Fund, we actually try to source them and find them, and then we reach out. They could also reach out, but we actually do a lot of research to try to find them.

Will you do the accelerator package or process as part of like batches? I’m thinking like YC, for example. You have YC batch X, and maybe this is a version for open source where the Accelerate – is it called Accelerate?

Accelerator.

Accelerator. This Accelerator program, that - maybe this first batch is like “Hey, we’ve helped these maintainers level up their projects…” Maybe the GitHub Fund is right after that for them potentially, to throw some money in there, or whatever it might be… Is there a thought around that process? To repeat it.

Yeah, we’ll definitely repeat it. I hope with all the things that we do, that we learn and iterate. And I’d love to see us build more and more into the product, so that we can make it available to everybody. Like, maybe when you reach 5000 stars – I know we were joking about it before, but when you reach 5000 stars, we know it would be really helpful if you knew about GitHub Sponsors, and had a list of tips and tricks that work really well with it… And so we somehow surface that.

Right. Behind the scenes we’re hearing that a lot of the activity on GitHub is done by like one person in the repos… And that’s kind of part of like funding open source. Like, there’s a lot of activity in GitHub around open source and maintainers and whatnot that’s in like a very small percentage. How as part of GitHub Sponsors - do you have active reach-out to those kind of folks? Are you looking at the 1% that’s got a lot of activity? How do you kind of quantify or narrow down who to help and how to help them?

So GitHub Sponsors, individuals and companies are deciding who they want to sponsor. We can obviously offer suggestions, but ultimately, it’s down to you deciding that you want to give Jerod like $10…

So you’re handing out shovels and picks; you’re not giving maps.

We’re trying to provide maps. We’re not providing rules, and saying “You must turn right here.”

Yeah. Guides.

Well, you said at 5,000 stars you may be. So that made me think you might have some proactive outreach as part of Sponsors.

I would love to start doing that. But what I wanted to say when you asked what’s next - I hope we learn from the Accelerator this round, and learn who is interested, who came, what did they learn, what was the most valuable for them? What kind of problems are they encountering? And we iterate.

Yeah. But in terms of the Sponsors, the product, it’s pretty much what it is until we get this new person to come run product, right?

We have a team working on Sponsors, but we’re hiring a new lead –

A lead for the team.

For Sponsors and Accelerator together.

Okay. Because I know when we spoke with Devon Zuegel originally, when she was finished with her work there, and probably when we were talking with Jessica as well - you know, there’s other ideas of ways of providing funding for open source, through Sponsors the product, that’s not…

Well, no, it’s money, but maybe you have – so bug bounties is one idea… Of like “Well, we have issues, we have all these things… Through Sponsors maybe we could also provide funding through bug bounties.” And I remember asking Devon about that, and she had her ideas on it, and then I think Jessica had her ideas… But in terms of changing the product dramatically, or like adding to it, you’re looking for a new leader. Is that fair?

[22:07] We’re still working on the product, and we’re hiring a new leader. And I would hope with things like bug bounties, that what we’re doing is making it possible for you to host a bug bounty if you want to, not that you’d have to have a GitHub bug bounties to sign up for.

Sure. No, I mean, the idea there is like, “Well, you could just build it right into issues.” And so you open an issue and say, “Hey, I would love for this issue to be addressed. Here’s $1,000.”

Or maybe we could all bid on it. We can all say “I’ll throw $10 into the pot.”

Yeah, exactly. Pool the money.

Yeah, for sure.

So those kinds of ideas… Maybe a good idea, maybe not a good idea, but ultimately, the Sponsors team has to decide what’s going to be worked on… And so I was just wondering if the product’s moving forward, in the meantime, while you’re looking for someone to lead that team, and it sounds like they’re still working on stuff…

They are.

…but this Accelerator thing is super-cool, by the way. I remember covering it in Changelog News, and seeing a bunch of projects getting money, and they’re all excited, and they get mentorship, too… Right?

So hopefully –

They get mentorship, and a cohort…

Yeah. I mean, hopefully, that whole deal really helps them, and then we can learn from it, like you said, and do it again, and help more people.

Yeah, because when I started in open source, it was definitely everyone’s dream, was to get a paid job working at open source software. And everyone that got one, it’s like “How did you do that? How did you convince them? What are you working on?” And that’s been great, and it’s expanded, and many of us get paid to work in open source… But I think there’s more models that we could add to it.

Absolutely.

Is there a maintainer dashboard, or a place that a maintainer can go, or something where they can go see “Here’s what GitHub Sponsors has available to me”? And I’m thinking beyond – just a place to get educated on how GitHub Sponsors can help them sustain their project, whether it’s through donations, through sponsors… I’m thinking about even - there’s a lot of, I guess, SaaS companies, service dev tooling that give away their tool for free to open source contributors, or to maintainers… And is there a dashboard to go on and say, “Okay, I can go get Sentry for free, because I’m in open source”? Or there’s XYZ program, where they may be spending their dollars on this stuff, and they could be getting it for free. Like, some way to say, “Here’s my access to the maintainer kingdom that GitHub Sponsors has orchestrated for me. A dashboard that says I can do Sponsors, I can get money from here, I can get support there, I can get cohorts here, I can learn about Accelerator here…” Is there a place for that?

So you can go read about GitHub Sponsors and maintainers and GitHub Fund. Now, we don’t offer maintainers free software, but if you are a student interested in open source software, and you sign up for GitHub Education, there’s a whole student pack of free software that you can get.

There’s a repo that you can find, something along the lines of –

Awesome OSS, stuff like that…

Yeah, it’s like “Free for open source. Awesome–” It’s an Awesome list.

It is an Awesome list.

And it’s just gonna be maintained. And it’s a list of Sentries, and BitBuckets… I just made that up; I don’t know, is BitBucket still out there? Other things… Things that have a free plan for open source maintainers. And that’d be one place people could go, but… Just throwing that in there.

Well, to me it seems like you all have the great opportunity to connect dots. The dots are on GitHub. That’s in a repo, right? It’s in disparate places. Centralize…

We’re always looking for new ideas –

Bring it together…

A maintainer dashboard. That needs to be your next big thing. “Where can I go as a maintainer to find out what’s available to me to sustain?” Funding, people, free services… I don’t know. Bug bounties…

So when you say maintainer dashboard, what I always think about is - when I talk to maintainers, they tell me… They’re not asking what they get for free; what they’re asking is “How do I know who contributes to my projects, and how do I know who this person is? And the last time they were active. And did they submit this code on behalf of GitHub, or Microsoft? Or are they an individual?”

Right. That would definitely be a good thing to put in that dashboard, too.

A lot of things.

A lot of things. We could create a project.

[26:08] There’s kind of two sides to an open source project, though. There’s the running of it, and the creating the software, and like managing the community, potentially finding contributors, or identifying three-time contributors who may get an opportunity to become a full-time, or core team member, or whatever it might be… And then the sort of the somewhat lesser-known business side of it, where it’s not really the business side, but it’s not development. It’s more admin type stuff. That’s what I think this dashboard should maybe have, where it’s like “As an admin of this project, what’s available to me to sustain this thing.” Not only just that, but those things, too.

That, and I think we need to make sure developers and maintainers have tools to do their job well, and to get funding, whether it’s through Accelerator, or GitHub Fund, or Sponsors, in a way that doesn’t require them to become marketing and social media experts. I kind of feel this way about all small businesses, not just software; if you have a really awesome hairdresser, or massage therapist, should they have to become business experts as well? In our current model, they do. Same thing with writing code… Like how do we – for the open source software developer community, how do we help them be successful businesses, in a sense, without having to go be marketing people?

Right, precisely.

To a certain extent, that’s being built through the dependency graph… So you have the distribution. Of course, there’s different kinds of open source, but let’s just talk about libraries, where I write a library, and maybe it’s really fast JSON parsing, and everybody starts using it… Now I’m in their dependency graph, and now when these companies come to GitHub Sponsors and they say, “We’ve got 300k for the year. Here’s the invoice.” It goes into my – I’m sure I get a wallet, or something, and I’ve got a stash of fake money there that represents the money that I put there… And now I can divvy that out. And you’re showing them “Okay, you’re using this project. That project using superfast JSON library by Jerod. He’s available on GitHub Sponsors”, and so trickle down in that way, right? That’s what you’re trying to build. Or do you guys – is that there today? Can you do that today?

Yes. It’s not as simple as just clicking a button, but you can do it.

Okay. But you can see it at least.

And that’s the goal. You as a creator should get some kind of compensation for the thing you created that is now powering businesses around the world.

Exactly. So all these businesses - maybe they don’t rely directly on me, they rely on this framework, that uses me… And the framework gets 10 bucks, and for every 10 bucks they get, I get a buck, or whatever it is.

Or maybe get 10 cents if they use 100 libraries. But once a thousand companies use it, that adds up.

Right. So now you have a distribution of your software, but you also have distribution of your sponsorship along that same graph. I think that’s one way to do it without being like “Hey, I’m out on Twitter, talking about my fast JSON parsing library…”

We do have someone who shames people on Twitter… They talk about using his product, and he goes and says, “Oh, that’s great. Would you like to contribute on GitHub Sponsors?” And he’s actually pretty successful at it.

Okay, so there’s a hack…

Yeah, I like that.

But if you don’t want to be that guy, or gal…

You could just write a bot, so you don’t have to deal with that every time… [laughter]

There you go. There’s always a bot for that.

Bot Jerod, or Bot Adam.

Yeah. Cool.

Maybe one more facet is how do maintainers get paid? How easy is it for them to extract the dollars from the donation, from GitHub Sponsors?

It’s a Stripe payment.

Okay. So they have to maintain a Stripe account, deal with taxes, of course…

Is that a struggle? Is it a struggle that you all care about, I suppose? I’m sure you do, but like product-wise today…

We’re always looking for – we’re always listening to people, and asking them how they like to receive money. So right now Stripe seems to work for a majority of the people, but the majority of the people that we’re listening to are the people have signed up. We’re also looking at partnerships with other funding methods to see what else we can add.

Yeah. Well, cool. Big problems to solve, Stormy.

Fun problems.

Thank you.

Yeah, thanks.

Thank you.

Break: [30:08]

So we’re here with Dawn Foster from VMware. How are you doing?

I’m good, thanks. Thanks for having me.

What do you enjoy about conferences like these? What’s your favorite part?

Oh my God, it’s the people. So you get to run into people that you’ve known for years, you get to meet new people, and you get to reconnect with people, you get to have interesting conversations… And when we were all virtual, through, the pandemic and lockdowns and things, it just wasn’t the same… Because you don’t get those serendipitous conversations. You know, [unintelligible 00:35:06.27] is not gonna drag me across the room to do this podcast in a virtual environment, right?

Well, maybe not drag… But did she drag you?

No, she didn’t drag me. She very kindly asked me if I would like to do one right now.

I watched you guys walk over; you were a willing party…

So Kara was telling me that your Ph.D. had something to do with the Linux Kernel… And I was like “Tell me more”, and that’s all I got so far. So can you tell me more?

Yeah, absolutely. So a few years ago I decided for my midlife crisis I was going to move to London on a student visa, and get a Ph.D. And so I found a university I liked, the University of Greenwich in London, and they had a center for business and network analysis, and I pitched them an idea to do network analysis and study the people networks within the Linux Kernel. They said, yes, they let me do it, and so I spent three and a half years studying the Linux Kernel. And so I gathered a bunch of data –

Three and a half years…

Yeah, because that’s what a Ph.D. takes.

Or - it can take more, but I did it in three and a half. But yeah, so I looked at collaboration within the Linux Kernel, I look mostly at mailing lists, because that’s how the Linux Kernel works; they don’t use GitHub, it’s not pull requests, it’s patch diffs, mailed back and forth on the mailing list… So yeah, so I looked at mailing list data… I looked at some source code data as well, but I just did a whole bunch of analysis.

What did you learn?

So it’s interesting… I also did interviews with some of the Kernel developers… And one of the things that they’ll tell you is that timezones don’t matter. It doesn’t matter where you’re located around the world, it just doesn’t matter. And turns out that’s true. That’s what the data showed, was that it didn’t – I wouldn’t collaborate more with you because we’re in the same timezone. For whatever reason, it wasn’t significant. And it was interesting also - one of the things I’ve found interesting is that two people who work at the same organization were also more likely to interact with each other on the mailing list… Which I’ve found – I was surprised by that, but I really like it. So I like that companies are interacting in public on the mailing list, instead of just sending each other Slack messages, walking over to somebody’s desk and talking about something. So I’ve found that kind of interesting.

I wonder if there’s something about public mailing lists… I guess maybe they allow this research to even take place, because a lot of other forms of communication potentially may have not been reachable by you as an outside analyst. Right?

Yeah, exactly. So that’s one of the beauties of open source, is that you’ve got all of the data, because it’s all in the public. I mean, now - so I do some work within the CHAOSS project, and outside of the CHAOSS project as well, but I spent a lot of time in the GitHub API, and just pulling out data on open source projects, and looking at what’s what, and just trying to get a feel for different aspects of the project.

[37:58] Poking and prodding. That’s so cool.

Poking and prodding, yes.

So CHAOSS… This is Community Health… Help me out with the rest.

Community Health Analytics for Open Source Software. So CHAOSS with two S’es.

CHAOSSS…

Yeah. So we basically – I’ll give you an overview of what CHAOSS is. We are a project and we’re focused on kind of two things. We’re focused on metrics, so defining metrics, so that we can be – when we talk about a certain metric, that we can be consistent about what it is, and have a definition that we can point people to, and we say… When we’re talking about numbers of lines of code, that’s what this means. When we’re talking about the bus factor, which is how many people you have contributing to a project, that we measure that kind of the same way. So we do metrics definitions, and then we do software.

So we have two pieces of software within the CHAOSS projects. We have Augur and GrimoireLab. And those are both – they’re basically software projects that go out and they gather a bunch of data from various sources… So GitHub, obviously, Slack, and other things that you can – basically, anything with an API that you can get access to the data from… And allow people to analyze that using software.

Pretty cool.

So do you have some sort of a score, or how do you quantify the health?

That is an excellent question.

Thank you!

No, we don’t have a score. And I am anti-health scores. So what I like to look at when I’m looking at project health is I like to look at trends. So are you closing more of your pull requests? Is your pull requests backlog getting bigger or smaller? Are you responding to pull requests and issues more quickly, or is it taking you more time? So I like to look at trends over time, and I like to look at metrics in the context of projects, because individual projects have certain ways of working, and certain things that impact the metrics, and unless you part of the project, you don’t know.

For example, if I work on a project and we’re cutting a huge release, that has a bunch of breaking changes, there’s probably going to be some weird things in the metrics associated with that… So pull requests, you’re getting a backlog while you get everything together for the release, for example…

I was talking to a friend at Google, Sophia Vargas, and she does a lot of analysis on things like Kubernetes. And some of the metrics that she was looking at made just no sense, because the way Kubernetes works is you’ve got bots that do all the things. So you have bots that respond to things automatically, the bots close issues automatically after a certain amount, they go stale, they close them… So there’s all this bot activity that she was looking at data and she’s like “This makes no sense.” And she went and talked to some people, and they were like “Oh, yeah, that’s the bots. That’s what they do.”

It is normal to them.

But unless you understand that, you can’t interpret it; it doesn’t tell you anything about the health of the project unless you understand what’s going on within the project.

So it’s a hard job then, I guess, to quantify… And so when you say you like to look at trends, you’re basically measuring the health of the project relative to its past health. Why is that beneficial, I guess? Just to see where they’re headed, or – I guess, who… I don’t wanna say “Who cares?”, but actually… Who cares…?! No, who’s the person, or the org, or the entity that says “I care about the future health of this project”? Is it foundations, is it individuals? I would come to it as an individual and think – this is why I’d want a score, is because my question is “Do I want to get involved in this project? Do I want to use this thing? How’s the health of the community?” I look at the GitHub Pulse tab, the insights… Not super-useful, but it’s there. Because I’m trying to gauge “Is this a dependency that I’m willing to take on?” perhaps. So that may be one angle into caring about the community health of a project, overall health… And so I would like to see “Well–” I mean, trends would be useful, but if it’s starting from a really bad place, and it’s trending up, but it’s still maybe not the nicest place to hang out… Long-winded question. Who are the users of your information, I guess? Who’s the end user?

[42:22] Yeah, so it depends. I think all of those people are end users of metrics. So part of the reason that I look at trends is because – let’s talk about from a VMware perspective, from a company perspective…

I want our maintainers to look at the projects and use the project health metrics to decide where they need to improve. So if they’re responding to pull requests really quickly, then that’s great. But if they’re never closing any of those pull requests, maybe that’s where they need to focus. So it gives them a place to focus.

And the reason I like to focus on trends is because what I don’t want is somebody getting all hung up because their number is going down, but maybe it’s going down less quickly, or it’s improving in some way. So they’ve already made some improvement. And I don’t want people getting hung up on just like the number, because the number’s less than it was last month, or whatever; I want them to think about whether they’re already improving, is there something else they can do to improve?

And then I think when you’re new to a community, and you’re trying to decide whether you want to participate in a community, I think those are a whole different set of health metrics.

That’s a different set.

Yeah. I mean, I think that’s things like “Is anybody actually using this thing? I don’t want to contribute to something nobody uses. Are there lots of other people contributing? Do all of those contributors work at the same company, and I don’t work for that company? Am I even going to be welcome in this project?” So I think there’s a lot of things that you look at, depending on what your goals are as a contributor, and depending on what kind of project you want to contribute to.

How do you represent this data? Is it on a website, and I can go to a certain domain and a certain org name and a certain project name? Is it like GitHub URL structure to get to this data? How could I go and find my projects that I’m interested in their data? How can I find that information?

Yeah, so you kind of have to – if you’re talking about it from CHAOSS perspective, you kind of have to use one of the tools, and load your project’s data into it. And then you can access it.

I guess a better question is how does it work? How do I use CHAOSS?

Yeah, so we have two tools. So we have Augur, which I use within VMware myself… So the way Augur works is on the backend it’s a Postgres database. So basically, what it does is it pulls – it has a bunch of workers that pull data from GitHub, for example, and puts it in a very nicely-structured Postgres database. And then there’s also – they’re doing some work on the frontend, so they’re kind of making some changes in the frontend; it’s a little bit less mature… But the reason I picked Augur was because there were four metrics that I wanted to measure, that I wanted our maintainers to look at. And so because it’s just a Postgres database in the backend, I can just write a whole bunch of Python scripts that generate the four charts that I want, and then we display those into internally. We have a little internal dashboard that we use for that.

And then we also use the [unintelligible 00:45:03.28]

Say what?

So GrimoireLab is one of them, and there’s a company called [unintelligible 00:45:08.29] So that’s the other piece of software, and it uses the ELK stack. So basically, Elastic Search, although they’re migrating to OpenSearch, and a fork of Kibana called [unintelligible 00:45:23.07] So it’s more of that style. So it’s not a relational database, it’s like an Elastic database. You can run queries, but it’s got really big dashboards that people can use.

So that I think is great for community managers who really want to dig in on their individual project and want to know every little bit about it, because the dashboards have all this stuff already in them, and then you can write custom queries around it. So Augur is more powerful if you want to write like Postgres database queries, and display stuff yourself… Although they are working on the frontend, and it’s looking really, really cool. So I don’t want to diss the Augur frontend, because there’s some awesome stuff happening. And then the other one has like a more robust dashboard, but it’s confusing for a lot of people; they don’t know how to write those queries, because they’re not relational database queries. They’re different. So it just kinda depends on what you want.

[46:14] How did you get to those four metrics? Why are those the ones that are important to your team? And where are they? Recount them for us, and then why.

Yeah, sure. Yeah, so the four metrics are response time, for – I picked pull requests; response time for pull requests. And so our guideline internally is that if someone submits a pull request, we should have a human respond to it within two business days. So I exclude the bots, and then I look at how many business days it took us to respond. And then I chart that over time.

And then I look at change request closure ratio, which is basically - in a given month, there are a total of 100 open pull requests during that month. Did you close 90 of them? Did you close 50 of them? And how big is the gap between the number of pull requests and the number of pull requests you closed? So this is kind of the pull requests backlog, and whether you’re keeping up with pull requests.

So response time is good, because new contributors want a response to their contribution. Everybody wants a response to their contribution. The pull requests backlog is good, because it shows that people are either merging pull requests or closing them without merge…

Yeah. It’s like throughput.

Yeah. Because you don’t want a huge backlog of pull requests. I look at release frequency… So I want to make sure that when they release bug fixes and security fixes, that they actually land in a release in a timely manner. So those are not just like big releases, but like individual point releases. And then I also look at contributor risk, which is kind of a bus factor type metric. So I look at “Does a project–” And these are VMware-owned projects that we run these metrics on. I look at “Are there three people who are contributing 50% of the contributions to the project, or is it one person who’s contributing like 98%?” …in which case, that’s not good. But if you have a large number of people who are contributing across the project, then if one person left the company, or retired, or decided they didn’t want to do it anymore, then the project can more easily continue.

So I picked those because I thought it was a representative sample of things that a lot of people care about. And then what I want the projects to do and the maintainers to do is then drill down and have other metrics. So like I said, we have a team using the GrimoireLab tools for their metrics, and then we have other teams that are doing custom stuff out of the GitHub API, for example to measure other things that they want to care about.

What metrics hit your cutting room floor? What metrics was important, but didn’t make the cut?

That’s a good question. I didn’t really approach it that way. I just picked the four that I thought were important, and we went with those.

So you only chose four.

Just four. I’m focused. Focused.

Okay. It seems like the importance of those metrics is - I’m trying to paraphrase - contributor; if I give a pull request, I want as a human who spent my time and effort to give you, the project, some value, whether it’s X or Y, some sort of feedback. But the other one where I think you were talking about the pull request backlog… And you mentioned, Jerod, throughput… I’ve gotta imagine that tells you “Should we increase our team size, or should we decrease? Because we’re just closing fast? Maybe we’re just fast, or - hey, we’re slow this time; or three months consecutively. Do we need to add a team member? Should we incubate a new core team member?” etc. Is that kind of how you look at it? It helps identify risk, it helps you communicate with the community really well, but it also helps you grow or shrink the team as necessary, based upon this feedback?

Yeah. And do you recruit more contributors from outside the company? So do you get more people involved in the project, because you’re not keeping up with the contributions?

Yeah. How well is this idea used by other projects? This seems to be like a very good idea… How many people are using CHAOSS and Augur to kind of dig in like you have, to showcase its health?

[50:03] So lots of companies, actually… So I think lots of the big companies that have open source program offices have at one time or another used some of the CHAOSS tools. Yeah, I hate to name names, because I can’t remember which ones I can talk about and which ones I can’t…

You don’t have to name names…

But most of the big open source program offices at the big companies have used the CHAOSS tools, and are involved in the CHAOSS project. So if you look at the people who are coming to meetings and being involved in the CHAOSS project right now, we see people from Bloomberg, and Microsoft, and Google, and Red Hat, and all of the big tech companies.

More specifically, why did you not score? Like, why did you not establish maladaptive, healthy, a score of 50… Why the pushback against the scoring? Is it too concrete? Do you need to be a bit more ambiguous in terms of like that true health?

No, it’s because every project is different.

So how do you compare a Kubernetes, and give that a – any algorithm that you could put together, that would score something like Kubernetes, and then compare it to a project that has two contributors, and 10 pull requests a month… Any metric that you could score would give you wildly different results, because those are very different sizes of projects. And they have different automation, they have different release schedules… Every project is different, so I want the project themselves to think about “What do these metrics mean to me, for my project?” and interpret it in light of the other stuff that’s going on with their project. Like a release window, for example. Or KubeCon comes up and you see a drop across the board on like CNCF projects, the week leading up to KubeCon, where everyone’s writing their talks, and during KubeCon. And then you see it go back up.

So there’s lots of stuff that can impact that. If it’s a mostly European-based project, you see a big dip in July, because we’re all on vacation…

Does it answer the question “Are we healthy or not?” What’s the question specifically that it answers?

Community health.

Yeah, because you can score health and say “We are healthy”, or “We’re healthy-ish”, and it can be specific to your repo, and I can understand why, if it’s a European team, why July might be less so. And it’s not like – even as an OSPO, I might be like “Are my projects healthy, or are they less healthy?” And if it says less healthy - oh, because it’s July, and that makes sense.

Yeah. The question I like to ask is “Where can I improve?” So that is where I try to focus on the metrics, is being able to look at where I can improve. But you can use it as kind of a gut check for whether it’s healthy or not healthy. So I do that; within the VMware projects there’s an arbitrary threshold that I’ve set, where it’s like healthy and at risk. So I don’t define something as unhealthy, I define it as at risk. And then maybe we look at those a little more closely if they’ve moved from healthy to at risk.

And then we have other projects that are at risk simply because they’re very large, and my threshold is arbitrary, and doesn’t suit them well, because they’re a really big project, and my thresholds work really well for the average size projects that we have. So just - yeah, it just depends on the project.

It makes sense. One last question for you… You said at a certain point it might be time to recruit an outside contributor… What does that look like? How do you do that?

Again, it depends on the project, but a good place to start is by looking at the people that are adopting it. And so if you have people who are using your project, that’s a good place to start, to talk to some of them to see if any of them are interested in contributing. Sometimes you have people who have contributed a little bit, they’ve made a pull request or two, they’ve filed a few issues… Maybe encouraging them to contribute a little bit more to the project. But it depends on what the project’s like, who’s adopting it, who’s using it…

And what do you say? Do you say “We have a core team member slot opening up, because we recognized we have a lack, and we have more space for another team member”? And do you suggest to these adopters, “Hey, we have a slot opening up. Submit a request to fill it”, or “Do you have anybody available?” How do you ask specifically? How do you engage specifically?

[54:22] Yeah, so I don’t really look at it as like a spot opening up. If you have an open source project, you’re always looking for contributors, so you’re always looking for more people to get involved. And ideally, your governance documentation will give you some guidelines for how you recruit new contributors. So a lot of projects have governance so that the existing maintainers recruit the new maintainers, so they get to decide who gets to come in and maintain the project. So it depends a lot on your governance model, it depends on your project, it depends on what kind of contributions you’re looking for.

Are those governance documents different per project, or is it sort of VMware at large, government documents, or governance documents, that’s how it works?

No, they’re different depending on the project. And I also work with a bunch of – so I spent a lot of time in the CNCF contributor strategy/technical advisory group, and one of the things that we work on for CNCF projects is governance templates. So we have three different governance templates that we use for CNCF projects. And we encourage them to use those, but they’re individual projects, they can use whatever governance they want; sometimes they’ll pick something else. But yeah, it varies widely across projects, even within the same company or within the same foundation.

And if someone’s out there saying, “Wow, CHAOSS sounds awesome. I run an OSPO and I’ve never heard of it”, what should they do?

They should go to chaoss.community, which is our website, and we have loads of regular project meetings, we have working groups you can get involved in, and so I would say poke around there and there’s information on how to participate. And we’re very welcoming to new community members.

What’s your time to pull request closure ratio? What’s that –

Yeah, that’s a good question. I have no idea. [laughter] No idea.

Well, thanks for joining us today. This is cool.

Yeah, thank you, Dawn.

Yeah, thanks for having me.

Drupal is still a big deal, right? Is Drupal still a big deal?

I would think so…

I wouldn’t say Drupal is still a big deal, yeah.

I know somebody who’s big into Drupal… Well, I don’t know him-know him, but I know him… His name’s Jeff Geerling.

Yeah, yeah.

He’s a big Drupal guy, and he’s moving this stuff off of Drupal –

YouTuber, right?

…onto, I believe WordPress, if I last looked…

Oh, he’s moving off Drupal?

Yeah. Like he would self-host, and do a bunch of stuff… So I think he was a big Drupal person, but I just wonder, is the tide shifting away from Drupal? Is it still a big deal? What’s the – do you know?

I think what I would say about that is Drupal has kind of shifted, where what it’s really targeting at this point is like ambitious digital experiences, sort of what we say. It’s an open source data platform for all that kind of stuff. And what that means is if what you’re doing is running a personal blog, Drupal is probably going to be a really frustrating platform to run that on, to be honest. But if you’re building, for example, a university website, where all of the different departments need to have the same functionality, but look different from each other and have different access control, it’s really great for stuff like that.

Right. Access control. So do you plug into like SSOs, and stuff like that now? Is there plugins for that?

Oh yeah, there’s plugins for everything. Yeah, plugging into SSO; if you want different functionality and features, you click buttons for that, that kind of stuff.

Gotcha. Are you still in the Drupal community? Like, what’s your state?

It’s been a while since we talked to you.

It has been a while, I know. Yeah.

2018, the last time Angie has been on the show. So it’s been –

Five years.

..essentially a lifetime ago.

Yeah, in tech especially. It’s like, that was seven lifetimes ago.

What’s happened? Are you still involved? What’s your state?

Yeah, so I ended up departing Acquia in 2021 or so, because I kind of had gotten to the point where it’s like, okay, I kind of saw Drupal through – you know, it’s a toddler banging itself on the furniture kind of stages, and up to now it’s an adult, with a stable apartment, and all this kind of stuff.

Right. Paying their bills, earning credit…

Yeah. You know, the releases are coming out on time, we’re not having security vulnerabilities… These kinds of things. So it kind of felt like “Okay, I beat this level of my career” kind of thing. And then I started getting into data platforms. So I went into MongoDB, and now I’m at Ivan, which is a startup around open source data stuff. So they run Kafka, Postgres, MySQL, Cassandra… A bunch of other things.

[01:01:53.17] Yeah, so I would say I’m less involved in the day-to-day of Drupal. I used to know literally everything that was going on, I was on top of every issue, I was on top of every new contributor, that kind of stuff… But what I do get pulled in for Drupal now is like the kind of big strategic decisions, like Drupal 7 end of life, or things like if the Driesnote is going to create a different strategic direction, they’ll call me in to talk about that; or core maintainership stuff, that sort of stuff. It’s kind of nice, because I get to still be knowledgeable and involved with the big decisions in Drupal, but I don’t have to like bikeshed what color buttons are anymore, which is kind of nice.

Right. Well, I have to say that I really, really enjoyed the episode we did with you way back when…

Yeah, that was fun.

…episode 321, if you’re listening to this, back in October of 2018.

It’s a good number. 321.

It’s a great number.

I just loved the energy you brought to that community. Jerod and I are very much departed from Drupal; we’re not involved really at all, and I feel like you gave us the best 30,000-foot, maybe 12,000-foot view of that world… And you just had so much passion, you really just did.

Well, thank you. Yeah.

I mean, you represented Drupal very well.

And I still do. I love Drupal, and I love that community… The software is really interesting, especially for kind of like those big projects that have a lot of different moving parts, or – I used to say Drupal is great if your client has no idea what they want, because it can do all of the different things that you need it to do. But again, it’s not such a good platform if you know exactly what you need is a blog, or what you need is a shopping cart, or something like that; there are other platforms a little bit more –

Right. So we’re here as part of Maintainer Month, along with GitHub, and celebrating this community, and open source maintainers… So it’s been a bit since we caught up, so what’s your maintainer story now? If you were giving a fresh view of your maintainer story, what is it?

I think my maintainer story has moved to the point where I’m trying to sort of empower more people. So if you think about building out a leadership bench of your maintainership, so that you’re not solely dependent on individual contributors, that have been with the project for a long time, and have a lot of historical knowledge, but really clearing the way so that folks newer to the project, who have new, interesting ideas can come in and can take a leadership role in the project. So I’d say that’s more the point where I’m at, is sort of shepherding in new leaders, providing some mentorship to some of the incoming product managers for Drupal, that kind of thing.

What’s involved in that? Is there documentation involved? Are you writing syllabuses?

Gosh… I should, right?

How are you educating and on-ramping this leadership? It seems like it’s just proving ground for documentation to some degree, because you can document the process, and usher them in.

Yeah. I mean, when we set up the governance structure originally – because originally, it was me and Dries. We were the two maintainers for Drupal 7. And that was not going to scale as we built out. So we started by creating like a core governance, where we had kind of different types of committers, that would focus in different areas - product managers, framework managers, this kind of thing; release managers… And so that stuff, the distinction between those is documented. And that way, you don’t have to be someone that can cut across all of those areas. You can sort of focus on one area or another.

So my involvement has been a lot more ad hoc, just kind of like having one-off conversations with people… But you’re right, I should start documenting some of this stuff, because - yeah, it’s good information for people to know.

You probably have to repeat yourself a lot.

Well, I don’t know. I enjoy repeating myself a lot… [laughter]

Positively, I mean. In the most best case possible. So I find that I repeat myself a lot too, and I’ve learned that I have limited bandwidth, and I have to begin to jot down and put down things that I do, particularly for our organization… And I’ve been executing on that, and like getting that positive feedback loop from that effort, too. So maybe you repeat yourself a lot, so maybe it’s time to document the process.

Do some thought leadership? Yeah. You’re right, you’re right. It is true. Because otherwise, the stuff that you’re imparting kind of stays within that one conversation, when it won’t be out there for the benefit of everybody.

But talking is so much more fun than writing.

It really is, that’s the thing.

I like writing too, honestly… But yeah. I just never shut up, so it’ll be like 4,000 words that could have been in 20.

You could transcribe yourself, which is what we do for our shows.

Oh, interesting.

This is being transcribed right now.

Not right now, as we speak…

[01:05:51.09] Okay, so I’d better watch what I–

Not literally right now, but –

Eventually. This is on the record.

There is a buffer between now and the transcribed.

Okay, right on.

And then you could give it to your favorite language model and say, “Turn this into documentation.”

That’s cool. Alright. I’m gonna think about that.

There’s an idea.

Here’s a question for you… So going back to ‘21, you said you felt like you beat that level, you’re ready for your next adventure… How do you decide what’s next? How did you decide what’s next? How did you pick this area of work, and what drew you here?

Well, so Drupal had this amazing community, but largely consisted of web developers. Web developers who could stand PHP, specifically. So that’s like a pretty small –

Alright, it’s a niche inside a niche.

It’s a little bit of a niche inside of a niche, exactly. So what appeals to me about data platforms is that any kind of developer can use them, in any kind of language. So you can be – you have C++ developers doing embedded systems, you can have folks doing AI and ML, you can have web developers…

…all these kinds of things. And what interests me from a community management perspective, because that’s kind of my deal, and Director of Community - I love getting people together, and just like making awesome things happen… Is cracking that code. Do you know what I mean? Around those different language frameworks. What’s the Venn diagram of things that these people have in common.

Right. Where is the common thread.

Yeah, exactly. And Ivan is really interesting, because it’s the common thread among many open source projects. A MySQL developer and a Postgres developer don’t necessarily have a lot in common; they won’t go to the same user groups necessarily. But if you pull it up a level to open source data infrastructure, now all of a sudden we do have a lot in common. So it’s been a really interesting thing to kind of get involved in all these different communities, see how they each do governance, and how they do different approaches to – you know, kind of the common things that maintainers deal with. How do you triage incoming stuff without overwhelming people? How do you make sure you’re keeping the platform stable, but also adding innovation? And seeing that as a bird’s eye view across many different open source projects is really fascinating.

How did that opportunity present itself?

Well, the MongoDB opportunity presented itself because I know a guy named John O’Bacon who is big in the community leadership space.

Yeah, he’s great.

We know John O

Yeah. And we’ve kept in touch, and I kind of subtly was like “Hey, I’m not actively looking, but if you know of anything, just pass it along my way.” And yeah, he passed it along, and I was like “Wow, this is really cool.” And so I got to kind of meet the different leadership at MongoDB, and I was like “These people are awesome. They really believe in this, and the story is amazing, and there’s a lot of good I can do here.” And I feel like I did do a lot of good there. But it gets into a lot of – I don’t know how much you get into legal… You know, philosophy debates around licensing, and stuff. But MongoDB is not open source. It is SSPL.

We’ve covered this.

Well, not Mongo directly, but all the peripherals around the BSL, the SSPL…

Yeah, yeah.

Right. Mostly with a view into Elastic, at the time…

All the nuance, yeah.

Which is interesting, because the OSI hasn’t quite cracked this yet, right? Because if you look objectively at open source projects that have adopted these open-ish licenses, except if you’re going to run your own service, it becomes a stable funding model for them. MongoDB’s revenue went po-po-poom!

For sure.

And the open source, true open source communities do not have that. An Amazon or somebody can take their product, productize it on their own thing, charge a bazillion dollars, and they don’t have any obligation to give back anything to the project. So it’s a huge challenge. So I appreciate that about them.

It has restrictions, though, right? Like, the SSPL and the BSL both have restrictions, which I think is a sticking point.

Yes, and that’s why they’re not open source licenses.

Exactly.

Right. It’s obvious why there is a sticking point. It’s not like “Oh, well, we just can’t call them open source.”

Because eventually open source is not open source necessarily.

Exactly.

Now, there will be people out there who will argue that, as you may know… And those people may even operate those companies who run that software that is BSL, or SSPL-licensed… And that’s cool. But it is restricted. So by the nature of restriction, it is not open.

[01:09:55.13] Exactly. But it is an interesting thing in that absent of having a sustainable, recurring revenue model that you can build off a service to run your thing, you kind of have to do one-off projects, or you have to beg for money from big corporate… Your funding options are much more limited.

For sure.

So I respected MongoDB a lot that they went after a solution to that problem. Even if it’s not keeping with the full spirit of open source, it was like – it’s creative. I give you credit for that.

I think the community accepts the SSPL and the BSL license solutions you’re talking about though, quite well.

It depends on the part of the community, yeah…

…which part of the community you’re talking about, yeah.

Yeah, but I guess what I mean by that is that it’s not like “Oh, you chose that, so therefore you’re bad, because you decided to go a route that funded your business, or made your business sustainable.” I think the sustainable side more so than the funding side is the part that you have to have empathy on, because particularly Sentry would not be a company and be as profitable as it is if it was not BSL-licensed. It was originally, I believe, Apache VL2 - I could be wrong… If it was not BSL-licensed, it would not have the funding model it has, nor be giving back to open source. So there’s all these positives to that. And they’re also very open source-centric, and very giving in a lot of cases out there in the community… There’s a lot of good that’s done, so…

Definitely.

I think there’s a spectrum.

But they’re not calling themselves open source, necessarily.

No, they’re not. That’s where it gets icky. It’s like, if you’re BSL, okay. Shout it proud. If you’re open source, officially, shout it proud. But don’t play the game in the middle, because now we’re getting to where it’s like, “Eh”

Don’t conflate them.

And then there’s people who really don’t care, and there’s people who really do care, and then in between, we all find ourselves, “Which way do you lean?” And so it’s hard to say the community accepts that, because I think there’s plenty of people in the community who don’t, but there are plenty who are… And then there’s those of us in between. I tend to be slightly over there to be like “Well, it’s better than nothing.” I’m kind of on the sustainability side myself. It’s like “Well, this is what I think is a good thing, and we would not have this good thing if it weren’t for this particular circumstance that they chose. Maybe they could have chose something different, and it’d be okay. But this is what they chose. I’d rather have that than nothing. And so okay.” I think eventually open source is kind of cool, but open source right now is cooler. But maybe that thing wouldn’t exist if it wasn’t for –

[laughs]

It’s true though. People apply different value frameworks.

Yeah. What you value changes? And then there’s other people who are like “No, it has to be OSI-compatible”, and then there’s obviously the FOSS side of things, it has to be copyleft etc.

Yeah. And it’s interesting, because that’s why these arguments can get kind of fractious, because no one’s wrong. It’s like, everybody has a defensible position in this whole thing.

This goes back to Adam Jacobs’ war for the soul of open source, right?

For sure.

It goes back to “What do you value, and why do you come here?” And we all have to kind of answer that ourselves. What are your thoughts on these things?

My thoughts on these things are I think the – I think the OSI needs some solution to this “Someone else can productize your service and make a bazillion dollars and you see nothing of a problem.” Because I do think it’s a problem. It creates an issue, and - since we’re talking about maintainer month - where the actual maintainers upon which these millions of dollars are built are slogging it out on nights and weekends, ignoring their families, while you’re making a billion dollars. Like, that’s a problem. I get that it’s tricky though, because the whole ethos behind open source projects is there is no restrictions.

Do whatever you want with it.

It’s free, and do whatever you want, including make money off the backs of that one guy in Nebraska, who’s maintaining the project.

Exactly.

Yeah, so I don’t know. I can see all angles on it, but I do think that it’s a clever way to make your open source-enough project, open source-ish product sustainable. Because the financials speak for itself.

Yeah. So you think that OSI needs to either expand the definition to include some of these, or one of these, or come up with some other license or model that is inside of its own definition, but allows for maintainers to thrive under this one circumstance that’s really kind of crushing certain maintainers.

[01:14:15.11] Yeah, I just think it needs to be grappled with. And I’m sure it has been. But I think it really needs to be grappled with, because just being like “Nope, this is the definition, this one little box, and that’s it”, it’s like, that isn’t working in 2023. And you’re seeing actually abandonment of open source licenses for things like BSL or SSPL because there’s no open source solution.

So in the same way we have different variations of Creative Commons, for example, that require attribution, or non-commercial, that kind of thing, it feels like we need some model like that for open source licenses, with whatever asterisks and disclaimers are needed. But without having a formal framework for that, this is going to continue happening.

Right. You almost need a spectrum to address the spectrum, right?

Yeah. [laughs]

Right? Like a spectrum of licenses that move from one side to the other, that allow you to slot in where it matters for you.

Sure. Do you pay attention much to the OSI’s - I guess news, so to speak? The last time I checked, they were like “The SSPL is not open source.” That was like the title of the blog post.

Yeah. The end. Yeah.

That was back in 2020, I think, when we did the – I don’t know when we did the episode. 2021? It was all ElasticSearch, and that debate that they had between them and AWS.

Yeah. I don’t think their position has changed. And again, it’s a defensible position.

What I mean is have they addressed it, by any means. Have they gone back to the SSPL conversation and said, “Okay, worst case, here’s the positive sides to the SSPL or BSL-licensed organizations that are doing this”? I mean, if they’re not going to call it open source, which is totally at their discretion and the committee’s discretion, who gets voted in, and runs the board, and stuff like that - which is peer-led, it’s a peer vote…

Correct.

So it’s not like some randos are just running the OSI ragged, or whatever. They’re voted in.

But they’re voted in by folks that are way more on the “This is the pure definition.” Because that’s why the OSI was created, right?

To defend the definition.

Exactly.

Right, exactly.

So it’s sort of a self-replicating machine, because it’s like the people who are voting are going to vote for people who still believe – you know. I don’t know, though. In their defense, I wouldn’t call myself an avid keeper-upper on top of OSI breaking news.

That was my question primarily…

Neither are we, which is why we’re asking you.

[laughs]

And the question I guess then if you were was “When have they last addressed BSL or SSPL?” Have there been any positive and/or negative – maybe we can go back and…

Yeah, not to my knowledge –

There’s people listening to the show right now and they’re like “I’m looking it up right now, you idiots…”

Yeah, well - hey, if anyone from the OSI is listening, please tell us. Because yeah, if there is something in the works, or already happening, around this funding/sustainability issue - great.

Right. So where does Ivan fall in this world? Is it like purely open source, or…?

Yeah, so the reason I like Ivan is because all of the underlying data technologies are actual open source, with a capital O and capital S. So they’ve got streaming services built off Kafka… Or it’s not even built off Kafka; it’s like “You get Kafka. We manage it for you so that you don’t have to panic.” Because Kafka is apparently a nightmare to manage, is what I’m reading out of things. And so it’s like “We know how to do it.”

That’s the key to having an awesome open source infrastructure project to build businesses around, is it has to be really valuable and really hard to manage on your own. [laughs]

Yeah, exactly.

I just had a conversation with Redpanda’s founder, which is probably in your neck of the woods, because they essentially are a better version of Kafka.

Yeah, okay, right on.

…you know, in their terms.

Yeah. I like Ivan, because they legit don’t want vendor lock-in. If Ivan makes you angry, you can take your Kafka and move it to Confluent, or whoever you – I’m probably not supposed to say that word, but anyway, you know what I mean. It’s like, it’s fine, because what we’re trying to sell is like “Hey, we’re the security layer on top of your thing. We’re gonna do the updates for you, this kind of stuff”, so that you can then be like “Great, I don’t have to worry about that. I can just write the stuff my business cares about. Because they don’t care if I’m running a Kafka cluster. They don’t care about that. They care about the results that they’re gonna get.”

[01:18:05.25] The other thing I like about them is a lot of companies will try to make money off of open source. That’s why we’re all here. This conference is very enterprise–

How do we profit?

Yeah. But they have an Open Source Programs Office, for example. And they hire Kafka core maintainers to make sure that the software that we’re selling to our customers stays well-maintained. So that’s what kind of drew me there, is it aligns really well with my values. And I still love MongoDB, I still love Drupal, but that idea of like building something that can really be used to build anything, and all powered off true open source stuff - that’s awesome. So that’s why I’m there.

So what is it you do there then particularly? What is your role?

Yeah, I’m director of community. So that means that we’re handling meetups, we’re doing things like our community forums, our real-time communities, that kind of thing… Trying to bring together practitioners of open source data infrastructure broadly, whether we offer it on our platform or not, to kind of come together and talk about the problems that they’re having, and some of their pain points, and some of their tips and tricks, and stuff like that… Because it’s a really fascinating thing to be part of, and a lot of people don’t realize that there are open source alternatives for like data warehousing, or some of these other challenges. Yeah, so that’s why I’m in it.

Do you interface with OSPO, by any chance?

Yeah. I mean, with the caveat I’ve only been there like weeks, so who knows. But yeah, the OSPO people are amazing, and it reminds me a lot of the work that we did at Acquia around Drupal. It wasn’t called an OSPO, but it was very much like “What’s the best thing for this project?” That’s the thing we have to focus on, whether or not it’s good for the business as a whole, because those are separate. Hopefully there’s a Venn diagram, but they can be separate and competing concerns.

Yeah. Every OSPO has a level of maturity. What do you think yours is at? Without calling it immature, what level are they [unintelligible 01:19:49.22] you don’t know? Ok.

I don’t know if I’m qualified to say that… But I mean, they’re in the to-do group, they’re a member of the Open SSF, so I feel like they’re doing the right things, they’re contributing in the right ways.

Right. And they’re also employing, you said, Kafka maintainers, and stuff like that?

Yeah. And there’s Postgres, a couple of people, from different – again, they want to make sure that the technologies that we rely on for our customers stick around. And I think that’s really awesome. Because they wouldn’t have to do that, right? They could just sell the stuff and not give back, but they’re choosing to do it.

But on the maintainership thing - yeah, I do think that that is a general problem that people need to think about. It’s like right now you’re in this, you love it… You could do this the rest of your life. But realistically, your life’s gonna change over the course of your life. Maybe you get different hobbies, maybe your interest in technology’s changed; maybe you have a kid, whatever. And so it’s really important to think about that as you’re maintaining your product and your project, to make sure that you’re thinking about who’s going to take that on when you have to step away, so that you can step away when you need to.

One of the themes – I didn’t put it in my notes, actually; one of the themes for maintainer month and maintainers, I believe, is essentially finding a way to step back, finding a way to have succession planning, and stuff like that. Do you as part of your leadership talk at all about that? …like, that kind of maturity of a maintainer, and supporting folks that – to anti-burnout, essentially.

Yeah, so we do things like have what are called – oh, my God… What is the word…? This is so bad. Ah! Provisional. That’s the word. Provisional maintainers. So we find people that are kind of active, and doing the right things in the right subsystems; we’ll kind of find those people, pull them in and say, “Hey, would you like to become a provisional maintainer?” A provisional maintainer doesn’t get commit access necessarily, but they are allowed to make like “Okay, this RTBC–” Sorry. “Reviewed and Tested by Community Patch - it’s gone through the review process. This patch is good to go.” And they can escalate it to a committer to actually commit it. And after they’ve done that for a little bit of time, then we do give them commit access, but maybe just to their own subsystem, and not the whole of core. And then later, they kind of grow into that. So we have like a progression model.

[01:22:02.02] What we’re also exploring is the idea of term limits on a committer as well. Terms and term limits, I should say. So terms meaning you’re not signing up to something for life necessarily; why don’t you sign up for something for, say, three years, and we stagger it, so that not all of the communities come on at the three-year mark, and then [unintelligible 01:22:18.23] … But like stagger it, so that there’s still a group of people to help bring on the new folks.

But then it’s a lot easier to make a commitment, or for your business to make a commitment if you’re employed by somebody, to say “Okay, we can pay you for, say, 20% of your time for three years. That’s an investment we can make.” Versus 20% of your time indefinitely, is a lot harder to ask.

And then we’re talking also about term limits, which means once you’ve done let’s say two, three-year rotations, then you have to take a year off. And if you want to come back, great, but otherwise we’re gonna make you go out there, build some stuff, and get familiar with what the field is doing, that kind of thing. See if this is still what makes you passionate.

Kind of like a forced vacation, in a way.

Yeah. In a way it is, yeah.

Because there’s a lot of people who won’t take vacation and will just burn themselves out.

Exactly.

They’ll take the money instead of the vacation. They just keep working through it. And some companies allow that, but this is kind of like – it’s kind of like that, it’s forced vacation.

It is, and it’s coming from a place of love. It’s coming from a place of “You’re probably not going to do this unless you’re forced to”, but forcing you to really gives you that, “Huh. Okay, I don’t need that responsibility anymore.” And then if I want to go back willingly, I’m able to. But we’re not stuck with people who maybe should have moved on a while ago, and just feel like they can’t, because they’re like “Everyone’s depending on me”, that kind of thing.

Yeah. Well, they feel like that, but it’s not – it’s kind of true, but it’s kind of not true. It’s like “That person should really take a break, but they will not, so…”

Yeah. I mean, that was the thing. Like, I stepped away, and I was super-active, but it’s like, Drupal is still fine. You know what I mean? It’s like, Drupal is doing fine, everybody’s still getting their stuff done… And it proves that out; that even if someone is neck-deep in everything, it’s fine. Step away if you need to step away. The project will figure it out.

I had this epiphany a while back, because I listened to and read Seth Godin’s book Linchpin. Have you read that book or know of it?

Well, Linchpin essentially is like your crucial. The linchpin in a wagon wheel was what kept the wheel on the thing. So if you’re the linchpin, you’ve got to be there to do the job, so that the wagon wheel stays on the wagon, and the wagon keep moving. And I learned a long time ago that I’d rather be a cog, because at some point, somebody else is gonna be better, or be much more hungry than I am, and I’m not really the linchpin I thought I was. So I might as well just be a very purposeful cog. I do my job well, I serve my team well, and I don’t have to be a linchpin. I can be very important, I can have an important role, and play a crucial role, but I’m not a linchpin. I’m more of a cog in a better machine, I suppose, to get the things done.

Let me give you a slightly different analogy, because “Yes, and…”

Think of yourself as you’re like the drummer in the band.

Oh, I like this.

The drummer in the band kind of sits back, just kind of does his thing, or her thing, and makes sure that the beat’s going on, and this kind of thing… And then you let someone else be the lead singer and the guitarist, doing that kind of stuff. Because you still have a really important role to play. And I don’t think calling yourself a cog is like doing service to that, because it’s like…

[01:25:16.23] Every once in a while you have a drum solo time. But not the whole time, right? Like, let other people shine.

Yeah. No, if it’s the whole time, people start walking. [laughter]

[unintelligible 01:25:21.02]

You can’t have the whole thing be a drum solo.

The reason I think I came up with cog was there was an analogy between linchpin and cog. Because the cog is like the thing that – it’s just part of the bigger clock, but the clock wouldn’t work if one or two of the cogs broke, right? It wouldn’t take time the same way.

Not to nitpick your analogy, but while we’re doing this…

Sure, please…

[laughs]

This is Jerod’s MO. Please…

Tell me the different ways, tell me you’re wrong

Come on, Jerod. Let’s go. I cannot wait to hear this.

If you pull a cog out of something, it’s still gonna bust. So isn’t each cog in its own way a linchpin?

I think the – yes, to use Angie’s “Yes, and…” So a linchpin is like, “It all breaks if I break. It all rests on my shoulders.” There’s far more superiority, to some degree, so much more pressure… Whereas if you’re just a cog, you can be replaced with another cog that’s similar.

Oh, I see.

Whereas the linchpin is like “There’s only one of me, and if I break, everything breaks, and there’s no replacing me.” That’s the difference.

Okay. So you can’t buy another linchpin.

Well, linchpins are hard to come by.

Okay. I didn’t know that part, so I think the analogy holds…

I didn’t also know that part.

But I figured a linchpin - you just got another one somewhere else, shove it in there… Maybe a stick if you need to, I don’t know…

Yeah, you could… The stick might break, eventually.

Just MacGyver something with some duct tape and some safety pins…

We’ll have to actually get Seth to talk us through this, because –

Okay, because he uses that exact analogy.

…the whole book is called Linchpin.

He tells you to be a cog though?

No, he says to be a linchpin.

Okay. That part I get. But the cog, where does the cog come in?

I said that cog. This is me, I made this up. Like, I love that book, I love the idea of that book, but I don’t want to be so focused on my importance that I have to be this linchpin with all this pressure on me.

He tells you to be the linchpin?

Yes, he tells you to be the linchpin.

I guess there’s job security in that, but… It seems like I’d rather be a cog.

It’s a lot of pressure and a lot of responsibility.

I’d rather be a drummer.

Keep the beat. Keep the beat.

Yeah. Right? Keep the beat. Because - it’s like, linchpins are great for a business, but they sure do get divorced a lot, you know what I mean?

It’s like the 10x-ers… It’s the BDFLs –

Well said.

Yeah, the 10x-ers. Be the 1x-er.

Be the 1x-er.

…that might run things poorly… It’s the “I’m very important. I can’t be replaced. I’m super-crucial.” And yeah, there’s unhealthy balances, I’m sure, that ensue as a result of calling yourself a linchpin. Whereas if you’re a purposeful cog… That’s what I fight for. If I know my purpose and I can deliver that purpose, and I’m 14… Because a cog is not an individual – or a cog is not… Yeah, not an individual.

It’s a part of a larger whole.

Exactly. So if you understand the working system, you’re part of the working system. But if you’re a linchpin, it’s like, “Well, it doesn’t work unless I work is.” There’s a difference in psychology there, in my opinion.

I see. Okay. I like it.

As long as you have some spare cogs. Because otherwise, you pull a cog out, the whole thing falls apart.

For sure.

Especially on a watch.

Alright, Angie… Well, thank you.

Yeah, thanks.

Thank you, yeah. It was wonderful catching up with you guys again.

It’s always fun.

Changelog

Our transcripts are open source on GitHub. Improvements are welcome. 💚

Player art
  0:00 / 0:00