You might have heard that several thousand people have converged on San Francisco for Red Hat Summit at Moscone this week. One of the highlights for Summit this year (at least for me!) is the Community Track, part of the main Summit schedule for the first time this year. Missed it? Don't worry, there's more tomorrow!
Today is the day that Fedora 24 has been released!
It's kind of a big deal at Red Hat, since Fedora is the upstream from which many things flow. So, as such, it's a community release that gets a lot of attention both within Red Hat, and without.
I actually had the opportunity to clean-install Fedora 24 Beta last week—not that I am some Fedora über-fan or anything. No, this was a necessity brought on by a dead hard drive. Thank goodness for cloud backups… one new drive later and I was installing Fedora 24 from a live USB.
The experience itself was nothing notable, in that I had enough bad experiences with Xconfigurator and snapping CRT monitors to still make my subconsciously twitchy whenever I do a full install. Silly, yes, but I was poor in those days. So "not notable" is high praise indeed.
This is not about how to create communities and who is doing it wrong. This is about the perception of community and the difference between the perception and reality.
Here's what I know about communities:
- They're hard to get into.
- They're hard to get out of.
What in the what?
On the first rule: this goes for all communities. Move to a new neighborhood. Get into a new software project. Go to a new school. Move to a new city. Join a new company. All of these are "communities" in different ways. It's usually not the case that you show up and you're immediately seen as "a valuable member of the community"—you're an unknown quantity. You have to put energy into this community to be welcomed; to be able to contribute, you have to have spent time there.
One of the things I have discovered while working with mapping platforms like OpenStreetMap is that there really isn't anything like a straight line in the world.
You think there are lots of straight lines out there—streets, property lines, boundaries—but there is really no such thing at all. Some of the deviations are geographical, with rivers and mountains and valleys carving up the world. And some are purely political; Mark Stein wrote a whole book on How The States Got Their Shapes, detailing the boundaries of various U.S. states and the historical and political intricacies of why the states are the way they are.
In the day of the great Slack outage, which left large parts of the internet unable to communicate with each other, we also discovered that a large part of our feelings had been hidden in the everyday discourse. It was actually easier to talk to each other about the various challenging aspects of our work than to be alone with it. (This happens every time a major component of our communication tools goes down. Twitter, Slack, pick a thing.)
It's like that discovery around language and monkeys: when a monkey is lost, they will lament the state of being lost instead of trying to find the rest of the tribe. When you can't communicate with other people who help you articulate your feelings of discomfort, it gets harder to deal with them. I see this as big factor to burn out—when you cannot articulate your values and where they are not aligned with the work that's being produced, you lose the ability to rationalize the difference between those things. You can't process the difference between what you see happening every day, your own sense of "the right way to do things" and where the overall group is going if you don't have a space to talk about it that everyone understands.
Last week, one of my teammates related a conversation he'd had about how poor community manager job expectations are and, concurrently, how little they are getting paid.
What my colleague pointed out—correctly—is that a lot of the jobs listed out there that are called "Community Management" are really not anything close to what the job actually entails.
I've covered this before, back in July 2015. The actual title "Community Manager" is vague enough to get co-opted by many other occupations that think the whole collaborative/open thing is just a nice turn of marketing phrase.
As Red Hat preps for Red Hat Summit in the venerable Moscone Center next month, the Open Source and Standards team is preparing to be a strong presence at the event with our Community Central in the Main Expo Hall and a separate Open Source and Community track within the sessions.
The Community Central area will feature a lounge and plenty of space to interact with the Fedora and CentOS projects, which will anchor the space. But projects like RDO, Gluster, Ceph, oVirt, and Project Atomic will also have a home in Community Central, just to name a few.
Governance in an open source community always varies from project to project. Typically it's along the lines of a meritocracy, where community members' participations are weighted by the quality of each respective member's contributions, but not always.
But one thing a community should not be is completely governed by the management hierarchy of any companies that sponsor that project.
There is much—legitimate, mind you—celebration of late about the continued success of open source within software development. But there are times when that success may not be enough, even when good-faith efforts are made.
It is one thing to have an open source software project and quite another to have a healthy and growing open source community. Even when a company or project is making legitimate and strong efforts to free and open source processes and values, it may not always hit the mark—especially when it comes to community.
There are quite a few software projects that we in the Open Source and Standards group work with, both on personal and professional levels, and one of the key differentiators that gives a community better growth is the presence of what we call "onboarding."
One of the very first things I learned about OpenStack was just how difficult it was to install.
With so many components handling so much automation, installation and deployment of a cloud computing platform like OpenStack, it's no small feat to get it up and running.