A few weeks ago I spent a couple days commuting up to San Francisco for DockerCon SF 2018 at Moscone West. This was my first DockerCon and my second time attending a conference in this venue, though last time was for Google I/O when I was living a couple blocks away so the commute was considerably shorter! I came in for Wednesday and Thursday of the conference, which allowed me to see a couple days of keynotes, along with sessions here and there.

The first thing you notice about this conference is how big it is. Coming in at about 5000 people, it’s on the large side of events I go to. Unfortunately the sessions were a bit hard to get into if you didn’t plan ahead by at least a week. The badges doubled as attendee check-ins for the sessions so they could manage flow with guaranteed spots and wait lists. As a result, I missed the opportunity to see a talk by my Mesosphere colleague, though it was nice to see the wait list was also full for his talk!

The second thing that because clear very quickly was that, like Puppet, this was a very vendor-focused conference. They keynotes trended very Enterprise-focused both in product and audience, especially on the second day. I think part of this is that they separated out some of the community stuff into other days that I didn’t attend for. The schedule system was also pretty confusing, so it’s possible I just missed things that may have been interesting to me due to how they split up the event to various “theaters” and things that were not necessarily main track talks.

There was a strong theme of avoiding cloud-based vendor lock-in. It’s an important message for me as well, so I did like to see others pushing the message, and their technical preview of a hybrid cloud solution was good to see.

I was also there to to pitch in at the Mesosphere booth, which I did both days!

On Thursday headed out to lunch and meet up with my friend John, in town from Philadelphia.

Talk-wise, I ended up in few that were less interesting to me due to the proprietary nature of their solutions and focused more on the product than how they solved specific problems in a more general way. However, I really enjoyed a talk by Ilan Rabinovitch of DataDog who shared adoption trends gleaned from statistics that DataDog collects. This gave insight into the most popular workloads (ngnix, Redis) and how many were using orchestrators like Kubernetes, Docker Swarm and DC/OS (about 50%). Perhaps most fascinating for me though was the lifespan of a typical container, which comes in at about 2 days, and is less than it was in previous years. Broken down further, the lifespan of a container in an orchestrated environment is actually 1/2 a day, and unorchestrated is 6 days. For those of you following along at home, a shorter lifespan is typically better, since it should point to a system that’s resilient, automated (perhaps driven by a CI/CD process), and updating containers as needed rather than letting anything get outdated or otherwise insecure. I also enjoyed a talk about Itsio, since they dove into the specifics into why traditional tooling for monolith applications isn’t well-suited for a microservices world. They went into the basic architecture of an Istio deployment by explaining what each component was, talked about features of the next release, and gave a demo.

I’m glad I went to experience it and meet up with folks who I know from the community, but I think this conference tended to be on the less valuable side for me. Maybe if I had attended previous ones I may have understood the format a bit better, or if I was actually more involved with the community directly I could appreciate some of the breakout sessions. As a peer in the container space and open source enthusiast, I think it just was a bit too product-focused for me. Back to pure open source and DevOps events for me!

A few more photos from DockerCon 2018 are here: https://www.flickr.com/photos/pleia2/albums/72157694835161302

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).

Thanks to Leslie Hawthorn for taking a picture during our talk! source

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!