Comment by codebeaker | Hacker News Reader

Comment by codebeaker | Hacker News Reader

Maintainer of Capistrano here, I've been close to FOSS burnout a couple of times, and more often than I would like people catch the sharp end of my tongue. I can count on one hand how many issues have been opened with a corresponding PR, and from those, barely any ever come with tests, or acknowledge the stuff in the CONTRIBUTING file (Github includes a "Before opening this issue, check this project's guidelines). Fortunately there are couple of people who consistently tackle issues that the lazy people have opened, and submit super high quality PRs with unit and functional tests, documentation and entries in the CHANGELOG. These people are the main reason that I still work on FOSS.

My solution was to make heavy use of labels at GH, the "needs more info" and "feature request" ones are obnoxious colours. Second to that, I bought a TextExpander licence, and setup a bunch of macros `notanissue` which expands to:

> Closing because I’m not sure this is an issue, if you are convinced that this is really a bug, please feel free to re-open the issue and add more information (your versions (Ruby, Cap, etc), your Capfile, your logs, and relevant sections out of your Gemfile) > Otherwise support is done via the mailing list (https://groups.google.com/forum/#!forum/capistrano) or at StackOverflow (http://stackoverflow.com/questions/tagged/capistrano) with questions tagged `capistrano`.

And a number of others 'contrib' for contribution guidelines when a PR is in conflict with them, etc.

It's helped lighten the load a lot, and now tend to invest heavily in grooming the issue list, and keeping things neat and tidy at GH. I dare guess, when I'm awake 90% of the issues are classified, or closed within 5 minutes of being opened, this has helped a lot with the feeling of pressure and constant nagging with which I've previously suffered.

Of course, maintaining a large project is a burden, but it comes with career and profile benefits.

Thanks for your hard work on the project! You have improved the lives of many working programmers. What are you looking for for the future of Capistrano?

The problem and major benefit to github is how easy it is to contribute. Sometimes it's like a high maintenance low paying customer vs. a high paying customer that treats you like a professional and gets out of your way I guess.

Actually we're planning to keep improving it, I factored out the SSH driver into SSHKit (http://github.com/capistrano/sshkit) when I did the v3 rewrite. Right now we are founding a company, and hiring a team to build Harrow, the tool we all wish existed to tidy up some of the workflow loose ends, and bring some order (whilst maintaining flexibility) to what might otherwise being DevOps chaos. Find it (not launched yet) at https://www.harrow.io/. One of our goals for Harrow is to open source that as well as running a hosted service, and using the revenue and expertise to follow the (exceptional) Hashicorp example of building a commercial FOSS company to build excellent, useful software, whilst defining new standards, and providing all the tools people didn't know they needed.

Of course we know that Docker, and Rocket, and to an extent more of the AWS tools are automating a lot of these processes, but for every problem they solve, some people can't use them, and we're counting on "script things, run them in a repeatable environment, share the scripts, and results with your team" theme won't go away for a while (ever?), as most of what we do, even with all these modern deployment tools is still programmer duck-tape.

(Late to the conversation - I've had this tab open that long!)

I just wanted to ask your opinion on the docker comment - I think tools that make repeatable builds will always be necessary (even if only to make the first docker instance of your immutable server).

Or is there some other theme at play I so not understand that means this idea is old hat?

The cool thing is that you get to triage the issues and handle them as you see fit instead of waiting on a senior developer, tech lead, CTO, executive or someone else to give you the go-ahead.

That's the real power of FOSS imo. It gives all programmers breathing room to try and make good technical and social decisions without being subject to too much politics or interference from management.

A sandbox in which to become a better developer and the career/profile benefits are huge.

I really dont understand what is wrong with this issue. Poster did his homework: he found problem, debugged script, listed missing characters so its easy to test and pointed reason why. I would love to have such reports all the time.

While the content of the report was fine, the language was not. It reeks of entitlement and is rude towards the people that spend their spare time providing value to others. This is especially true in this case since the projects readme clearly states that it's based on the Phantom Open Emoji library and thus limit to the restrictions of that library. If the reporter really feels like he should raise an issue, then he should raise it with the icon library.

From documentation that library called 'emoji' is limited by some underlying library is not clear. This guy asked to update readme with that. And I really do not feel entitlement or rude tone from there. Perhaps I have different sensitivity level.

Anyway some people spend years working for free, receive death threads, are harassed by governments, have to move to different continent.... All because working on OS. And this is suppose to be THE reason why people burn out?

This gem exposes the Phantom Open Emoji library unicode/image assets and APIs for working with them.

Second line of the the readme

Yes, the fact that a vocal chunk of opensource users expose an attitude that could be summed up as "you wrote this tool I'm using, you're obliged to fix all my issues with it" is a constant strain on open source contributors. It's certainly not as bad as death threats, but it's still a problem and it's one that needs to be called out.

People need to be aware that something was given to them and that they need to give back in return if they want to preserve what was given. I, personally, think that a humbly written bug report is sufficient in terms of giving, but courtesy towards the author/maintainer should always be included in a bug report. I try to add PRs when I can, but I obviously can't in all cases.

> I really do not feel entitlement or rude tone from there

You don't?

> I like your gem otherwise, but it's called "emoji", implying that it's the Ruby library for handling those characters. The facts that it only handles some of them, and that you already knew about this issue but didn't tell us is bad form and frankly rude to your users.

It is quite sad how constructive communication breaks down. Users of open source have to deal with half dead projects and ponder constantly when the pain of not getting issues addressed overcomes the pain of switching or rewriting from scratch or risk wasting time learning the code base, providing a fix and having the fix ignored or rejected summarily. On the flip side, providers of open source have to deal with incomplete information and rude / burned out users.

Thanks for your contributions. Having explanatory answers is great. I wonder if a bit more effort could go a long way. How about: Run this script that collects your Capfile, your logs and the relevant sections from your Gemfile and paste the results in the bug report.

PR = pull request

GH = GitHub

For a moment I imagined someone starting a public relations campaign against a ruby gem.

Reply on news.ycombinator.com