26

I run a project with a decently-sized userbase - a couple of hundred people, perhaps. It's regularly used by all users, and I've made it clear who developed it, where it can be found, and that it's free software.

However, I'm currently the only developer and contributor. With the exception of some small amounts of documentation, nobody has made any pull requests to the project.

I've got other things to do as well, and I can't spend all my time working on this one project. I need other people to pitch in.

Given a sizeable, active userbase, how can I encourage users to contribute to my project?

6
  • 9
    Does your taget audience even have the necessary skills to contribute to development in a meaningful way?
    – Philipp
    Aug 7, 2015 at 10:25
  • @Philipp In this case yes, though I'd be saying assume they do in any case.
    – ArtOfCode
    Aug 7, 2015 at 10:31
  • @Philipp on that note, development is but one of many ways to contribute, and often not the most important. Bug reports, feature requests, advocacy, documentation, feedback, management, communication, translation... all require different skills, of various degrees. Aug 7, 2015 at 14:20
  • 4
    a very minor suggestion: on any error messages you have in your application, you might drop a request for help there: "Oops! Something went wrong. If you'd like to help fix this, file an issue on our website/github or submit a pull request!". Aug 7, 2015 at 19:03
  • 1
    I'm afraid "a couple hundred people" is a very small number if you want to convert them to volunteer developers… (or paid users anyway, which I know it isn't what you asked, but the answer is the same)
    – o0'.
    Aug 8, 2015 at 15:32

6 Answers 6

24
  1. Make it clear that you want contributions.
  2. Make it easy.

I would start by putting a friendly note in your project's ReadMe file.

This project is looking for contributors. If you have a feature you'd like to see implemented or a bug you'd liked fixed, the best and fastest way to make that happen is to implement it and submit it back upstream for consideration. All contributions will be given thorough consideration.

Or something like that.

Next, reach out to your users on your mailing list, forum, and social media letting them know that the project needs more developers. Seriously, I can't tell you how far a Twitter account and a few well placed hashtags can go into generating interest. Also, blog about your development on the project if possible. Anything you can do to get your project in front of even more users is a good thing, particularly if those users are also developers.

However, even if you get some interest that way, it won't matter unless you make it easy as pie to help out.

  • Write clean and understandable code. If people can't understand your code, they can't change or add to it.
  • Document the build process thoroughly.
  • Make sure that the project builds "out of the box" when cloned onto a clean machine. If people struggle with getting it to build, they'll quickly move on and just write off trying to help out.
  • Add a Contributing file to the repo detailing the project standards and workflow. This goes a long way to reducing the frustrating back and forth that can happen during a pull request.
  • If you're able, add [up-for-grabs] and [easy-fix] labels to issues that someone new could easily tackle. This gives people a place to start.
  • Be available for real time chat to help new contributors get started. There are often a lot of questions when new contributors get started. Real time chat is the best way to help them get on their feet.
  • Reduce your standards. Don't really reduce your standards, but go ahead and accept that patch that isn't quite up to par. You can always go ahead and take a few minutes to clean it up after the fact.
  • Write unit tests. It can be hard to tell if you broke anything while making a change to someone else's code. Provide the tests to make it easy to make sure everything is still working correctly post change.
2
  • I'm sure I'll think of more. I'll add to this as I think of them.
    – RubberDuck
    Aug 7, 2015 at 10:17
  • Sorry, when I started typing my answer, yours was not there yet. I did not mean to add another answer right after your already really good one. :-)
    – Soong
    Aug 7, 2015 at 10:25
15

To me, this question is very similar to how do I attract customers to my business? except instead of cash, you want contributions. Successful salespeople deeply understand their customers' needs and tailor their services to address those needs. It's a very powerful method: put yourself in your potential contributors' shoes, and ask what's stopping you. Many things will become obvious in this light.

Keep the lights on

I find the most common reason people don't contribute is simple: no one's home (or it seems so). How can contributions happen if there's no one at the other end receiving it?

Show activity if you have any. For projects I care about, I love reading developer logs and other related blog posts. It shows that there are people also passionate about the project, that I can talk to. Talk about what you're working on now, not what you've shipped a month ago. This is important for potential contributors, and is an unnatural skill for most developers, since they may have been burned by over-promising in the past. One of the biggest obstacles for new contributors is not knowing where to start. Well, here's one way you can not only give people a glimpse of the inner workings of the project, but also where they can contribute.

How you show off your activity will depend on your target audience and what you can bother with. The most obvious is having a website. GitHub for example provides free light-weight web hosting and blogging, but there are many others. You could also use social media like Facebook, Twitter, IRC, mailing lists, web forums...

But if you're not actively working on the project, it's not all bad. Provide easy ways for people to get in touch. If I find no one home but I still want to contribute, I'm going to touch base first instead of spending a week preparing a pull request. Have a public issue tracker. List an email address, or social media handles. Provide a comment section. Maybe forums or IRC where you hang out. Whatever it is, list it clearly and respond promptly. Few things put off potential contributors more than seeing unanswered bug reports from months ago!

One point worth making is that you should prefer open channels for communication. E.g. if appropriate, put it in the public issue tracker rather than private emails. This has many advantages: it shows activity (hey look, there are other people contributing), and it discourages cliquish behaviour once more contributors join (although that's a problem you wish you had). On occasion I've reposted IRC chats or emails on the issue tracker for these reasons.

Why do people work on free software projects?

This is not a trick question. Most people intuitively think the answer is "resume-padding", or to "write good code", and they are wrong. Instead:

We find in contrast, that enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver. We also find that user need, intellectual stimulation derived from writing code, and improving programming skills are top motivators for project participation.

-- Why hackers do what they do: Understanding motivation and effort in free/open source software projects, Lakhani, Karim R., and Wolf R.

For me to willingly contribute to someone else's project, I'd want to be able to work creatively on a problem I find interesting, challenging, or that addresses one of my needs (or my itch). The last thing I'd want to work on is an uninteresting, strictly-to-spec task to be judged by an opinionated or rude maintainer. After all, most people who do that get paid, in day-jobs!

When you're hungry for contributors, you need to put in extra effort to appear approachable, and once in contact make them feel welcome.

One of the best and often overlooked ways to do this is to show appreciation. Say thanks! It's the bare minimum you should do, for anyone who reaches out. "Thanks for your interest!" Treating users as potential contributors is a good attitude and start. If someone contributes a killer feature, the additional success of the project is reward enough, but that rarely happens. I don't want my contribution to simply wither away in the commit logs. Yes, non-trivial code changes mean you have to add contributors' names in the copyright notices, but that's out-of-sight. Does your project have a "credits" or "acknowledgements" section? What about other communication channels? One of the best acknowledgements I've received for contributing features was being mentioned by name in a blog post, as an example. What this also does is it shows future contributors that they will be acknowledged.

But external motivation may work too. Not all projects have interesting and easy tasks to do, and you probably want to work on such tasks yourself, which is fair enough since the project is yours. But it does leave a backlog of interesting-but-hard, or simple-but-tedious tasks that no one wants to do, especially new contributors. I've wondered whether a bounty for such tasks can attract new contributors to an obscure project, and I'm happy to report that it does, at least in the one time I've tried it. It did take one month after the bounty post for anything to happen though, which leads to my final point...

Be patient

When a project is run by volunteers, things happen at an unpredictable pace. Motivation comes and goes, real life happens. Sometimes you'll be actively updating a project for months with no acknowledgement from the outside world, others you'll get a flurry of contributions on a project you've abandoned years ago - I've been there, on both ends. Be aware it's the nature of the beast, and most things just take time.

6

Generally speaking, finding contributors is very difficult. Benjamin Mako Hill described in a talk at Libreplanet that the median number of contributors to Free Software projects is 1.

That being said, it is a good idea to ease people into the process. Make it easy for users to file good bug reports, maybe by adding a reporting tool to your software. Then give them feedback on those bugs.

Let them make feature requests and have them participate in the community that way. Also make sure there is a good and easy to use way to exchange ideas.

Sometimes, newcomers who want to help find it easier to help write or update documentation or translate documentation and parts of your program.

Once you have people involved, translators who know a bit of code may be familiar enough with it that they start fixing small issues. From there, they may go even further and take on bigger responsibilities.

The key is with any of this is to keep the threshold as low as possible.

5

You could register your project at http://up-for-grabs.net/#/ as was suggested on Scott Hanselman's blog.

From their homepage:

We're looking for projects who can take the time out to help mentor developers as they get started with open source.

What sort of tasks are a good fit?

  • Tasks should take no longer than a few nights' worth of work
  • Tasks should stand alone - avoid core functionality on which other tasks depend
  • Tasks should be well described with pointers to help the implementer

We suggest the tag up-for-grabs but using a different name is also acceptable.

3

Talk to them. Learn about their workflow, use cases, needs. Ask them to write up what improvements would benefit them most. Ask them to enter them as feature requests. Ask them to compare various features requests and prioritize for you.

Engage everyone you can - ask for feedback, discuss the project, show enthusiasm, it's infectious.

2

People contribute to an opensource project because of either career or need. On the other side, a project get contribution when it has well known by its users and it welcomes contributors.

First timers

With the inspiration of firsttimersonly, I created many first timers friendly easy and small issues which can be solved in just 5 min effort. I spent 2-3 times more time to create an issue instead of implementing them. And then talking about it on twitter with @first_tmrs_only, and @yourfirstpr help to know people that you're welcoming the first time contributors. A badge, or quote on README is also helpful.

Users

Most of the contribution in any opensource project is done by it's users. And there are many reasons why a good project don't get many users.

  • chicken egg situation: Many good projects don't get much attention because they are new, have less popularity, less stars on github, people don't know if there is someone who is using this project etc.
  • Less activity : Authors who has less activity on a project, or overall github activities, a project which is not updated from a long time (more than an year or something), a project with less contributors, unattended long time pending issues (specially bugs) makes a project unreliable.
  • Documentation : Many good projects don't have easy to understand documentation. Or the documentations are placed on some place which is not known by their visitors. For my opensource project Stubmatic I initially created documentation on wiki. But when I received many basic questions, I realized that I should link them on README as it is the initial point for any visitor.
  • just another project : Many projects seem "just another" project. People don't want to switch until it is really needed and it is easy to switch.
  • Many times users are not even aware that there is a project exist which can help them. Such projects don't even appear in google search.

Contributors

  • We're open: A badge, quote or clear notice that your project is welcoming contribution is really important. But in addition, you should also create CONTRIBUTING.md in the root of the project.
  • Implementation: A project inspired by many anti-patterns demotivate their users to contribute.
  • Credit: Mention your contributors on README or on a separate file. And appreciate their work once they're done.
  • You may mention following in issue template

    Would you like to work on this issue?

    • [ ] Yes
    • [ ] No
  • You may ask your users to contribute when they raise an issue

Would you mind to raise a PR for fast resolution? ...

2
  • Hey Amit! Nice answer. Just so you know, if you're talking about your own projects, we've got a rule that you need to say so - I know you did for one of the projects you mentioned, but for the other two it wasn't so clear. In this case I just edited them out, since they weren't directly relevant to the answer.
    – ArtOfCode
    May 9, 2018 at 7:18
  • no problem @ArtOfCode. Sometimes we fail to convey what we actually want to say. In this case, it is good to take that part out instead of confusing the readers. May 9, 2018 at 7:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.