How to build a strong community for developing robust and valuable software

Participants at the Foundation for Public Code Storytelling workshop in Amsterdam

Public Code Promising Practices in conversation with Leslie Hawthorn from Red Hat

This article was also published on LinkedIn on 1 September 2022.

These conversations have been edited for print. They were originally a part of Public Code’s podcast Let’s Talk About Public Code.

No one group of individuals that gets together to do something exciting and valuable has all the answers. We will never have all the answers.

Often, when open source projects or communities get started, they get started because a group of people who know each other and are primarily in agreement about how to solve a problem decide to get together and solve their problem.

That is important to them, but that cannot be sustained forever if you want the project to grow. If folks have a change in their interests, you want to make sure that there is somebody who is equally excited to carry that work forward.

Hence, a strong community’s power is:

• sustainability,
• longevity, and
• a diversity of perspectives.

It’s lovely when we all get together as folks who are primarily like-minded to solve a problem but then what we find is we tend to think alike: you tend to be friends with folks that think like you. That’s just being an average human.

Let’s talk about a few things one must check to build a strong community.

1. Have a diversity of perspectives

Being able to have a strong community involves growing that community and growing a diversity of perspectives within that community so that you make sure that whatever it is that you’re producing is most valuable for all participants.

I have worked with communities all over the world, and I have personally seen better outcomes from communities that prioritize a diversity of perspectives, such as neurodiversity, physical abilities, geographic location, age, gender identity, etc.

2. Consider folks who are differently abled

We should ensure that the code we’re producing in these open source projects that are now becoming increasingly important to public administrations is also accessible and serves the most vulnerable citizens in our societies.

Also, we have a rapidly aging population of seniors who will benefit from this same focus on usability and accessibility. So having diverse perspectives means we can meet our constituents’ needs and make that community broad. We can’t do that without wide input.

3. Realize you will not be able to do all of the work yourself

There will be some dedicated individuals who are excited and some who are not. To ensure that there are long-term maintainers for these public software projects, we make sure to employ some individuals to do that work right.

Without a community, you will not be able to carry that work sustainably on your own. People need to take holidays or decide to do something else with their existence.

4. Ensure your group can explore other things

You need to have the ability for succession within your community and to ensure the original participants or the core group of folks can explore new, interesting, and exciting things.

Suppose you’re doing the same thing daily; there isn’t always space for imagination, creativity, and growth. So having more folks around to not only share their diverse perspective with you but also to share the load allows you to have that space for thought and creativity and to think about new things or new directions the project can go in.

5. Never forget we are human, not code

I think the most critical aspect of community building is one we don’t necessarily talk about because it’s one of those things that’s hard to measure - and this doesn’t necessarily have a bottom line impact.

We are human beings, and we need friends.

We need people to talk to.

We need folks in our life whose company we enjoy and who are our fellow travelers throughout existence.

If your open source project does not have a place where people can come and feel like they have nurturing, autonomy, mastery, and a place to exercise their craft and expertise. Whatever that may be, from writing software to producing beautiful documentation to doing a great podcast, people need to have joy.

It turns out a lot of our happiness comes from interacting with people with similar interests and who care about the same things we do.

So that social aspect, that feeling of identification and social cohesion, is a huge part of the community that gives people the energy to keep doing their work even if they’re having a hard day.

You know that that social fabric is so fundamental to the long-term sustainability of a project because people need to have joy in what we’re doing.

A lot of our happiness comes from our relationships with other people.

Here are some of the challenges to enabling a strong community

I will start by saying something I’ve been saying for a very long time, and I wish I could remember who said this to me the first time.

Software is easy. People are complicated.

1. Being able to explain to people not only the value of the work you are doing in your project, but also what the value is for them as a participant

That can be very challenging in a community where you work with a mixed group of volunteer contributors and paid professionals.

Usually, for the paid professional, what is in it for you is your livelihood.

Invariably, I think most folks involved in open source projects are not just interested in it because it’s how they earn their livelihood. Still, they chose to earn their livelihood in that way because they feel a particular relationship with what we think of often as traditional open source community values.

These include transparency, collaboration, and a rigorous evaluation of the different ways the project can move forward. And making sure that the best one is chosen based on a wide variety of input, making sure all voices are heard right, and creating an environment in which there is transparency.

2. Managing different types of expectations

There is a sense of mutual accountability in a very positive way. We are accountable for each other’s success and for making sure that if we make mistakes together, we fix them together. That can be challenging when you have folks with differing agendas, and I don’t even mean that in a negative way.

For example, suppose you have an employer who expects specific outputs of your product. In that case, the folks you work with in the community may not necessarily see the same amount of value as your employer does.

They may prefer to spend their energy over here. How do you rationalize these various sets of expectations to ensure that you can all continue working together effectively?

I’ve been doing community management forever, but this is where having a solid community management function comes into play because people must be doing work that is in their self-interest.

3. Make sure what people are doing benefits them

You want to ensure that what people are doing benefits them, or they won’t continue doing it. You need to make sure it satisfies the project outcomes as much as it helps the community and the end users of this software - that it meets their needs.

4. Having someone who understands these varying needs and expectations

I believe the only way to do that effectively is to have someone who can effectively understand all those needs.

Because it turns out if you’re producing software and you know what someone expects of you, and you’re trying to collaborate with other human beings, and you’re trying to maintain software systems guess what? What is the thing that no one has time for?

Understanding what everyone else needs and wants and how to ensure they all get there.

Imagine we start small, are all friends, and know how to help each other get where we need to go at first. The more work we do and the more impact we have, the easier it is for that kind of automatic social cohesion and glue to crumble, and this is why community management and thinking about how you’re going to manage your community from the very start is such an essential part of the long-term success of any project.

As an internationally known Developer Relations strategist and Community Management expert, Leslie has spent the past decade creating, cultivating, and enabling open source communities. She’s best known for creating Google Code-in, the world’s first global initiative to involve pre-university students in open source software development, and receiving an O’Reilly Open Source Award in 2010 for her work to grow the Google Summer of Code program and her contributions to Humanitarian open source projects. She is currently a Senior Principal Program Manager at Red Hat, focusing on the CentOS project in the Open Source and Standards Department.

The Foundation for Public Code helps public organizations collectively develop and maintain public code. This results in higher quality services for the public that are more cost effective, with less risk and more local control. We define ‘public code’ as open source software developed by public organizations, together with the policy and guidance needed for reuse. Get to know us through this short leaflet.