An effective developer relations strategy depends on understanding the motivations, structure, and rewards of the developer community that is touched by your programme. The trouble is, developer communities come in all shapes and sizes.
Thankfully, most developer communities fall into a few broad types. Once you recognise the type that applies to your developer community then it becomes easier to understand the roles that your programme and the community play for each other.
So, what are those types?
The original developer communities, Barn Raisers exist to build something. Such communities tend to:
The name “barn raisers” comes from the idea of a community of people coming together to build a barn that would be impossible to build otherwise. While not everyone has the same motivation for taking part, the ultimate goal of raising the barn (or delivering the software) guides the community.
Examples of barn raising communities include Debian, Apache Kafka, and the Ruby programming language.
Some Guilds can appear a lot like Barn Raisers. However, in a Barn Raiser community the motivations of members come second to the overall mission. Guild-type communities exist to further the interests of its members in relation to the software.
Guilds often have the following characteristics:
The name “guild” comes from those medieval guilds that were seen as the source of learning and legitimacy for particular trades.
Examples of guild-type communities include React and the OutSystems developer community.
Academies are those developer communities that exist primarily for the exchange of knowledge. Usually, they:
Examples of academies include Stack Overflow and the many large crypto chat groups.
Ambassadorial communities exist to help a vendor bring their product to market. In most cases, that’s not exploitative as there are benefits on both sides. Community members stand to gain professional standing, skills, and an expanded network. Academy-type communities tend to:
Ambassadorial communities are common. Look at pretty much any community that is organised around an API product, for an example.
True communities offer an authentic experience where all members have the opportunity to contribute and feel that they benefit from their participation. There is a fifth type, though, that shouldn’t be called a community but often is.
That fifth type is “Your Cousin’s Wedding”.
Think about it. The parallels are remarkable:
If you haven’t yet been to a developer meet-up like that, then you know someone who has. There are programmes that call themselves developers communities but are inauthentic and miss the entire point of what a community is meant to be.
If you’re worried that your community might fit into this type, then ask yourself two questions:
If the answer is no, then you need to find a way to turn your promotional campaign into a community. If the answer is yes and you’re still worried then it might be time to audit your developer relations programme to find room for improvement.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?