How to explain to users that we do this in our spare time?

Question

Success can be painful for a FLOSS project. We now have nearly a thousand active users and many more people are becoming active contributors to our backlog/issue tracker. Note that while we're getting much more activity around discussing bugs & feature requests, the number of active contributors actually submitting pull requests has remained very small. It's really still just the core team of 3 or 4 who are actually maintaining the project.

Now, the core team all have day jobs and, many of us, families. We have other responsibilities. I personally haven't been able to make a commit in several months now. I've been keeping up with monitoring the forum, but that's about it. This leaves just one developer actively working on the project at the moment.

It's great that our users are getting involved. I love it, but some are honestly becoming a bit pushy about some things that they honestly don't fully understand. I've tried explaining that:

1. What they're asking for would take a considerable amount of work in some cases, nearly impossible in others.
2. We do this in our very limited free time.

Now, our project is free as in beer and I've repeatedly encouraged people to submit pull requests, reminding them that the fastest way to get their feature implemented is to write it themselves. This doesn't seem to be doing any good though.

How can I explain to these users that it's a small dev team, working in their free time, providing zero cost software and that features will take a long time to get to market?

Answer 1

1. Put it on the front page.
2. Put it in a pinned message at the top of the forum.
3. Stop worrying about it.
4. Find a way to create a marketplace where people can put up money if they care to, and someone else cares to take it.

You don't owe the universe anything. You and your colleagues built what you built to scratch your own itches and made a gift of code. If other people want to use it, you're delighted. But if they expect the level of support of a for-money product, they need to be reeducated. Just reeducate them. Any time someone complains about the lack of a fix or a response, and you have a moment to spare, just post a link to the boilerplate, and go back to your life. Otherwise, leave them to do the work of finding all the explanations you've already left around.

If they all wander away, so what? You scratched your itch, your code solves your problem. The rest of them are just along for the ride.

You cannot educate the internet. Whatever you do, you will get email messages from people who are hostile, confused, or over-entitled. Don't let them worry you.

Answer 2

I have started utilizing BountySource. If people are hounding you about an issue/pull request, you can edit the issue to include code similar to this:

<bountysource-plugin>
[![Bountysource][1]][2]
[1]:https://bountysource.com/badge/issue?issue_id=4807368
[2]:https://bountysource.com/issues/4807368-support-for-package-upgrade
</bountysource-plugin>

Result:

Example

This way, if people are serious about the issue, they can put money up to support you.

Answer 3

I don't think you should explain the fact that you are a small dev team, working in your free time, providing zero cost software. This is irrelevant.

Emphazise that your project is an open source project. It means that it is a zero cost software once it has been paid. Currently, it has been paid by your time.

When you have a feature request, use your expertise to explain the tasks and associated time to implement it. When the user knows that function xyz has to be modified in file abc to add functions d, e and f and you estimate that it would take 40 hours (10h for new function d, 15h for functions e and f), they can either start to implement it or propose to pay for your time. If asked for the progress, you can mention that you have been able to spend 2 hours programming since last time. Then ask if they have started to contribute -- "what? nothing! you could have created the function prototypes at least" -- then help them to get involved: link to git access documentation or write yourself prototype for function d but do not proceed until they have created the prototypes for functions e and f. If the person is motivated, you will get a new contributor, if not, he will shut up.

The time is also a barrier to entry for new contributors who do not know the code. Just pointing to the relevant file and function can save them several hours if they can hack code.