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?

How “I am Groot” defines a community manager’s role

I was watching Guardians of the Galaxy, Part 2 and I realized that while baby Groot was making me laugh, it was Rocket that I understood. Rocket is an interpreter. He might even be a community manager.

In Guardians of the Galaxy, there’s a character called Groot. And the only thing he ever says is “I am Groot.” After a few instances, it becomes clear that he is saying a lot with each “I am Groot.”

This becomes particularly clear in Guardians of the Galaxy, Part 2. Every time Baby Groot says “I am Groot,” Rocket either responds to him or tells the rest of the group what Baby Groot just said.

For example, in the scene below, Baby Groot knocks over an alien and then says “I am Groot” and Rocket responds “They were not looking at you funny.” In that moment, we realize that Baby Groot is obviously saying something that we don’t understand.

Community managers are often interpreters just like Rocket is. Community managers often can hear both sides of a discussion and they realize what someone is trying to say that is not being heard by others. They hear “I am Groot” and realize the person is saying “If we do it this way, then we’ll get more contributors.” or “If you do it that way, you’re forgetting about that risk I mentioned before.” They are interpreters. Or at least people that can recognize that something is getting lost in translation.

Good community managers make sure people are heard correctly and lead us to realize that we are missing some thing. That way we all learn to listen more carefully leading to better communities.

Originally published on Medium.

It’s true: because you can travel, you have to

I once sat on an airplane for 20+ hours in order to spend a day in Italy. I spent the whole trip wondering why we had to meet in person when we have all this technology like video calls, email, irc. While having my surreal foreign driving experience where a gazillion lanes merged into a few and all the signs were in Italian, I tried not to let my jet lagged brain wander and I wondered what I was doing.

Why, when we have so much technology, do we have to travel so much to work together?

MDN Hackfest, March 2015

And the secret is to flip the question around. It’s because we have all this technology that we have to travel. Because we can communicate and work with anyone around the world, we do. And when you work with people, you need to meet them. You don’t need to see them every day, but you need to understand how they talk, how they hold themselves, what’s important to them, what makes them raise their voice in excitement. Once you meet them, you’ll read all their emails differently. You’ll get what they are trying to say in that pull request so much faster. You’ll be a team.

Once you’ve met them, had a beer with them and learned that they too have a five year old kid, you’ll be more likely to be willing to get up at 6:30am for a meeting with them. You’ll be more likely to tell them you think something’s wrong with their idea and believe that they’ll really listen to you. You’ll be more likely to ask them for help. Because of how the human brain works, you’ll be more likely to remember them in another conversation where something they are working on will go together wonderfully with the idea a new friend is talking about.

Meeting in person is key to working well together. Technology lets us work with more people in more places and so now we travel further to meet each other.

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.

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?

8 ways companies have influenced open source software

A decade ago, I researched and gave a talk called Would you do it again for free? If you worked on an open source software project for free, and a company started paying you to work on it, if they stopped paying you, would you stop working on it? At the time it was a valid question as many of my friends were starting to get paid positions doing their dream job. In case you are curious, the answer is “it depends”. Most people will stop working on that particular project but most will go on to work on other open source software projects. You can watch versions of the talks and see links to the research studies I found.

My new question is how have c0mpanies influenced open source software over the past decade? They’ve influenced open source software in many ways from career opportunities to support to licensing to barriers to entry. Let’s take a look at 8 ways companies have changed open source software.

Careers

They have provided paid positions and enabled people to pursue their passions for 40+ hours/week. While most open source software advocates believe that full time jobs working on open source software is awesome, many also worry that company’s priorities now greatly influence projects through the maintainers they pay.

Making it possible for open community participation to be part of a job, rather than necessarily being a personal lifestyle choice — Nick Coghlan ‏@ncoghlan_dev

It’s worth noting that, in addition to salaries, companies also provide much better research into what paying users want as well as roles such as UX and product marketing — they provide a complete software ecosystem as we discuss below.

While many open source software developers make a living working on open source software, most projects could still use many additional paid staff. Nadia Eghbal in her research funded by the Ford Foundation argues that we do not pay enough of the open source software maintainers.

Barrier to entry

Companies have changed the barriers to entry. In some cases it’s harder — for example, committers, especially product owners, are expected to work full time on projects.

an increase in # of new open source devs with no community experience, an acceptance of a high bar to get started… — Dave Neary ‏@nearyd

Without a paid position, it is hard to keep up with expectations and grow and support a community. In other cases, companies have made it easier for a more diverse group of people to join open source software projects by hiring people unfamiliar with the project and giving them time and training to get started.

Increased diversity

When companies hire people to work on open source software, they often hire from the greater pool of software developers and provide training and support for them. While the worldwide pool of software developers is not representative of our world’s diverse population, this paid training and assignment has increased the diversity of open source software projects. Anecdotally, I know many woman who were first introduced to open source software through a paid position.

Working styles

Companies bring new working styles to the projects that they get involved with. Some of these styles are probably more positively accepted than others. For example, when companies become involved with open source software projects, meetings and phone conferences become more prevalent. Conferences transition from weekends to work weeks.

Conferences happen midweek instead of on weekends, the assumption that leaders have 40h to spend on project… — Dave Neary ‏@nearyd

I also believe companies introduced concepts like agile, pair programming and six week training “dojos” such as the ones Cloud Foundry has. In order to become a committer, a Cloud Foundry contributor attends a 6 week dojo in person where they are partnered with experienced committers. Cloud Foundry does all of its coding in pairs. Work is assigned to pairs by a project manager.

Rights

Companies have shifted the predominate licensing methods from copyleft to more permissive licensing. And while they’ve cleaned up much of the copyright assignments, they’ve also often introduced controversial committer licensing agreements, CLA’s.

it has widened the governance models, with mixed results, CAs held by corporations is a controversial development — Alberto Ruiz ‏@acruiz

Complete software ecosystem

Companies have brought new knowledge and skill sets to open source software such as UX designers, product managers, market research and product marketing. Open source software on its own has not attracted many volunteer into these roles.

Loss of a unifying enemy

Much of the energy behind some of the early open source software projects seemed to center around an anti-corporate sentiment and in particular, an anti-Microsoft sentiment.

Loss of sw corporations as a enemies of freedom has led to loss of cohesiveness as a group. — Alberto Ruiz ‏@acruiz

As more open source software contributors receive paychecks from these corporations, and as more corporations support open source software, this anti-corporate sentiment is fading.

Support

As Nadia Eghbal describes in her research for the Ford Foundation, many open source software projects are not able to provide support for their projects. Often well established projects are maintained by a few individuals who are not full time on the project. Heartbleed is one of the most famous, recent examples of how this can be an issue. Heartbleed was a bug discovered in the OpenSSL project. A project used by most of the world and at that time supported by one paid staff member. The Linux Foundation stepped in and raised money from companies and used their existing infrastructure to provide support to four paid committers.

Apache, Eclipse, Linux: Companies giving up control to #FOSS #Foundations and allowing open governance to work. — Shane Curcuru ‏@shanecurcuru

Support for open source software projects varies from, a company paying the salary of a maintainer or two to a non-profit organization dedicated to the project to non-profit organization that collect funding from multiple sources to support multiple projects.

For better or worse, I would say community vs. commercial versions. Also paid support as desired by corp/govt users. — Tony Wasserman ‏@twasserman

Summary

Open source software has become a predominate software methodology and companies have become more and more involved in open source software projects. They have supported and changed the way those projects work. They provide salaries to committers, support to users, change software methodology styles, complete the ecosystem with market research and UX designers, change barriers to entry and increase diversity.

How else have you seen companies influencing open source software projects?

Originally published on Medium.

Our World Depends on Unseen Labor: Open Source Software

Our digital infrastructure is all open source. It’s built and maintained by a relatively small community of open source software developers. Right now the open source software work is funded by a variety of methods: volunteer time, nonprofit corporations and donations of time and money by a few corporations. Is that sustainable? Or should we be looking for ways to fund our digital infrastructure much like we do our roads and bridges through government or community efforts? This is the question that Nadia Eghbal poses in her very comprehensive paper covering her research funded by the Ford Foundation.

About a year ago, at the recommendation of a friend, I met with Nadia Eghbal. Diane Tate introduced her as someone “who recently left her role in venture capital to explore ways to support developers working on early infrastructure projects.” We had a fascinating conversation. Nadia was trying to expand the venture capital world and when she went looking for projects that venture capital doesn’t fund but that really need funding, she found the world of open source. In particular, she found that the infrastructure behind most of our current technology is based on open source software maintained by a small community of developers. Some of them work for nonprofits that pay their salary (like the Linux Foundation now sponsors OpenSSL), others have corporate patrons who pay the salary of maintainers who work on projects they use (like HPE and Google) and others are completely volunteer based.

Nadia believes that our policy makers, grantmakers and activists are unaware of the role that open source software plays and, when they have heard of it, they erroneously believe that it’s well funded. As an example, the IRS is no longer granting 501(c)(3) status to organizations that primarily produce open source software with the argument that software is not a public good and they can’t guarantee that people won’t profit from it.

Nadia’s report, funded by the Ford Foundation, is a great read. I highly recommend it to anyone interested in learning more about open source software, how it works and how it’s funded. Warning: it is very long! Think about it more as a short book than a blog post!

Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure

The code review culture kills new ideas

First published on Medium.

Many open source organizations start around code. Someone has an idea and they write some code to express it. If people like the idea, they add more code. That code gets reviewed and incorporated.

This works great while the project rallies around the original idea. However,when they go to add new products or plan new features, the culture of code reviews gets in the way of a culture of new ideas.

Why’s that? Because code reviews look for flaws. You need to make sure you don’t introduce bugs. Ideas, on the other hand, need a whole team of input before they are strong enough for the risk analysis. New ideas get stronger when people add to them, figure out ways they can help. Once ideas become a plan they need something like a code review but not before they become a plan.

Reviewing Code is about Eliminating Risk

When new code is submitted, it’s always reviewed before it’s accepted. And often there are very clear guidelines. You are reviewing to make sure that your project’s guidelines are met, that the code is well written and that it introduces no new bugs. Often this means you are looking for things that are wrong. You may also suggest improvements, but the focus is on looking for things that are wrong.

Reviewing Ideas is about Exploring Opportunity

When new ideas are reviewed, they are often not fully formed. Ideas, especially new product ideas, need the entire organization to help figure out the full potential, what each team could bring to the table and how people might react to it. New ideas need to be fully developed before you start poking holes in them. And new ideas cannot be fully developed by one person. They need a whole team of people to say, “yeah, that’s great, and I could help by linking it to this other thing I’m working on” or “yeah, I like that and it makes me wonder if we did this, if that would be even better.”

What happens when you apply code review techniques to ideas?

When you apply code review techniques to ideas, you kill them before they are fully developed. You look for everything that is wrong in an idea. You look for all the risks, all the holes, before you add your strengths to it. Just when the idea needs you to help figure out how it could succeed, you poke a hole in it.

Next time you see someone in your organization propose an idea, make your first reaction an additive action. Challenge yourself to make the idea even better instead of looking for the bugs.

What’s in a good developer relations plan?

Developer relations is the combination of activities, programs and tactics to get developers using or developing for your organization’s product or ecosystem. The goal of a good developer relations team is often to make your organization’s product or ecosystem the first choice for developers. (You may be doing this just to sell more of your product or you may be doing this because you believe your product’s mission helps make the world a better place. You are still trying to get more developers using your product.)

What’s the goal of a good developer relations plan?

Your developer relations plan needs a goal that you can focus on. You need to be able to measure the results of your activities so that you know what you should do more of and what you can do less of.

Some potential goals for a good developer relations plan might include: (Some of these by Patrick Chanezon.)

  • Increasing the adoption of your organization’s product. Example: more people using Firefox.
  • Increasing the number of available complementary goods. Example: more 12 factor apps running on Cloud Foundry.
  • Providing an opportunity for developers to profit. Example: an app store for developers to list their applications.
  • Growing the number of people that benefit. Example: training companies, consultants, app providers.
  • Reducing the cost and risk of using your product.
  • Increasing the percentage of developers that are developing only or mostly for your product.
  • Increasing the network effects in your ecosystem.
  • Decreasing the cost of adopting your platform or increasing the cost of leaving your platform.
  • Creating an environment where developers just assume they’ll use your platform.
  • Encouraging third party tools, trainers and consultants for your platform.
  • Creating a community of volunteer advocates.

Some developer relations groups also act against the competition. I don’t think that’s a long term strategy. Your product and ecosystem have to be good.

What are the stages of a developer relations audience?

Screenshot 2015-08-13 15.04.58

You can move from one stage to the other using many different techniques. Breaking down the stages a bit further, you can map how specific evangelism activities like blogging or talking, might take you from one to the other.

2015-08-13 15.13.55

Who should you have on your developer relations team?

While we usually talk about developer relations as teams, we also need to look at their functions. While each team has a primary function, functions are often shared between teams. Mozilla has outreach and content teams. Google is also organized this way, as presented in a talk by Patrick Chanezon.

  • Outreach. Creating awareness of the product or ecosystem among developers. Most outreach efforts include evangelists. These are people that go out and speak, engage with others, teach enough to get people started, write blog posts, let large numbers of people involved. They are typically most involved in the outreach and awareness part of the program.
  • Content. This includes tutorials, documentation and examples. Making sure that developers that are interested in the platform have the materials they need to learn it. This team should include technical writers, educational experts and programmers. These are the people that are most involved in the online training part of your program. They write documentation that lets people learn how to use the technology. Sometimes they write the examples. Sometimes they create training or online tutorials.
  • Support. When developers start using your product, they will need people to help answer their technical questions or help resolve the bugs they find. This team usually consists of support engineers. They are around to answer questions, help people get going, create code examples. Often when bootstrapping, this function comes from the evangelists but it’s really a different type of personality and role. This team is most likely to provide valuable feedback to the product teams.

There’s another couple of roles worth calling out.

  • Program managers. A successful developer relations program often relies on programs. These might be things like a world wide community run, simultaneous events or a “free phones for apps” program.
  • Key stories/participants/case studies. These are people that have a story that successfully highlight what you are trying to do. And, while they might not be evangelists, they are competent spokespeople. You talk about them, point people at them, highlight them, enable them to tell their story and help them spread it.
  • Event managers/coordinators. Smaller groups might have several volunteers. Larger organizations might have lots of volunteer meetup or hackathon organizers and maybe even a paid staff team to support them.
  • Community management. Whether or not you have an official community manager, there are probably numerous people helping out with “community management” whether it’s onboarding new contributors, reviewing patches or answering questions on the mailing list.

What are the key components? What types of tools and projects are useful?

It’s useful to first look at your project’s strengths. Do you have a large community? Strong contributors? A highly followed blog? A strong culture of global meetups? A clear brand?

Some of the projects and tools you might consider are:

  • Programs that support your goals. For example, Mozilla ran Phones for Apps.
  • Messages/materials. Developer relations can either include product marketing and press or work closely with those teams to develop messaging and materials that support the goals and the audience.
  • Events. Events can include everything from monthly meetups to hackfests to large annual conferences. Many teams often divide events into the organization’s events, sponsoring others events and sending speakers to events.
  • Training. As people join your ecosystem or start using your product, they are more likely to stay if they can get the training they want. Cloud Foundry has “dojos” – a place at several member organizations where interested developers can go train with a more experienced member for six weeks.
  • Examples. A key component of learning is being able to see how something is done and copy it. At Mozilla we created Demo Studio to allow people to share and build on others work on the web.
  • Documentation. Documentation is key to a project for two key reasons. One is discoverability and the other is learning and support.
  • Contributors. Depending on the type of product or organization you are supporting, you may want programs in place to specifically support contributors. This may be as simple as swag or as involved as official titles and budget for programs and travel for them.
  • Feedback mechanisms. An important part of many developer relations teams is providing feedback mechanisms for users to give feedback to the product teams. It helps to put into place objective tools and mechanisms for this.
  • QA forums. Question and answer forums like StackOverflow have become critical to how developers expect to find help when they are working. Having a standard place where your experts will be will help.
  • Membership. Often membership can support the different groups you want to grow. You can have users groups, contributor groups, advocacy. You can use titles, mailing list membership, swag and travel funds to distinguish and reward them.
  • Discussion. A place where people can come and chat and “hang out” with your community is important. Q&A forums often give them answers but not a sense of belonging. Also discussion groups are often an easier way for really new users to get started.
  • Advocates. Recognize our key advocates and give them a megaphone. Connect them with the press and speaking opportunities.

What does your Developer Relations plan and group look like? What would you add to create your ideal plan?

What labels are applied to you every day?

When you hear that a 13 year old, black girl is giving a keynote at OSCON, what do you think?

  1. Wow, she must be a child prodigy, what did she do?
  2. Who are her parents?
  3. She got that keynote because she’s a 13 year old, black, girl.

I’ve heard all three options and a few in between.

The truth is that Keila Banks is pretty awesome. She’s an accomplished blogger/technologist and her 10 minute keynote (to a 4,000 person audience!), “The Undefinable Me”, is well worth watching.

And Keila’s parents are pretty awesome too. They have given Keila lots of support and encouragement as she explores the opportunities around her. They are as inspirational to me as a parent as Keila is.