Most open source projects pick communication tools the wrong way

How to avoid fragmentation, why proprietary platforms are risky, and what good documentation tells you about a project.

Communication tools shape how open source communities work together, but most projects never stop to ask what they actually need. In this episode, Alya Abbott, COO at Zulip, joins the We Love Open Source podcast to share why choosing the right communication tool requires a structured approach, how proprietary platforms exploit open source data, and why good documentation is the clearest signal that a project welcomes contributors.

Open source communities face a unique challenge. People are scattered across time zones, backgrounds, and availability. They’re not employees with set hours. They volunteer with variable commitments. This makes communication not just important, but critical. Yet most projects approach tool selection like picking a nanny based on a gut feeling instead of requirements. Companies do structured procurement. They make checklists of must-haves and nice-to-haves. Open source projects skip that step. They think, “I know about Discord,” and jump in. Then regret follows.

Communications fragments across Discord for real-time chat, a Discourse forum for searchable discussions, email lists for old-school contributors, GitHub for code review. Nobody wants to manage disparate tools. Instead, think coherently. Zulip uses their own chat for discussions and GitHub for code, then cross-links them. Each tool has a purpose. No jumping between platforms wondering where the conversation lives.

The bigger problem is that most communication tools used in open source aren’t open source themselves. Slack and Discord are owned by corporations with fundamentally different values. They don’t give you tools to own your data or communication history. Slack limits API access to messages. Discord has no built-in export tool. If you want to leave, your data stays locked in their platform. And with AI becoming valuable, they’re increasingly viewing your community data as an asset to monetize. Zulip offers an alternative. Open source, community-owned, where your data is yours.

Finding your first open source project to contribute to matters more than picking a random repository. Look for genuine interest. If you love astronomy, find an astronomy research project. If you’re into board games, find a game design project. Genuine passion keeps you motivated through feedback cycles and setbacks. But also look for projects with really good contributor documentation. That’s a signal the maintainers invested time teaching, not gatekeeping. Good documentation means maintainers won’t need to handhold you one-on-one. It also means they genuinely want contributors joining in. That combination, genuine interest plus good docs, is your starting point.

Key takeaways

• Choose communication tools strategically: List your requirements, nice-to-haves, and interconnect tools with clear purposes. Avoid fragmentation by thinking coherently about how you’ll collaborate.
• Proprietary platforms extract open source value: Slack, Discord, and similar tools lock your data while viewing community content as AI assets. Open source alternatives like Zulip let communities own their data.
• Find projects through genuine interest and good documentation: Pick something you love, then look for projects with clear contributor docs. That combination signals a welcoming community and sustainable learning.

In the full episode, Alya also dives into her GitHub workflow hack that keeps her on top of every PR and issue, and shares how to recognize projects that genuinely want you contributing alongside them.

More from We Love Open Source

• We Love Open Source podcast
• What to do when your AI starts going in circles
• AI accelerates architecture, but you have to babysit
• Why grabbing a model and playing won’t get you what you want
• From coding to orchestration, why critical thinking matters in the AI age