Building Open Source Communities - Tierney Cyren
>> 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.
So Node has changed from that model through the io.js fork to a more community-centric
model.
This focuses on enabling community members or anyone, really, to come and participate
and engage and build the platform.
I started by a very small contribution that actually got closed, because I didn't know
how markdown worked.
So I was trying to fix links that were broken, but I was hard-linking GitHub instead of doing
the GitHub URLs, instead of doing correct kind of well formed link.
So and now, you know, I'm involved in the project, because I've been able to dedicate
more and more time, and that has actually helped my career in a lot of ways and I've
been able to spend more time actually working on Node itself, or at least the community
around it.
So by enabling people to grow up in your project, you actually create -- you can create leaders
for the future.
You can create a hiring pipeline if that's important to you in your company, if it's
like a corporate open source project and you can generally build a lot of goodwill and
care and compassion for your community, which is really important if you really want to
actually have an open source community.
You have to let people flock together and really understand how this is a cohesive group,
rather than, you know, something that I'm running personally.
So lesson 4: Communicate effectively.
This is a very interesting one.
In my experience, nobody prefers to communicate the same way as someone else.
And I don't mean necessarily how they write, although that is definitely a factor.
I actually mean the media that they're choosing or the medium that they're choosing to actually
communicate through.
Communicating an idea, one-on-one, and kind of building consensus beforehand is a really
effective thing and doing that on the platform of choice of someone you're trying to communicate
with is really, really powerful and impactful and it's a good way to actually build goodwill
with both that person and the community because you're not presenting something that's highly
contentious without kind of understanding everyone at the table and how they can kind
of engage with it and where they're standing and maybe understanding their objections,
as well.
So this has kind of been an evolving thing for me.
But you know in that evolution, I've really learned that there are so many platforms that
we all prefer to be on.
You know, for political reasons or privacy reasons, or, you know, just access reasons.
There's a lot of different things that you have to cater for if you're building an open
source community.
You have to be willing and open to accepting communication on different media, just because
it's so -- the internet landscape for communication is so broad.
So whether that's IRC or Twitter DMs or email or whatever, please be open to that because
that's a really good way to open the barrier to contributing.
That said if you're not having a centralized communication media, you need to also assert
that that's an OK thing, because just assuming that everyone knows that or that they'll be
willing to communicate to you what their communication preferences are is a challenge.
So asserting that, you know, you can reach out to us on Twitter, or you can send us an
email or, you know, if you're in any of these Slack groups you're also welcome to do that,
or if you're in Discord or IRC or whatever.
Making sure that you're open to that but also being open to having more social media is
really impactful to accessibility in terms of personal and global access.
In io.js, it became very transparent of how do we do these things, but I was still really
nervous and not really comfortable.
I ended up back-channeling a lot of people, Michael Rogers specifically I back-channelled
quite a bit, just because I didn't know what I was doing, I also commented on GitHub a
lot.
I engaged in there.
GitHub is also a valid communication media.
And I also reached out to people on Slack.
And I basically tried to go through all of the channels and make sure that I was connecting
with people and that helped me succeed, but I also realize the inverse is true, where
if you go to other people, you can help lift them up and help them succeed more.
So by doing that, you're actually building trust and awareness that it's OK to reach
out to me on this platform, or it's OK for me to not exist on this required platform
that is basically mandated by this project.
So certain channels, you know, given that, will eventually emerging as the thing your
team or your group or your community needs and uses once you hit a certain scale.
In Node, there isn't actually a suggested way of how we can like realtime talk to each
other.
There's been many long and contentious proposals about IRC versus Slack versus Discord or some
other platform.
And we've kind of decided that we're not going to have a centralized platform outside of
GitHub because there are too many people who care too passionately about it.
And it's like you would be surprised at how contentious setting up a Slack is.
It's real hard.
So, you know, I think there's a lot of benefit in that, though, in that we as individuals
can go and talk to each other outside of that.
There's also the Node.js Slack, like the unofficial community Node.js Slack that we have brought
in as a community project and we really appreciate and I talk to a lot of people on there.
There's a lot of media that we can actually go and use, and this actually ends up being
beneficial because it creates multiple routes for people to come and participate where they
might not have found this other route because it's not the normal kind of space that they
would live in.
So basically you kind of need to have every communication platform available.
And be able to communicate through there and that doesn't mean you as an individual, but
it's very, very helpful to have access, or be accessible, rather, to everyone, via as
many platforms as possible.
And this becomes especially true geographically where certain sites or tools are blocked and
others may not be, or others are preferred, whereas these ones are unknown and nobody
is on them in XYZ geographic region.
So try to go where people are comfortable.
Quick recap.
I'm going to let you out a bit early.
So the lessons.
Don't build too much.
Please don't build empty communities.
Build something that's minimal and then let the community grow naturally.
Empower your contributors.
Contributors who feel empowered are actually more likely to stay around and contribute
and grow in your project and help your project grow, rather than kind of floating away once
they make a first PR and get a badge on their repo or on their profile.
Accept help as a leader.
This is a really hard one to accept, and to exercise, and if you want help, I'm more than
happy to help.
But if you don't let others do work, you're not going to have a good time as a leader
and you're eventually going to burn out and not be able to continue.
And then communicate with people in different ways.
Please allow people to communicate with you how you're comfortable, but also how they're
comfortable and try as a community organizer to cater to your community's needs, which
again, taking into account lesson 1: May be different from what you initially expect.
So, how you can actually apply these lessons today.
Have a scope.
Have something that you can really stick to.
This helps ensure that you're not creating empty space and it helps kind of nurture your
natural growth.
Have a path to meaningful contribution, so don't just always suggest, oh, yeah, the good
first contribution is adding a test.
Yes, tests help increase coverage and they help you kind of as a project become more
stable, but that also, like, at the end of the day, doesn't really feel meaningful as
a contributor who's coming to your community for the first time.
Having something where they can go and help ship a feature and go and help improve a feature
or go and help do something that actually is impactful and that users of your project
or your community will end up seeing, is a really good way to do that.
Ownership leads down an unhealthy and unhappy path.
Owning a community on top of like the toxicity for your own community, is also really unhealthy
for you and it's something you should avoid at all costs.
I highly recommend this.
Onboarding new leaders and onboarding people who care about the project is really important
for your success and your own personal health.
And then communicate effectively.
Have multiple channels.
Know that people use them differently and that's okay, and accept that.
But yourself, you should try to use them as effectively as possible to communicate with
your community.
Thanks! [applause]