Hacker News new | comments | show | ask | jobs | submit login
The reason people burn out on open source (github.com)
243 points by clukic on Dec 7, 2014 | hide | past | web | favorite | 171 comments



Same reason people burn out on Hacker News.

Independent developer consultants, as a demographic, significantly skews towards a larger-than-average number of people who were never surrounded by a good professional office culture. Many never learned the benefits or skills of writing in ways that won't be interpreted as mean. In fact, many pride themselves in trying to be the opposite of a professional behaving office person. Toxic culture, loves to point out the tiniest flaws in everyone else's work and don't care or realize that doing so is hurting others.

Case in point, Hacker News was a much happier place that was more receptive to positively responding to people sharing their work, back when it was Startup News. Inviting in all kinds of hackers, ended up bringing in the worst of the worst segment of the demographic.

I love doing developer consulting, I know many awesome consultants who behave great, but the average behavior of the demographic as a whole is is really bad.


> Inviting in all kinds of hackers, ended up bringing in the worst of the worst segment of the demographic

If you think the current HN crowd is the "worst of the worst" of the demographic, you need to get way, way out of your microbubble.

... and with an elitist attitude like that, don't think you're exempt of that demographic either.


You say 'elitist' like it's a bad thing...


Counterpoint:

"Corporate culture" environments where everyone is at "Stepford Wives" level of jollyness rarely get much done.


Who do you really think gets more done: The people who show up to whine and criticize, or the people who hold back the whining to silently go and make their own improved solution instead?

Consider that people who wine, seem to outnumber the people who do by at least 1000 to 1, and you'll have my answer for who I believe to be contributing more to getting things done.


There is no contest: it is the environment where frequent, uncensored criticism is tolerated or even encouraged. That guy who is silently working on their own solution? Without listening to feedback from his peers (or, more likely, his betters) his work is probably junk that nobody wants or worse - something that will cause more problems than it solves.

Before I worked in software I noticed companies would have two cultures. A "shop" culture where workers can wear casual clothes, swear, kick stuff, and at the end of the day, get things working, and the "front office" that focused on sales. You never knew if a client was on the phone or in the office so workers dressed well and any negative speech was strictly forbidden.

Because programmers work at a desk, they are shoehorned into front office culture. This has probably done more harm to the productivity of software projects than any other factor. Just this year I watched a small software project (one that a small team of competent developers, QA, and a BA could have completed in several weeks) waste millions of dollars (some say hundreds of millions - the real figure (in the true spirit of front office culture) would be "rude" to tell) before being cancelled. I saw this train wreck coming a mile away and documented the issues and forwarded them to my supervisor but it made no difference. In defense of the company I work for, at least they didn't fire me. It is pure front office culture to blame the whistle blowers for failure.

And don't even start with "Oh, you just need to say it in the nicest, politest manner!" There is no way to tell somebody they are wrong and have to change in a "nice" way. Your organization either can focus on the quality of the end product and encourage criticism or focus on appearance and censor it. But if you choose the latter, unless your project is a con, it is doomed from the start.


"There is no way to tell somebody they are wrong and have to change in a "nice" way. Your organization either can focus on the quality of the end product and encourage criticism or focus on appearance and censor it."

I agree with some of your post, but this part here is a false dichotomy. All over the world people doing complex work are able to disagree constructively without being raving douchebags about it.

There is a ton of collateral damage that comes from employing some sanctimonious jerk who cannot be bothered to consider the humanity of his/her colleagues. Most companies I've worked for get that.


To be clear, the system I'm suggesting is about show, not tell. It requires no emotions:

1. First person drafts a solution. 2. Another person doesn't like it so he drafts an alternative solution. 3. The other developers then look at the two solutions and further build upon the solution that they like better. 4. Repeat. Kind of like a proof of work chain system, now that I think about it.

I don't see how adding in emotions, whether whining or praising, are an improve upon this system at all, but thanks for your explanation.


This ignores the (rational, if naive) cost-benefit of a complaint about someone else's work: if they accept your complaint as valid, then you get what you want for 0 cost. Additionally, since they agreed it was a valid criticism, in the creator's view the product was improved, overall. This is globally a very efficient scheme, because there is often a significant barrier to "showing" an alternative solution, particularly if the solution is the culmination of a lifetime of study.

When criticism is ignorant, purely selfish, or otherwise not constructive, it becomes a problem. And I don't think FOSS leaders should have any problem expressing this sort of judgement without anger or ill-will.


"Complaints have 0 global cost."

That theory seems to be the essence of this entire debate.


So... you are saying that if a whiner contributes at least 1/1000th as much as a normal person, the whiner is better for humanity?

I'm not sure I follow...


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?


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.


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

Second line of the the readme


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


I'm maintaining a small open source mobile app. The app is fairly popular and well liked.

However, there are also a lot of people who just send comments to the app store that the app is useless without feature x or is total crap if I don't change something.

Nowadays, I get anxiety when I just think that I should go to the app store and read the latest comments.

I understand that open source is about community and things should be made together. However, I haven't really got any contributions except few language translations.

I'm getting tired of the app and sadly it will be the last open source software I'll release under my own name. From now on, I'll just dump the source to somewhere and forget about it. Or keep the source closed.

Writing software, even open source software, should be fun. It shouldn't mean that one person writes everything and others complain that it isn't enough.


If you get anxiety when you to have read what others think about your app, your problems are somewhere else.. mostly taking into account that you're uploading it to the app store, a place where almost nobody knows what open source is and they don't even care.


The app store problem is also there in various review sites. For instance, my plotting app gets quite a few satisfied users, albeit very few external contributions, but it get some extremely lousy reviews from people who've run it for two minutes and not read the documentation, particularly on Mac websites, e.g. https://www.macupdate.com/app/mac/21029/veusz (a site where I didn't even upload it).


Hey all. I'm on psudo-vacation, so I'm just going to leave this one comment and not read the rest of this thread or respond to anyone:

1. This was a few weeks ago, but I literally woke up, grabbed my phone, checked my email, and had this sitting in my inbox. Not exactly a great way to start your day.

2. Said person eventually apologized to me, and apparently didn't understand what open source meant or something? I don't hate him or anything. We all have bad days. I'm not perfect either.

3. The reason that this gem is missing those emoji is twofold: I cannot distribute copies of Apple Color Emoji due to licensing, as I mentioned in the issue. IANAL, but gemoji is infringing on Apple's IP. I'm not willing to do that. For more on this issue: http://words.steveklabnik.com/emoji-licensing Secondly, for some reason, Phantom Open Emoji doesn't have the full set.

4. If you're willing to infringe on Apple's IP, you can use your own images, and then it all just works.

5. It states in the second line of the README that this uses Phantom Open Emoji, contradicting what the author said in the issue.

6. I actually have issues open to integrate Twemoji and Emoji One, which I assume have the full set?

Burnout on open source is real, and many, many days, I feel like it's all take and no give. If you run a company, please give your employees time to contribute back to the libraries you use. It scares me how much of the world runs on top of stuff that people basically do in their free time. It's not sustainable.

(an addendum: thank $DIETY GitHub lets you lock issues nowadays, or I'm sure this would be filled with terrible .gifs)


In the US, rasterized font representations are not copyrightable, in contrast to vector representations. Emoji are very clearly a font, and Apple uses a rasterized format, so using Apple color emoji is fine in the US.

http://en.m.wikipedia.org/wiki/Intellectual_property_protect...


That's a leap that's far from guaranteed by the cases summarized in your link. A court or the copyright office could just as easily say "just as the latest digital outline fonts have elements that can be protected as software, emoji have elements that can be protected as visual art."


But this person's username is emojiofficer, that clearly means they're the official emoji officer and they must be right...


The user who filed that bug is Jake Lodwick, co-founder of Vimeo:

https://en.wikipedia.org/wiki/Jake_Lodwick


Someone who should know better, then. Disappointing. Perhaps he was simply having a very bad day.


Anyone else feel uncomfortable by the above comment.


Not uncomfortable, but disappointing that someone, who founded their own company, would lash out to someones work that decided to share to the world for free.

There is being rude, and there is being down right disrespectful.(which has been displayed in that comment)


Not really, I think both guys in the issue discussion are obviously very smart, and I can identify with their respective frustrations.

I do think Jake's comments are a little harsh as the README refers to Phantom Open Emoji in the 2nd paragraph -- however if I had just spent hours debugging something like this, making an annoyed issue on GitHub could be the outcome.


Why should they? Jake already revealed his full name over at Github.


If Reddit has taught me anything it's that linking information about someone people may dislike sometimes leads to harassment.

Hopefully the HN crowd is mature enough to engage in such tactics but I have a very low faith in any internet community in general.


He has used his real name and posted his personal website on his github profile. What's the problem?


At least HN is a notch above GamerGate


Yet he mocked the existence of a open source project not that long ago

https://harthur.wordpress.com/2013/01/24/771/


I remember this controversy. https://news.ycombinator.com/item?id=5106767

Edit: See also: steveklabnik's apology. http://blog.steveklabnik.com/posts/2013-01-23-node


This is the same strategy I've used in open source projects. Handling the report is annoying, but then having to go spend time fixing the issue to help someone who is being an ass is soul draining. And it only encourages them and other people to be an ass to get what they want.

So I call them out and close or delete the issue, and if they get frustrated because of that, great! This doesn't mean I won't fix the issue eventually, just on my own terms without giving that person the satisfaction. Makes me feel a lot better.


Contrast with this where someone puts up a short bit of code on Github and is mocked for it: https://news.ycombinator.com/item?id=5106767#up_5106935


This is a much better example. Heather put up code, Klabnik was an asshole to her. He really doesn't deserve sympathy for whining when a user asks that his readme expose the lack of functionality of his project.

That's actually a legitimate bug report, even if not delivered with sufficient kissing of Steve's ass.

What Steven did to Heather, however, is pretty typical of him. It's the way he treated me in our one interaction online.


Well, the readme _does_ expose the lack of functionality in the first line. It links to the underlying library which explicitly states that it's an incomplete set.

Also, because somebody behaved like an asshole in a different situation does not grant me the permission to behave like an ass in a different situation.


Wow. And what a lame apology, too.

The difference is rudeness vs. cruelty. I think the latter is vastly worse.


Well, OK, so Klabnik is an asshole, that's hardly news. It's unfortunately true that participating in OSS, as in any shared endeavor encompassing such a large subset of the species, requires dealing with assholes. The current contretemps (and corresponding HN thread) provides a valuable example, for the novice, of one particular suboptimal strategy, its ramifications, how to avoid it, and what might be worth doing instead.

Of course, that's not to say I recommend novices study HN, especially for advice on how to behave -- God preserve them from such a fate! But, should a novice have happened in by mistake, perhaps he'll glean something useful from this thread in those few fleeting moments before the panic takes hold.


I guess GitHub comments "make it hard not to accidentally be an asshole".


The point I don't get is why he complains about that gem when he obviously found an alternative that better suited his needs. Why for heaven's sake not just use this but raise an issue. If we all started raising issues for for something beeing "not what I was looking for" github would be bursting at the seams. Is he really moping about the fact that the readme does not provide a full list of ALL emojis and whether they are supported? And why is a emoji gem required to work with "massage" and "satellite"?


> I like your gem otherwise, but it's called "emoji", implying that it's the Ruby library for handling those characters.

That's not the first time I've encountered this assumption. I can believe that it makes sense, if you're will to willing to play the part of the layman user: "I want emojis, so I'll just do: gem install emoji"

However, I don't think it's too unreasonable for people with some basic level of experience to understand that there's no central authority granting library names. If it were a core library that came with the interpreter, sure, it's fair to expect that that is the library you're supposed to use. When you get into community-sourced libraries, names are just granted on a first-come, first-served basis for whatever service is hosting them.


> When you get into community-sourced libraries, names are just granted on a first-come, first-served basis for whatever service is hosting them.

Maybe they shouldn't be.

I dislike Apache being called httpd in yum, as compared to apache2 in apt. I can see how a package called markdown wouldn't be a port of the original, but CommonMark, and that would be misleading, too.

If a package managing system doesn't care, it loses some pride in my eye.


The lack of a central authority for names hardly absolve individual library creators/maintainers of the responsibility to choose appropriate names; closer to the opposite, surely.


Pertinent follow-up. Jake was naive about open source norms.

See twitter conversations: https://twitter.com/jonathanwallace/status/53368051800961433... https://twitter.com/jonathanwallace/status/53367933259062886...


Maybe naive, but also impolite. Opening an issue with a passive-aggressive tone isn't likely to be productive.


That's really the problem here. Ignorance is excusable, especially in someone who hasn't got a lot of experience yet. Rude ignorance is never so, especially around a library on Github where, if it's really that big a damn deal to you, you can always just fork, edit a big "THIS IS NOT APPLE COLOR EMOJI" note into the readme, open a PR, and see what happens.


I think this misses the point, if someone doesn't understand open source etiquette then I would give them a friendly reply. Even if it was mentioned somewhere in the documentation, I understand that people can miss it.

It's just that if someone speaks to me in that tone, regardless if this is an open source project or if I'm working customer service for a product, I'll still think they're acting like an ass. It's not a huge deal, people act like asses all the time, but why not just raise the issue in a friendly manner?


FWIW - the guy in question (Lake Jodwick) did apologize for his behavior:

https://twitter.com/jakelodwick/status/533777782484897792


I don't find the opening post to be rude. Jake Lodwick simply states that he's wasted a lot of time tracking down a known limitation that should have been listed in the docs, and that he feels Labnik could try a bit harder to avoid wasting other people's time. Probably Jake was frustrated there. It's not something I'd consider worth posting, but he was hardly abusive.

Then, Labnik's post is pointlessly emotional and irrelevant, making a big deal out of a simple complaint. I feel like working with people like him would be more likely to make me burn out on open source. The author is acting dramatic and overreacting to a relatively mild comment.


Sounds a great deal like what I've gone through in my attempts to evangelize Tcl as of late.

http://morderwerk.de/Spoken.png

http://morderwerk.de/He%20really.png

http://morderwerk.de/hates%20potheads.png

http://xan.pw/twitter/


I recently got a bad review of one of my free WP plugins. The same guy published negative reviews for 3-4 other plugins also in row in the next days. Apparently some people are just mentally disturbed. If you think the emoji issue report was rude, have some fun with these "reviews"

https://wordpress.org/support/topic/everybody-thinks-they-kn...

https://wordpress.org/support/topic/bad-and-misleading?repli...

https://wordpress.org/support/topic/bait-plugin-for-google?r...

https://wordpress.org/support/topic/no-support-weak-plugin?r... (I made the mistake to answer him which resulted in another set of awesomeness).

You just have to develop think skin. I'm still learning this slowly.


> I've yet to find any plugin (Free) that actually performs functions of a job board.

That is some intense entitlement right there.


I'm guilty of some severe cases of bike shedding bug reports back in my blunder years. Within my small model of reality I couldn't grasp why people wouldn't implement minor feature xy as it would have costed them seemingly only 10 minutes of their time. I appologize to anyone who had to deal with these.


Regardless of the specifics of this case, I do feel like there is such a thing as "burning out on open source", a topic which is of interest to me at this point. I would like to read other people insights about this, this would probably help me better at setting proper boundaries in my own projects.

I found myself often struggling to deal with this kind of issue: How to be sure whether you are being used (possibly not even on purpose), or whether the issue raised really benefit the whole project?

On one hand we don't want to be used, on the other hand, we don't want to chill contributions of good ideas. It can be tough sometimes to assess properly (keeping in mind we all have bad days on top of all this).


I had a similar "open source burnout" recently. Since you asked for it, there is a blog post I wrote which might be of interest: http://nxlog-ce.sourceforge.net/why-the-gpl-does-not-work


I don't relate to your blog post. I am definitely not second guessing my use of GPL. That is another topic than the one here as far as I am concerned.


I maintain the gitignore.io repo with about 900 stars and thankfully the contributors aren't as snarky. I will say that the users of gitignore.io are probably more on the technical side, but it just seems like Jake is not familiar with the culture of FOSS. That being said, He's a 'customer' of your 'product' and even though his delivery isn't the best, there may be something you can take away from suggestion.

When I'm evaluating a FOSS project, the first thing I try and do if I find something wrong is see if there is a way I can fix it and submit a PR. Then if it looks like it's out of my scope, I'll file a bug or look for another project.

For gitignore.io, I often take product decisions from the community, but I like to have a discussion about what the best course of action is. I still have open issues in my backlog that I just haven't found an elegant solution to yet. Thankfully gitignore.io has a small enough feature scope that you can't do much with it, otherwise i'm sure the project would become overbearing very quickly.


I'm not sure I understand, what is there to see in this link?

Is there some underlying message to all this? Oh well, the issue was handled poorly or maybe the guy just went too far with this accusations, so what?

How'd this get to the front page?:O


When the producers of open source programs, scripts, and utilities spend some of their time, intelligence, and thought on this planet to produce something useful and give that product of their effort away for free, it gets seriously disenheartening to have someone else make a dumb comment, or create an issue out of anger which is unjustified due to the consumer of that product not having read either the documentation, or the source code they decided to use.

Other ways of pissing us off are asking a question which is obviously facepalm-inducingly stupid due to again not having read the documentation/code, or trying to use the product whilst simulataneously not having the first clue on what they're doing (which could be because they're new at coding or handling computer systems in general).

When a producer of Free Stuff gets the kind of bullcrap described above, it wears them down over time.

I have encountered this with my stuff - especially in comments on my blog. I do try to answer questions and be as helpful as possible, but there are some people out there who you just know can't be bothered to do some basic research, or read your helpful instructions, or are basically just too lazy to learn and only want to consume without thinking.

This is what wears people down. It's not just one crappy issue being raised on your stuff in Github, it's the accumulation of this cruft over time - like hundreds of straws piling up on your camel's back - eventually it'll break.


As maintainer of OS project I find this issue justified and constructive. It points to usability problem and how to fix it (documentation). And poster did his homework by debugging script first. He enumerates missing chars (easy to unit tests!) and clearly spells reason (underlying library).

I would love to have such reports all the time!!!


As a creator and maintainer of OS projects, I have to disagree for the following reasons;

1) It is clear from the issue raised, that the creator of the issue did not do his homework. This means actually looking at the README file, and, seeing that the project "exposes the Phantom Open Emoji library unicode/image assets and APIs for working with them", proceed to the link to the Phantom Open Emoji library that the author took the time and trouble to provide a clickable link to , and read on from there.

2) Additionally, the creator of the issue then posted a link to an alternative project.

Ergo, not only was the creator of the issue being lazy in the first place, he then tried to punish the author of the project for that laziness. If you really cannot see this, then I suggest looking again at the project's README, how it describes itself, clicking through to the Phantom Open Emoji library link provided, and reading the information there. Then re-think your opinion on this matter.


Keep in mind that every alternative free library to do something adds cost to the task of selecting a library. Some open source projects (not suggesting any specifically) actually do make life worse for people because they spend time studying it only to find it's not useful.


In my book, spending the time to see whether something is useful (or works) or not, is called "due diligence".

I'm also of the opinion that the time spent raking through libraries that look useful to you to find out if they really are useful to you, more than offsets time you'll spend looking for bugs in your program which were caused by using something which turned out to not do what you thought it did.


It's a silly and petty jab at the maintainer of a small open source project. Fighting with people on these "complaints masked as a fake issue" is one reason people sometimes burn out on maintaining open source projects.

- -

For a similar scenario: Imagine if some tiny indie band put up a song or two on their own website for free.

Now imagine if the top response said "You songs aren't as good as Taylor Swift's songs. You should disclose that your band isn't Taylor Swift, so I don't waste my time listening to this, and you should take these songs down and replace them with pirated copies of Taylor Swift songs, because I like them better"

That's effectively what's happening on this issue, in open-source-code form.


He didn't pick on the underdog, don't give this false impression. The bug report was certainly not nice, but it was not answered by an unknown anonymous grunt of the open source movement, we're talking 15k followers on twitter.


I think the "Public Contributions" section of the two users says it all:

https://github.com/jakelodwick

https://github.com/steveklabnik


I think it's the entitled aspect of some open source users this is demonstrating.

They expect everything to be the way they want it. they want all opensourced stuff to be polished, supported and free, without wanting to help out or chiping in.


Your comment and (as of this comment, anyway) the thread of replies is one reason why I think using a person's opensource contributions as part of an evaluation of their suitability for employment is a bit ridiculous. There is a whole range of completely arbitrary and subjective "measures" around such contributions, and they end up being no better filters than any of the other (flawed) filters people use to evaluate such things these days.

It may have held (marginally greater) value at some point, but at this point it is just another bullet point clueless HR managers and petty managers can stick next to the "alphabet soup" in their job descriptions.


This is overly cynical. It can be a meaningful positive indicator, and simply not a data point if a candidate lacks one.


That's overly charitable. It can be a meaningful positive indicator, but only the same way that any other work experience can be. Compare that with the proliferation of requirements for experience in specific languages rather than for specific (but more general) engineering ability, and I think my cynical take isn't overly cynical at all.


On the other hand, people use open source to market themselves to promote their talks, books and consultancy gigs. You have to accept the negative sides of that as well. People will start to question the motivations of your contributions. People will be annoyed when the code you promoted has faults in it. Once you are doing things for commercial gain then people's attitudes towards you will shift. That seems inevitable.


>they want all opensourced stuff to be polished

That would be nice though.

Why would you release something to the public and put your name on it if it's lazily done?


This would be ideal, but in my experience evaluating some open source libraries, they were clearly works in progress or abandoned. I think people had good intentions when putting the stuff out there.

Maybe because github is free for public open source, stuff gets put out there before its polished?


> Why would you release something to the public and put your name on it if it's lazily done?

No software is perfect. It has either no features in it or has bugs. The assholes will either demand to get the missing features added or the bugs fixed.


Isn't the whole point of Open Sourcing your stuff, is so that others can contribute to it if they so desire?

Whether or not something is "lazily done" is besides the point. The point is - they produced _something_, and the consumer did not. If you see something which you think could be done in a better way, wouldn't a better use of your time be spent issuing a pull request with your suggested improvement, rather than whining that "it was lazily done" ?


Maybe it's because it involves Steve Klabnik, who is a prominent commenter here?

While the tone of the report may not have been very polite, it is understandable why the reporter was disappointed.

I think it's perfectly reasonable for a user to ask that a library's deficiencies be made obvious in some way, regardless of why they exist. The readme file is a good place for this.

I don't think that Steve handled it very well at all, though. Calling the report creator an "ass" is uncalled for. Creating unnecessary drama over a perfectly reasonable request is uncalled for. Closing the bug without adding a line or two to the readme file addressing this deficiency is uncalled for. Preventing further discussion is uncalled for.


"Politeness" is not a vestigial compile-time option, to be discarded in the pursuit of efficiency.

Having a basic respect for another hacker's time on a project they're maintaining out of the goodness of their heart is what causes people to keep maintaining projects.


> "Politeness" is not a vestigial compile-time option, to be discarded in the pursuit of efficiency.

Especially since rudeness is a good way to get drama and nothing done. To paraphrase Neil Gaiman, maintainers are not your bitch. Treat them as courteously as you would like to be treated yourself.


Perhaps if the issue was raised as a pull request with the desired changes to the Readme, rather than just raising the issue as a general whine.

The whine itself stinks of someone not having gone through the source to see if the product really does what they want it to do. It reeks of "hey this looks like what I want YOINK! " , implementing it in their code, and discovering afterwards that some Things are missing. Then getting pissed off at the producer of the product, rather than at themselves for their oversight/laziness.


I shouldn't have to look through the source code to see if a library does what I want it to do.


That is absolutely what you have to do with open source. If you aren't willing to do that, don't use OSS.


I've been using open source for 20 years and I don't think I've ever had to do that. Sometimes I have to fix bugs in a library or ditch it because it's a piece of crap. However you generally shouldn't have to read the source code to see what it actually does. If so, that's just laziness on the part of the author (and it's wasting everyone's time).


I think this post is attempting to make the exact opposite point? The issue reporter is effectively ranting that the gem isn't good enough, and because it's called "emoji", he for whatever reasons feels entitled to this rant.

I don't see anything wrong with the maintainers response..


someone wanted to launch the hivemind against the bug reporter because he was not deferential enough.

The irony being that the victim is a member of Ember.js who is bullying the rest of open source on twitter while touting how they are saving Africa from a Portland coffee shop.


Not 'not deferential enough', bug reporter is a general asshat. Maintainer seemed well aware of that and replied in kind.

It doesn't matter that the people you are bullying are bullies themselves, that doesn't make your bullying in any way ok.


Wow.

I'm honestly kind of happy right now that none of my projects are very popular....



Why can't everyone be nice to each other? </naive>


Basic queuing theory says that if the rate at which issues are opened exceeds the rate at which they are closed (which is easy to do if the project is popular), the number of open issues will grow without bound. The result is that most bugs filed against any popular project can't be acted on. A good UI would help people understand this and set expectations accordingly. It's still very useful to have a database of known limitations and workarounds.


The point I don't get is why he complains about that gem when he obviously found an alternative that better suited his needs. Why for heaven's sake not just use this but raise an issue. If we all started raising issues for something being "not what I was looking for" github would be bursting at the seams.


Yes it's hard at times, I especially have trouble maintaining Django-Facebook as both of those dependencies change so freakingly fast. Let me know if you want to help out :) https://github.com/tschellenbach/Django-facebook


AKA:

Tech Support Customers

Solution:

http://www.despair.com/apathy.html

---

In commercial software tech support is probably the biggest draw of energy, but is harder to ignore them than in volunteer-based efforts (like open source, tech forums, blogs, etc).


There are many, many activities, paid and unpaid, in which people get confronted with entitled a-holes on a regular basis.

This is not unique to open source, or tech in general. This is a generic social issue.


The reason I stopped being the maintainer on a popular jQuery library was the wave after wave of incompetent folks asking me to do their work for them. I don't mean mere API questions, or asking things around how the plugin works or does what it does. These were entire "Integrate this for me" questions. People unwilling to do the bare minimum of work. No matter how many examples or how much documentation, these folks flat out wouldn't do their own work. Beyond that, most of these weren't being asked by some 12-year old learning to code, these people would link to their commercial site and expect me to "Give them teh codez"

In retrospect, I should have taken the hard-line approach and directed everyone to StackOverflow and limit GitHub to an issue tracker. When it came to assholes making asshole comments and requests, I had no problem telling them to stick their overbearing request where the sun doesn't shine. Of course those folks were few and far in between.


I wrote the Python library that handles Microsoft Word files. My entire inbox was filled with people from Bangalore and Hyderabad asking me to do whatever work was outsourced to them. The library came with an example of creating, modifying and saving documents that answered nearly all of the questions, and a README that pointed people to it, along with other resources people could use.

I've since passed the library to someone else who has a lot more patience than I.


Isn't it kinda racist to say "people from Bangalore and Hyderabad"? As I'm sure many people from Hyderabad and Bangalore are very competent people who are willing to pay for support. How would you feel if people replaced Bangalore and Hyderabad with London and Liverpool? Even if there are people like what you describe that live there?


The truth is never racist, it's just a fact. I'm not saying parent's description is accurate, but distorting facts to conform to somebody's desire for political correctness is on a similar level of despicableness as racism itself, imo.


He didn't post entire logs, but he mentioned their origins, as if it were important. That is what could be racist. Mentioning race in situations where it isn't important implies correlation on the part of the speaker.


But the parent lacks facts, therefore it is not proven true. Just leave out this one sentence: "My entire inbox was filled with people from Bangalore and Hyderabad asking me to do whatever work was outsourced to them."

Do you seriously think that they had 15GB of email? It's a pretty small email provider that doesn't support much space and filters. I think "entire" and "filled" are most likely examples of exaggeration, not facts.

Was it really "Bangalore and Hyderabad"? They had it in the signature of the email? They did a statistical analysis on where they came from? None were from Eastern Europe, Japan, the US, England, or college students? Most English native speakers I know have horrible written communication skills. This is also most likely exaggeration, not facts. Even if you traced the IPs of the messages you would still not be able to claim location, we all know how IPs do not correspond 1:1 to physical people.

He knows that they were doing it because they were outsourced to? They stated that in their questions? I would love to see some evidence of this. Even if they did "fill" his inbox, with messages truthfully stating they were from Hyderabad and Bangalore, they also told him that it was work that was outsourced to them? I doubt that is even exaggeration for effect.

I would like to see this 15GB archive of email showing that proves this is true. Either that, or it seems to be a gross generalization targeted at a specific race or group of people. Which isn't just racist to people who have fallen victim to over sensitivity in service of political correctness.


It's targeted as a specific group of people: outsource workers. That you conflate that with race says a lot about you.


If it is literally true that 80% of the emails were from India, then it's not racist to say so.


Why does a statement being 80% true make it true? Could 80% of 80% of it being true make it true enough? You can just keep multiplying until you get to one email being enough.


What's racist in stating a fact?


Judging by the way the racism card has been thrown around in the media lately, I'd say something like this is very likely to happen (if it weren't for it's ridiculousness): "Study finds library XYZ has only 5% of minority A. Therefore, library XYZ is unfairly discriminating against minority A".

They then go backwards to post-rationalize and assign reasoning/causation in order to 'explain' the discrepancy. "Well, 20% of all developers are of minority A, therefore they are not fairly represented if there are only 5% of them using this library."


Racism isn't the statement of a facts, racism holds that people should be treated differently based on their ethnicity or culture. As see nothing in the parent comment that is stating people should be treated one way or another.


Does stating something make it true? I don't see any facts being backed up in the op. Stating things that are backed up by data help, but I would say that any time that ethnicity or country of origin are the only thing that you measure, you end up making the picture more cloudy. There are things that span ethnicities and cultures such as education, IQ, and work ethic that predict much more about success and failure than ethnicity or culture.

You've probably heard this before, but correlation is far from causation.


If you ever want to go back in OSS development, include a disclaimer that you are more than willing to integrate it into their site, at your usual rate of $X00 dollars per hour, with a minimum of $Y hours.

The worst that might happen is that somebody takes you up on that.


Agree. The way to answer"do my work for me" is "Thank you for inquiring about Commercial Support offerings ...."


That does not really help - people he's talking about simply do not read and do not care about what you did. Going through bunch of soul-sucking emails/messages/issues every day, even if you do not answer, is a huge demotivator for any public development work :/


That's the big thing for me. It's not the lack of a witty response or a canned reply. It's knowing you did something for free, out of love, and there's an endless stream out people going "more! more!" and getting angry when you won't accommodate their edge case.

I had my phone number on one of my personal sites so friends could get in touch with me. Took it down after a week because people would call me in the middle of the day for plugin support, even though there's a forum for support. There's nothing inherently wrong with that, it just wears you down. Makes you afraid to check email or answer the phone.

Edit: Without getting too deep into personal territory, I'm coming to terms with the fact certain aspects of my childhood trained me to always put other people's needs above my own. Saying "no" has a psychological cost for me because I reflexively beat myself up for being a selfish person.


Could it be a good idea to create a service where people can help with FOSS projects by being the 'intercept' between messages and the maintainers? I feel to inexperienced to help out with actual coding, but helping out with support emails or tickets (and only forwarding those that seem useful) is something I could see myself doing, for example.

And I could imagine that after helping out in this way for a while, I'd feel more inclined or more self-confident to start helping out with code.

Or does this already exist?


I don't think that such a service exists, but you can still do some of that. Pick any open source project you like, hang out on their tracker and IRC channel and answer questions. You might not have the permissions required to actually close issues, but you can certainly do some grunt work: Try to reproduce an issue, give concise description in a comment, create a PR with a test case etc.

IRC channels are a good place to start if you know a little about the usage, but not much about the actual code: Answer beginner level questions first. For any moderately complex project there's always tons of these. And when you feel confident, move forward to more complicated ones. It's a great way to learn.


Why can they simply be ignored?

I run a support department (for a closed source product) and we do this all the time.


I'm in the same situation with a popular jQuery library. I did manage to get one integration to pay me about twice my normal hourly rate because it's just a few hours of work. Most requests don't respond once I offer to do it for money though, so I'll probably need to advertise it.


This is kinda why I dislike Github and JavaScript. There isn't enough friction to force people to stop and think before they ask stupid questions. Previously, things like that were limited to random forums, IRC or mailing lists, "I'm trying to do X, can you do X for me?". Now that lack of culture has infected popular projects that are on Github.

It's strange though that this doesn't seem like a huge issue for projects that have their own issue trackers and wikis...


Sounds frustrating. I'm in a patient mood this morning and I feel like testing my patience; do you have any links to these discussions?


Not OP, but the form builder I created gets its share of "issues" such as [1], but more-so attracts a ton of mail of the same kind..

[1] https://github.com/minikomi/Bootstrap-Form-Builder/issues/10...


Well at least that guy is humble, polite and willing to pay. On the other hand, you've closed the issue without telling him why, so he doesn't even know how to correct his behaviour next time.


He also sent me an email which I replied to.


A pull request where two guys acted like jackasses towards each other, and where we instinctively try to pick sides based on our past experiences and beliefs.

I think really thinking on why I'm siding with one person almost immediately despite not having much context in this is really revealing and maybe not a little unpleasant.


One of the guys wrote something and published it as open source. The other got to use it for free but still complains with an inappropriate tone. Hard not to side with the first one by default.


I can't bring myself to care about the tone people use to speak to me when they're just listing facts.


It also depends on who is saying it. A person you know online and your manager carry different weight.


Offering incomplete software as open source doesn't make it any less incomplete. Are we giving out blue ribbons for participation now?


What the hell does "complete" even mean? No software is ever "complete".

Literally every open source license says something along the lines of "there are probably bugs and stuff; it's not my problem".

I really can't even comprehend this mindset of "unless it'll work for people without issues, don't put it on github".


Also, since when was there a definitive list of "over-animated emoticons" that one had to fulfil?


In this specific instance, calling the library "incomplete" is a less-than-completely-accurate characterization. What the issue creator wants is easily possible using the library, but cannot be included as default behavior because of licensing issues. This is hinted at, but perhaps not made as explicit as it could be, in the README.


It is perfectly complete and exactly what it claims to be. It's just not what whatsisname expected it to be. Are we expecting OSS developers to be mind readers now?


So the alternative in your view is to not offer anything at all unless it's complete by some objective standard? Does that really sound preferable to you?


An alternative is to offer it, but mark it clearly as "incomplete" or "alpha" (which is what one of the original complaints was about). Versioning it would be even better (say, call this "emoji 0.1").


No-one asked for blue ribbons or sympathy.

If someone whines about a perceived shortcoming in stuff which has been released incomplete, but free and modifiable, then they can expect short shrift.


They should expect that, but instead they are getting sympathy in this thread, quite ironically:

https://harthur.wordpress.com/2013/01/24/771/


Apparently we give out blue ribbons and $$$$ to corporations who deliver incomplete software. So yeah, why the fuck not for open source? ;)


Note it's not a pull request; it's an issue in the tracker. Had it been a prepared patch, I would have more sympathy towards the reporter.


Actually while I posted earlier about the 'show me the codes' people, this guy isn't really one of them and I might have felt bad for implying it was.

It might be reasonable for an emoji library to say 'ALPHA: missing a few characters' to stop people from trying to debug non-existent rendering problems - but he puts this in a very aggressive manner.

As you said, they're both wrong (and right) in their own ways.


> A pull request where two guys acted like jackasses towards each other, and where we instinctively try to pick sides based on our past experiences and beliefs.

A Github issue where a user behaves rudely and labours under the misapprehension that he is owed anything by the person who made his work available for free. All that because of a limitation of the underlying library he would likely have found out about if he had bothered doing his homework. It's not very difficult to pick sides here.


[deleted]


Almost all countries are signatories of the Berne Convention, meaning that works are under copyright protection automatically, without requiring copyright notices. Similarly, no license mentioned means that you only have the rights given to you by law (such as fair use or fair dealing).


so much this ++


By the way... what is the raison d'etre of this gem? I just don't get why anyone think it's a good idea to replace a character with an image. It's like to replace all "e" characters in this comment with a .png congaing a fancy custom "e"...


> It's like to replace all "e" characters in this comment with a .png congaing a fancy custom "e"...

So, uh, like Web Fonts, then?


you mean "in a totally different way", do you?

you are comparing a gem replacing, in a string with html content, a text fragment with an '<img />' tag, with a way to load and apply custom font from a remote location to a web page text region.

While, closing one eye, the effect of the two solution are similar, the solutions are totally different from the technological point of view, from the abstraction layer when they are applied to the practical implications (try to do a simple cut-n-paste from the browser to a text editor, for example)


I know they're technically different; what I wanted to point out is that it's not such a far-fetched idea.


Mostly because a lot of browsers do not support emojis at all, and they’ve become pretty ubiquitous.


They're a mean to be expressive via text ... and I really hate the fact that apps are replacing the text with the image.

I can always recognize what a string of emoji is supposed to be (there will be obscure one, but then that's entirely dependent on who you're communicating with). Replacing the emoji with the image means that I now have to decipher the image. Not to mention that everyone does it differently. For example, ":))" and "=))" is not the same, and it's really hard to guess which one is which in most of the apps.

Yes, I know this whole comment is silly...


This is in reference to the Emoji Unicode code pages, not ASCII emoticons. Characters like 👾🍭💔💩

It seems like the image pack they were using did not represent the full Unicode set.

ATM, there are still many applications which either don't have access to fonts with those characters or don't otherwise work with code points in that range.


You may take issue with Mr. Lodwick's tone, but he's not wrong. This gem is incomplete, and for a gem occupying the namespace "emoji", I think it's reasonable to expect the full, standard set of emoji. Passing the buck to another open source library is irresponsible and, frankly, lazy.

Perhaps the maintainer should burn out, and let someone take over the gem who'll commit to feature-completeness.


I'm really trying to avoid saying "Pull requests welcome" but it is darn tempting.

Full disclosure: I'd consider "the maintainer" -- a gentleman named Steve -- an Internet buddy of mine. He is a real person, just like you. When he's not doing excessive amounts of free work for for-profit corporations, he enjoys philosophy and Netrunner. (Edit: Steve has contributed code and a lot of non-code scutwork to dozens of projects in the Ruby/Rails ecosystem, including -- off the top of my head -- Rails, half of why's body of work, Shoes (a pedagogy project), and, oh yeah, the emoji gem.)

You appear to have the notion that Steve owes you quite a bit of work regarding publishing knock-off versions of Japanese cell phone character sets. This is an interesting entitlement to have, not because it is unique -- no, the OSS community includes lots and lots of people with it -- but because you've chosen to throw down the gauntlet over approximately the most trivial problem space ever addressed by an OSS project and it is one you don't even use. And for the sin of not making it easy enough to consume the free solution to that problem space (which is -- for bonus irony points -- because Steve actually was a conscientious OSS developer and went the extra mile to avoid infringing on the copyright law that OSS is vitally dependent on), you're wishing ill on him.

You can, should you choose, publish a competing emoji gem. It will be whole keystrokes away from Steve's. Should you achieve success with it, the Google gods will even look upon you with favor and put it one notch higher than the Internet.

Instructions for building and publishing gems are available on your local Internet. Godspeed.


> Passing the buck to another open source library is irresponsible and, frankly, lazy.

Did you read Steve's justification for the limitation? "This other library is infringing copyright" isn't passing the buck.

> Perhaps the maintainer should burn out, and let someone take over the gem who'll commit to feature-completeness.

There is a handy "fork" button on Github. Of course, entitled bitching is a lot cheaper than maintaining a library, emitting a pull request or spending precious bytes on a modicum of courtesy.


>for a gem occupying the namespace "emoji", I think it's reasonable to expect the full, standard set of emoji.

It may be reasonable, but it's not correct. Unless there's a central authority assigning and approving namespaces for gems, then insisting that authoritative-sounding names actually be authoritative doesn't reflect reality. "Emoji" really doesn't mean anything other than "here is a unique string to differentiate this package from all of the others." Describing what it actually does, or doesn't do or contain, is what the readme is for.

I'm not arguing that namespaces should be arbitrary and essentially meaningless, just that for the most part they are.


It isn't just the tone that I'd take issue with. The person who reported the bug is also implying that the library author is either negligent or incompetent. I consider this to be an extremely uncharitable attitude.

The library author is a person who's taken the time to publish their work for free. If one finds issues with the library, the polite thing to do would be to first ask about it instead of complaining. There are likely good reasons for this (and lack of time is a very good reason). A simple "I find you aren't supporting these emojis. Is there a reason for that and can I do anything to help?" goes a long way.


> Perhaps the maintainer should burn out

I find this comment in poor taste. A burnout is not something I wish to anyone.


To clarify: by "burn out" I'm referring to becoming tired with a project. I'd hope that the maintainer would simply move on to another project.


What do you mean by "move on"? I'm sure Steve hasn't been spending the majority of his finite amount of time since he put the emoji gem code up on github working only on the emoji gem.


Have you ever maintained a reasonably popular OSS project?


The problem with this line of thought is that the number of serious contributors to FOSS is very small, the number of projects that need maintenance is large, it's not realistic to expect that someone will come in and maintain it if you step away, particularly for a small, limited-scope project like an emoji library.

The difference is not between an incomplete gem and a complete gem, it's between an incomplete gem that's still being maintained, and an incomplete gem that's not being maintained.


> I think it's reasonable to expect the full, standard set of emoji.

What full, standard set? Is there an RFC that sets it out, possibly called Annoyingly Animated Smilies From Japan?


As a matter of fact, yes! http://www.unicode.org/reports/tr51/


Haha, cheers. This document http://www.unicode.org/Public/emoji/1.0/full-emoji-list.html seems to indicate that even if the dude had wrapped the Apple set of these damned things, it still wouldn't be definitive, which would make for fantastic bug reports about how we're missing 'ferry' and 'disabled car'. This reliance on pictorial fonts is making me feel very old. Get off my lawn you damned kids with your cleverphones and your wing dings smilies.


Replying with an attack and closing comments is definitely something a douchebag would do. Free or opensource doesn't mean you get to be irresponsible about what you release or maintain, if your project has some caveats they should be listed explicitly.


Actually, it does-- have you ever even READ the MIT license?

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: