Tag Archives: osscommunities

Three best features of open source events

As part of Stormy’s ongoing blog challenge, here’s my take on “Three best features of open source events.”

1. The hackathon

While there is considerable evidence that the term “hackathon” should be avoided (No, I can’t find the article right now. I’ll keep looking), the collaborative space at an event is, in my opinion, the most important part of an open source event.

Open source events are educational, of course. You can attend a talk and learn things. But most of the information that you need to learn is available, free, online. So to me the most important part of an event is the opportunity to meet and collaborate with the other people on the project.

Defining a specific space for this is critical to get people to sit down and play along. Signs identifying project teams or topics is even more welcoming. Having a white board where people can identify specifically what they are working on gives a way for introverts to be overtly welcoming of other people with similar interests.

Publicizing the collaborative space well in advance of  the event gives the opportunity for people to discuss what they might work on, and gives some people the added incentive to show up at all.

2. The after-party

While it’s indeed a cliche (because it’s true!) that open source events have too much alcohol, having an after-event, with or without food and/or drinks, is a critical part of the event. It gives a specific time and place for your community to get to know one another in a less formal atmosphere, and talk about something other than code. These kinds of community bonds will simply never happen on the mailing list, which is by design focused on the project, the code, the design, and so on, rather than on the personalities.

Open source communities fail because of personality issues at least as often as they do because of code issues. Providing a specific time and space to address these issues saves communities. As we say at Apache, Community > Code.

3. The keynotes

Picking good keynotes is really hard, because keynotes should be inspiring. As such, they don’t always have to be directly related to the topic of the event, but should be, in some way, of interest to the audience.

A keynote should be delivered by someone who is engaging and eloquent. And it should have some kind of call to action, or end on a note that inspires the audience to go do something.

I’ve been attending technical conferences for 20 years, and I remember only a handful of keynotes. I remember Douglas Adams because he was funny. I remember Hugh Howie because I got to sit on stage with him and grill him about the process of being an author and engaging your fans. I remember an OSCon keynote about maps, and one by a guy from WETA about the making of the Lord of the Rings movies. I remember Gema Parreño talking about using data to save the earth from collision with space objects. And most recently, Sandra Matz talking about what your social media profile says about you.

But there have also been a lot of clunkers, and a lot of product pitches, and a lot of Hey Look At Me talks. I can do without those.

Oh, and if you have any suggestions for great keynotes, please let me know. 🙂

3 ways you find the right type of contributor and where to find them

Another one of Stormy’s questions caught my eye:

“What are 3 ways you find the right type of contributor, and where do you find them?”

Thinking back to the last few years of work on RDO, several answers come to mind:

The people asking the questions

Watch the traffic on your mailing list(s) and on the various support forums. The people that are asking the most questions are often great potential contributors. They are using the project, so they are invested in its success. They are experiencing problems with it, so they know where there are problems that need to be addressed. And they are outspoken enough, or brave enough, to talk about their difficulties publicly, so they are likely to be just as willing to talk about their solutions.

These are usually good people to approach ask ask to write about their user experience. This can often be done collaboratively, combining their questions with the eventual answers that they encountered.

If they appear to be the type of person who is implementing solutions to their problems, ask them to bring those solutions back to your community for inclusion in the code.

In RDO, people that participate in the rdo-list mailing list will sometimes end up contributing their solutions to the project, and eventually becoming regular contributors. We probably need to do a better job of encouraging them to do this, rather than just hoping it’s going to happen on its own.

The people answering the questions

In watching the question-and-answer on ask.openstack.org I often see names I don’t recognize, answering questions related to RDO. Sometimes these are Red Hat engineers who have recently joined the project, and I haven’t met yet. But sometimes, it’s people from outside of Red Hat who have developed expertise on RDO and are now starting to pay that back.

These are the people that I then try to approach via the private messaging feature of that website, and ask them what their story is. This occasionally evolves into a conversation that brings them to more active involvement in the project.

Most people like to be asked, and so asking someone specifically if they’d be willing to come hang out in the IRC channel, or answer questions on the mailing list, tends to be fairly effective, and is a good step towards getting them more involved in the project.

The people complaining

This a tricky one. People complain because something is broken, or doesn’t work as they expect it to. The traditional response to this in the free software world is “Patches Welcome.” This is shorthand for “Fix it yourself and stop bugging me.”

The trick here is to recognize that people usually take the trouble to complain because they want it to work and they’re looking for help. This passion to just make things work can often be harnessed into contributions to the project, if these people are treated with patience and respect.

Patience, because they’re already frustrated, and responding with frustration or defensiveness is just going to make them angry.

Respect, because they are trying to solve an actual real world problem, and they’re not just there to hassle you.

It’s important that you fix their problem. Or at least, try to move them towards that solution.

Once the problem is addressed, ask them to stay. Ask them to write about their situation, and the fix to it. Ask them to stick around and answer other questions, since they have demonstrated that they care about the project, at least to the point of getting it working.

When people complain about your project, you also have a great opportunity to brush them off and persuade them that you are uncaring and unwelcoming, which they will then go tell all of their friends and Twitter followers. This can be a very expensive thing to do, for your community. Don’t do that.

When people come to #rdo on Freenode IRC to ask their RDO and OpenStack questions, I frequently (usually) don’t know the answer myself, but I try to make an effort to connect them with the people that do know the answer. Fortunately, we have an awesome community, and once you bring a question to the attention of the right person, they will usually see it through to the right solution.

Retaining community contributors

Stormy, at OpenSource.com, recently asked the question “What are 10 steps to keeping new contributors once you have their attention”

I’m not sure I have 10, but here’s what I’d say:

Celebrate their contribution, loudly and publicly

People like to be noticed, and they like to be thanked. Tell them that you noticed their contribution by telling the whole world about what they did.

There’s a number of ways to do this, from tweeting every first contribution, to including a Thanks section in your monthly newsletter, to doing a weekly blog post that lists new contributors for that week. Whichever approach you take, make sure that you personally send them a message telling them about it, rather than just hoping that they notice it.

If you have very few new contributors every week/month, then take the time to describe what the new contributor did. If you have dozens every time, this can be more of a challenge, but sending them a personal note is still a very critical part of the process if you want them to stick around.

Give them the keys

A lot of people in open source think that everyone should have to earn their place on the contributor list, by consistent, high-quality contributions over a long period of time.

I’m at the other end of the spectrum. I think you should hand out committer rights like candy. If someone shows initiative and contributes once, give them the opportunity to contribute again, immediately, with no barrier to entry.

What’s the worst that can happen? You have to revert a patch. This is why you have revision control.

So, give them the keys on day one. But there’s a caveat here, which is the next item on my list:

Give constructive criticism

Nobody likes a patronizing pat on the head. Give constructive feedback. After thanking them, tell them patiently and kindly what they can improve. This shows that you consider them to be a contributor to a serious project, and not merely a statistic to report to your boss.

If you have a style guide, and they didn’t live up to it, point them to it, gently and kindly, and give them specific pointers on what they need to improve.

Don’t be one of those jerks that throws it back in their face with a nasty remark. That will guarantee that they won’t come back. Remember that your goal is to retain new contributors, and train them up in the way that your project operates, not merely to act as a filter to keep out unfavorable contributions.

Ask them to do it again, with a specific request

People like to be asked. Asking someone, personally, to do a particular task, is much more effective than a shotgun “Hey, can someone …” sent out to an anonymous faceless mob on a mailing list.

Once someone has contributed something, that’s your opportunity to say, “Hey, I notice that you have some interest in the WhizBang feature, and Ticket 31245 is about that, too. Maybe you could take a look?”

Ask them to write about it

The new contributor experience is a rare and valuable thing. You don’t know what it’s like any more. You remember bits of it, but mostly you’ve forgotten, and become jaded with your second, third, and 700th contribution.

Encourage this new contributor to write about their experience. What was too hard. What was fun. What was unexpected, frightening, exciting. Who helped them. Who got in their way.

These are hugely valuable data points for your project. And they are also a great way to tell this new contributor that their input is valuable, and that you’re trying to make your project more welcoming.

And, of course, once they have written about it, share it with the developer community, along with the name of the contributor, and say, here are some ways maybe we can make this better for the next person.

Point them to the documentation

You have docs, and then you have hidden docs, and then you have the stuff that “everybody knows”. Steer this new contributor to the docs, and take the opportunity to turn the other two categories into actual docs.

Some of this will come out of the blog posts that these new contributors write. Some you will need to write yourself, based on their feedback of the new contributor experience.

This is tedious, but, remember, you’re making an investment in the next time. The better you make this process, the easier it will be for the next person, and the sooner you can pass this part of the job on to someone else.

Ask them to mentor the next new contributor

Ask them to turn that first-timer experience into mentoring another first-timer, as soon as possible. They’ll have the recent experience. They’ll know the potholes that you have long since learned to steer around. They’ll know which people in the community are helpful, and which ones are jerks, who you’ve long ago dismissed as “Oh, that’s just how Larry is.”