Thank you so much, the organizers and everybody here today.
This is such a dream.
Before I get into some things though, I wanted to dedicate just like the next 30 seconds
right now to my best friend that passed in August.
Many of you know her, Chris Nova.
She is a prolific open source engineer, alpinist, hacker and past Fosdome speaker.
What you're seeing on the screen right now is a photo of hers when she summited Mount
Rainier several years ago.
What I just wanted to say is that I hope we can always continue her memories here.
With that said, I'm Paris Pittman.
I'm a recovering Kubernetes maintainer.
These days I hang out with the Swift programming language community and I sit on the Swift
Core team.
If you hear the twang in my o's, that's my hometown of Baltimore, Maryland.
I sit in Seattle these days.
So hello from Pacific Coast time and my brain still.
I've been focused on committee management and governance of open source projects for
quite a long time and I'm so happy to be here.
The word cloud on the screen is a key part of my talk and my biography.
It represents examples of roles, titles, groups and project organization that make up our
open source communities today.
I'm not going to fib.
I've had a lot of very undefined hats in my life.
These are some of the defined ones.
Our maintainers today, if you sat in the talk that Kara just did, our maintainers today
have tons of hats that they have to wear.
At the end of the day, how can we help reduce these?
Organizational design could definitely play a part but of course it doesn't play into
all of our woes today.
I'm not going to hit on anything funding related.
It's quite funny how we were paired up on the schedule today, carried out all cash.
I'm doing all humans.
So welcome to the human piece.
So in this open source world, if you have any kind of participatory goals with a project,
there's elements that you need to plan for with and around when architecting roles, groups
and processes for sustainability.
The secret sauce to community lies in how you interpret and implement the elements.
Let's go through those.
Goals you have them.
Lives collaboration.
Distributed decision making.
Transparency.
And community engagement.
Pull requests accepted.
But now life has presented us with new elements that we need to design for and around.
We have decades of open source community stories that we can look to to formulate new elements
that can help support the maintainer.
I'm sure you've heard a few of these, right?
First one, you know a couple of maintainers that are probably masquerading as moderators.
You probably know some who are tied up with code of conduct incidents.
You've heard the infamous toxic community.
What about that open source project that you know that has amazing engineering and no documentation?
Or what if you know the engineering project where the maintainers are really trying to
do their best to be the best documentarians that they can be but they just can't?
Right?
Same thing goes with website and branding.
At the end of the day today, in order to market a project, you need to have a website and branding.
So that means you as a maintainer are also going to need to put a hat on for website dev and designer.
Another famous story.
You're a product of your own success.
Hooray!
We've heard so many of those this week.
Or weekend rather.
It feels like a week, right?
Hooray!
But boo because now the workload is so absolutely not manageable for you.
And yes, the next one.
The never-ending quest for contributors to help out.
Or for you to turn your users into steady maintainers.
And that just really falls into this bucket that I call contributor turnover.
And in a white paper, speaking of contributor turnover, in a white paper that I read from Carnegie Mellon,
titled Why Do People Stop Flossing?
That is, Why Do People Stop Contributing to Open Source?
Quote, prior work has shown that the turnover rate of a project profoundly affects its survival probability and code quality.
And in the same paper, another quote, 80% of projects fail due to contributor turnover.
So, community management is clearly the missing element for organizational design today.
If contributor turnover is that much of a metric for not having a lot of success.
You've heard it themed in the stories too.
Someone needs to do this work.
We can't be everything to everyone.
So how can we delegate this via roles, groups, and processes?
When I have these conversations a lot with maintainers, because I do, that's my job.
My question to them is, do you want to do this forever?
Is this what you always want to do?
This being 15 plus hats, or things that you don't want to do, or even things that you don't have skills in?
Hilariously enough, this screenshot from Macedon literally came to me yesterday.
It's such a great summary.
This individual is saying that they need social media skills in order to promote their thing.
And they just don't have that.
And what is that?
And what is this when I say, do you really want to do this forever?
That's creating, maintaining, moderating mailing lists, chat platforms, forums,
recruiting and onboarding new contributors, that's their documentation, their workflows, their processes.
Also keeping your current contributors and maintainers.
Also GitHub administration, website creation, mentoring, holy moly, y'all.
That's a lot.
So, first thing, maybe you should define a role that could be successful for you, which is community manager.
This does not need to be someone who does community management as a profession.
I know tons of engineers who wear a community manager hat.
They love it.
They have the skills and they're passionate for it.
Because at the end of the day, that's all you need to shift the weight around from the maintainer.
And implementation in the wild.
And that's what I'm talking about.
Dapper, a distributed application run time has a community manager role description posted in their community repo.
It starts with writing down some responsibilities and posting it somewhere to be seen.
That's your mailing list, your social media accounts, your issue backlog.
The role can be iterated as code.
That's not something that I hear a lot from maintainers.
Maintainers are really pretty fearful about this.
But ironically enough, you're not fearful about putting half-baked code out there.
But you're okay with just going without.
And let's not go without.
You can iterate on this.
It doesn't have to be the end state.
So we talked about that.
I just let loose with this one role that you should have, right?
This community manager role.
What are the other roles in open source though?
This is it.
That's what we got.
Contributor and maintainer are two of the most common forms of organizational design in open source, no matter the size of the project.
Two of the most common words that imply all of the work that you do.
And that distributes trust.
Even if you're the smallest of projects, you should at least have these two roles clearly defined, including how to get to be a maintainer.
You've probably heard this term before in the last few years, but a contributor ladder, if you will.
It helps people understand what you do, why you do it, and how to get there.
What about the contributor ladder though?
Is it that easy of a jump to go from contributor to maintainer?
It's not.
That's why we need things like mentoring and other community management type of activities.
We added one in the middle and made it an actual ladder.
Kubernetes has this, for instance, and it's the introduction of something called a reviewer.
So you've got your contributor, reviewer, and maintainer.
That reviewer is giving new contributors another wrong on that ladder to help build the trust, grow skills, and have practical mentoring experience versus a lofty one.
Okay.
But why stop there?
Why do we have to stop with just those two roles or just community manager?
If a project has needs, create them.
Again, it's just like your code.
Create it, and if it doesn't work, sunset it.
According to the same Carnegie Mellon paper that I quoted earlier, role identity.
It plays a strong role in contributor turnover.
How about that?
So while you're creating other roles, you're also building belonging and incentive to contribute.
So what are some of those other roles that you could create that would solve some of the problems that we heard from the stories earlier?
A release manager.
A security lead.
A communications lead.
A social media manager.
The list goes on.
And honestly, it's kind of endless.
Think about the things that you need and build for it.
Speaking of endless, though, if a thriving community is your goal, build an emeritus role.
One of the most forgotten parts, I think, of open source organizational design.
How to exit off-board and be done with it and hang up your hat.
And that should be celebrated.
It should be kind of like retirement from your day job where they throw you a party at the end of the day and celebrate you.
Project Jupiter actually calls their folks distinguished contributors.
Isn't that cute?
And I think that this is something that we really should try to normalize and include this in your contributor ladders.
So now you have four.
Contributor, reviewer, maintainer, and emeritus.
So we have roles as one approach.
Like groups, they're probably my personal favorite.
And that is groups of humans.
Groups allow people to drive work or interests in a space.
And the group can only be two people.
I hear a lot of naysayers from my maintainer friends sometimes.
They'll say groups are so heavy.
We're not Kubernetes.
But like Kubernetes had groups before it was Kubernetes.
Like why do we all think Kubernetes is Kubernetes?
Kubernetes is Kubernetes because of these groups that were formulated in the early days.
Because at the end of the day, what we've learned from groups is that they're great at bringing people in and guiding them to the work.
Because at the end of the day, one of the most common phrases that I even use a lot of the times when we're talking about contributing over the source is jump right in.
Just send a PR.
That's not helpful when you're trying to scale a community.
It's helpful to the people that you're talking to that know what you're talking about, but that's about it.
So it's all about what you want out of it.
Do you want experts in areas that you aren't?
Do you want to distribute the load?
Do you want a way to drive the work?
Applying this to community management, because now that we know community management is so hella important.
Several related successful groups have shaped over the years.
And they are all targeting this community management of how can we together collectively work on that burden of community management.
I recently created a contributor experience group with a hard focus on mentoring and bringing in over 60 new folks to the project each cycle.
Kubernetes also has one that I led that supports 80,000 contributors.
You all, 80,000.
And all of these groups have different levels of decision making, approvals, charters, duties.
But the one commonality that they all have is to support the maintainer.
Some really cool examples in the wild of this that I've seen from various different types of sizes and types of projects.
Again, because I think a lot of people assume that you have to be the Kubernetes of the world in order to do these cool, fun things.
But you don't.
For example, open telemetry has an end user working group that helps maintainers reduce their product management hacks.
Because I know a lot of you have to toggle between what's important.
This group helps them toggle between what's important.
And then not only that, but then tries to get them to participate, them being end users.
There is also advocacy and outreach with Jenkins, Debbie has a security team.
Many projects have security teams these days.
And then even in the SWIFT team, we are just about to launch an ecosystems work group to help our ecosystem maintainers.
So again, this is also endless and this is also about your needs.
But if you're still in the audience right now and you're still kind of like, I don't know.
I don't know if I can do all this.
Or if you have a community manager now, but your project is scaling up so much that it's even too much for them.
Or what if you have tried, but this isn't just a thing for you?
Well, there is the process component here.
This process is really coming from the emergence of strong CI CD systems and the overarching infrastructure as code movement.
And I've seen some really creative things on how engineers are project organizing themselves through configuration files.
And I mean, imagine that you're an overburdened maintainer and you're really trying hard to onboard new contributors.
And that means helping them with forming their groups and helping give out permissions to things like your Twitter or your Slack or whatever, you know, or your GitHub keys.
And then you're also needing to update the documents in a million places, training folks on code of conduct stuff.
The cool thing is in Kubernetes, we set something up like this that takes care of all of that.
And it's this infrastructure is as community as I call it practice.
Could be a way forward for you.
This practice covers testing contributor management like bots that welcome first time contributors, artifacts, governance policy and procedure scaling.
Kubernetes no longer has a full time community manager.
I bet a lot of people think that it does.
And the other thing is it hasn't for a long time.
And the reason why is because it's held up by this infrastructure as community, it's governance.
And all of those elements that I mentioned earlier with the delegated groups that have decentralized decision making, like contributor experience, special interest group and the testing special interest group and the steering committee.
So we've reviewed roles.
We've reviewed some groups at a high level and also showed you some process stuff.
Good project organization and governance create environments where projects thrive and the humans do too.
I was talking with Zach Saylor, a distinguished contributor.
Again, I love that title in the Jupiter project.
And he said that it took them two years, two years to rearchitect their project organization.
But he said Paris quote, this is a quote, it was so worth it.
And I said, why?
Why?
Because roles, groups and processes at the end of the day attract and bring new people to your project.
It's scalable mentoring.
One-on-one doesn't scale at communities of size.
It just doesn't.
And this way roles bring in shadows.
You can easily have shadow organizations like CIG release and Kubernetes.
Amazing shadow program, y'all.
Just truly top notch.
You should absolutely take a look at it.
And then the third in that same kind of bucket is inviting other skills in, increases your chance of A, survival, and B, having a more diverse project.
So why we sit in these talks of how to get more diversity, look to your project organization.
And then the last thing, the one thing that I need to take a drink for because this gets me so excited.
The last thing that not a lot of people recognize here, and this also goes back to Keras talk too, a little bit with the funding.
It's like, how do we get more people that have day jobs contributing more and also being supported to do so?
You know how we can do that by giving them roles and titles.
Companies love roles and titles and it makes sense because you know why when you go to your managers at work and you say, hey, I want to contribute to XYZ project.
You say that's nice.
What's cool?
What's in it for us?
And then you're like, yeah, that's usually how the convoy goes.
It's good, you know, we should do it.
But imagine if you say, I would like to work my way to be a security lead for Kubernetes to bring industry experience to my day job.
That's a game changer, y'all.
And that's one of the reasons why Kubernetes has grown.
And that's one of the reasons why you've seen Kubernetes so just well staffed in a way.
I mean, of course, yes, trust me, I think the 300 plus maintainers would probably throw tomatoes at me when I say, well staffed.
So I'm like ducking right now.
But it's 300 maintainers, y'all.
It's a lot.
So to wrap up, remember the slide.
Let's rally the industry around community management as an element go forward in addition to engagement, you know, pull requests accepted.
Because at the end of the day, building robust, sustainable communities is more than accepting pull requests and taking issues.
These two words, y'all, they can go so far to help our maintainers.
Thank you.