字幕列表 影片播放 列印英文字幕 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]
B1 中級 構建開源社區--Tierney Cyren--2019年美國JSConf大會。 (Building Open Source Communities - Tierney Cyren - JSConf US 2019) 0 0 林宜悉 發佈於 2021 年 01 月 14 日 更多分享 分享 收藏 回報 影片單字