Tag: maintainers

Posted on

Be Clear About How Things Work (How Open Source Can Work with Companies)

This post is one of a series of posts about what open source software projects can do (if they wish to) to make it easier for companies to participate in their projects.

When a company wants to get involved in an open source software, often they need some help understanding how things work. Sometimes it’s the developer who wants to contribute that has questions. Sometimes it’s their management who wants to understand what type of commitment they are making and what they can expect.

An open source software project can make it easier for a corporate contributor to participate by being clear about:

  • What the release process and schedule looks like.
  • How long it takes for a PR to be reviewed and how to best position it for acceptance.
  • Who makes decisions and how.
  • What roles people in the project play and how they get to those roles.
  • Where and how to ask questions.
  • Who is working on the project and what their motivations are. (Is this software to make apps run faster on watches or is it to make apps run on car computers?)
  • How to find out and stay informed of security issues.

As an open source software maintainer, the more you can help organizations understand how you work and how to work effectively with you, the more likely they are to engage.

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?