Building Vibrant Open Source Communities: Lessons from Rocky Linux and CNCF

Editor's Notes

• #11: Hello. Open source is more than just code, or even non-code contributions. It’s a COLLECTION, of the gifts of time, knowledge, and other resources contributed by people. I suggest to you that the foundational task of any open source project is to collect, organize, and redistribute contributions in a way that benefits the community. When I was invited to serve as the community architect for Rocky Linux, I had to think a lot about how to motivate and support the people who contribute to the community, and how to make it accessible so more people could become contributors.
• #12: I started by looking at how people are motivated to do anything. I stumbled across a Linked In blog post last summer, from the CSR Group, about “Understanding the five salaries every job offers and the pitfalls of chasing the wrong one.” Basically, ways people are motivated to trade in their time for the benefit of the organization. The obvious one is money. But that doesn’t account for why some people stay in jobs that pay below their range, or why some employers experience high turnover despite paying well. And it certainly doesn’t account for open source, which sometimes pays a financial salary, but often doesn’t offer one at all. For the record, the Rocky Enterprise Software Foundation, or RESF, which hosts Rocky Linux, has no paid employees. A couple of our sponsors have hired Rocky Linux contributors and give them paid time to work on the various parts of the project. But for the most part we are all volunteers in addition to other careers. So how else could I motivate people to invest their personal time into our project, and attract new ones to join us?
• #13: Being part of an open source community can offer psychological benefits, like a sense of competency with a subject. Or a sense of pride in helping curate a valuable tool or software that has wide adoption.
• #14: It can offer social benefits. Friends who check in on you, who cheer on your successes and encourage you when you struggle. We are wired to seek out people like ourselves, and open source is one place to find that.
• #15: You can learn new things in open source community. I discovered open source community, Looking for the chance to grow as a technical writer. Get the chance to practice working with version control software. Be part of a testing team to prepare for a new release. Learn technical writing by documenting tutorials. You can even learn how to be part of a team by just attending team meetings, listening for assignments you can do, and taking feedback to make your contribution be its best.
• #16: And finally, some people are motivated by simply the freedom to contribute on their own terms. In open source, contributors work on the tasks that they choose, at the time it is convenient for them. A good community works to reward contributors by adding value to all of these categories.
• #17: Contributors who have been around for awhile probably already know what the thing is that gives them value. The reason we want to focus on that for new contributors is because you get a small window to attract people when they come. Do you know what the things are that a new person will find, that will bring them value?
• #18: The single task I have been working toward in 2024 has been to make it easy to become a Rocky Linux contributor. This is like our front door, and I want to make sure that door is bright and shiny, the door handle works, and people know right where they are and how to get to the information they are seeking.
• #19: One way to make it easy is to make shared knowledge accessible. That way anyone who wanders in has a place to get caught up on what the project is up to, without needing a personal tour. Today I want to share with you, 4 ways we work to make shared knowledge accessible.
• #20: As a first stop, A code of conduct outlines from the very beginning what a newcomer can expect from the community. Here is how we did it in our community. This code includes examples of positive behaviors our community values, like kindness and open mindedness, and examples of behaviors that are considered offensive. It outlines the consequences of offensive behavior. when newcomers read this code and realize there are rules of engagement that protect them, They are reassured to continue further into getting involved in the project.
• #21: Our code of conduct includes these elements: Our pledge to the community Our standards of conduct, including examples The scope of these standards. This applies to all of our community spaces, to those representing our community in public spaces, and to anyone using a community email address. How enforcement works: Who is responsible for enforcement, which in our case is the community leaders; how someone can make a report; and what are our guidelines for enforcement; and the attribution of where we found this particular code. And attribution, which is where our code is derived from. Yay, open source community materials!
• #22: In essence, our code of conduct includes examples of positive behaviors our community values, like kindness and open mindedness, and examples of behaviors that are considered offensive. It outlines the consequences of offensive behavior. The reason a code of conduct is important is because when newcomers read this code and realize there are rules of engagement that protect them, They are reassured to continue further into getting involved in the project.
• #23: With a code of conduct in place, we can organize the project. This is primarily done through the project documentation and the community wiki. (move on to next slide)
• #24: We believe excellent documentation should be accessible. To that end we make a standard pre-reading layout. We add a check for gendered language. We review the docs whenever we have a major revision to ensure they are still correct. We make sure it’s supported on a variety of browsers, across different devices, and by actual accessibility tools. It should be easy to contribute to documentation. Easy to find the starting point, easy to comprehend for people who might have English as a second language. And for the more complex parts, consider whether you have tutorials or easy places to ask a live human for help.
• #25: Here is an example of the pre-reading layout, which includes the reader’s prerequisites for using this guide, the assumptions we make about the reader, and an introduction to the topic.
• #26: In addition to accessibility features… It should be easy to contribute to documentation. Easy to find the starting point, easy to comprehend for people who might have English as a second language. And for the more complex parts, consider whether you have tutorials or easy places to ask a live human for help.
• #27: Easy and accessible are also important when applied to storing other shared knowledge. A project is accessible when a visitor can easily find content like notes from previous meetings, links to recorded meetings, blog posts, and presentations that explain the project. From foundational beginnings, to roadmaps of present projects and dreams for future development A newcomer will want to easily find notes from previous meetings, links to any recorded meetings, blog posts, or standard presentations that explain the project.
• #28: You can see here in our Community Team sidebar menu, we now have documented our meeting notes, roadmap, which is our current initiatives, Past Events we have attended, and reports for each of those. I’ve got a project tour presentation that still needs to go in that menu, that’s where it will live.
• #29: Maybe your project doesn’t have notes yet. When I started as community manager we didn’t even hold meetings, let alone keep notes. If that content doesn’t exist because a project isn’t actually holding meetings or publishing blogs…creating content like that is a great place to start with making a project more accessible. Don’t know where to start with blog content? There should be at least an initial post that describes why the project exists, and outlines the project commitment to the community.
• #30: All these various bits of info may be stored in various places. So above all, a project needs a single point of entry that collates where to find all this shared knowledge. This is the readme file. It’s an introductory statement about the project, and a bullet point list of the pieces I’ve just been talking about. This idea of making shared knowledge accessible comes from a tool for communities, that was developed Jonas and the communities he has worked with over the years.
• #31: To sum up, the way to make your project accessible and help newcomers feel welcome in your community is this one thing. Make your shared knowledge accessible. there are lots of other metrics and checks
• #32: These are things we have learned from our experience. Hopefully you’ve heard something here today to help you in your quest to build vibrant open source community for your project. I’ll close by saying, there is one more thing I’ve learned about being a community leader, and that is to always be prepared with swag! I have enamel pins and stickers for everyone at the end. Thanks for your attention!