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?
How can I convert users to contributors?
contributor;project management
Make it clear that you want contributions. 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. 