One thing I have learned while attending events around the world is how to at least say four things in the local language: "hello, goodbye, please, and thank you." It's not much, and I realize its yet-another sign of U.S. cultural centrism that I don't know more languages than English and some German, but I figure if you're going to visit someone's home, the least you could do as a good guest is try to be polite.
Language barriers are not the only thing that can create difficulties communicating, particularly within communities. Personalities, methodologies, and even the most basic goals for a community can put community members at odds.
That last might seem a bit off. After all, why would the goals of a community be unclear? We're all here to make great software, after all. But are you sure that's what everyone in your community wants? More importantly, have you asked?
That's the important thing about an open source community that a lot of people might miss: every single individual has a reason for being there. And it's not always going to be about the software.
For some, it's about expressing their talent in a constructive way. For others, it's about relating to people who seem to understand them. Perhaps it's about building skills so someone can get a job.
You can see how the betterment and creation a certain piece of software may not be the end goal for someone's participation in your software community. It could actually be a means to another end. That means people are coming into your project with different agendas. This, in and of itself, is not a bad thing. Indeed, you want to have multiple points of view when working on projects, to help build better solutions.
But it should serve as a cautionary tale for anyone who wants to propose a new idea in a project and assume that everyone will want to go along with it. "Let's use golang" could be met with resistance from people who wanted to practice their skills on another development language. Or "we don't need a code of conduct" could alarm people who are looking for a safe community in which to participate.
The good news, this is not a terrible problem to solve. You can simply ask.
Community feedback surveys are not universally performed within open source projects, but they should be. Especially for projects with more than 20 people. Less than that, too, but smaller communities can have more informal conversations.
Creating Community Surveys
There are two main things to remember when working on a community survey: setting an objective and asking the right questions.
Setting an objective is relatively straightforward, if you make the objective focused. A survey should not be "I want to know everything about my community members." That sounds nice, but it's not really achievable. Instead, narrow it down to a more specific goal, such as:
- Exploring new development tools
- Adding new features
- Event goals and objectives
- User satisfaction
Asking the right questions is trickier. You want to get honest answers so you have to make the questions as neutral and unbiased as possible. So, "How much do you think Acme Tool sucks?" would be a bad question. Reframing it to something like "Please rate your overall satisfaction for Acme Tool." would be a lot better.
The best way to do this would be to let someone outside your community take a look at your survey when you think you have it done and have them look for instances of bias or leading questions. If they are outside of the community, then they won't be thrown off by any loaded questions you may have accidentally written.
However you go about getting the information from your community, remember to keep an open mind for the surprises that will come. Cast aside the assumptions you have been carrying, and move forward armed with the knowledge you have gained.
Image available under the CC0 Public Domain Dedication license.
About the author
Brian Proffitt is Senior Manager, Community Outreach within Red Hat's Open Source Program Office, focusing on enablement, community metrics and foundation and trade organization relationships. Brian's experience with community management includes knowledge of community onboarding, community health and business alignment. Prior to joining Red Hat in 2013, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit