>> Hello?

Good morning, everyone!

AUDIENCE: Morning!

>> Thank you!

All right, so who's ready to hear about building open source communities?

AUDIENCE: Whoo!

>> All right, so let's welcome Tierney Cyren.

>> Hello.

Could we give another round of applause to the organizers and the supporting staff who

have built this amazing event that I've really had an amazing time with and I hope you have

too.

Awesome, OK, so today I want to talk about building open source communities.

Before I get started, I'm going to do a quick who am I.

My name is Tierney Cyren, my pronouns are he and him.

I work at Microsoft, I collaborate on the Node project and a number of other projects

in various different ways, that's basically what you need to know about me.

So what is an open source community?

>> Open source is everything, or at least the community side of open source is everything

beyond the code.

So everything that's not technical, like literally writing lines of code and consuming lines

of code, is the community.

This includes people, coordinating a bunch of different aspects of your community itself,

processes, location, funding, social media, blogging, diversity

and inclusivity, outreach, documentation, licensing, there's lot.

>> I think like a year and a half ago, I asked what open source community is.

And there was a bunch of different responses and they're all pretty good and honestly I

agree with all of them.

That said, they're all pretty different, and it kind of leads us to understand that there's

not consensus around what open source community is, because it's so individual to us as individual

contributors, to us as maintainers, to us as consumers.

You have to really take into account those aspects when you're asking like such a broad

question.

Whatever technology you came from originally, whatever you started with, is going to influence

how you perceive an open source community.

Whatever your personal history is going to influence how you see a community in general

and then you are aapplying open source definition to that of what's important to you.

Again differentiate how you'd perceive an open source community so everyone's idea is

different of what a community is.

So taking that, how do you actually build an open source community?

It's kind of challenging, but it's also very easy in a lot of ways.

I generally try not to say easy, but it's -- I'm using it in in this case, because it's

easy to stumble into it and do it accidentally and this is how a lot of communities do end

up starting.

So I'm using easy very intentionally there.

Every open source community has a lot of its own quirks and unique aspects and often those

are really good and often those can be really bad.

Luckily, there are some fundamental traits, at least in my experience of the open source

communities I've been a part of that are shared and these aren't necessarily like I can give

you XYZ answer to a problem.

These are kind of cultural things that are shared and kind of manifest no matter how

you get to open source community evolves and builds up.

So let's go into some of the lessons I've personally learned from being parts of open

source communities and helping them grow and also seeing them fail.

So these are the communities I participated in.

MyBB is an open source forum system.

It's been around for a very long time.

It was created in 2006, I think, 2005, which for me is a long time.

It's PHP, so you know, very different from JavaScript that we're used to, and kind of

the build speed was a very different pace than what we're used to in JavaScript.

Tent was a protocol, the implementation was Ruby.

Whoo Ruby.

Interesting choice in this crowd!

So Tent was very much an idea and a definition similar to what HTTP is, people go implement

T very interesting community and one that I really loved and very sad to have seen it

die.

Io.js, I assume many of you know what that is, but that is the fork of node that happened

in node 10 just before Node 12 shipped.

Eventually got merged into Node.js and got moved under Node.js foundation.

And then there's Node itself.

I know these kind of merged.

I do absolutely classify them as two different communities and two different experiences.

And we can get into that a bit later.

So lesson one, don't build too much.

Creating too much structure can be a really bad thing that hinders your community.

Specifically it sets guardrails on how your community can grow and sets implicit expectations

about that growth, and it limits what you can do once you begin getting momentum, because

people try to stay within those guardrails rather than doing something natural and probably

something that you're not going to expect.

So my experience in MyBB was I created a website called techno board.net: It was a forum for

people who were interested in technology.

And I built a lot of structure, because that's how all of the forums I saw were doing it.

Turns out that didn't work.

There were two forums that had a bunch of posts and al.

Rests were empty and that creates an environment where oh, I see a bunch of empty things, this

looks dead and so I'm not going to participate.

So defining those guide rails and setting up structure when it's not needed yet is actually

really challenging because it one, makes your community look empty, and two, it limits how

you can actually grow naturally.

So yeah, that's an example of how to do something that's maybe not the best, because you're

trying to do, and you're trying to mimic what others do, and that can hamper your actual

growth.

Additionally, in Node, going through the process of creating a PR and submitting it, and, you

know, getting it merged and going through the entire process can be a little bit cumbersome

and can kind of feel like this, where it's just a cycle, and you know, certain groups

in Node have gotten a lot better about this.

That said, this process is also very intentional.

We do this because it's needed in a lot of cases.

Node is a very highly impactful project, and making sure that we're not letting things

slip through that shouldn't be slipping through is really important, because we don't want

to create, you know, a bad experience for the end users for the people who are using

this in production, for the developers like you who are using this on their machines.

So that said, in a lot of cases, if you set up too much red tape early on, it can actually

limit growth.

I ended up setting up too much red tape, or at least trying to.

I got a lot of push-back and I really appreciated it, in the Node.js committee.

There's two committees in Node.

The technical steering committee, the inward stuff and the org and the community committee

focuses on outreach community stuff.

When I was beginning to get involved there, I was like, oh, yeah, we need to mimic all

the things that the TS C and.

-- I got a lot of push-back on that and rightfully so, because it was going to be limiting the

growth of how we can actually engage with the community, and it was very unnecessary

at the time, because we didn't actually know if we needed that.

Those things existed in the technical steering committee and working groups for a very good

reason.

Whereas the com com was new, the community committee was new and didn't necessarily need

that.

We decided to go down different paths and I'm very glad we did this.

Instead of doing working groups and teams we went down a path of pure initiatives.

In the com com we've gone a completely different path and if those things that I've actually

PRed landed, we would not be on that path today.

So lesson 2: Empowerment.

Empower your contributors.

So without contributors being empowered, there's not a reason for them to stick around.

This is a vital, vital thing to make people feel welcome and like they're making an impact,

because they are.

You need to actually give them that to make them kind of want to be there and to feel

like they own something or that they belong.

And this is a phrase I like: So enabling contributors enables contributors to enable contributors,

so by you doing something to help lift someone else up, that someone that you helped lift

up actually helps them go lift other people up.

So it becomes a network effect of you being able to grow your community just by being

present and welcoming and giving trust to people.

And that's something I really believe in and I've personally seen this happen and be very

successful many times.

So in Node, we had the evangelism working group.

This was in both Node.js and io.js.

I was involved in both sides of it.

I didn't mean to both sides there.

But you get the point.

It was a working group that was both in io and Node.

We had a pretty tremendous scope.

How do you define that?

What is that scope?

That social media?

Is that blogging?

Is that providing resources for events?

How do you actually get that?

And because that scope was so big, we didn't actually necessarily have the resources that

we needed to, and so we ended up a little bit like Oliver Twist here, asking for more

and not necessarily getting it.

more because it was too broad and we weren't actually giving them a usable request.

And that was a case of a group not necessarily being empowered and not because of anyone

else not empowering them, but because we were not defining our scope well enough to be empowered.

And so in that, we eventually kind of split out into the community committee.

It's a very long arc that we could go into later if anyone is interested, but basically

they're a new committee that kind of did similar work was eventually instantiated at the top

level of the Node foundation and we kind of got to this place where we were able to have

power and define what we were doing a lot better and actually find success with certain

pron projects and kill off other projects when they weren't needed.

And it was really good way for us to be able to flex that muscle of empowerment and get

more people involved actively.

Cool.

So lesson 3: Accept help along the way.

The first time I gave this talk, it was to student ambassadors or campus experts for

GitHub education.

I at the time was chairperson of the community committee and was feeling super burnt out.

I -- it was toward the end of my time there and I had just spent a lot of time on it,

and it was just basically direct correlation to how much time I spent on it, and me not

kind of setting boundaries for myself.

And also going and trying to do everything by myself.

So one of the lessons that I think is really, really important is you can't actually own

a community.

Because at that point it ceases becoming a community.

It's a project that you are the owner of.

And this kind of came -- I learned about this in Tent.

Turns out software is never going to be perfect

and to think that is a little bit maybe not correct.

So three people were working on this.

They were doing a really good job and they had a really good base, but because they were

focusing on it being perfect for 1.0, they actually ended up ignoring the massive community

that they built and instead, just focusing on their thing and by not actually letting

people contribute in a way that was meaningful, they killed their community.

They killed every kind of ounce of goodwill and every project actually that was built

on top of their platform.

They killed it.

Because they were trying to own it, rather than trying to actually make a community.

So it became a little bit like the ring where they were really trying to go for the perfect

thing, and they owned it, it was theirs.

And nobody else could kind of help.

Because they were the only ones with the vision and the insight to do it.

And for what it's worth, they're all wonderful people, and I think it was a really good project,

but that's kind of what ended up happening.

This is also true: Communities can outgrow the project leadership.

This is definitely the case in Node.

For a long time there was a BDFL model benevolent dictator for life so it's basicalliy you're

someone who ons or runs the project and accepts other help.

It, too, was going to be perfect with 1.0, which is why we're on 0.10 and 0.12 was in

development for so long, and throughout the process, I believe there were three total

BDFLs, yeah, so those BDFLs did good work for the project, but the project outgrew them.

As was shown by io.js.

There was a ton of people that were going to be working on Node, but they were the gatekeepers

in a way that prevented that.