When the Kotlin project began 10 years ago, we never imagined it would grow into what it is now. While Kotlin began with internal ambitions, it was a vibrant, thriving community that took the project to the next level. JetBrains, which dog foods all of its own products, wanted a programming language to use when developing its own product. But it was the community that noticed it, started using for their work and eventually made it what it is now – over 4 million users, as was stated during the Opening Keynote at KotlinConf 2019, including high profile companies like Atlassian, VMWare, Coursera, and AutoDesk. That’s just one brilliant example of how communities can contribute to and influence a whole company’s path.
The success of various software products, from WordPress to Salesforce, depends on the community built around them: the people who use it for their work, provide services and develop additional tools around it. After joining the team in 2010, the same year the Kotlin project began, and being the first developer advocate, I’ve had a front-row seat to JetBrains’ extensive, engaged developer community. From day one, building and supporting a strong community has been core to our mission, and my role in particular.
RELATED CONTENT:
The rise of Kotlin
A new approach to your open source supply chain
Four simple steps can put you well on your way to creating and maintaining such a community.
- To start, engaging directly with users must be part of your company’s DNA. In the beginning, JetBrains had used something along the lines of a bulletin board system where the three founders would publish their builds and get direct feedback from users. Since then, we’ve widened the number of channels through which we can solicit feedback. We hear directly from users and the community through one-on-one conversations at events, through chat tools, through Early Access Programs, through developer advocacy, and through open-issue trackers, which lets developers get feedback through a ticketing system. It’s not a single line of feedback, but myriad channels that can be aggregated and acted upon.
- The work with the community should become something you do because you want to, not because you have to. The first thing that comes to mind when you realize the power of the community is to invest heavily in the engagement. But successful engagement and the efficiency of developer advocacy, in general, can be a difficult thing to measure, meaning that the goal of working with the community should not be determined by any indicators. At JetBrains we, developer advocates, have a simple goal of sharing knowledge and to give feedback to product teams – be a bridge with the community if you will. We enjoy learning and enjoy sharing what we’ve learned.
- Focus on the needs of the community, not just on your products. Obviously, all community engagement should work to zoom out beyond a specific product. Successful engagement is about making developers better as opposed to teaching only your own products. This is especially true since earlier developers used to be focused largely on a single technology but have now moved more towards polyglot scenarios where they’re touching many tools and many things. We always aim to mirror this range, while making sure we stay equally committed to using our own products and coding. We strive to improve the ecosystem and the environment so more professionals are out there to experience JetBrains products in the long-term.
- Always stay on the same wave with the community you create and support. On the Advocacy team we share a common rule that at least 30-35% of your time as a developer advocate should be dedicated to writing code. The type of work depends largely on the person; there are people contributing to open source projects that aren’t part of JetBrains, others work on internal projects. One of the biggest challenges of this role is to make sure that you are always using the things you are promoting and teaching others yourself.
Just about all successful software is backed by a dedicated community, especially in the world of open-source. But these communities don’t just happen. They must be invested in and tended to with multiple feedback channels and a commitment to broad engagement.