Big milestone for #Arazzo 1.1 - #AsyncAPI support has been merged into the release candidate. Arazzo will soon span @openapis.org and AsyncAPI. One workflow language for multiple API styles.
Huge thanks to the community. Just 136 review conversations over 7 months!
github.com/OAI/Arazzo-S...
The best communities aren’t free of problems; they’re places where people trust they’ll be treated fairly when challenges come up. Building that trust is proactive work, not an afterthought.
#OpenSource #CommunityHealth
2️⃣ Address conflict openly using fair processes and visible forums. Don’t let issues fester in private.
3️⃣ Focus on issues, not individuals. The goal isn’t to “win” but to find solutions everyone can accept. Follow up to support relationships and keep building trust.
Unspoken or ignored conflicts shape the community’s culture in subtle, often harmful ways, making it harder for newcomers and marginalised people to participate.
Here are 3 practices for better handling conflict:
1️⃣ Identify disagreements early and give people a safe way to raise concerns.
If everyone always agrees, it’s either a tiny group or a culture where dissent is hidden; neither is truly healthy.
What matters most isn’t whether conflict happens, but whether there are clear ways to deal with it.
A healthy community isn’t one without conflict; it’s one where disagreements can surface safely and are managed constructively. When people care about technical direction, values, or priorities, debate is a sign of engagement, not dysfunction.
Following clear guidelines for consequences helps keep things consistent. It is also important to follow up with the person who reported the issue, so they know what happened and feel heard. The code of conduct is just part of what the community’s culture is really like.#OpenSource #CommunityHealth
Enforcement means having a clear way for people to report problems, like an email address or a form. There should be a standardised process for reviewing reports, with a team that reviews each case fairly and quickly.
Writing a code of conduct is the easy part. The real challenge is enforcing it consistently every time, especially when someone important breaks the rules. If enforcement is inconsistent, it is worse than having no code at all. It shows that some people’s safety matters less.
It also sends a message to people who have had bad experiences before, to developers who feel left out, and to newcomers who might be nervous: we thought about you before you even joined.
A code of conduct explains what your community stands for: everyone should be able to join in without facing harassment or exclusion. It gives everyone a common set of expectations, sets clear standards, and helps maintainers avoid making quick, subjective decisions.
A code of conduct is one of the best ways to keep an open-source project stable and healthy.
When a community does not have a code of conduct, it relies on unwritten rules that only insiders understand. This approach helps those already in the group, not newcomers.
Projects rely on people. Community forms the foundation. People do not just support the project; they are why it grows, adapts, and succeeds. Stay focused on them.
#OpenSource #CommunityHealth
The best community builders I have worked with did not find a perfect balance. Instead, they made the tension clear, built systems to ease it, and kept putting people first, even when the project demanded attention.
Rather, the appropriate approach depends on the community's current needs. When all members understand and agree on these priorities, decision-making becomes more straightforward. The process then shifts from choosing between values to operating within a shared value framework.
The objective is to establish frameworks that facilitate both, rather than making difficult decisions daily. Each Open Source community establishes its own priorities, whether focused on growth, stability, inclusion, or technical excellence. There is no universal solution.
Hitting a milestone is urgent. Noticing when a contributor goes quiet is important. Both matter, but they work on different timelines. The milestone has a deadline. The contributor has a time window. If you miss that window, they may leave. Be clear about which timeline you are working with.
Ignoring this tension is a mistake. When community builders internalise it, burnout follows. When leaders overlook it, decisions lose context. Raise this issue in meetings and retrospectives. Let it be a team conversation, not an individual burden.
Project or People: Navigating the core dilemma in community health. This tension sits at the heart of community management. Here is what took me a while to recognise: the project and the people may seem to compete, but they do not.
Access means having clear ways to join and flexible ways to communicate. This helps open the door for everyone.
Inclusion clears away obstacles so people’s talents can shine and help change what is possible.
#OpenSource #CommunityHealth
Belonging means people stay when they feel noticed and valued.
Representation is about showing who the community welcomes. The more visible and open you are, the more people will feel invited.
Inclusion does not happen by accident. Saying "Anyone is welcome" is not enough. True inclusion means taking steps to remove barriers. One is just a hope, the other is real action.
Inclusion relies on three things: belonging, representation, and access.
When newcomers see others like themselves, it becomes easier to imagine joining in. Diversity is more than a good feeling; it is a smart strategy. Communities that reflect the people they serve are more likely to grow, last, and make a real impact.
Open source is more than just code; inclusion is at its core. When people feel they belong and have access, new voices join in, and the results improve. Seeing others represented makes it easier for more people to get involved.
05 · Contributor attrition Most contributors make 1-2 contributions and never return. Not because they lost interest. Because nobody followed up.
04 · Unresolved conflict Disagreements are healthy. Ignored disagreements are not. Without a process, tensions fester until they explode, or until people quietly disappear.
03 · Contributor invisibility: Behind every visible success are quiet contributors. If we overlook them, we risk losing the energy that keeps projects alive.
02 · Gatekeeping disguised as standards. Lower the barriers, not the bar.
01 · Maintainer burnout Free labour. Endless demands. Zero recovery time. The most common reason Open Source projects die isn't a lack of interest. It's one exhausted person who finally stops.
🔥 Nobody puts these in the README.
The 5 real challenges in Open Source communities and why most communities pretend they don't exist.