45

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?

  • 2
    Kind of related to this question in an odd way. opensource.stackexchange.com/q/395/775 – RubberDuck Oct 11 '15 at 11:49
  • 3
    I feel your pain. The projects I work on were fun for the first 5 years or so but for the past 15 it's been mostly maintenance: defending against fuzzers and bounty hunters. There are only two really active developers left, one who works on new or improved features and helps fix security bugs, and the other who manages distribution and keeps up with security. I lost all of yesterday, which was a beautiful fall Saturday here, fielding a security bug report, fixing the bug, distributing the fixed version, and filing a CVE report. – Glenn Randers-Pehrson Oct 11 '15 at 12:50
  • 9
    Losing beautiful Saturdays is something I'm just refusing to do @GlennRanders-Pehrson. =) The fun part you mentioned is important. Dealing with entitled users is starting to suck the fun out of this. – RubberDuck Oct 11 '15 at 12:53
  • 5
    I needed to take care of it immediately because it appeared to be exposing a vulnerability in a widely distributed library. It turned out to be a bug only in the application, so it could have waited. – Glenn Randers-Pehrson Oct 11 '15 at 12:57
  • 1
    I think you can make it clear that your primary concern is maintenance of the core codebase, not implementing features X, Y, and Z for a user just because they asked. My strategy is to label these feature requests as such, and then gently point them in the direction they need to go to implement it themselves. In other words, I start with the assumption that they are going to do it and create a pull request, though I know that in 99% of the cases, they really want me to do it for them. Most people take the hint. – alexw Oct 13 '15 at 17:10
46
+250
  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.

  • 6
    Perhaps not the answer I was looking for, but maybe the one I needed. ++ thanks. – RubberDuck Oct 11 '15 at 12:44
  • 4
    Frustrating, ain't it? The internet is a big place, and you don't have to pass tests for intelligence or careful reading to be allowed to use it. Some people just won't get it. – bmargulies Oct 11 '15 at 13:14
  • 9
    I'd call 3. the most important one of those advices. Regarding contributor skills, keep in mind that there is much more to that than "just" coding. And don't think that any arbitrary wish of a paying customer will be added to a company's product, either - it's just not zero cost vs. any cost, it's cost vs. 10 times the cost the customer expected. – Michael Schumacher Oct 11 '15 at 13:20
  • 3
    Linus Torvalds (of Linux fame) has famously stated that his principal job is saying "no" to proposed patches. Someone looking out for the overall sanity of the code base is a must, try to recruit developers, by putting out a "nice to have" features list, "easy bugs" rosters, perhaps even get a local university to give out homework/projects patching your code. – vonbrand Oct 12 '15 at 1:21
  • 2
    Seems like "you have to implement each and every feature that is suggested" is the FLOSS version of the Perpetual Growth Myth :) – Michael Schumacher Oct 12 '15 at 11:23
16

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:

Bountysource

Example

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

  • Does this approach make it easy for outsiders to come in and contribute to get the bounty? – Thorbjørn Ravn Andersen Oct 12 '15 at 11:20
  • 2
    The problem with Bountysource et al: if you are a reasonably well-known project, they will scrape your bug tracker and create bounties for all of your bugs. Even the ones where this is pointless. tracking bugs for example (that are simply depending on other bugs to have an idea of a bigger goal's status). This makes it really hard for people to find the worthwhile ones. – Michael Schumacher Oct 12 '15 at 14:18
8

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.

  • Why is the team size and its composition irrelevant? – Michael Schumacher Oct 11 '15 at 19:30
  • 1
    I'd like to know that ^ too, but +1 for work estimates & being open about work done. – RubberDuck Oct 11 '15 at 20:58
  • 4
    The problem is that some people would say "sure" and give you money. Now they really are entitled. Do you want that? It would also make the project a business, with all the hassle that involves. (Accounting, taxes, other employers complaining, etc. etc.) – Stig Hemmer Oct 12 '15 at 8:19
  • A big team, paid for developing a software, still has to make development choices and discard feature requests. So the team size and composition are irrelevant for the user (not for the development team though). – Futal Oct 13 '15 at 11:48
  • @StigHemmer Only a proper offer would be binding. If some users are ready to pay the real price including operating costs, there will probably be a freelance developer to do it. This is open source, it does not have to be the original developers. – Futal Oct 13 '15 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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