48

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?

RubberDuck
  • 5,418
  • 2
  • 20
  • 33
  • 2
    Kind of related to this question in an odd way. http://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

3 Answers3

49
  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.

Philippe Ombredanne
  • 14,441
  • 2
  • 32
  • 87
bmargulies
  • 4,257
  • 17
  • 23
  • 6
    Perhaps not the answer I was looking for, but maybe the one I needed. ++ thanks. – RubberDuck Oct 11 '15 at 12:44
  • If I knew of a magic elixir to convert users to contributors, I promise I'd make it free-as-in-beer. Realistically, many won't have the skills, aside from any other barriers. – bmargulies Oct 11 '15 at 12:46
  • Yeah. I'm not even concerned about them actually contributing. I know that's unlikely. I would just like to get through to them that we do this for free. – RubberDuck Oct 11 '15 at 12:48
  • 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
  • And about getting through to "them": Don't. Just make sure that the general audience - much, much more people than the vocal user that gets to you - have an idea of how you are developing the software. – Michael Schumacher Oct 11 '15 at 13:21
  • There's an important misunderstanding there @MichaelSchumacher. We're not a company. We're not selling anything. We just built a useful tool. – RubberDuck Oct 11 '15 at 13:57
  • No misunderstanding on my part - I figured that you are most likely not a company. – Michael Schumacher Oct 11 '15 at 14:01
  • 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 01:21
  • 1
    I think 4. can also be very important. Not even because it will actually bring in enough money to pay people to do something, but just to tell annoying people. "I want xxx and I want it now!" "Well, we do this in our free time and if you really need it, you can implement it and open a pull request." "I can't program and this cant be this hard! Also it's literally the most important thing for everyone on the planet!" "Well, you can just pledge money at yyy and if it's enough, someone might implement it!" "cricket sound" – Josef Oct 12 '15 at 06:56
  • This approach is just another way to convey to the world that the project is for all practical purposes dead (or at least very smelly). – Thorbjørn Ravn Andersen Oct 12 '15 at 11:19
  • 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.

Community
  • 1
Zombo
  • 1
  • 1
  • 5
  • 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
  • 3
    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.

Zizouz212
  • 6,449
  • 4
  • 36
  • 75
Futal
  • 215
  • 1
  • 1
  • 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
  • 6
    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 08: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