To paraphrase my colleague, Dave Neary, cookie licking is when you volunteer to do something and underestimate the commitment required. Then, instead of stepping back so someone else can do the work, you keep the task marked as yours, preventing someone with time from taking it. This can also manifest as staying on as part of a leadership group you don’t have time for, thereby creating a block on consensus and decision making when you don’t have time to show up.
This is a question community managers hear a lot. Everyone wants to grow their project and we all want to hear what worked (or didn’t) for others. One of the benefits I have by working for Red Hat is being part of a large community of community managers and community oriented people. Stormy Peters put this question to that group last year:
We are all working to grow the communities around our projects, in particular diverse communities (diversity of company, gender, geography, etc.). What’s the single best tip you’ve gotten for attracting new contributors? Who gave it to you? Or, alternatively, what’s the single thing that’s made the most impact on attracting new contributors to your project?
She got a lot of great answers, some of which I’ve collected here.
This week’s opensource.com community blogging prompt by Stormy Peters includes the question, “should community managers sit in marketing or engineering?” This is a very individualized decision and not an easy one at that.
A lot of companies support open source communities. The Fedora Project is supported by Red Hat. Red Hat’s support is huge and includes infrastructure, engineering and non-engineering contributions, budget for community driven activities and events and community coordination assistance.
Fedora is a community with a lot of moving parts and has at least five different ways of thinking about new contributor onboarding. Unlike some single code-base communities where there is a focus around a repository or a bug tracker, Fedora is constantly working on lots of things and the linkages can be hard to see. Some of those activities are directly (in a creation sense) related to the amazing Linux distribution we produce.
These activities, like Release Engineering, must happen or no bits get shipped. Other activities are critical to the experience of Fedora, like Design. Without these activities we might as well not ship. Some activities, like a lot of the work done by Fedora Infrastructure, are critical to providing the tools and glue we need to get our work done.
Onboarding is much on the mind of communities of late, thanks to Stormy Peters’ prompt on how community works at opensource.com. Go read it, as it inspired this post and will contain lots of great information in the roundup post later this week.
I had the pleasure of going to FOSDEM this year and the annual spectacular didn’t cease to deliver. During this year’s conference, my second FOSDEM, I worked with Brian Stinson of CentOS fame to produce the Distributions Devroom.
FOSDEM gets busier every year and the Distributions Devroom was no different. For almost the entire day, the room was filled and we were routinely turning people away for lack of seats. The few times there was a dip in attendance seemed tied to the topic and not the time. This leads us to believe that the program was well balanced and represented the current thoughts and interests around distributions.
I recently attended LinuxCon Europe 2015 from 5-7 October, 2015 in Dublin, Ireland. I came with high expectations and goals and I am pleased to be able to say they were met.
The conference was combined with two other conferences (CloudOpen and Embedded Linux Conference Europe) and I expected it to be a painful to navigate a huge venue, where I wouldn’t be able to find anyone. Instead, at about 1500-2000 people, the combined conference was very addressable, allowed for easy crossing of tracks, and presented a fantastic "hallway track." The organizers, sponsors, and venue did a fantastic job.
Rather than recap every talk I attended, I’ll talk about the event from the perspective of a software engineer working with container-related technologies. In my $dayjob I focus on Project Atomic, a collection of container-related technologies that make containers easier to implement and deploy. While the project focuses on Docker containers and tends to use the Kubernetes orchestrator, Atomic is really container-technology agnostic.