Taking risks in an open-source community

With a little prodding from Rogan, several Evergreen community members stepped up over the past week to commit to working on a project during the hackfest day, pushing us over the threshold where I am required to sing karaoke sometime during the 2023 Evergreen International Conference. I am now researching sites where the karaoke will happen. If you know of any good karaoke bars in the downtown Worcester area that can accommodate a large group of conference-goers, let me know.

Many thanks to Terran McCanna, Ruth Frasur, Rogan Hamby, Stephanie Leary, Debbie Luchenbill, Scott Angel, Blake Graham-Henderson, and Galen Charlton for their commitments! We’re now up to ten commitments, still a ways off from reaching the threshold where Rogan will be able to pick my karaoke song. As a result, my anxiety level is still somewhat manageable.

I am also grateful to Terran and Debbie for adding the challenge to the agendas for the Evergreen new developers interest group and documentation interest group meetings. I hope to see high participation from both groups at the hackfest. In my experience, documentation is one of the most valuable contributions a person can make to an open-source project, just as valuable as the actual code.

The new developer interest group was formed back in 2019 with the goal of gathering together people in the Evergreen community who have an interest in learning more about coding for Evergreen, but very little experience. This group formed after I left the community, but, from what I’ve seen, the learning happening through their activities has led to more code contributions from people who didn’t enter the Evergreen community has developers. The more you can grow new code contributors in an open-source community, the more you can ease the pressure on all contributors as the work spreads out among more people.

This fact leads to my next fun fact about tuits.

Fun fact about tuits #2
Tuits can reproduce simply through the presence of other helping hands.

It’s true! More contributors in an open-source community can create tuits for everyone, allowing people to focus on areas where their expertise is required and/or where they derive the most satisfaction. The wishlist item that one contributor has never had the time to work on suddenly becomes doable when two or three new people step up to do the code review that had been taking up all of the contributor’s time.

This solution may seem simple, but recruiting and growing new contributors in an open-source community can be challenging. There may be a steady stream of people willing to spend time on specific tasks that are handed to them, and an open-source community should certainly be ready with a list of starter tasks on hand, but communities often are most in need of people who will take the initiative to find the tasks that need doing and step into leadership roles.

This type of contribution is one that requires people to take risks and step outside of their comfort zone. In order fully participate in the community, contributors need to share their thoughts and work with a large group of people, many of whom they do not know. A contributor’s code, along with all its potential flaws and clunkiness, is visible for the entire world to see. Contributors will make mistakes in very public ways, will need to ask questions, and will sometimes overstep. In short, they will need to make themselves vulnerable as they engage with the community to help support the project. It can be scary. But these risks are well worth the effort and will help you form connections with other community members and become a highly valued contributor to the project.

Many who knew me in the years I worked on the Evergreen project might assume I easily slid into the community and had no qualms about speaking up in community channels. But this assumption couldn’t be further from the truth. The first time I sent an email to the community list, I agonized over the wording of the two paragraphs before hitting the Send button. I was highly intimidated as I started involving myself in developer meetings, but I forced myself to speak up because I was working with two consortia that needed version 2.2 to be released before they could go live on Evergreen, and there was no perceptible movement towards a release date. Then, when the time came to make my first code contribution, I created a patch through GitHub instead of asking the Evergreen developers to add my key to the Evergreen working git repository. My rationale was, if I failed in submitting my bug fix, nobody would know I had even made an attempt. For every step I made towards becoming a leader in the Evergreen community, there were moments of taking risks and being okay with revealing my vulnerabilities to others in the community.

When considering ways to contribute to an open-source community, would-be contributors should step out of their comfort zone and take risks. Chair an interest group for a topic you’re interested in. Write documentation even if it means asking questions of a developer to get a solid understanding of how a specific piece of the system works. Dig into the project wiki to find those dusty corners that need work. Evergreen technical folks who are still contemplating what they should work on for the hackfest might want to consider stepping into the role of working on the next OpenSRF release. With a Wednesday morning pre-conference session on building an Evergreen release and core committer Galen Charlton on hand to answer any questions, it’s a perfect opportunity for more contributors to help with the OpenSRF release process. OpenSRF, which is required for Evergreen to run, hasn’t been installable from a packaged release for many months – it must be installed from the master git branch. The person who works on making the next release a reality will be making a very valuable contribution to the overall project.

Of course, open-source communities have an obligation to make it easier for would-be and current contributors to take these risks. Providing a welcoming atmosphere to new community members, providing documentation on how to contribute, and answering questions are all ways to encourage new contributors to become active in the projects. Community leaders should be forgiving of mistakes made by contributors – we’ve all made them. If a new contributor appears to be overstepping, examine your reasons for this perception. Is it because the contributor doesn’t fully understand the project standards and guidelines? If so, gently point them in the direction of documentation that explains these guidelines. Or maybe the perception stems from the fact that they are stepping into territory that has traditionally been your own. In that case, see if you can find common ground where you can both make valuable contributions in this area.

In 3 steps to developing psychological safety on opensource.com, author Kathleen Hayes suggests other steps open organizations can take to create an environment where people can feel comfortable taking risks.

Communities should also learn to take risks with their contributors. Often, an organization or community expects a contributor to demonstrate a high level of skill in coding or another area of expertise before giving them the power to effect real change. I prefer to take a risk on somebody who may be less knowledgeable, but shows a greater willingness to make consistent contributions to the project. As long as an individual has built a certain level of trust in a community, the project should show a greater willingness to take a risk on them.

Tuit Dashboard 4/8/23

• Days until hackfest: 18
• Days until deadline to commit to a hackfest project: 13
• # of hackfest commitments: 10
• # of additional commitments required for karaoke: 0
• # of additional commitments required for Rogan to pick the song: 6
• # of tuit cookie batches kmlussier must make: 1
• Musical artists mentioned in the context of karaoke in the community:
  • Burt Bacharach
  • Beastie Boys
• Musical artists that have not yet been mentioned in the community (in case somebody [Rogan] is looking for ideas):
  • B-52’s
• On a scale of 1-10, level of kmlussier’s anxiety at the idea of singing karaoke: 5