A few weeks ago I attended my second DevXCon. It was held in the dogpatch neighborhood of San Francisco this year, which meant a BART ride and then a MUNI Metro ride to get to the venue, but it was still quite accessible to public transit.
This year my colleague Judith and I put in a talk which was accepted titled “Debian to DC/OS: factors that shape open source communities” where we pulled out some of the similarities between open source projects we’ve worked on and evaluated the strategies for effectively supporting these communities. My own experience across projects has shown some very interesting trends around the relationship between an open source project and the company or companies supporting it. Perhaps most notably, is in the Ubuntu community where we were fiercely loyal to the project, but bristled at the association with Canonical. Community members would be thrilled to have their work highlighted on an Ubuntu-branded resource, but less likely to even allow Canonical to “use their work” to promote the company at all. The key point of the talk is that analysis of the company, project and community needs to be done on several axes so you can craft an effective approach to community development, since what may work well in one community could fail in another, and you need anticipate and handle that. Slides from the talk can be found here (PDF).
It was an enjoyable talk to give, but the talk slots at this event were 20 minutes long (short!) and I’m not used to having a co-presenter, so I was a little nervous about timing and flow. Still, it went well and I’ll be giving it again at the end of August for the Open Collaboration Conference at the Open Source Summit in Vancouver. I have some additions I’d like to make to the criteria for evaluating projects, and it would be fun to add a couple more projects to our examples.
Of course the real value of this conference is in hearing what other people have to say! The event kicked off on Monday afternoon with a keynote from Jono Bacon about cultivating leaders. This is a complicated topic, and he handled a lot of the nuance of it well. All of the communities I’ve worked in have struggled with cultivating leaders beyond the original few, but you can’t just hand off leadership to anyone who comes along and wants it, as it’s common for people who want responsibilities to be ill-suited for it. You need to look for the right characteristics and recognize that not everyone is cut out to be in a leadership role. He stressed the importance of listening, ability to be decisive, humility and self-awareness for when mistakes do happen. He also talked about how you need to support the people in your community who may be good leaders by providing coaching and mentoring.
The second keynote came from Mano Marks who explored the developer advocate/evangelist question of “Who do you work for?” It’s a question I’ve easily answered as “the community” but you are being paid by a company and there is some loyalty to be recognized there as well. He explored motivations of various stakeholders and factors like company size, project and product maturity and community size, and how these all impact where your role. I was also happy that he addressed the topic of integrity, since many of us are hired partially based on our reputation and that’s important to keep healthy if we wish to succeed across multiple positions in developer relations.
On Tuesday I enjoyed hearing from Bear Douglas about connecting developer relations to product inside of a company. It’s something we’ve started doing more as we process community feedback and tickets. Part of your job is to be the filter and the funnel to make sure feedback is of a high caliber and clear. One of my favorite bits of advice was that you should mix in feature requests and concerns with positive and neutral feedback as well. You don’t want product to dread your reports or visits that are full of complaints and requests, instead mix them up so they also have reason to feel good about what the community members are expressing. She also talked about the importance of closing the feedback loop so everyone involved feels like their feedback is being addressed in some way.
I also enjoyed the afternoon keynote chat with Alex Salazar at Okta who shared a story of their first developer experience hire whose actions actually caused the company to pivot early on based on community feedback, despite protests from leadership. It ended up being the right decision for the company and was an excellent demonstration of how powerful developer relations can be.
During afternoon sessions I heard from Brian Proffitt about effectively talking to the media as a representative of your community, including key tips like making sure you communicate major changes, new things and the larger ecosystem impact of whatever you’re seeking to announce. Clarity is important, since news may go out regardless, and you want it to be accurate. He also appealed to the need to find the right reporter for your news and to stay on target with your messaging. I think what I liked most about this talk was that Brian is a story teller, and I enjoy the story he weaves in his talks.
I also attended a talk by Leslie Hawthorn and Laura Czajkowski where they talked about the success of the Ubuntu community in hiring known people in the Linux ecosystem to work on Ubuntu early on who could effectively impact the product and seed the community, and how the community friendly messaging early on created a passionate community. The Ubuntu community also made clear calls for contributions and always placed a high value on contributions from community members. They also leveraged existing structures in place, like LUGs and existing open source conferences that were receptive to the goals of Ubuntu. It was all stuff that I knew since I was part of the community and lived through it, but I enjoyed seeing it presented as a use case like this since it helped me more objectively look at the successes the community had and how I can more effectively integrate that into my own community nurturing work today.
The conference was a good one for me, and I was quite happy both with the 20 minute talk slots and the duration of the event itself, lasting from Monday afternoon through Tuesday. I think a lot of the attendees are like me and do a lot of events, so taking time to attend yet another event, even if it’s for more specific professional development, can be a bit of a burden. It is a lot easier to squeeze in a day and a half into our schedule, and of course I enjoyed that I didn’t actually have to travel for it!