1. 7
  1.  

  2. 10

    If maintaining a popular free and open source software project is producing stress… don’t do it!

    Really, just stop. Maintaining it, I mean. Unless you have contractual obligations or it’s a job or something, just tune it all out. Who cares if people have problems. Help if you can, help if it makes you happy, and if it doesn’t, it’s not your problem and just walk away. It’s not worth your unhappiness. If you can, put a big flag that says “I’m not maintaining this, feel free to fork!” and maybe someone else will take it over, but if they don’t, that’s fine too. It’s also fine if you don’t put a flag! No skin off your nose! You don’t owe anything to anyone!

    Now I’m gonna grump even more.

    I think this wave of blog posts about how to avoid “open source burnout” and so forth might be more of a Github phenomenon. The barrier to entry has been set to too low. Back in the day, if you wanted to file a bug report, you had to jump through hoops, and those hoops required reading contributor guidelines and how to submit a bug report. Find the mailing list, see which source control they used (if they used source control), see what kind of bug tracker they used (if they use one), figure out a form to see what to submit where… Very often, in the process of producing a bug report that would even pass the filters, you would even solve the problem yourself or at the very least produce a very good bug report that nearly diagnosed the problem.

    Now all of this “social coding” is producing a bunch of people who are afraid of putting code out there due to having to deal with the beggar masses.

    Just don’t.

    1. 7

      I totally agree that your own needs are the top priority if you are an OSS provider. Nobody has a divine right to your time.

      I do think that having people be able to report bugs easily is really good. For even relatively small projects, this also serves as a bit of a usability forum, with non-maintainers able to chime in and help. This can give the basis for a supportive community so the owner isn’t swamped with things. Many people want to help as well.

      Though if this is your “personal project”, then it could be very annoying (I think you can turn off issues in GH luckily?).

      Ultimately though, the fact that huge projects used by a bazillion tech companies have funding of around $0 is shameful. Things like Celery, used by almost every major Python shop, do not have the resources to package releases because it’s basically a couple people who spend their time getting yelled at. We desperately need more money in the OSS ecosystem so people can actually build things in a sustainable way without having to suffer all this stress.

      Hard to overestimate how much a stable paycheck makes things more bearable

      1. 5

        “Back in the day, if you wanted to file a bug report, you had to jump through hoops”

        This is where I disagree. Both maintainer and other contributors’ time are valuable. Many folks won’t contribute a bug report or fix if you put time wasting obstacles in their path. Goes double if they know it was there intentionally. I remember I did one for Servo on Github just because it was easy to do so. I didnt have time to spare to do anything but try some critical features and throw a bug report on whatever I found.

        I doubt Im the only one out there that’s more likely to help when it’s easy to do so.

        1. 5

          This is where I disagree. Both maintainer and other contributors’ time are valuable.

          !!!!!

          I remember I did one for Servo on Github just because it was easy to do so. I didnt have time to spare to do anything but try some critical features and throw a bug report on whatever I found.

          @manishearth, who set up http://starters.servo.org, dropped this very nice sentence about contribution: “People don’t start out serious, they start out curious.”

          1. 4

            The problem is that projects don’t survive on such drive-by fixes alone. Yes, you fixed a bug and that’s a good thing, but the project would probably still run along just fine without that fix. And you never came back. In the long term, what projects have to care about are interested people who keep coming back. The others really don’t matter that much.

            1. 5

              I think this is a bit like a consumer acquisition funnel.

              Every contributor first started off by providing a drive-by fix. If they do it enough, now they’re contributing a lot. Now you have full-time contributors.

              1. 1

                Sure but the question was about how high the bar for such drive-by contributions can be while still keeping a project healthy, based on the premise that making drive-by contributions too easy can result in toxic community behaviour overwhelming active maintainers.

                1. 3

                  The “height of the contribution bar” as quality control is - in my experience - a myth. The “denying low quality contributions” is not.

                  I’ll explain why: the bar to unfounded complaints and troll is always very low. If you have an open web form somewhere, someone will mistake it for a garbage bin. And that’s what sucks you down. Dealing with those in an assertive manner gets easier when you have a group.

                  The bar to attempting contribution should be as low as possible. You’d want to make people aware that they can contribute and that they can get started very easily. You will always have to train - projects got workflows, styles, etc. that people can’t all learn in one go. Mentoring also gets somewhat easier as a group.

                  Saying “no” to a contribution is a hard. Get used to it, no one takes that off you. But it must be done.

                  Also, there’s a trend to have people voicing their frustrations blamed as “no respecting the maintainers”. There’s pretty often complaints that have some truth in them. Often, a “you’re right, can we help you with fixing it on your own?” is better then throwing stuff screenshots on Twitter.

                  1. 1

                    I agree with you but quality control is, again, a separate question. I wasn’t talking about quality control. The question is about how to best attract only those people with an appropriate kind of behaviour that won’t end up burning out maintainers, and whether a bar to contribution can factor into this.

                    I think JordiGH’s point was that if someone has to jump through some hoops to even find the right forum of communication to use (which mailing list and/or bug tracker, etc.), just by showing up at a place where maintainers will listen a contributor shows they have spent time and enganged their brains a bit to read a minimum necessary amount of text about how the project and its community works. This can be achieved, for instance, with a landing page that doesn’t directly ask people to submit code by pushing a simple button, but directs them to a document which explains how and where to make contributions.

                    If instead people can click through a social media website they sign up on only once and then have their proposed changes to various projects appear in every maintainer’s face right away with minmal effort because that’s how the site was designed, it’s no surprise that mentoring new contributors becomes relatively harder for maintainers, isn’t it? I mean, seriously, blog posts about depressed open source maintainers seem to mostly involve people using such sites.

              2. 1

                Id considered this but do we really have data proving it? And on projects trying to cast a wide net vs those that dont? I could imagine that scenario would be fine for OpenBSD aiming for quality but Ruby library or something might be fine with extra little commits over time.

                1. 2

                  I think you’ll always need at least one developer dedicated enough to give the project a home, integrate changes, drive releases, and so on.

                  A pile of drive-by patches and pull requests with nothing holding them together is not a “project”.

                  Edit: BTW you said “extra little commits” and i said “drive-by fixes alone” so we may be talking past each other a bit… :)

            2. 3

              Really, just stop. Maintaining it, I mean. Unless you have contractual obligations or it’s a job or something, just tune it all out. Who cares if people have problems. Help if you can, help if it makes you happy, and if it doesn’t, it’s not your problem and just walk away. It’s not worth your unhappiness. If you can, put a big flag that says “I’m not maintaining this, feel free to fork!” and maybe someone else will take it over, but if they don’t, that’s fine too. It’s also fine if you don’t put a flag! No skin off your nose! You don’t owe anything to anyone!

              Totally. In this scenario, you should just quit cold turkey.

              The rest of the post is more advice that I’ve found myself giving multiple times to people who do want to keep maintaining the project, or be active in their larger community, but aren’t super focused on that particular library anymore.

              1. 2

                There’s a lot of poor communication out there with unstated assumptions on each side for relationships not just open source and that drives a lot of frustration and resentment. There are dozens of books on the subject in the self-help aisle of bookstores. The points in the article are all good advice but I think the best advice is to make it clear what on terms you volunteer your work and not be ashamed to say “I don’t want to do this but feel free to do it or fork it” if it’s not scratching your itch.

                Personally, I’ve turned away issues resulting from old and on bleeding-edge compiler or library releases and on OS’s or equipment I don’t run (doesn’t behave on Windows XP? doesn’t work with Chinese clone of hardware? Hell if I know…)