If you’ve been inspired to build a Web3 startup, you’re probably already well aware of the vital role played by communities of developers in protocol success. Indeed, many high-profile founders started their own projects after years of occupying hands-on development roles in early crypto communities such as those of Bitcoin and Ethereum. Even today, developer communities still form the backbone of most projects could not have evolved without a healthy developer ecosystem. That’s why it’s crucial for Web3 founders to build an engaged developer community. Even if you don’t think your project needs an ecosystem of developers specifically, many of the same tactics used to build developer communities can be deployed to build other types of communities too.

Here’s an overview of what we’ll be covering:

• What a developer community consists of.
• Why Web3 startups need developer communities.
• How to grow a developer community in the inception phase.

What Is a Developer Community?

Generally speaking, a developer community is a group of developers who engage with one another based on their enthusiasm for a particular project or technical ecosystem and want to see it thrive. This engagement goes beyond answering technical queries on a platform like Stack Overflow or submitting pull requests on Github. These communities usually come together because they share the vision of the project’s founders and want to see the project adopted as a standard solution within the wider developer community.

In Web3, a canonical example is the Ethereum developer community. This community evolved around a shared vision of a platform that would allow developers to build truly decentralized “trustless” applications. This in turn spawned the adoption of the Ethereum Virtual Machine (EVM) as a single shared standard across a flourishing ecosystem of dApps. Developers contributed to this new standard because it provided key infrastructure for their own projects. 

However, developer communities are not homogeneous. They can be divided into different layers based on motivation and level of engagement. This is best encapsulated by the Orbit model—an open-source framework for tracking the growth of a developer community.

According to the model’s creator, Josh Dzielak, developers fall into four different levels of orbit. These can be summarized as follows:

• Orbit 4—“Observers” who are mainly there to explore and look around.
• Orbit 3—“Users” who have had some kind of initial interaction with a project but are still trying to figure out how to use it successfully.
• Orbit 2  —“Fans” who have been enabled by a project’s technology, are enthusiastic about it, and contribute to its development.
• Orbit 1—“Ambassadors” who have successfully built something on top of a project and have become a leading voice in a community.

Within each of these orbits are different types of developers with different motivations and spheres of influence. One type could be an explorer looking to learn more about an interesting new technology but unsure what to do with it. Another type could be an experienced developer looking for the right technology to solve a specific problem. Thus, open-source developer communities are usually made up of people with diverse motivations and professional backgrounds.

Why Build a Developer Community?

While the vision for your project might not be as ambitious as Ethereum, you can still benefit from building a developer community. Indeed, it isn’t just layer-1 blockchains that need a developer community—many players in the Web3 ecosystem rely on developer communities to scale their projects. This includes centralized platforms such as exchanges, marketplaces, and infrastructure providers; decentralized organizations such as layer-2 scaling solutions; and DeFi applications and protocols. The success of DeFi projects in particular is partly contingent on their ability to grow developer activity, which leads to more dApp and wallet integrations. But aside from integrations, there are many more reasons for investing in developer community building.

For example, a healthy developer community can also help to:

• Provide early feedback on the utility of a project.
• Uncover overlooked security and performance issues.
• Build awareness in adjacent communities and bring in new members.
• Participate in the governance of decentralized projects.
• Stimulate direct and indirect network effects.

Yet despite the clear benefits of having an engaged developer community, there is no definitive playbook for growing one. Such a playbook would be challenging to write because each community is shaped by a distinct vision and mission. Community-building tactics tend to differ according to the unique traits of the founding team and the nature of the product. 

How To Build A Developer Community 

Although a playbook may not yet exist, there are some common tactics that Web3 projects have used to grow thriving developer communities.

These tactics include:

1. Iterating gradually and adapting to the community’s scale.
2. Documenting the vision and purpose of the community.
3. Designing the community experience.
4. Creating a communication and content strategy.
5. Engaging early members and fostering one-to-one interactions.

Iterating Gradually and Adapting To the Community’s Scale

In some ways, building a community is a lot like lean software development. According to the lean approach, startup teams build software in a gradual, iterative process, starting with a minimal feature set. The software is then tested, deployed, and its success is measured before developers commit to building the next set of features.

This approach ensures that startups only allocate resources to the most essential community-building efforts. Founding teams start with a few basic tactics and only move on to more advanced tactics once their initial efforts have been shown to work and they have enough resources to try new initiatives.

This approach is also supported by more traditional literature on online community building. For example, the 2009 research paper “A Life-Cycle Perspective on Online Community Success” found that community-building strategies change “depending on which life-cycle stage the online community is experiencing”. 

Community building consultants have taken this research and synthesized it into an “Online Community Lifecycle,” which typically consists of four main stages. 

This concept is highly generalized to any online community—it is worthwhile to compare it to the Orbit model which is specifically oriented toward developer communities.

The goal for early-stage startups is to get inception and growth right first. It is crucial that founders match their tactics to the size of their company because mistimed strategies can be a repelling force, pushing developers away.

For example, hackathons are a common case of the right tactic applied at the wrong stage. Hackathons are often discussed as must-haves to drive Web3 developer adoption and this is true, but many founders don’t realize that hackathons only work at a certain scale and are incredibly resource intensive. They are sometimes attempted before the project has been properly documented or tested by a tight-knit circle of early supporters. Many hackathons also suffer from low participation. This is why some developer relations experts believe that teams should only consider hackathons when they’re confident that they can attract at least several hundred participants. 

Defining the Purpose of Your Developer Community

If you’ve decided to start a Web3 project, you’ve hopefully already written a whitepaper and defined your project’s wider mission and vision. You need this content to show investors and educate early backers.

To build a developer community, you need to consider how your mission aligns with the goals of your potential community members.

Ask yourself questions like:

• Why should a developer believe in your project?
  In a sense, you are “pitching” developers, but the pitch needs to be different from your pitch to investors.
• What value do you hope to get out of a developer community?
  Do you want them to build integrations? Contribute to the core protocol? Use your technology to build something else and evangelize your product?
• What value will you provide to your developer community?
  Do you expect developers to gain value principally because your technology unlocks previously unattainable use cases or are there other value-adds that your community can provide? These value-adds could include education and advocacy, or material incentives such as rewards, merchandise, and grants.
• What kind of developer would be attracted to your project and why?
  Do you only want to attract developers who are already in a vertical such as DeFi or GameFi or will you welcome outsiders too? Are you targeting Web3 natives or are you open to developers crossing over from Web2?
• What value should developers get from engaging with each other?
  Do you expect more experienced members to help new joiners overcome technical challenges or collaborate on shared projects or are they likely to have disparate interests?
• How should the community shape the evolution of your project?
  Do you need a process for capturing insights from your community and ensuring that they are shared with members of your team? How much about your project do you want to disclose to your community? Do you want to be completely transparent on your roadmap or are there initiatives that should stay within the founding team?
• What should be the culture and ethos of your community?
  What makes your community distinct from other developer communities? What are the core values that set you apart?

Many of these questions are tough to answer, but a good source of inspiration is Gitlab’s Community Learning pathway. This resource is intended to get internal Gitlab team members up to speed on its various community programs. Gitlab is a rare example of a developer-focused enterprise company that publishes its internal documentation for anyone to see. Of course, Gitlab is a mature Web2 SaaS solution with a multi-billion dollar market cap and such comprehensive programs are only possible at a much larger scale. Nevertheless, the company’s documentation provides a good example of how to structure internal messaging and formulate community goals.

Designing the First Iteration of Your Community Experience

To build community, you need to create some form of online discussion forum. Discord has emerged as the default choice for Web3 community building especially. Unlike other platforms such as Telegram, Discord makes it easy to share and discuss code, a feature that developers will need once they start building. After choosing a platform, you should invest time in how you want channels to be structured and how you want people to be onboarded.

Structure Your Community Experience With Your First Ten Members in Mind

Many spaces start off with too many channels, which can overwhelm newcomers. Instead, structure your categories around the typical conversations that take place in an emerging community. 

Such conversations between developers include:

• Making personal introductions.
• Asking questions about the project.
• Explaining what they’re working on and what their challenges are.
• Showcasing what they’ve built so far.
• Sharing opinions and content regarding the wider technical ecosystem.
• Sharing memes, gossip, or other interests outside of the core community focus.

The precise tone and content of these discussions will be shaped by a project’s overarching purpose and culture, which is why it’s important to think about this aspect first.

Mitigate for Unwanted Discussions

One type of discussion to avoid in a developer community is speculation about asset prices and the direction of the market. There a few potential concerns here, one being that such discussions can be highly distracting and spiral out of control. If such discussions emerge, participants should be directed to more appropriate channels such as community-run Telegram groups. 

Open up the Community Gradually

In the early stages, the quality of a developer community is especially important. The focus should be on recruiting and nurturing members who are more likely to actively participate. To this end, founders can choose gating methods such as:

• Invite-only participation
  Many developer communities often start as invite-only because they are part of a limited beta program to road test an early product release.
• Pre-vetting new joiners
  Other projects ask people to apply to join the community and will vet members based on the answers they provide on an application form.

These tactics might deter casual newcomers, but they can also heighten a sense of exclusivity. They also help to ensure that your first 10 members are truly interested in your project.

Moving to Self Sign-Up

The next stage is to take the community public and allow anyone to register. When moving to this stage, many organizations still include multiple checks and balances in the sign-up process, such as collecting basic information about the user, and ensuring that they agree to the community guidelines. Just note that Web3 communities place a special emphasis on anonymity. If you are going to collect information, it should center around the developers’ interests rather than their identities and should conform to your privacy policy. 

Assigning Community Ownership

Lastly, you need to decide who in your organization is going to “own” the community. In more mature startups, this task is handled by a community manager or a developer relations all-rounder, but in the very early stages, it often falls to a member of the founding team. While everyone in your team may initially contribute to your community, it should ultimately be one person’s responsibility. This means being accountable for the success or failure of the community and tracking its progress.

Finding and Nurturing Your First 10 Members 

When discussing how to build a Web3 product people want, we talked about the wider concept of “MVC” or “minimum-viable community” and how to build one. 

The core advice for founders was to: 

• Leverage existing networks—Technical founders have often been involved in multiple projects and have access to a wider network of developers. They can leverage these connections to identify community-minded developers who are aligned with their project’s mission.
• Join existing Web3 developer communities—Communities are often powered by reciprocity and mutual opportunities. Technical founders can build reputation and attract community members by adding value to the community and to the development of a related project.

The hard truth is that these approaches take time. This fact can be hard to accept when other kinds of Web3 community seem to explode overnight, often ignited by a celebrity tweet or a sudden movement in the market. But patience is essential when finding your first 10 members as their contributions will steer the direction of your developer community and pull new members toward your center of gravity. 

Creating a Communication and Content Strategy

Content is the bedrock of any community-building initiative because it helps to drive awareness of a project and educate developers on its core vision and roadmap. 

Community Builders and Marketers Have Different Goals

In traditional content marketing, content is regarded as a “top of funnel” activity that drives consumers down the funnel to become “leads” which eventually “convert” into paying customers. While technical content can be leveraged by marketers and community builders alike, it serves a different purpose in a community-building strategy.

Use Content To Drive Community Engagement

In the context of the Orbit model and Web3, there is no concept of a “lead,” rather there are “activities” that indicate that developers are being pulled closer to the center of gravity.

Content is what pulls developers into the outermost ring of a project’s orbit and holds them there. Examples of early technical content include high-level documentation, getting started guides, tutorials, and use case inspiration. 

Create a Content Plan

Early-stage startups have limited capacity to create content so content creation should be planned carefully. Many teams start with a simple plan that covers the next three months and later expand the plan as the content strategy matures. The publishing cadence reflects what is realistically possible given current resources. 

This could be one content piece every month, one every two weeks, or one every week—there is no one-size-fits-all approach when it comes to publishing frequency. The main goal is to have a predictable schedule and theme so that developers know what’s coming up next. This effort should be supported by a social media calendar to structure content promotion.

For an example of an integrated technical content marketing strategy, see Gitlab’s marketing calendar.

Again, Gitlab’s marketing calendar is far more complex than that of an early-stage startup and it’s designed to align marketing initiatives rather than drive community building.  Nevertheless, it’s helpful to have a template for how to structure a content plan. 

Nurturing Engagement and Fostering One-to-One Connections

Even in small, exclusive communities, it’s not a given that engagement will materialize on its own. In the early stages, the flames of discussion need to be sparked and fanned. 

Seeding and Sparking Discussions

In the Web2 world, many tactics have evolved to address this challenge. In his book, Community Masters, founder Varum Maya proposes a “fake it till you make it” approach where founders reach out to their power users directly and ask them to post articles and resources. He admits that he often had to “draft their posts for them to make their lives easier”.

This approach is extremely risky when applied to a developer audience because they can easily spot inauthenticity and ulterior motives. But you could ask developers to repeat questions or discussions that you’ve had privately in one-to-one conversations in a public forum.

Another approach is to spark discussion around your content. After you publish a new content piece you can then post it in the community. Discussion can be further stimulated by including an excerpt from the content piece and asking opened-ended questions about the topic. For example, if a content piece is about best practices, you can ask questions like “Are you are doing this already?” or “Do you have anything else to add that I haven’t thought of?” Even for basic technical content such as tutorials, you can ask questions like “Was this easy to follow?” or “How could this be improved?”

Initiate One-on-One Conversations

One benefit of the inception phase is that you can engage community members directly. You can offer to hop on a call with them and talk through their challenges and what they are trying to achieve. This will also enable you to build sustainable relationships and identify early developer community advocates. 

Web3 founder Max Goodman provides a good example of the in-person approach. His Gyde project aims to onboard those traditionally excluded from Web3. In an interview on the NEAR Protocol Official Blog, he advocates for “building community in-person first” and onboards members with one-on-one educational meetings. This approach also helps him to quickly build strong connections with his community members.  

Approach Developers Carefully

The one-on-one approach won’t always work on developers. Many developers prefer self-service approaches and often eschew online meetings. That’s not to say that developers will shun all attempts to engage them personally. Some developers might even appreciate the attention—provided that founders can speak their language and demonstrate a genuine interest in empowering them to meet their goals. They will also relax when it becomes clear that founders don’t expect anything specific in return and don’t require any “next steps” after the meeting.

Growing Your Community With Developer Incentives

Most Web3 projects use incentives to help grow their communities. These might take the form of competitions or prizes in return for undertaking specific activities on social media, for example. But while these tactics might inflate vanity metrics such as follower count and likes, they do not generally lead to sustained community growth.

Similarly, rewards and financial incentives for Web3 developers can easily be gamed and must be approached with caution. Additionally, developer incentive programs tend to be more labor-intensive because they involve technical tasks.

Startups need to reserve enough resources to write task specifications and judge whether the task has been performed correctly. Luckily, some of this work can be outsourced.

Common incentives for spurring developer community growth include:

• Bug Bounties
  Bug bounty programs incentivize developers to find security vulnerabilities in a project. These programs can often be outsourced to third-party providers such as such as hackenproof and immunefi.
  
• Competitions
  Web3 projects can also run competitions and offer prizes for developers who find elegant solutions to a particular problem. This tactic is very popular in the data science community, where platforms like Kaggle (Web2) and Numerai (Web3) offer rewards for solving specific data science challenges.
  
• Developer Grants
  Once early-stage startups have acquired some form of seed funding, they can afford to offer larger incentives such as developer grants. Grants can help to spur activity in a startup’s developer community because successful applicants will inevitably turn to existing community members for guidance.
• Governance
  Lastly, the most powerful incentive is governance—one of Web3’s biggest differentiators. As a Web3 project evolves, it often begins to decentralize and management is eventually handed over to the wider community in the form of a DAO. As they become more engaged, early contributors have the opportunity to take a leading role in steering the direction of the project. That’s why it’s important for founders to involve their developer communities in certain strategy and technical decisions even while they are still centralized.

Developer Communities Take Time to Build but Bring High Rewards

Growing a developer community is one of the hardest challenges that founders face. This is because there are so many factors that are out of their control. The challenge is similar to that of entering a new market—it’s unknown territory and there are many hidden risks. But success is more likely when founders invest in researching and documenting their community strategy. This preparation will enable them to plan ahead and carefully craft a rewarding experience for their early members. Once these communities gain momentum, much of the moderation and administration work can be left to the community’s inner circle. Founders who have been active community members understand this process intuitively. Sometimes, the first logical step in building a successful developer community is to participate in one yourself.