Approaching Developer Relations in an Open Source Foundation
About 7 months ago, I was employed as a Developer Advocate by the Cloud Foundry Foundation alongside Ram Iyengar to build and scale a DevRel program.
The Cloud Foundry Foundation is an organization focused on supporting the Cloud Foundry open source community. The foundation basically exists to drive global awareness and adoption of the Cloud Foundry open-source project, to grow a vibrant community of contributors, and to create coherence in strategy and action across all member companies for the sake of the project.
I am pretty new to working with an open-source foundation because it’s an entirely different ball game as compared to working for a profit-based organization/business.
Over the past 7 months, we’ve built a new DevRel program from scratch, and in this article, I’ll share some tips, ideas, and frameworks we’ve built to help us with our work and some lessons we’ve learned along the way.
There’s still so much to learn and do but the aim of this article is to share what we’ve learned along the way, and maybe, just maybe it may be beneficial to a team out there.
Before working for the Cloud Foundry Foundation, we didn’t have experience working with Cloud Foundry so we had to learn the technology first before anything. I mean we can’t educate people on something we know nothing about.
We went on a call with Chip Childers who has been actively involved with the Cloud Foundry community for about 5 years. The purpose of this call was to set a time frame of one month to learn the basics of Cloud Foundry so that we would be able to create content for individual developers.
One of the reasons the Cloud Foundry Foundation started a full-blown Developer Relations program is to attract individual developers and change the narrative that Cloud Foundry is meant for just “enterprise teams and usage”. So our target audience is individual developers that need to deploy their applications or side projects fast and also very small teams that want to deploy their product on the cloud.
As developer advocates, we need to do the following:
- Create clear, accessible, and easy-to-understand educational content on Cloud Foundry for anybody to use (videos, blog posts, demos, infographics, etc.).
- Answer important questions from the community or from people that want to start using Cloud Foundry
- Come up with initiatives to create awareness on the benefits of Cloud Foundry and its existence (live streams, social media campaigns, labs, and events, etc.).
- Collect feedback from the community and relay the feedback to the appropriate channels (community slack, forums, Twitter), etc.
There are other things we are doing but the above listed are the main responsibilities we have and are doing.
So how did we go about our responsibilities?
Creating a Devrel Framework for the Foundation
Answering Important questions
This was the tricky part because initially, the foundation itself didn’t have a plan so we had to come up with something ourselves. So I came up with a presentation that contains various methods we’ll be making use of to achieve our goals. If you’re interested in seeing what the presentation looks like, please visit here.
Summary of the presentation:
- I noted that one of the most important things we need to do is listen to the community, only then would we be able to help the community grow.
- I highlighted that we needed to answer certain questions like:
- What is our vision, what are we trying to accomplish?
- What strategy do we plan to take to accomplish our vision?
- What are the objectives that would help us develop a strategy, How do we know we are doing the right thing or we are on the right track?
- What do we do on a day to day basis to move towards our goal?
3. I highlighted certain questions that we need to answer to help us understand what the foundation is trying to achieve with Developer relations.
4. I also highlighted questions related to developers (our audience) that we need to consider when doing anything.
5. Most importantly, I made sure we had a list of successful developer evangelism/relations programs in open source that we could learn from.
We had to be able to answer all these questions I highlighted or use them as a guide for us to develop our Devrel program going forward. In the long run, it has yielded great results because it has helped us put ourselves in the community or audience’s shoes while developing educational content or providing feedback to the contributors. While we were answering these questions slowly and intentionally we had a list of ways we can help our existing community and new users of Cloud Foundry get started and improve the overall Developer Experience.
Before we started making content or any new educational material, we conducted research and drafted a document on the different personas we will be creating content to get them interested in Cloud Foundry. We put into consideration various types of developers that could possibly use Cloud Foundry for their divergent needs. Currently, whenever we create content, we have these personas in mind and create content based on the information we amassed.
Besides just creating content based on the personas, we made this persona research to:
- Find software engineers/programmers/developers & get them interested in the Cloud Foundry ecosystem.
- Make software engineers/programmers/developers aware of Cloud Foundry.
- Get new users to adopt the open-source version of CF and include it in their existing workflows.
With this personal research, we can reach various levels of developers and teams whenever we create content or do anything developer evangelism related.
Developer Experience is a very important thing to take into consideration especially for open source software, one thing teams fail to understand is that developer experience is much more than just how easy developers can use or understand your software, there’s more. One important thing that is usually left out is having great documentation and tutorials simulating different usage conditions for that particular software for people that want to get started with the software as fast as possible.
The way we approached the developer experience is quite interesting. We already had existing documentation for Cloud Foundry but the issue here is that there’s so much information in there, some of the information wasn’t updated enough and we are more concerned with how fast and easily people get started with Cloud Foundry.
We quickly began making comprehensive but concise tutorials for people that hear about the technology and want to try it out as easy and fast as they could. We also made tutorials for people that already have an existing infrastructure (Google Cloud, Digital Ocean) and want to get started with Cloud Foundry on it.
These steps improved the way people saw Cloud Foundry, it is much easier to get started with unlike before where you had to figure out most things by yourself. We care about developers using Cloud Foundry that is why we had to make these tutorials to make it easier for them to use and also get started with.
Asides from just making tutorials, we have since then employed other methods to improve the overall developer experience and easy access to getting started with Cloud Foundry.
Methods We Are Employing to Approach Developer Relations
Apart from making tutorials, we need to get more people into the Cloud Foundry community, here’s a bunch of other methods we are employing on a day to day basis:
Note: This can change at anytime as we are still experimenting with these strategies
- Webinars/Hands-on Labs — We set up hands-on labs for various regions(APAC, MENA, EMEA, etc.) for people that want to get started with Cloud Foundry. We use our existing tutorials to teach people the basics of Cloud Foundry
- Talks — We plan to submit talks at various Paas/Iaas tech events to basically talk about how Cloud Foundry can improve your Deployment workflow and how easy it has become to use.
- Community Reward Programs — We plan to improve our existing Cloud Foundry Ambassadors program to highlight our highly performing community members and also give awards to them. In order to show that we have to show we actually see what these community members are doing and we appreciate it.
- Collaboration with other communities — This is very important and we are paying a lot of attention to it currently. Cloud Foundry as a Paas can work with various other tools e.g Kubernetes, Github Actions, etc. We plan to collaborate with advocates from this community to showcase how well Cloud Foundry can work with these tools/platforms and improve their overall developer experience.
- Community Publicity — We are a non-profit organization, so we cannot spend so much funds on social media ads and commercials but what we are doing and plan to do is spend as little as we can on social media ads and do more community outreach. For example, giving talks, appearing on highly listened community podcasts (I was on a bootiful podcast by Josh Long), interviews with thought leaders in the Cloud Foundry community and also the Kubernetes community, etc.
- Proper Content Distribution —The main aim of this process/method is to generate interest, generate awareness, extract engagement. Other than distributing content on our Medium publication, YouTube channel, and Twitter account. We are making conscious efforts to also distribute content on various other platforms like Reddit, Dev.to, etc. We also have an internal document that we created to record our various distribution channels. These distribution channels are categorized into three categories; Short term, Medium term, Long term. These categories indicate how long it would take to create a meaningful impact from content published on those channels.
How We Measure Success
Metrics are everything in Developer Relations, as a DevRel team, you need to understand what kind of impact the activities you’re carrying out are making.
At the Cloud Foundry Foundation, we measure everything we can from Youtube videos to the number of views and reads we get from our blog posts. It’s from these numbers that we are able to know what type of content people are interested in and we make new content based on the data we have gotten.
We also make sure to keep track of the number of people that attend our hands-on labs and events. We are currently not big on so much success we just want to make sure we provide care for our new and existing users through the educational content we provide and the overall developer experience.
Establishing a new developer relations program for an open-source organization like the Cloud Foundry Foundation, we’ve learned a few things on the way:
- Keep Experimenting — There’s never one way to do something in developer relations, you have to try out other methods to achieve our goals.
- Make sure to understand what you’re trying to achieve from the onset, this will help you make the right decisions.
- Measure everything you can — It is important to measure as much as you can because only then can you use the data gotten to make informed decisions.
- Developers First — Whatever you’re trying to do, always make sure that you place yourself in the shoes of the developers that are using your software and make decisions or content based on what would be beneficial to them. This is why creating personas that model real developers is important.
Developer Relations is hard, it takes a lot of thinking, experimenting, etc. to figure what would work for your organization, and sometimes what works could stop working and you’d have to figure out another method. However, it is important to understand what your organization is trying to achieve with its Devrel program and work based on that. At the Cloud Foundry Foundation, we are constantly trying out new things and experimenting to make sure we create as much awareness as possible and get smaller teams and individual developers into the Cloud Foundry community. There’s still so much we are doing but for now, this is what I can share with you all.