Project Management
Maintain Less, Mentor More: Community Building Techniques from Open Source

Summarized using AI

Maintain Less, Mentor More: Community Building Techniques from Open Source

Wesley Beary • October 08, 2012 • Earth

In the talk "Maintain Less, Mentor More: Community Building Techniques from Open Source," Wesley Beary shares insights on the importance of community in open source projects and how it can significantly enhance the experience for both maintainers and contributors. He reflects on his personal experiences with the Fog cloud computing library, discussing the challenges of initial solo development and the evolution towards fostering an active community. The key points of the talk include:

  • Engagement and Participation: Beary highlights the importance of community involvement in open source, suggesting that maintainers actively engage with contributors to cultivate a collaborative environment.

  • Transition from Maintenance to Mentorship: He explains how his role shifted from merely fixing bugs to mentoring contributors, enabling them to solve problems and contribute effectively. This change not only alleviated his workload but also reinvigorated his passion for the project.

  • Community Collaboration: The speaker emphasizes the value of collaborative efforts over individual contributions, as interactions with new contributors brought fresh perspectives and identified overlooked issues.

  • Effective Communication: Beary discusses the significance of language in interactions within the community, underlining that expressing gratitude and focusing discussions on solutions rather than problems fosters a more positive and productive environment.

  • Constructive Engagement: He encourages maintainers and contributors alike to focus on building bridges and seeking mutual understanding, which can lead to stronger community dynamics and collaborative problem-solving.

He concludes by reaffirming that community building is fundamentally about people and relationships, rather than simply managing code. To thrive in open source, it is essential for both maintainers and contributors to prioritize community engagement and support. Beary invites attendees to share their experiences and emphasizes the role of empathy and appreciation in nurturing open source communities.

Maintain Less, Mentor More: Community Building Techniques from Open Source
Wesley Beary • October 08, 2012 • Earth

Open source is hard but it gets much easier with a community backing you. I tried many approaches while developing fog, and thankfully, the resulting community is amazing. Now I'm doing my best to apply the same principles to the Heroku CLI and other open source projects. I make mistakes and often get lucky, but I have learned a lot about fostering community in the process. This session distills some of my techniques and explains how you can help build community around your favorite projects.

Help us caption & translate this video!

http://amara.org/v/FGgY/

Aloha RubyConf 2012

00:00:15.400 Good afternoon, everyone. I appreciate this vote for me over the beach. That is pretty fantastic. I hope that I can make your last 45 minutes of the day or so enjoyable and worthy of the non-beach vote. I've come to talk a little bit about community building and my experiences surrounding that, and how they relate to open source.
00:00:34.360 Some of the things that I think I've kind of gone to open source to find are things that I can't find elsewhere. Hopefully, somewhere in there, you guys can gain insights into ways that you can participate, contribute, and manage open source projects that maybe you haven't quite thought about before.
00:01:06.119 To start off and make sure that people are awake, I'd like to see if I can get some participation. If you use open source, could you please raise both hands? All right, I think this is most everybody not touching their laptop. That's progress! I'm glad that you're paying attention.
00:01:17.560 Now, if you contribute to open source, could you keep your hands up? It's actually a pretty good number of people that do both, and I’m glad for those of you who only had your hands up for one of them. If you have any questions or anything about how you can start contributing, and it's not clear by the end of this, by all means, talk to me. One of the best parts of my week is frequently when someone comes up to me and says, 'This is my first pull request that I am submitting to your project.' That is just a great feeling to know that I’m helping someone to start being part of what I feel is a really great community.
00:01:42.640 So, where does my experience come from? My work with Fog has taught me a lot. Just to gauge, how many people have used Fog? How many people have heard of Fog at least? There's also a discrepancy that I would like to fix. I'm glad that some of you have used it and that more of you have heard of it.
00:02:09.200 For those of you who haven’t used it, the simplest way to describe Fog is that it's a cloud computing library. In the same way that ActiveRecord provides a uniform interface to PostgreSQL or MySQL, Fog tries to provide the same with different Cloud services, whether it’s S3, Rackspace storage, or Amazon EC2. It attempts to provide common interfaces so you can start getting work done without digging into every detail immediately.
00:02:40.879 Fog has been an interesting project for me. I have certainly learned a lot from it technically. I would say that in many ways I'm a cloud expert now, where I was not at all when I started this. But it also taught me a lot about open source and what it can provide.
00:03:11.760 In the first year of working on Fog, I spent almost every day outside of work working on it because I had other commitments. I sensed its importance because I wanted this tool, and it was not available, so I decided to do something about it. That was also decent reasoning to start a project.
00:03:31.439 However, things took a turn, and it became this sort of DIY Death March. I had the motivation to start, but as I learned more about cloud computing, I found it harder to stay motivated. It was difficult to convince anyone to use Fog when they already had AWS S3 or some other library they were using, leading to frustrations.
00:04:05.039 Along the way, while starting to get more adoption, it became a liability rather than a benefit. I now had a larger base of people running into edge cases that I hadn’t thought of. I would suddenly have to fix bugs for users I had finally convinced to try Fog. My codebase started expanding quickly, which, while beneficial, also meant I had more to manage. Instead of spending a half hour or 45 minutes, I was spending one to two hours every day just responding to bug reports.
00:04:48.759 Ultimately, I fell into a downward spiral where I dreaded working on Fog and was less excited about the project. I believe this is a danger that many open source projects face. Hopefully, you will see some ways to avoid getting into this situation.
00:06:09.120 I started the second year with a focus on two things. One was building more community around Fog so that others were involved and could assist with some of the burden. The community did grow; we got more contributors this year, which made it clear that the project was becoming sustainable.
00:06:47.840 Over time, the amount of time I was spending on it diminished. Instead of being involved in low-level coding, I found myself doing more project management. This involved helping others who were excited but lacked the background to contribute. That was really rewarding because I felt energized instead of dreading my responsibilities.
00:07:37.879 The nice thing was that I transitioned from a state of dread to excitement. When someone opened an issue, I saw it as an opportunity to interact with someone who was interested in the software. My focus shifted from merely maintenance to mentoring.
00:08:13.680 This taught me the difference between a gardener and a topiary artist. I preferred the creative side of development—crafting something amazing—over just keeping the software running. I didn’t want to be in a situation where I was merely preventing the house from collapsing.
00:08:35.199 This realization pushed me into a mentor role, where I focused on helping others rather than just addressing issues as quickly as possible. Instead, I learned to open discussions around the issues at hand and find out how I could help the individuals involved.
00:09:45.079 One of the worst things I did for my open source project was merely solving bugs. This was a huge mistake that led to burnout. Instead, I've found that fixing misunderstandings is far more beneficial than fixing the software directly. Ultimately, the path shifted from individual contribution to collaborative effort.
00:10:47.600 My focus transitioned from hacking around problems for my own learning to teaching and empowering others to skip the early hurdles that I had to go through. This shift made it clear that our collective efforts in open source fostered a richer learning environment than individual work.
00:11:57.920 As a mentor, I gained valuable perspective from those new to my project. I recognized that they could help clarify documentation gaps and identify issues I had long overlooked.
00:12:54.799 The language we use in these discussions is also crucial. I've found it essential to convey my gratitude and enthusiasm clearly. Emotion is challenging to express in text, so I go the extra mile to share my appreciation for contributors.
00:13:59.360 Moreover, I encourage everyone, regardless of their level of involvement, to understand the importance of language while interacting in open source spaces. It can drastically affect the responses and outcome of our interactions.
00:15:09.120 Our discussions define how we engage with others, whether you're maintaining or contributing to a project. The language we choose shapes our community.
00:16:27.440 It’s about building bridges rather than just creating barriers. This approach leads to stronger communities where people are motivated to collaborate rather than just pointing fingers.
00:17:44.560 Conversations should focus on solutions rather than problems. Seeking mutual understanding rather than blame can transform interactions. We can foster constructive discussions where our collective efforts lead towards progress.
00:19:07.679 I invite everyone to engage constructively. Appreciate the efforts of others, show gratitude, and actively contribute to the discussions. Show empathy with the maintainers.
00:20:20.960 Finally, as we engage with open source communities, let’s remember that community building revolves around people, not merely code. Collaborate more; focus on community rather than simply consuming resources.
00:21:59.080 If you have questions, don't hesitate to ask. I encourage everyone to share experiences and insights.
00:23:02.040 Thank you for allowing me to share this afternoon. I hope you've enjoyed this conference, and I look forward to any questions.
Explore all talks recorded at Aloha RubyConf 2012
+17