Made by
Made by
Spectrum
Developer relations and community management share many similarities. Depending on your experience of them, it can seem like they’re two sides of the same coin.
It’s easy to see why. They share common ancestors, they’re often practised together, and there is crossover in terms of tactics.
Take a step back, though, and it becomes clear that they are related yet distinct disciplines. As we’ll see, they evolved separately to solve different problems and we can find examples of one being practised without the other.
Think of the electromagnetic spectrum. Some of it is visible light. Other parts give us FM radio waves, x-rays, and more.
We mark out parts of the spectrum as bands because that helps us to understand their characteristics. Bands are a human convenience, though. For example, infrared radiation changes gradually from behaving like microwaves in far-infrared to being more like visible light in near-infrared.
It’s the same with developer experience, developer relations, and community management. There’s a continuum of the things we do to serve developers, yet it makes sense for us to think of them as distinct practices: developer experience, developer relations, community management. But we all know that the lines are blurred.
Developer experience, developer relations, community management continuum
Looking at it this way shows that it doesn’t make sense to think of a hierarchical relationship between, say, dev rel and community. That’s not to say that organisations don’t put such a relationship in place. When they do, though, it’s an implementation choice, rather than a natural state.
However, there is a hierarchical relationship, of sorts, that can help us to understand the interplay between developer relations and community management.
Neither dev rel nor community management arrived fully formed. Both are evolutions of what came before.
Developer relations draws heavily on how open source projects built awareness and attracted contributors, while mixing in elements of the closed developer programmes of the 80s and 90s. Developer experience is an evolution of tech writing, UX, and more. Community draws on open source, PR, various forms of marketing, and customer service.
Many other practices, disciplines, and areas of interest also contributed to what we call DX, dev rel, and community today. The main antecedents, though, give us a family tree that helps again to see that developer relations and community management are related yet separate.
Devrel family tree
Both developer relations and developer community management owe a great deal to the open source software movement. The OSI’s Simon Phipps even describes dev rel as “the secular expression of open source community“.
However, they’ve both taken different directions from the same root. If we look back to the late 1990s and early 2000s, it was rare for companies to involve themselves in open source. Open source communities persisted mostly without overarching corporate sponsors, foundations, or professional organisers.
They borrowed methods from academia, special interest groups, and clubs. Those communities also developed their own ways to manage the development of complex software, as well as attracting users and contributors.
Sun, Red Hat, Canonical, and others took those blueprints and began to turn them into developer community management.
Canonical, in particular, went beyond the idea of developer-only communities and encouraged non-developer contributors to the Ubuntu community. And one way that contributors could, and still can, take part in the Ubuntu community was by promoting Ubuntu to other people.
Arguably, Ubuntu’s broader community focus is one of the many inflection points where community management and developer relations began to take separate paths.
So, much of what we do as dev rel and community professionals was pioneered by open source communities. Then, open source sponsor companies took those community techniques and tweaked both the incentives and motivations to benefit not just the community but also the company. That led to where we are today.
Perhaps the starkest contrast between dev rel and community management is in their end goals.
Developer relations is about building sustainable ongoing awareness, adoption, and community around developer-targeted products. Community management is one of the techniques that dev rel relies on.
Community management is about creating and maintaining a process that enables people to come together for a common goal. It can apply to dev rel but is applicable in many other contexts.
Community management is, seemingly, everywhere. Sure, some of what is called community management is actually customer service delivered through social media and forum software.
Nonetheless, genuine communities are built and thrive in places where not a line of code is written. Charities, workplaces, educational institutions, and more are home to communities that use techniques we might think of as belonging in developer communities.
Similarly, developer relations frequently –– and, perhaps, regrettably –– often happens without any attempt at building or managing community.
Take the example of the banks releasing open banking APIs. They have developer portals, many are starting to go out and talk at events, some publish content. Few, if any, are building genuine communities around their offerings. Perhaps within time some will have thriving communities but many will meet their goals without doing so.
None of this is to say that either community management or developer relations is superior to the other. Indeed, recognising them as separate yet related is essential to giving them the room they both need to develop and in helping us as practitioners to know when to apply which techniques.
However, it is clear that developer relations and community management are not the same thing.
Photo by Thor Alvis on Unsplash