1. 32

  2. 12

    Hm. This is a super short opinion piece and while it clarifies their position, none of this would be different if they were not doing Open Source, maybe just another form of Freeware.

    In my view it’s important for Open Source projects to declare which level of user interaction they want. For the projects I’m in, direct user interaction - also on issues - is extremely important. So yep, we do include free support.

    The assumption of the person in that chat log, that they want to inform of a (perceived) bug, rather than observing it silently, is fully okay. They probably don’t even feel like this is a “support request”. Being hit with a hostile mood can trigger an averse reaction. There’s a chance that both are talking past each other and that leads to the conflict.

    1. 10

      To me, a piece of software being open source means that the source is available and I am allowed to change it and distribute it in accordance with the license. This does not mean the development process is necessarily one of open collaboration.

      But I think it is also worth considering that to some degree you are given free testing for your software. Imagine if a user sent you an email saying “I found a security flaw in your library, you can buy a support ticket from me to get the details”.

      You can hope to find a balance between the benefits you get from open collaboration and the work (and sometimes frustration) it entails.

      1. 6

        I think this paid-only support setup is fine overall, but I do have a bone to pick with the way the author is interacting with people.

        One of the ways we can contribute back to open source is by making quality bug reports that save maintainers time. So, imagine you’ve investigated some problem and want to share that information with the maintainer, only to be told “yes, that’s a support request, please open a [paid] ticket.” The system is fine — you just don’t share your investigation and move on — but the way it is communicated is not cool, in my eyes. If it is such a common problem for the maintainer, then they should consider a canned response that is both nicer and also explains the situation, like:

        Thanks for taking the time to report the issue. Unfortunately, we’ve found that having an open bug tracking system leads to a lot of requests for free support disguised as bugs, which consumes a lot of maintainer time, so we’ve decided to restrict access to paid users only. If you are a paid user please post in ${place}, otherwise we are not taking public reports at this time.

        1. 3

          nothing was broken, just didn’t work as expected (which is actually to be expected for every reasonably complex piece of software)

          If something isn’t working as the documentation says it should work, it’s a bug. Period. If there’s a widely agreed-upon “feature named X should work this way” convention in the field, there’s feature X and it isn’t working that way, it’s also a bug, unless there’s a prominent warning.

          I don’t see any information on paid support there either.

          1. 3

            Either this person gets swamped with help requests or has a low tolerance for interaction.

            Every reasonably popular open source project I ever took part in gets a lot of bug reports that are simply misunderstandings or failure to use it correctly. You can either shush them away, clarify where they went wrong, or think hard how to improve your docs. Of course one takes more effort than the other, but if short on time I don’t see any downside to just close them as “Not a bug”. Some people will be angered in any way if you’re not handholding them to a solution, so those should be ignored anyway. And still I’m usually happy to show them the way, but if I only offered paid support I think this sounded overly confrontational, to the point of driving people away..

            1. 1

              The article seemed to be written by someone who does not want to grow an ecosystem around their project. That’s fine, but not common. Open source projects thrive when people contribute. There are, broadly speaking, four ways that people can contribute:

              • Testing
              • Code
              • Documentation
              • Money

              Bug reports are contributions. Some of them may be very poor-quality contributions, but that’s true of code and docs as well: some of the PRs you see will be things that you want to completely rewrite rather than accept.

              Bug reports are also the lowest friction way for people to contribute. This means that most people who eventually contribute docs, code, or money will start their interaction with your project by contributing bug reports.

              The author of this article has made a decision that the only kind of contribution that he cares about is money and has a process that will encourage everyone who starts thinking about contributing to either leave or funnel into the direction of contributing money. That’s fine, as far as it goes, but it seems that the most likely outcome is for this project to either die or be forked by people more willing to build a community. In my experience, the open source projects that have succeeded have been the ones that have built good communities not (necessarily) the ones with the best technology.

            2. 2

              Actually, most reasonable size OSS project I,ve used does have free support on IRC, and usually helpful.

              And typically, the larger the project, the bigger the support channel. So, scalability.

              1. 1

                This clearly frames all people reporting bugs as clients who consume resources by requesting support. In actual fact, some (if not most) people reporting bugs are an extension of your test/QA team, who are generously donating their time for free to help the project. Sorting one from the other isn’t free, but pushing the latter away just because the former exist hurts the project, and I’d be less likely to pay money to a project that appears to be hurting itself.

                I also provide the source code, so you can fix things yourself, should my solution turn out to be unsuitable.

                Yeah, but you’ve made it much harder for the community to fix your bugs for you by hiding the bug tracker. If you provide a place for the community to report bugs, you allow contributors to pool their knowledge. The combination of someone who observed something interesting + someone else who had a few minutes to diagnose the issue + someone else who has the skills to fix it = bug fixed, whereas on their own and isolated they don’t help anyone.

                Of course, the author is free to do whatever they like with their project, but I can’t see why people would want to pay for support when the author is determinedly stamping on any potential community and chasing away contributors. If I’m paying for support, I want the author to be focussed on new features and major issues, not trivial bugs which the community could have mopped up.