Placeholder Image

字幕表 動画を再生する

  • 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