Positioning for Community Building

I recently wrote a piece for The New Stack about community building, and the only thing missing from the article was an explicit discussion of positioning and why it matters for community building.

In the context of building communities around an open source project, there are in fact two things to position, and they are both important.

  • The open source project itself

  • The community

As Jono Bacon discusses in the article, the community has to have a value proposition that is unique to the community itself, not merely the same value you’d get from using the product or open source project. I’m assuming, of course, that when we say ‘community’ in an open source context we’re talking not just about people who download the project and use it, but people who are active in Slack and/or Discord groups, who go to meetups, who write blog posts about the project and perhaps contribute back to it .

The same goes if we’re talking about a purely commercial product that you’d like to build a community around — if you want to build a community, you have to have a reason for the community to exist and a benefit that people will get from the community that goes above and beyond what they get from the product.

The examples that came up as I was working on the article included FitBit and Harley Davidson. In both cases, the community is about helping people solve a much larger pain point than the product itself can address. The product you’re selling (or the open source project you’re promoting) becomes a piece in a larger puzzle. FitBit might help people in get shape, but purchasing a FitBit does not make you able to run a marathon as soon as the charge goes through on your credit card.

This is just as true about developer tools. In nearly all cases, they are going to be a piece in the puzzle for users. I’ve yet to come across a project that solves everything, from development to operations to security to underlying infrastructure. The ultimate goal is always larger, around delivering applications that delight end users — or perhaps delivering infrastructure that delights the internal development team.

As you’re building a community around your project, focus on the overarching goal that you help users achieve. Position your community as a way to reach that goal — and choose a goal that is not so high level to be disconnected from your project, but at least one level up in abstraction from the specific goal your project has. Don’t lose sight of the fact that a community’s value always includes that it makes members less alone.

Don’t just assume that people will want to join your community because your project is technically awesome. Focus on making the community a way to provide even more value to users, value that a project download can’t possibly provide.

Emily Omier