Tag Archives: community

Open Source Glossary

When discussing open source with colleagues, I tend to assume that they already know the basics. But, as open source becomes a standard part of all software development, and the number of people working with open source grows, this has become less and less true.

What follows is a minimal viable vocabulary, which I’m posting here so that I can link to it elsewhere when having these conversations, and attempting to assume a lingua franca.

Open Source

Open source refers to software which is developed and released under an OSI (Open Source Initiative) approved license. Open source licenses are those that comply with the Open Source Definition, which sets forth ten tenets which are mandatory components of a compliant license.

Within these tenets, there is a lot of room for variation, and thus there are many licenses that qualify as open source licenses, ranging from extremely permissive (“Do whatever you want with this code.”) to much more restrictive (“You must do these things with the code.”)

While, strictly speaking, “open source” is a legal definition of the license under which software is released, it also implies a project which is run under the guidelines of the Four Opens – Open Source, Open Design, Open Development, and Open Community. In reality, most projects fall short of that ideal in some way, but it is an ideal to be striven for.

Fork

A fork is a copy of an open source project, for the purpose of making changes to the source code. Usually, this is done with the intention of offering those changes back to the original (“upstream”) project for inclusion in future versions (See “PR/MR/Patch”)

A private fork is when this copy is made privately, inside a particular company or organization, without visibility to the upstream.

A public fork, as the name indicates, is done in public where everyone on the project can see what changes are being proposed. This is always preferable, as it allows the project community to comment and participate in these changes, rather than them being a surprise.

A hostile fork is when a project is forked with no intention to ever contribute back, but, rather, to continue to run a competing project indefinitely. This should be considered only in the most extreme of situations.

PR/MR/Patch

A PR (Pull Request), MR (Merge Request) or Patch, are all terms for offering a change back to the originating project (“upstream”), for inclusion in future versions of that project. The terms indicate different ways that the change may be submitted, but all refer to essentially the same thing – a proposed change.

A PR is the desired end-game on any fork. Forks should be short-lived, and have a specific proposed change in mind, rather than being long-running or permanent artifacts.

Upstream

An upstream project refers to the open source project from which you are building. That implies the existence of a downstream – a project, product, or service which inherits some or all of its code from that upstream. For example, Apache Kafka is the upstream for Amazon Managed Streaming for Apache Kafka (MSK). (Which, of course, implies that MSK is the downstream from Apache Kafka.)

The upstream/downstream relationship is symbiotic. That is, a project relies on users, and a product or service relies on the upstream’s health and sustainability. As such, a downstream product or service should do everything in its power to support and sustain the project which it depends on. And project, in their turn, should listen to customers and users, and be responsive to them.

Maintainer

A maintainer is someone empowered to make changes to an open source project, and/or to make releases of that project. Ideally, a healthy project will have multiple maintainers, and there will be healthy discussion and debate around changes that go into a project.

Single-maintainer projects, or single-vendor projects (ie, where all maintainers come from the same vendor/company/organization) pose a risk to the sustainability of that project, since the change in direction from one source can result in the user community being suddenly disenfranchised or surprised. Thus, it is an ideal of open community that there be a diversity of inputs in the pool of maintainers, to ensure that all voices are equally heard when changes are made.

Measuring conferences

In a normal year, I go to a lot of conferences. 10-14, typically. These events are, presumably, picked because they are in some way useful to my company, or my project.

That’s really hard to measure.

We kind of just know which events are good ones – a gut feeling – but we kind of stink at actual metrics.

One of my goals this year was to be more rigorous about measuring what benefits I got from a conference, so that my budget is spent as effectively as possible, in ways that actually produce long-term benefit. This then informs the events that we’ll do the following year.

Caveat: I am a community manager. As such I care about community metrics. Not sales. Not business cards. Not dollars or contracts. That makes these things that much trickier to track.

Here’s some of the things that I try to measure when I do a conference.

Meaningful Conversations. Most of the people that come to a conference booth are there to get the free stuff. But a precious small number are there to learn, to connect, to solve, to contribute. In past years I have kept a bit of an impression as to how many that was, as a fuzzy metric of whether a particular event was the right audience. This year, it was my goal to actually count, and keep that data from year to year.

New Community Members. This is hard, and, frankly, I don’t know how to track this. But it’s really the most important thing that I would like to track. I know, anecdotally, that lots of people, over the years, have joined, and stayed with, Apache projects because of an experience at ApacheCon. But that’s not the only factor, and it’s certainly hard to track because it requires years of events, and years of conversations, and people willing to tell those stories. I would like a better way to track this, and would love to hear your ideas.

Content. This one is easy to track. A lot of the events I run are all about content creation. When I run a CentOS Dojo, maybe 100 people attend, but then 1000 people see the videos that I record at the event, And maybe 1000 more read the blog posts that come out of those presentations. This is trickier when I am not running the event, and so don’t have control over that. At those events, I try to be very intentional about collecting stories. Stories can be interviews (video, audio, written notes), or they can be a promise of a later story, either delivered in writing, or via a video call that we schedule after the event. Here, obviously, followup is critical, and so it was my goal to be much more intentional about collecting contact info, and detailed notes about why I had that contact info. I wrote a blog post about that after FOSDEM.

As we try to be more intentional about what events we attend, sponsor, and speak at, it would be great to hear from some of you about what you measure, and how, to figure out if a conference (or other event) is a worthwhile investment of your team’s time and money.

What does a community manager do

Last week I took some long-postponed vacation time and missed Stormy’s blogging prompt. But this particular question needs answering.

What does a community manager do?

Whenever people ask me what I do, I find myself struggling for words, because being a community manager is a daunting mishmash of interrelated tasks that range from marketing to HR to event management to journalism to … everything else.

During the Obama years, the term “community organizer” was bandied about, and that comes close to what a community manager does. And then there’s the confusion around the term “manager”, because I’m not a manager, and I don’t manage the community.

So what do I do?

Well, it’s a bit of this and a bit of that.

Cheerleading

A major task of community management is to be the lead cheerleader for the community. I’m the community manager for RDO, and so it’s my job to promote RDO to the various audiences that might care.

In the case of RDO, that includes the larger OpenStack community, cloud operators in the general IT work force, and also internally to people at Red Hat who need to be informed about what’s happening in the “upstream” community, and how it affects our “downstream” product, Red Hat OpenStack Platform.

To this end, I manage our Social Media presence, post updates to our mailing lists and blog,  make announcements on IRC, and so on. I also show up at conferences and answer questions from attendees, put together presentations to tell people about what we do, and speak at events.

Event planning

At Red Hat, we have an actual event planning team, and they are awesome at what they do – booking facilities, shipping stuff around, planning and setting up and tearing down the physical booths at events, coordinating and communicating with all of the people that will attend.

I don’t do that.

But I plan and coordinate events that my part of the community will show up to. I plan small social events around the main events. I make sure that those events work with the schedules of the people that I’m responsible for, and encourage them to come and bring their friends.

And I help out with small regional meetups, providing swag, as well as helping with (i.e., funding) travel and lodging for speakers that might not have budget to do that on their own.

Make personal connections

A major job of the community manager is to become an expert on the community members. Who knows what. Who is willing to speak on a particular topic. Who has the connections to make things happen.

Then, when a question is asked, or when someone has a need, it’s my job to connect them with the right person that can help them.

So … kind of like first-tier support, triaging problems, solving the ones that I’m able to, and referring to second-tier support those problems that are beyond my expertise.

There’s also some mentoring that goes in here – helping people new to the project know where to fit in, and where to find the information they need.

Look for stories

I look for stories of people using our project, and tell those stories to the world. In this part of the role, I’m the journalist, looking for ways to tell the story about how our project makes life easier. Much of this is amplifying stories that other people are telling. And then some of it is going out and gathering the stories, and then finding ways to tell those stories.

Everything else

While I don’t write code for the RDO project, I do a little bit of everything else – whatever people need done, I try to fill in, or find the right people to do those tasks.

So, that’s why it’s difficult to know how to answer when people ask me what I do at work.

Too many beginners

Last weekend at FOSDEM I gave my “Write A Better Manual” talk. I got a question afterwards that I’ve never actually received before:

We’ve done such a great job of attracting new members to our community that it’s causing a problem. Our lead developers are spending all of their time mentoring beginners, and no code is getting written. What do we do?

Once I got over my “I wish I had your problem” moment, we had a great conversation about concrete ways that you can address this problem. And, of course, it is actually a problem, because it can lead to the demise of your project every bit as much as not enough new community members.

Here’s some things that you can do, even if you don’t have exactly this problem:

Turn the beginners into mentors

Someone has just come to your community, and asks a question. It’s one of the questions that you get every day, like “how do I find my IP address?” or “how do I connect to a wireless network?” or “where is the toilet?”

Rather than answering the question yourself, ask the not-quite-beginner to answer it. This does many things at the same time. It saves you the time and trouble of answering. It indicates your confidence that this person is part of the team. It lets this person know that it’s ok for them to start mentoring other people. And the next time the question is asked, you won’t even have to say anything – they’ll just answer it. You’ve taken the first step to making a mentor out of the mentee.

Take shifts

Mentoring beginners is amazingly rewarding, but it’s also exhausting. You shouldn’t have everyone doing it, and you shouldn’t have the same people doing it all the time. Take turns. Even go so far as making a rotation schedule – one week on, 3 weeks off. Your mentors will come back rejuvenated and ready to start up, and will get “off shift” just about the time that it’s starting to be frustrating.

Know when to quit

Even if you don’t take specific shifts, mentors should be told that they can, and should, take breaks. Mentoring is incredibly important, but it’s only part of your “job”. Work on code for 3 hours for every hour you spend answering questions on IRC. Or something like that. You’ll find that if you set yourself a specific quota of mentoring time, you’ll look forward to it more, and you’ll be more effective at it.

If you’re not good at it, don’t do it

Finally, some folks just aren’t that great at mentoring. Either they’re not very patient, or they’re not great at communicating, or maybe they’re just too valuable at writing the code or the docs, and should stick to that.

These people should be encouraged to stick to what they’re good at, because, frankly, some people do more harm than good when it comes to talking to beginners.

Celebrate your problem

But, at the end of it, recognize that most projects would love to have the problem you’ve got. Celebrate your beginners. Bring them along. Eventually, they will “graduate” and become the core of your community.

 

 

Living in community: Curbing your passion

1 Comment

I’ve had a very frustrating set of interactions over the last 3 days, on an open source community mailing list. Doesn’t matter which one, because I think that these things are universal.

I said “here are some ways we can make things better.” Or, at least, that’s what I thought I was saying.

Several people heard “everything is broken, and it’s your fault.”

At the end of several very heated email conversations, it became clear to me that we all agreed on (almost) everything, and were getting hung up on that initial statement. It wasn’t even that the things that I was proposing were opposed, it was that the way that I presented them was perceived as criticism of what people had done for the last few years.

Email is notoriously bad at conveying nuance. This is amplified in a multi-cultural, multi-lingual community.  Here’s some practical things that I took away from this conversation – most of which I should have already known

Suggest improvements. Don’t focus on shortcomings

Pointing out breakage is easy. Proposing solutions is where the real work is. Now, sometimes, you need someone to say “this is broken and I don’t know how to fix it.” Those situations are very tricky. Tread lightly.

Focus on what needs improving, not on who made it that way

This sounds easy, but is really hard. There’s always someone who spent hundreds, or thousands, of hours, making the thing the way that it is, and so when you point out that the thing isn’t perfect, that person might take it personally. I honestly don’t know how to avoid that, and this week has shown that very clearly. But I can look back and identify some of the things I did poorly, and apologize for them.

Curb your passion

This one is unintuitive. We need to be passionate about our community. But sometimes when you’ve been pondering something for a few months and arrive with all of that passion, people are more likely to mistake that passion for anger, criticism, and so on.

Yes, some people need to get thicker skins. Don’t read everything I’m saying as that we need to pamper everyone’s bruised feelings. But when people aren’t looking in your eyes, it’s easy to take passion as an attack. We’ve all done it.

I’ll close with one of my favorite quotes from Confucius, who said, “There is honor in the email not sent.”

Yes, he said that. I was there.

Read your email twice before you send it, and delete half of them unsent. This will lead to a better universe, and fewer three-day shouting-fest email threads.

 

90-9-1

1 Comment

In a talk I attended earlier this year, Shaun McCance mentioned, as though it was established science (which it is) the 90-9-1 principle of community participation. I’ve thought of it frequently since then, to set expectations and to keep myself sane.

The idea is that in any community effort, 90% of the people are going to sit around saying that it’s a great idea, but not actually doing anything about it. 9% of the people are going to work casually on it in their spare time, as convenient, and between them will do a huge amount of the work. Then 1% of the people – usually one or two dedicated people – will pour themselves into it wholeheartedly, putting every spare moment into making it a success.

Note that it’s not the exact numbers that matter here, it’s the undeniable fact that you can’t expect everybody to work as hard as you do on everything. It’s all too easy, when doing anything on a volunteer basis, to look around and get frustrated, discouraged, even angry, at the 90%. Understanding that this is the normal, expected, even healthy way that communities operate, can help you refocus on what you can (and can’t) do in any given effort.

Sometimes (most of the time) it’s ok to be in that 90%, and you don’t need to feel that you’re not pulling your weight. However, if you’re in the 9% or the 1%, it’s not reasonable to get angry with the 90%. They have other things to do, and are likely the 1% on something that you’re not helping much with.

By the way, here’s a couple of resources about this notion:

This article claims that the concept is dead. Note that this article appears to be someone just making up new numbers to illustrate the same concept. What’s important here, folks, isn’t the exact numbers, but the general concept. Way to miss the point. (This article also appears on dozens of sites in various different forms.)

Wikipedia claims that it’s a feature of Internet culture.

Here’s an actual statistician doing scientific analysis, rather than me making up numbers.

FTIC

Skippy posted some thoughts about FTIC which I found intriguing. About as close as I get to FTIC is, like Skippy, the folks with whom I interact via IRC. Although I keep in fairly close touch with Maria via AIM as well.

We tried, briefly, the text messaging thing. That was before either of us realized that text messages are billed PER MESSAGE, and the bill at the end of that month was rather startling. Presumably all the cool kids have unlimited text messages on their cell phone plans.

I’m also reminded of this quote:

I don’t own a cell phone or a pager. I just hang around everyone I know, all the time. If someone wants to get a hold of me, they just say ‘Mitch,’ and I say ‘what?’ and turn my head slightly.

Mitch Hedberg (1968 – 2005)