Tag: community

Posted on

Why People Don’t Contribute to Your Open Source Project

I just listened to Mike McQuaid‘s FOSDEM talk, Why People Don’t Contribute to Your Open Source Project.  If you are interested in communities and how they grow, I highly recommend you take a half hour and watch it.

Some of the things I got from the talk:

  • I get asked a lot what the difference between a contributor and a maintainer is. Mike does a great job of explaining it around minute 4:00. Contributors are people who write code or docs or do triage for your project but who need help from others to get their work included. Maintainers are people that review and merge contributions.
  • You should users as your source for contributors. The type of contributor that is not a user is not likely someone you want.
  • Once maintainers are not users, they are not likely to continue contributing. So if you stop using your project, you need to start recruiting someone else to maintain it because it’s unlikely that you’ll continue to maintain it.
  • Most maintainers are talked into it. Nobody thinks they are qualified at first.

I did wonder what Mike would think about open source software projects where most of the contributors are people paid by a company to work on it. There are projects that are unlikely to be used by individuals, that are primarily supported by paid contributors. Do the same rules apply?

Posted on

3 important things to consider when measuring your success

Photo by Thomas Leuthard.
  1. Figure out what to measure. How will you know if your open source software project is wildly successful? What will be different with the world? What problem will it have solved? If you don’t know the answers to these questions, you won’t know what to measure.
    Often when projects start out, they measure what ever is possible. For example, you start a blog and you measure web site visitors. But that in itself is not a measure of success. It might be a measure of popularity or reach, but not of success. Why’d you start the blog? Maybe you want people to know Linux is an awesome operating systems. In that case, a measure of success might be how many people use Linux. Or how many people try Linux after reading your blog. Or how many repeat visitors are now on Linux instead of an alternative operating system. Obviously, some of these things are harder to measure than others. But defaulting to number of visitors is a crutch you should only use temporarily while you figure out better metrics.
  2. Change your metrics over time. What you measure will also change over time. As your project evolves, you’ll be able to measure more sophisticated things that more accurately reflect your goal. You might start out measuring number of visitors and evolve into number of people who convert within a month of visiting your blog. Both the way you can measure things and what your project can do might change. And your goals themselves might change. Maybe you started out to create a login widget and then realized what was really needed was a user management tool. You should never be afraid to change your metrics. If you are afraid of losing data over time, you can keep measuring the old metrics.
  3. Keep it simple. It’s much better to have one or two key metrics than to worry about all the possible metrics. You can capture all the possible metrics, but as a project, you should focus on moving one. It’s also better to have a simple metric that correlates directly to something in the real world than a metric that is a complicated formula or ration between multiple things. As project members make decisions, you want them to be able to intuitively feel whether or not it will affect the project’s key metric in the right direction.

And then, make sure your metrics are working. Double check that when you are closer to your goal when your metrics get better. If not, time to figure out what else you could measure. For example, maybe you were measuring number of contributors, but signing up more contributors does not seem to be getting you closer to your goal. You might want to look at measuring monthly contributions or active contributors.

If I was going to recommend one book for getting started in thinking about metrics, it would be Lean Analytics. Thanks to Luke Crouch for the recommendation and the many good conversations.

Posted on

Can your community get too big?

Open source software communities, like companies and cities, can come in all sizes. They don’t get too big but they can grow faster than their infrastructure and processes.

Take for comparison, the size of companies and cities. Companies come in sizes from one person LLCs to 100,000 employee megaliths. Cities come in sizes from a single person farm to enormous cities with 10’s of millions. Are some big companies too big for some people? Absolutely. Are big companies good at getting certain types of tasks done? Yes. Some people prefer some companies and small towns (maybe not the same set of people) and some people prefer big cities and large companies (again, maybe not the same set of people.)

So, can open source software communities get too big? Not really. But they can grow too fast. They can grow faster than their infrastructure; they can outgrow their governance; they can leave their mission behind.

So how can a community grow productively? By considering things like:

  • Onboarding processes. I’ve actually heard of communities having so many new people show up that to answer all their questions would have meant nobody would have time to get work done!
  • Infrastructure that scales. Where are you going to put all those new people? Will your source code control system, your chat system, and your blogging system scale?
  • Governance. As you have more people involved, you may want different ways of deciding membership and making decisions. OSI moved to individual membership from a self elected board. Gluster is moving to a new maintainer model as it grows. The evolution of process takes time and thought.
  • Mission statements that evolve. Sometimes you accomplish your original mission and you’ve moved on to something else and you need to state that for new and existing contributors like Fedora is doing now.

What else needs to grow along with your community?

Part of the OSS Communities series — maintaining existing community. Contribute your stories and tag them on Twitter with #osscommunities to be included.

Posted on

10 Ways Community Managers Make Sure Projects are Healthy

Community managers must make sure their projects are healthy. Before they can help foster and grow a community, they have to make sure it’s a well functioning, welcoming place.

Photo from the Library of Congress.

While community managers and project leaders often don’t explicitly talk about what’s not working well, you will often find them doing a wide variety of things. They are doing whatever is needed — filling in the gaps — to make their project work well so that new people can join.

Here are some of the things that an open source software project needs in order to be healthy and grow community.

  1. Getting Started. In order for new people to join, here has to be an easy way to get started using the project and an easy way to get started contributing. Usually 30 minutes is the maximum amount of time someone will try to install and use your product for the first time.
  2. Clear Goals. A project needs clear goals before its community can grow. New members need to know what problem the project is trying to solve and how they plan to do that. Without a clear vision and set of goals for the project, someone who hasn’t been involved with the project won’t know what contributions might be welcomed.
  3. Target Audience/Market. As part of its vision and goals, a project needs to know who it’s for. Is it for enterprise software developers or elementary school kids?
  4. Project Lead. The project lead can be a single person (like Linus Torvalds) or it can be a small group of people (like Samba) or it can be a group of people (like Apache) but it really helps the project identity, the decision making process and the goal setting to have leadership.
  5. Release Management. Every project produces something and there needs to be a way that “something” gets produced and published for people to use. And a place where people know to find the latest version.
  6. Project Infrastructure. Every project needs some amount of infrastructure. Most projects need source code control, bug tracking and mailing lists. They also probably need a website, a place to publish documentation and a way to manage finances.
  7. Roadmap. Sometimes a project’s roadmap is simply a backlog of issues. Sometimes it’s a Trello board. Sometimes it’s a detailed 2 year roadmap. Whatever form it takes and however much detail it has, it’s important to the project to know what’s next.
  8. Governance. A well-defined project has clear processes for how decisions are made and who gets to make them. Some projects have well developed governance processes. Others have light weight, undocumented processes. But without some sort of governance, the project is likely to stall often.
  9. Advocates. In order for a project to grow, someone must be talking about it. These advocates may be users or contributors. They may be spreading the word on the internet or at in person events.
  10. Events & Outreach. More advanced projects will start to participate with a talk or a table at existing events and may even start to hold their own events.

If any of the above things is not working, it will be hard for a project to attract new users. A good community manager or project lead will focus on making the project run well first before inviting new people to join.

Posted on

3 ways open source software communities could learn from Crossfit

Photo by Anthony Topper.

This week I am participating in the opensource.com community blogging challenge: Encouraging New Contributors!

Crossfit gyms are great at creating community and welcoming new members. Here are 3 things that Crossfit boxes do that open source software communities could also do to encourage new contributors:

  1. Say hi to the new person. I drop in at gyms around the world, and no matter where I go, everyone in the class comes up to say hi to me and introduce themselves. How awesome is it that I can go to a gym in Frankfurt and have 10 total strangers walk up and introduce themselves and say how happy they are that I’ve joined them?
    For open source: When you see a new person on your mailing list or IRC channel, stop and say hi. Introduce yourself and tell them they are welcome. You can do it publicly or privately. (If you do it publicly, you might set a good example for others!)
  2. Celebrate daily accomplishments. When we finish a workout at my Crossfit gym, we all post our scores in an app. It gets ordered from best to worst but no matter where you are in the line up, everyone will  give you a virtual fistbump and most of them will notice when you’ve had a spectacular work out based on your skill level and they’ll congratulate you for it.
    For open source: Have a place where people can note what they’ve done, maybe point out what they are proud of or what was hard for them, and get kudos from others. Sometimes this happens on source code control systems. Sometimes on IRC. I think most open source software projects could do better at this.
  3. Allow for off topic interactions. To really build community, you have to know each other. Sometimes that’s hard to do if you just focus on the work all the time. There has to be a place to chat, to share goals, ideas and maybe every once in a while, a non-project focused thing. In my Crossfit box, we do this in a Facebook group. Usually, it’s fitness related but sometimes it’s just chatting about life in general. The group gets noisy and I turned off notifications, but I still visit at least once a day to congratulate, commiserate and just visit. It’s a place new members can ask questions, learn more about the community and get to know each other.
    In open source communities: Find a channel where people can chat. A place where they can ask all their questions, express frustration over a piece of code or complain about the weather. Sometimes it’ll get noisy but usually it will bring people together and, more importantly for the new people, help them “see” the community they are joining. Most open source software projects do this on irc or Slack.

How do you think open source software communities can Encourage New Contributors? What have you learned from the other communities in your life?

Posted on

“Modern society has perfected the art of making people not feel necessary.”

While I don’t agree with everything Sebastian Junger writes in Tribe: On Homecoming and Belonging, I love the way he manages to articulate some things that I’ve noticed but never been able to describe.

Just last weekend I was camping, and we had this torrential rain storm. People rushing to get their boats off the water were hurrying so much that they lost their boats off the trailers. Rain came down so hard and quick, it broke tent poles and tents literally floated away. People had to dig trenches to get water out of their campsites. And it was fun. Granted, my sleeping spot was completely dry, so I speak from a position of privilege. But everybody getting together to help make sure people were ok, finding ways to keep important things dry, finding dry places for people to sleep and ways to feed everyone, that was fun. There was a real feel of community. Of adventure. Of responsibility.

When I tell people it was fun, they give me this look and then I end up back peddling, trying to describe what I mean. Sebastian Junger describes it well. He talks about how social bonds are reinforced during disasters and “that people overwhelmingly devoted their energies toward the good of the community rather than just themselves”. Social differences and economic inequalities are temporarily irrelevant, at least until outside aid comes in.

Communities that have been devastated by natural or man-made disasters almost never lapse into chaos and disorder; if anything, they become more just, more egalitarian, and more deliberately fair to individuals. — Sebastian Junger

The same thing happens to our veterans. They join a community that’s closely knit, that trains, sleeps and eats together. They are placed in high stress combat situations where they work together regardless of background or previous social differences. Where they all have a job, they are all needed and they all work together. Ask a veteran you know about their “team”, about the people that served with them. Most of them have told me they’ll never be that close to any other group of people in their lives.

Then we bring them home. To this super loose knit society. One where not many of us are needed beyond our immediate family. One where our purpose in life, our job, is not often clear. Or doesn’t feel like our job fits into a higher purpose. As Junger says, “part of the trauma of war seems to be giving it up.”

We all need to feel like we are part of a tribe. We need to feel connected to other people and we need to feel like our work is meaningful, that it helps others.

Just yesterday I read an article in the New York Times that theorizes that we can get teenagers to eat healthier by getting them to contribute to a cause as a community: “as students work together towards a shared purpose, the impulse to resist authority fades.”

So is modern society broken? Does it make people feel unnecessary? What tribes do you belong to? During what moments do you feel most useful and connected? What moments make you feel like your life has the most purpose?

I am also doing a series of 22 pushups for 22 days to raise awareness for veteran suicides.