In his book "The Second Mountain," David Brooks talks about the journey from a life focused on personal success to one dedicated to community and service - our deepest fulfillment comes not from individual achievement, but from connection and commitment to others. It struck me that this concept also resonates deeply with the growth and adoption we're seeing — and need to continue cultivating — in the open source world.
The Two Mountains of Open Source
For many of us, we've defined open source as the first mountain. The first mountain is focused on personal achievement, recognition, and career advancement. It's about building a impressive GitHub profile, gaining stars on your repositories, or using open source contributions to land your dream job.
But there's a second mountain to climb — one that's about commitment to the community and shared progress. It's where the real magic of open source happens, and it's where we need to set our sights.
Connection in open source goes beyond collaboration. It's about creating a shared sense of purpose, building trust, and supporting a community where contributors are recognized for positive contributions. It's about having context and understanding the people behind the code.
In fact, in Evidence for a Collective Intelligence Factor in the Performance of Human Groups, the researchers concluded that connection creates a collective intelligence, where the groups's combined knowledge and problem-solving capabilities exceed individual efforts.
Extending this to tech, when developers connect, they don't just share code — they share ideas, challenges, and visions. This exchange sparks creativity and leads to breakthrough solutions that likely wouldn't happen in isolation. A connected community is more likely to engage in meaningful discussions about the implications of their work, and identify areas for improvement or growth. They're also more likely to resolve issues, know where to ask questions, and to be more productive.
Open source has the power to affect lives globally. But sometimes it can be hard to find that connection, to know the people behind the pull requests.
Despite the clear benefits of connection, the distributed nature of open source development can make it challenging to build these relationships. Contributors often work across different time zones, cultures, and backgrounds, rarely meeting face-to-face. The anonymity of usernames and the focus on code can sometimes obscure the human element that's needed to build collective intelligence.
Contributors as Connectors
This is where intentional effort from contributors becomes necessary. It's not enough to simply submit pull requests or report issues. To truly harness the power of collective intelligence and create impactful open source projects, contributors need to actively invest in understanding and connecting with the community they're part of.
This could involve:
- Taking time to read and understand the project's history, goals, and culture
- Actively participating in community discussions beyond just code-related topics
- Reaching out to other contributors to learn about their experiences and perspectives
- Offering help and support to new contributors, sharing knowledge gained from their own journey
- Initiating or participating in community events and collaborative problem-solving sessions
Through these efforts, contributors can help create an environment where everyone feels valued not just for their code, but for their unique perspectives and experiences. This approach also helps address some of the long-standing challenges in open source, such as contributor retention. When people take the initiative to connect and create a sense of belonging, they're more likely to stick around. They're also more likely to invite others in.
A contributor-driven approach to connection can lead to more sustainable and resilient open source communities. Rather than relying solely on maintainers to facilitate connections, it distributes the responsibility across the entire community, creating a stronger, interconnected open source ecosystem.
Essentially, by taking the initiative to connect and understand, contributors aren't just improving code — they're actively shaping and strengthening the foundation of what makes open source projects. This shift from passive participation to active community building is can unlock more of the potential of open source collaboration.
The "See a Need, Fill a Need" Approach
But how does a contributor get started? One way contributors can engage more deeply is by adopting a "see a need, fill a need" mindset. This approach encourages proactive problem-solving and creates a culture of initiative and responsibility.
Consider how React's reconciliation algorithm came about — developers saw a need for more efficient DOM updates and filled it, significantly improving the library's performance. Or how Webpack was created to solve module bundling issues that many developers were facing.
But contributing effectively goes beyond just solving technical problems. It's about understanding the project's philosophy and aligning with its vision. Evan You, the creator of Vue.js and Vite, emphasizes this point in a recent Secret Sauce Episode:
So for example, we have a current core team member on Vue's side where he's super young, but the pull requests that he makes, the quality of the code, the way he organizes stuff, and the way he makes the certain decisions makes me feel like, okay, this is probably how I would do it if I were to do it myself. And that kind of just naturally builds trust. And if he keeps doing, you know, if the person repeats this pattern a few times, then the trust just kind of compounds. I'm like, okay, this guy knows what he's doing and I can trust him to make the right decisions, even if I'm not directly paying attention to it. And that's important, right? And I think it's, if you're a maintainer, you will, like different maintainers have different style of working on their projects, right? Like we would have different code preferences. We have different design philosophies on how the project should work. So usually a good contributor understands your preference, your philosophy very instinctively, intuitively. I think that alignment is very key, right? Some people can be really technically brilliant, but maybe they just disagree on almost everything with you. And they wouldn't become good contributors or team members, right? So it's like technical skill is not really the only factor here.
This approach shifts the focus from "What can I get out of this?" to "What can I contribute that the community needs?" This deeper level of engagement goes beyond technical proficiency, and creates a sense of alignment and trust within the community. When contributors invest time in understanding a project's ethos, they're not just writing code — they're becoming integral parts of the project's ecosystem. This approach leads to more meaningful contributions, smoother collaborations, and a stronger, more cohesive open source community. It exemplifies the "see a need, fill a need" philosophy in a broader sense, where the "need" isn't just a technical problem, but also includes the need for contributors who truly understand and align with the project's vision and values.
Building Trust Capital: The Currency of Open Source
While the "see a need, fill a need" approach is a great starting point, sustained and impactful contribution to open source projects requires more. It requires building what we call "trust capital" — a asset that's accumulated over time through consistent, quality interactions, and a deep understanding of the project's context.
Trust capital in open source communities is the confidence and credibility you earn through your contributions and interactions. It's not just about the code you write or the issues you solve; it's about how you engage with the community, respect its processes, and align with its goals. As Evan You pointed out, when a contributor consistently makes decisions that align with the project's philosophy, trust naturally builds and compounds over time. In a previous post, The Compound Interest of Open Source, we explored how contributions can have a compounding effect, leading to increased trust and recognition within the community.
But how do you build this trust capital? It starts with understanding the project's context:
- Project History: Dive into past issues and pull requests to understand the project's evolution. (We're currently building a tool to connect you more granularly to the codeowners of a project to help you understand the project's history, so keep your eyes on our pizza-cli.)
- Current Direction: Familiarize yourself with the project's roadmap and immediate goals.
- Community Dynamics: Observe how decisions are made and who the key contributors are.
- Maintainer Preferences: Understand the maintainers' coding style, design philosophy, and communication preferences.
As you work to understand a project's context and build trust capital:
- Listen Actively: Pay attention to discussions, even on issues you're not directly involved in.
- Ask Thoughtful Questions: Show your engagement and desire to understand.
- Start Small: Begin with minor contributions as you build your understanding.
- Respect Processes: Follow the project's contribution guidelines meticulously.
Every interaction is an opportunity to both learn and demonstrate your commitment to the project. This approach aligns perfectly with the "see a need, fill a need" philosophy we discussed earlier. You're not just filling technical needs, but also the need for contributors who truly understand and align with the project's vision and values.
Ascending the Second Mountain: The Summit of Open Source
The first mountain of open source might be about personal achievement: the thrill of seeing your code merged, the pride in solving a complex problem, or the boost to your resume. But the second mountain? That's where the true magic of open source happens.
This second mountain is about connection — not just to code, but to people, to purpose, and to a larger understanding of the projects, maintainers, and contributors. It's about understanding that every line of code is part of a larger story, a narrative written by a experts in different areas, with knowledge bases that shouldn't be siloed.
Remember Evan You's anecdote about the young Vue contributor? That contributor didn't just write good code — they demonstrated an intuitive understanding of the project's philosophy and the maintainers' preferences. They proved themselves to those who had already proven themselves.
This approach is far more effective than trying to brute-force your way into a community. It's not about making the loudest noise or the biggest splash. It's about thoughtful, respectful integration into an existing ecosystem.
Top comments (0)