1. 42
  1.  

  2. 10

    Often I will get emails out of the blue asking for support on a project that I’ve long stopped maintaining

    One thing I have seen people do but have never done myself is reply with a quote of your consulting rates.

    It might come off as a bit dickish, but it also can help people understand what an amazing deal they’ve gotten so far getting what you’ve done for free.

    1. 6

      This is just a random idea, but there should probably be some way of monetarily rewarding maintainers. That may be a better way to triage issues.

      So if one person has a really business critical issue that they need fixed, they can offer a $5000 reward for fixing the issue. Or if there’s another issue that is a nuisance for a lot of people, they all put in $5 for a solution but if enough people get behind that, you know it’s an important issue that should get attention.

      Another alternative is for maintainers to directly offer a bid for each issue and each issue becomes a mini crowdfunding campaign.

      1. 5

        There is BbountySource. For a biased example there is now a $5000 bounty from IBM on some LuaJIT feature. Other example look on gtk tag people put some money to the jar.

        1. 3

          There’s a few available solutions doing exactly that, and I remember when I was maintaining a rather large project getting many emails from such systems to try them. In the end, most people don’t care enough to put their money in a “free” product, people who care enough pay you for an actual feature, feature that might not be high priority and it doesn’t solve in any way the issue shown here, which is triaging.

        2. 3

          It might come off as a bit dickish

          This is why I don’t do it. (And not because I don’t want to “look like a dick,” but I actually don’t want to be one either.) And most of the emails I get (at least a few a week) are very gracious and appreciative of work that I’ve already done, so responding with consulting rates seems…. a bit weird.

          My typical process is to split emails on open source projects into three categories:

          1. Emails that wish to start a brainstorming session.
          2. Emails with support/bug/feature requests.
          3. Emails with unreasonable requests. (“Please sign this NDA so I can talk to you about my new startup idea…”)

          If (1), I just take them as they are and respond with what I can. Some of them are fun.

          If (2), then I almost always direct them to ask the question on the issue tracker. If the question is easy for me to answer off the cuff, then I’ll write it inline. (I find it amazing how rare people actually go and open an issue after requesting that they do so.)

          If (3), I usually just ignore it or send a polite denial.

          1. 1

            And most of the emails I get (at least a few a week) are very gracious and appreciative of work that I’ve already done

            In my experience there has tended to be a correlation between “gracious and appreciative” with “knows enough to use the public issue tracker instead of personal email”. So it’s interesting to me that you’ve had different experiences.

            1. 3

              That is interesting. I haven’t noticed any such correlation. At least one of my projects is targeted towards people that probably wouldn’t call themselves programmers (more like, self described, “I’ve messed around with Excel and Visual Basic/Python a little”), and they generally don’t have any knowledge of the social norms around open source, but are usually quite appreciative.

              … but that’s only one project. If I think about other projects that attract folks that would call themselves programmers, then I haven’t really seen your pattern either.

              This could also easily be explained through my own personal biases. I’m clearly an optimist, so it wouldn’t surprise me if the positive stuff leaves a bigger impact than the negative stuff.

              1. 3

                I think it cuts all ways. Like the curl guy getting phone calls about hacking people.

                1. 1

                  I haven’t noticed any such correlation.

                  Now that I think about it a bit more, it’s probably better described as a correlation between “pushy and demanding” and “disregarding communication norms”. (All my projects are used by professional programmers and not general end-users.)

          2. 5

            Below are a few related but not continuous thought I had while reading this:

            This occurs even in internal projects at my company. Many teams build solutions for other teams to use and so this kind of issue arises even there. You have new people to software development filing bugs or sending emails. People new to the project, or new to a team, or new to the company, and so it’s easy to find bugs that aren’t well written.

            One solution we’ve seen being effective is having some template text describing generally useful information for issues: what logs to provide, what level of repro steps are desired, screen shots, particular settings, versions of particular things, etc. All of these should come with instructions on how to fetch them for the uninitiated. It looks like GitHub added issue templates in 2016. Good lord, project maintainers have been dealing without templates for that long? I’m surprised more projects aren’t abandoned.

            At least in an internal company, you can try and demand sane working hours. It’s a business transaction that can be terminated from either side so you can choose to not deal with the headache of maintaining a project if you want. It’s also in the company’s interest to not burn you out so they might consider expanding the team if it becomes important enough. At least at my company, you get some engineering manager to help meetings and communicate with dependent projects and dependencies, push on important issues against other teams, and plan for problems that will happen in a year or two. They also help be tie breakers on highly debated issues. You have people dedicated to looking at bugs and making sure high priority issues get pushed. You have directors and VPs who want to deduplicate work and foster partnerships with other orgs. You have EPMs to help administrate projects.

            I think the root cause is GitHub has fairly bad project management controls. It looks nice and has some cool metrics but it’s really hard to tell what issues need to be looked at. It’s hard to screen issues into a proper state. And it’s REALLY REALLY easy for anyone to throw themselves into the project.

            Many engineers have this fetish for open source, that it’s somehow more reliable and stable that closed source. Really, they’re just more scaled out with more clients and maybe more contributors. Sometimes, I wonder if it’s just really a disguised exploitation of people who want to volunteer for the community.

            1. 9

              Many engineers have this fetish for open source, that it’s somehow more reliable and stable that closed source.

              It really is that much better. We’ve just been waiting almost 6 hours for a developer of a proprietary building management system to get on the phone with a laptop and change a single constant.

              This was on the weekend and the vendor underestimated the need to prepare before the event. But still, we are used to constructively fix the issues as they arise and OSS allows us to do that. Unlike Sun IdM, Oracle, random proprietary BI, random proprietary ERP and so on.

              1. 5

                Irony alert: this software isn’t stable because we can’t change it fast enough. :)

                1. 2

                  Good point, you got me there. :-D

                2. 2

                  One fairly common approach to avoiding that problem other than open source is a paid source license, where as part of the $$$ enterprise contract you get a copy of the source and the right to build your own modified versions (but not the right to redistribute the source publicly). Not as good as open source overall, but does avoid the specific problem of needing to wait for some trivial change.

                  1. 2

                    You may get the right to build a modified version under these agreements, but I have to wonder how often people are able to make serious use of those provisions from outside the firewall. One thing open source brings to the table is the basic necessity that your build system and deployment process be something that newcomers can replicate, otherwise there probably won’t be any.

                    1. 1

                      That does seem like a likely problem. I’ve had one reasonably good experience with proprietary source licensing in academia, a site license from Franz years ago, where everything built well, even with good internals docs. But it’s admittedly an odd case because of how things work in Lisp land; extending a base system rather than interfacing with it as a binary blob is the norm, so customers of proprietary Lisp tech (back when that market existed…) expected source licensing where the source was actually usable.

                    2. 1

                      Burroughs MCP was done that way. You got the source with the machines. You could do what you want with it. Some people also submitted changes (esp fixes or optimizations) back to Burroughs which either could or did get included in main product. I think they changed that later but they made a lot of money early on. It also happens today in hardware with companies buying I.P. that’s either behavioral Verilog or RTL source. They then use their tools to customize it to what their implementation needs. I think the dual-license model also supports paid, shared source as well to some degree as many companies willing to buy proprietary licenses for FOSS would likely buy paid, shared source as well.

                  2. 5

                    Issue and pull request templates helped tremendously in clarity of what people were reporting issues for or making changes to on one of our internal repositories at Cisco Spark. I highly recommend getting those set up if you work with a repository that either has a large codebase or a large number of contributors.