Open Source Protips from the Trenches

Talks

Matt Rogers

1 talk

#open-source

#community

#contributing

#developer-experience-dx

#ruby

#mentorship

#collaboration

Open Source Protips from the Trenches

by Matt Rogers

In the talk "Open Source Protips from the Trenches," presented by Matt Rogers at the LoneStarRuby Conf 2013, he discusses the challenges and opportunities within open source contributions, emphasizing the importance of community interactions. The talk addresses how both new and experienced contributors may experience difficulties in kindness and support while engaging in open source projects. Rogers shares several key strategies to enhance the contributions' experience, such as:

Avoid Anger Responses: When faced with negativity, it’s crucial to take a step back before responding. This ensures that the reaction is more thoughtful and constructive.
Avoid Jumping to Conclusions: Understand the full context before providing feedback. Rushed or uninformed responses can lead to misunderstandings and diminish community relationships.
Encouraging Contributions: Instead of being indifferent, project maintainers should actively invite contributions. A welcoming response can greatly motivate newcomers to engage more deeply.
Promote Questions Over Orders: Leadership in open source should be collaborative rather than authoritative. Asking questions encourages engagement and provides a more inclusive environment.
Fostering Support: Those who offer help to contributors create a nurturing atmosphere that encourages ongoing participation.
Celebrate Contributions: Regularly recognizing even small contributions fosters a positive environment and encourages further participation. Acknowledgment can include fun comments and emojis, ensuring contributors feel valued.

Rogers illustrates these points with a personal anecdote from his early experience contributing to the KDE project, where he faced a dismissive response that hindered his willingness to contribute further. This highlights the significant impact of community dynamics on contributor engagement. Ultimately, the talk encourages building a kind, supportive community to optimize contributions and enhance everyone’s experience in the open source world.

00:00:15.759 As open source developers, we spend a lot of time pushing code up to GitHub. We merge pull requests, also on GitHub, and we spend time trying to figure out why our builds have failed, yet again. At times, we're looking for places to fix our bad code, and we use some incredible tools to do this.

00:00:26.320 When things are going well, we are wonderful to each other. However, when things go wrong—and they go wrong much more than we think—we can be quite terrible to one another. This experience isn't unique to the Ruby community; it happens in various places within our community and elsewhere.

00:00:37.120 There's a flow of vitriol that can resemble a fire hose, but ultimately, open source isn't just about code; it's about people and how we treat them on a daily basis. We're more than just the usernames we see on platforms like Reddit or Hacker News. As Ash Dryden said at Ruby Midwest, "It's people all the way down."

00:00:51.840 As a community, we generally do a good job of treating people well, guided by the principle of "Minnesota Nice." However, we all stand to gain by consistently being awesome to one another. This way, we can create more positive experiences and fewer negative ones. After all, we don't want people to feel trapped in a minefield with no way out.

00:01:06.720 For the next little while, I want to share some things I’ve discovered that can help us improve as a community and continue our tradition of community awesomeness without inadvertently creating drama.

00:01:20.000 I have a specific example that I want to discuss from ten years ago involving an open source project called KDE. If you're not familiar, KDE is an open-source desktop environment for Linux. It was 2003, and just ten days prior to making a particular commit, I had just received access to KDE's CVS repositories.

00:01:27.520 At that time, there was no Subversion, no Git; it was CVS! On a boring day, I decided to find something different to work on outside my usual focus, which was messaging protocols and instant messaging clients. So, I hopped onto IRC and began to poke around for tasks. I was informed that I could help on some code by adding null checks to ensure the code wouldn't crash. This task took about an hour, consisting of ten minutes of actual coding and forty minutes of compilation.

00:01:47.680 After completing the task, I received a rather curt reply. I remember thinking, 'Whoa, wait, what just happened?' I was caught off guard and perceived it as a lack of support; the response felt harsh and dismissive.

00:02:00.480 That experience profoundly impacted me and my contributions to that section of code. After my first commit in 2003, I contributed roughly ten more times over the next eight to nine years. My next contribution occurred nearly two years later, which was simply to fix a build issue. Then another fix enabled my email to work properly. Ultimately, that initial harsh reply led me to think that new contributors were generally unwelcome in that part of the community.

00:02:21.360 Sadly, this type of exclusion happens frequently, either in the Ruby community or in others. So my first tip for you is to avoid responding in anger. There are many things you can do to make those situations better. If you're feeling angry, remove yourself from the situation, do something else, and come back later to reconsider your response.

00:02:42.400 If you revisit the situation and you're still angry, walk away again. Engage in some exercise or take a break—anything to help you clear your mind. When you eventually respond, I guarantee it will be a hundred percent better than the hasty response I initially received.

00:03:05.760 Now that we've addressed anger management, let's talk about the pitfalls of jumping to conclusions. I frequently fall into this trap and often regret it. For instance, in a recent project where I worked on upgrading to Rails 4, a developer kindly informed our community via email that he had merged his changes. In my haste, I reacted too quickly without checking the announcement.

00:03:17.760 My response ended up being ill-received because I hadn’t done my diligence and had forgotten to see the prior communication. This mistake made me look foolish and, frankly, a bit of a jerk. Therefore, the next tip is to put yourself in someone else's shoes before you share your perspective; this strategy can prevent misunderstandings and unnecessary conflict.

00:03:34.560 I want to pose a question: What do you think is one of the main issues facing contributions in open source projects today? Many reasons stem from this challenge; notably, a vast number of people choose to start their own projects rather than contributing to existing ones. This reality can make establishing a vibrant contributor base challenging.

00:03:52.480 Another contributing factor is that many individuals pursue open-source projects as a learning opportunity, while some simply lack the motivation to contribute. Consequently, we often find that 80% of the work is completed by only 20% of the people involved in these projects.

00:04:16.760 This brings us to the issue of how we can encourage greater participation. Simply telling someone to "patch accepted" isn't effective, nor is it the best way to welcome input or contributions. Having experienced this personally, I can attest that an indifferent response discourages potential contributors.

00:04:30.320 A more constructive approach is simply to convey that you're willing to accept contributions. Invite contributors to help and reassure them that their efforts are welcome. Just recently, I merged a pull request from someone who contributed for the first time, and all I did was prompt her with a question and point her toward where she could make changes.

00:04:52.720 This approach illustrates tip number three: always ask questions rather than give orders. Even if you hold a leadership role, avoid acting like a dictator. We're more likely to attract contributors when we promote collaboration and support each other.

00:05:05.520 Pair programming can be a fantastic way to encourage involvement and help keep contributors engaged. As Mark illustrated in his lightning talk, offering help demonstrates to potential contributors that you, as a project leader, value their contributions and wish to foster a collaborative environment.

00:05:17.760 This leads us to tip number four: if you're providing assistance to someone, you are being absolutely awesome. By being supportive, you're creating positive experiences for others in your community.

00:05:37.680 I love to see contributions merged, and I particularly enjoy offering responses that encourage others to keep creating and contributing. A positive response can motivate a contributor to submit more pull requests, leading to ongoing engagement in a project.

00:06:04.640 Another aspect that brings excitement to projects is the use of emojis and fun comments, helping to create a friendly atmosphere. Using enthusiastic messages can fill a project with a sense of whimsy and recognition for contributors.

00:06:20.240 Ultimately, I want to emphasize the importance of offering praise and encouragement frequently. Recognizing others, even for small contributions, helps newcomers feel valued and nurtured.

00:06:31.040 To wrap things up, we excel in fostering kindness within our communities, but we can always improve. Just as businesses aim for happiness—whether it's customer or employee satisfaction—we should focus on optimizing for kindness. If you're interested in improving further, I highly recommend reading the book that has informed much of this talk.

00:06:48.880 It’s an older book—the version from 1981 is highly recommended—having been in print since 1936, and its earlier insights are incredibly relevant.

00:07:05.600 Thank you for your time. My name is Matt Rogers; I go by Matar with an underscore on Twitter. This has been "Open Source Pro Tips from the Trenches," and I'm happy to take any questions or engage in discussion before I conclude.

LoneStarRuby Conf 2013