How can I encourage users to work on other user's feature requests?

Question

As manager of several free software projects, I am familiar with feature requests that users of my project submit to its public issue queue.

Many of the suggestions are good, but having limited resources available, there is often no way I can assign a feature request to a member of our core development team. Core team members are on a salary, and in order to pay them, they have to do paid work (including working on feature-requests somebody will pay for having implemented). Our contract with paying clients makes sure that the result of this for-pay work always makes it way back into the free software distribution we make available for everyone, but there is little overlap between what paying clients request, and what is requested by members of the public. As a result there is always a huge backlog of feature requests coming from users that are not paying clients of our company and that are not willing to sponsor development. I.e. they want it for free. I've nothing against users that prefer to get their pet feature added for free instead of paying us to add it, I've just not yet found a sensible way to oblige.

We already have in place a pretty good system for managing and reviewing user's pull-requests, as well as a CLA that makes sure that user contributions can safely be merged into our project without creating future problems for our company or for downstream recipents of our software. We're just not getting as many as we would like of these pull-requests.

I first thought that we could provide additional support and some hand-holding to get the person requesting the feature to implement it. But after trying this out, we discovered that these users are not developers - they are literally just using our software. So the person requesting the feature is simply not capable of implementing the feature and submit a pull-request for review. To keep this question simple, just assume that all these feature requests comes from non-developers unwilling or unable to sponsor development.

So, given that the core development team can't provide this service without pay - how can I encourage users to implement features requested by other users.

What are the best practices when dealing with feature requests from the community, given that I want to minimize the cost of doing this for the company, while at the same time encouraging capable users to contribute pull-requests that implements (some of) the requested features?

To avoid this being closed as "too broad" or "opinion based", I am looking for specific strategies, backed up with references to real free software projects that has successfully encouraged and mobilized users to contribute in this way. The strategies can either be taken for relevant literature, or from personal experience.

Answer 1

Atlassian (the publisher of tools like Confluence and JIRA) has published a Feature Implementation Policy, which may be of some use. While not quite what you're looking for in that Atlassian still implement the features themselves, it does detail how they deal with scheduling feature requests.

In general, to get people to do something they're not obliged to do, you need to provide an incentive. This is the most important consideration. When someone submits a feature to you, recognise that they've put a lot of work into it and reward them somehow. This could be:

• monetary: a small (£10 maybe) reward - the official staff need salaries, but rewards have no minimum value
• cosmetic: if your app has networking features, give them publically displayed status
• swag: something tangible, a mug, a t-shirt
• privilege: let them do things they wouldn't otherwise be able to

You also need to make it as easy as possible to contribute to your software. Even for developers, it can sometimes be hard to read through a codebase and understand it, which is a prerequisite for adding features. Provide good documentation and support: perhaps set up a specific email inbox and someone to monitor it, and use it to support those with specific problems trying to work with your codebase.

Answer 2

This is a matter of community building. I've seen several variations on this theme in the Apache communities I've worked on. I offer them for what they are worth, which might be nothing to you.

• No such luck: open source communities are composed of people with itches. You can't make someone scratch someone else's itch. When people submit feature requests, ask them to submit a patch that implements it. Obviously, this is not helpful for end-users.
• Mild Blackmail: ask new would-be committers to work on the backlog of feature requests and bugs as a prerequisite to being given permission to commit -- always assuming that you grant permission to commit.
• Esprit de corps: Some communities develop a real feeling of collective pride and responsibility for the 'product', and this results in volunteers working on things just for the good of the product. However, in my experience, the more obvious it is that some people are being paid and managed to work on it, the less likely it is for volunteers to fill in, except when those volunteers are scratching their own, personal, itches. Esprit-de-corp is unlikely to develop, in my view, in an environment where only employees of a company have commit rights.
• Allow voting on feature requests. This creates some social pull in the direction of implementing popular feature requests.

Since you work for a commercial enterprise, your commercial enterprise's marketing department can help with the third item. You can't pay these people, but you can offer recognition and swag. Apache is very diffident about this, due to our concern to avoid commercial domination of projects, but you don't have that problem. Heck, you could even consider game-ification along the lines of Stack Exchange.

Answer 3

You could charge the paying customers a small extra fee of a few percent for open source development. You can argument that without the community and their contributions the software would not exist in the current state and you want to pay back all the effort being put in.

And while one user maybe can't afford to spend thousand dollars to get a feature implemented, hundered users could afford to spend ten dollars each to get it done. You can offer mini-fundraising for features where the people donate and as soon as a feature is paid for, it gets implemented.

Make sure you have an automated system for the donations and tax excemptions and so on, or you will spend lots of time on writing the documents. Also check your local law, what information from users you will need to have.