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.
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.
"Corporate culture" environments where everyone is at "Stepford Wives" level of jollyness rarely get much done.
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.
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.
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.
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.
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.
That theory seems to be the essence of this entire debate.
I'm not sure I follow...
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.
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.
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.
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?
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.
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?
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.
Second line of the the readme
> 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.
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.
GH = GitHub
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.
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)
There is being rude, and there is being down right disrespectful.(which has been displayed in that comment)
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.
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.
Edit: See also: steveklabnik's apology. http://blog.steveklabnik.com/posts/2013-01-23-node
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.
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.
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.
The difference is rudeness vs. cruelty. I think the latter is vastly worse.
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.
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.
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.
See twitter conversations:
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?
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.
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.
That is some intense entitlement right there.
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).
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.
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
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.
I would love to have such reports all the time!!!
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.
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.
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.
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.
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.
That would be nice though.
Why would you release something to the public and put your name on it if it's lazily done?
Maybe because github is free for public open source, stuff gets put out there before its polished?
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.
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" ?
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.
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.
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.
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 don't see anything wrong with the maintainers response..
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.
It doesn't matter that the people you are bullying are bullies themselves, that doesn't make your bullying in any way ok.
I'm honestly kind of happy right now that none of my projects are very popular....
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).
This is not unique to open source, or tech in general. This is a generic social issue.
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've since passed the library to someone else who has a lot more patience than I.
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.
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."
You've probably heard this before, but correlation is far from causation.
The worst that might happen is that somebody takes you up on that.
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.
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?
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.
I run a support department (for a closed source product) and we do this all the time.
It's strange though that this doesn't seem like a huge issue for projects that have their own issue trackers and wikis...
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.
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".
If someone whines about a perceived shortcoming in stuff which has been released incomplete, but free and modifiable, then they can expect short shrift.
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 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.
So, uh, like Web Fonts, then?
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 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...
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.
Perhaps the maintainer should burn out, and let someone take over the gem who'll commit to feature-completeness.
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.
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.
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.
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.
I find this comment in poor taste. A burnout is not something I wish to anyone.
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.
What full, standard set? Is there an RFC that sets it out, possibly called Annoyingly Animated Smilies From Japan?
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.