Running communities around projects is all about getting the job done, and getting it done well. If you don't nurture a community, it won't grow and produce. Then, if you get that right but fail to maintain and organize things so that the people involved, your community, can continue to succeed and feel happy doing it, your project's growth and success won't last long.
These are the intricate details of a project, and the people that constitute it, that Robyn Bergeron orchestrates everyday. She incorporates a deep understanding of the technology behind her company with the feedback she gets from the developers who are building the project out.
Robyn is an Operations Advocate for Elasticsearch, an end-to-end search and analytics platform. In this interview, she answers my questions about her role as part community manager, part developer advocate at this acclerating open source company. But, what is it exactly? Bascially, Elasticsearch is an open source, distributed tool for powering search applications, based on Apache Lucene. It has many uses; a popular one is a configuration often referred to as an ELK stack (ELK = elasticsearch + logstash + kibana) used as a backend for analytics tools.
Find out more in this interview.
Let's go way back. How did you get started in open source? What or who made the biggest difference to your start?
I started participating in open source communities back in 2008, volunteering as an editor for the proceedings of the Ottawa Linux Symposium. The toolchain and environment we used for editing was entirely on the Fedora desktop, and by chance in 2009 (my second year of editing) I happened upon the Fedora wiki page that showed the many ways to contribute to Fedora. I was intrigued by the idea of participating in the marketing group, as I had previous career experience in that area. I joined the mailing list, and within probably 6 months of my first post, I found myself not only writing a lot of release-related content, but also volunteering to organize a FUDCon in Tempe, Arizona.
I think there were a number of factors that influenced my participation and enthusiasm; honestly, if I hadn't seen the "join" page describing how to participate, which highlighted ways for non-coders to contribute to the project, I never would have thought that I could have contributed in any way. This is one of the reasons why I think it's incredibly important for projects to show how people can be involved—many people, including myself at the time, don't realize all of the different ways that various skillsets can make a project even better. Of course, having a number of people making me feel incredibly welcome and valued made a huge difference. I really felt like I was part of the team.
I remember the day when "stickster" (aka Paul Frields, who was then the Fedora Project Leader) first talked to me on IRC; it seems funny in retrospect, but I was so blown away that I was worthy of his attention that I was just giddy with excitement. And I learned so much from so many people, in such a short period of time. Max Spevack took time to listen to me and blessed me with his wisdom, Mel Chua taught me the value of transparency and documenting anything and everything. I could go on and on...
but the real point is that there were people who really believed in me, and that made all the difference in the world.
What does a Developer Advocate do, in general? What's it like to do this job for Elasticsearch?
It's funny—there are lots of "Developer Advocates" out there, and much like the "community manager" job title, the roles and responsibilities seem to vary from project to project (or company to company). And in many cases, there is a fair amount of overlap between those two job titles in terms of the roles and responsibilities they perform. I would say that, for myself, it comes down to a small handful of things:
- Ensuring that community members have access to the things they need to contribute in the ways that they wish. That can be anything from information, to helping out with a meetup location, to facilitating improvements in pull request processes, etc.
- Listening. Lots of listening. Making sure that what I'm hearing from the outside world is being funneled back into the project's developers ears.
- Communicating. Generally getting the word out, whether via presentations, newsletters, social media, or just participating in the hallway track at a conference. Making sure contributors and observers know about what's going on in terms of project development, participation opportunities, etc.
All that said, I recently, with my lovely boss's blessings, have shifted my title from "Developer Advocate" to "Operations Advocate"—mostly because ops is where my interests have always been, having been a sysadmin way back in the day (years that start with "19"), and because those are the folks that I tend to interact with most at conferences. In all honesty, I think there's not much difference between the two, other than perhaps better reflecting who I tend to connect with. I really just think of myself as advocating for contributors in general.
Any stories or lessons of note from your time as the Fedora Project Leader?
Oh, I have an a-bun-dance of stories. And the wurst puns you've ever heard. (Ah,Beefy Miracle. He shall live forever!) But they're best told in person.
As far as lessons go, that's tough. If I was to give advice to anyone participating in open source, it would be to remember that sometimes things fall on the floor, don't get finished, or just flat out fail—and that's okay, so long as you figure out why and prevent it from happening in the future. Even if that prevention is simply determining that perhaps something wasn't as important as you thought and eliminating it altogether! But nothing is worth burning people out; the community isn't made up of code and content, it is made up of people.
You'll be talking at SCALE13X this year about DevOps in practice, theory, and otherwise. Can you share a few things with us now?
Sure. Be warned: It may sound buzzwordy! (And barely scratching the surface!)
Communicate. Communicate. Communicate. And have empathy.
Automate All The Things.
Release early, release often!
Be transparent!
But wait! Those last two sound like things from the land of open source, you say? You're right. In fact, a lot of the goals one might have are very similar to what open source communities have, as they are both communities of practice (even inside an organization!).
What's the #1 best practice or habit of a successful open source community?
I have to pick a number one?! Impossible. But I'll mention one that I think is less often mentioned: Listening.
As individuals in a community, and the community as a whole. Being humble enough to not be above advice or criticism; being empathetic enough to put yourself in someone else's shoes; being kind enough to listen to one another as individuals who sometimes just need a friend to talk to. The things you learn by listening can be the things that make a difference to one person, or to the community as a whole.
This article is part of the Speaker Interview Series for SCALE13X. The Southern California Linux Expo brings together Linux and open source users, developers, companies, and enthusiasts.
