Taking a month off from OSS volunteering - <AUTHOR> https://snarky.ca/why-i-took-october-off-from-oss-volunteering/ <comment><USER2> For me it was very stressful to learn how to cope with that, and fortunately I'm paid at least to do the bulk of the work I do (that is, all the work on Redis is paid). However once you learn the mental attitude to have towards this issues, they disappear magically. It's you VS many people, and as the user base increases, there is _no way_ you can handle issues and PRs. The contributors need to adapt in order to make your work as simple as possible, otherwise their issues/PRs will get ignored. I personally cherry-pick among the ones that are easy to read, understand, general. There is always who will say, don't you feel ashamed?!!11 Redis has tons of open PRs / Issues! When people tell you this, always focus on what you did of good and not on what you can't do well enough. In case of unpaied OSS work, the attitude should be to do it only to _have fun_ and _learn_. There are no other justifications: IMHO it's very wrong to donate time to OSS like if it was a charity, OSS is used by companies doing tons of money and startups that sold for _billions_. Nobody cared about redistributing back money to authors of the OSS that permitted them to create (alonside with their great product) this result, so you as an OSS maintainer should only care to have fun.

EDIT: I think it is very important to outline how in my experience 99% of the user base is _wonderful_ , splendid human being, nice, willing to help. It's just that the wrong 1% is very verbal and if you focus on that one is terrible, but I believe it is hard to find an environment like the "Underground IT/OSS" scene from the POV of people quality. It's just that's impossible to get zero-assholes-environments.

EDIT 2: To other OSS maintainers, a trick is to be super gentle with harsh people. You'll feel much, much better compared to using their own tones.

<comment><USER3> Do you think there's room for contributors to OSS outside filing bugs and making pull requests?

I'm a technical product/project manager by day and a hobby programmer by night. Things like writing documentation, triaging issues, coordinating teams, and planning releases is my bread and butter. I'd like the idea of spending time on an OSS project(s) that I find interesting, but I wonder if this is the kind of thing that would be welcome or even considered helpful. OSS projects are passion projects, and it feels like trying to help out uninvited with management tasks would come across as asserting ownership.

I do try to contribute what I can, but they're small hit and runs -- update deprecated information in documentation or add some examples, add more information to bug reports, etc., but I'd like to do more. Just without offending anyone :)

<comment><USER4> It would be very easy to contribute by writing documentation to most open source projects, they'd be happy to take it.

Coordinating teams and planning releases.... I think a lot of open source projects could _use_ help planning releases (release management is incredibly important), but I'm not sure they'd _take_ it from a stranger they didn't trust (and they might be right). "Coordinating teams" not as sure how it would even look or would be needed. But anything that looks like being a "boss", people are going to be resistant to, esp from a newcomer stranger, for obvious reasons.

But I bet people will welcome documentation contributions with little hesitation. For the rest... if you want to try, I recommend taking a product you're familiar with (as a user, not a developer), and offering your services being very careful to come from a real service perspective. Your job is to figure out what they need help with and how they want it done, and help them do it -- not to tell them what they ought to want to do or how they ought to want it to be done, not at first even to helpfully _suggest_ it. At least not until you've built up a lot of trust.

After writing documentation, I think the thing you mentioned people would be most welcome to and least resistant to would be 'triaging issues' \-- but I think you'll have to build up some trust (say, by writing documentation!) before people will be willing to trust you with it.

<comment><USER5> >But I bet people will welcome documentation contributions with little hesitation.

People should treat documentation issues the same way as critical bugs IMO. Can anyone point me to projects where this is done? e.g. documentation category on a bug tracker, open issues requesting additional documentation.

<comment><USER3> I remember noticing Vuejs using the issue tracker for documentation in the lead up to their release of 2.0.

FreeBSD also does this, which will surprise no one who has ever read the FreeBSD docs.

Also, one of the reasons I asked this question in response to antirez is because the Redis docs are excellent and have been since I first set eyes on the project three or four years ago. I don't know what he's doing or how he does it, but whatever it is, it's working.

<comment><USER2> Hello, I write the doc myself for the most part, since I believe the docs should be only written by persons that wrote the code they are documenting, or that fully understand it in the subtle parts. I happen to also love to write, so it's quite fun for me to do documentation, while I understand there are a seizable amount of programmers that don't like to write documentation a lot.

However to return to your original question of what is possible to do to help, issues verification/triage is a HUGE thing because the issues are of hugely mixed quality. Moreover Github does not help by making users not able to label the issues in order to make them into categories: only the collaborators can label issues.

Another problem I face is high quality QA, that is, a person that explores certain parts of Redis to understand where there is a quality problem and how it is possible to fix it.

Code reviews are also crucial. For a few months I had a contributor, Sun He, that prevented a number of bugs in Redis by reading each commit and by understanding non trivial bugs just reading the code. Impressive. Eventually he got a job after the university and now contributes only from time to time, but I'll be thankful forever ;-)

</comment></comment></comment></comment></comment></comment><comment><USER6> I have a question for any OSS maintainers:

How should I ask for help/bugfixes/solutions? How can I get across that an issue is a "showstopper" for us without demanding anything? How can I offer solutions or fixes or changes up without contributing to the "burnout" that i've seen many many times from many people that I respect and enjoy the work of.

Recently I was inadvertently one of those nameless-faceless demanders, and I had no idea that I was coming across like that until it was pointed out to me.

I want to voice my opinions, my needs, my use cases without coming across as demanding or winy. And making a PR out of left field generally causes more issues than it solves since it was made without direction or input from the maintainer.

<comment><USER7> Start with a small praise and how the project had currently helped you. Even just a "Thank you for this awesome tool!" goes a long way.

Do a bit of story telling about why you want this or that. Try to make a good case of it.

Post as most as possible, code, backtrace, steps to reproduce, what did you tried, etc. In a structured way.

Assume you may be wrong. Use words like "Maybe", "We probably should", "I may be misguided, but", etc.

Format it correctly, check for spelling and errors.

Finally, reply back when asked for stuff.

It's not that hard, but most people aren't doing it.

<comment><USER8> This is just a general front line support problem. A poor problem description or incomplete problem description is irritating and gets to people. The other one is the people that only show you step #4 of a procedure they are using and keep trying to point to that as the root cause while it was really step #2. An issue report should show from damn near install to the observed problem, or thorough enough logs/config/stacktrace to give people on the receiving side enough information on how you got here. I call this the A-B-C-D problem, where they only keep telling you about something breaking in C but nothing about A, B or D that feeds in.

The assume you may be wrong attitude to take in problem description is definitely something I have seen well received as a reporter and a recipient. Issues that are submitted with a tone of finality and then it turns into a problem resolved by configuration/FAQ/documentation can be frustrating, because in the triage you have to ignore such language and verify anyway.

The unassertive language also clues the reader of potential knowledge gaps in the reporter. Inevitably just by construction of the report

Also this was something that was mentioned in postgres response after I believe Uber transitioned from the technology to MySQL recently- if you are doing something massive/slightly insane it helps build a strategy. A communication issue from VPS host to VPS host for MySQL will require a different diagnostic strategy than microcontroller to microcontroller MySQL connection over an TCP/IP on I2C bus duct taped to the bottom of a Honda Civic.

</comment></comment></comment><comment><USER9> I'm the creator and maintainer of a number of popular open source tools and projects. I even went on to start and build a company around many of them. Prior to that though, I was purely just an OSS maintainer during my free time for 3 or 4 years.

This blog post rings true 100%.

The unfortunate thing is that 99.9% of the community is filled with great, helpful, happy people. But then the 1 in 1000 person comes along that is... less than great... and that person puts a raincloud on your day as a maintainer (or even worse: puts a raincloud on SOMEONE ELSE in the community). And this person usually manifests themself exactly as this blog post states: demanding, lacking detail in requests, not understanding, irrational, rude, etc. They're hard folks to deal with.

I try to remember that THEY are also human. One thing I was taught when I worked at Apple Retail (yes, retail) is that people are angry for a reason. Very very very few people are angry purely to hurt you. Almost everyone who is angry, on the flip side, is angry for a reason and emotions are effecting them. I try to empathize and understand their pain, try to see what I can do to help them. This is certainly a challenge, though. ( See my blog post: [http://mitchellh.com/apple-the-key-to-my-success](http://mitchellh.com/apple- the-key-to-my-success) )

Disclaimer for the above paragraph: I'm not saying the blog poster here shouldn't take a month off. They absolutely should if they feel that would help. The constant berating is very mentally straining.

Something that helps greatly: if you're a happy user, if you had a good experience, just open an issue that says "Thanks". Some people close it, some people leave it open. Either way I promise that that little gesture of good will will really help the morale of maintainers. We don't even mind closing your non-issue issue. :)

As a maintainer looking at an issue list, we see just that: a list of issues. Its easy to fall into a trap of thinking everything is terrible and everyone hates what you do. Seeing happy users on Twitter, at conferences, etc. reinforces that its not all pain and despair.

So from a maintainer: thank you to the community for being so great! :)

<comment><USER10> The thing I have trouble reconciling is a few of you saying 90+% percent of OSS community is great/friendly but the OSS survey in article showing most projects get virtually no help even if downloaded a lot or with lots of requests. It would seem most FOSS users were selfish freeloaders who talked nicely on forums. Your project might attract different types of users, though.

<comment><USER11> I write OSS, and also use a lot of it without helping it.

That's the idea.

OSS can work just fine if we put together N developers, each working alone on exactly one of N projects, while using the other N-1 without helping them. The developer _is_ helping the N-1 by working on his/her project which they all use.

<comment><USER10> I like that. I just dont think most FOSS users are doing that. We could start with number of Apache or Linux users vs number who are FOSS contributors. My model says the disparity would be multiples or exponentially different.

<comment><USER11> The throng of non-programming users is valuable; they provide free testing. Also, they create a feeling of importance.

<comment><USER10> Testing is objectively valuable so long as they send good bug reports. I havent seen a metric on amount of gripes vs actionable reports. That would be interesting data point.

</comment></comment></comment></comment></comment></comment><comment><USER12> Thanks for writing this. It takes a hard head to be an open-source project maintainer and taking a step back and evaluating how to contribute to open source software while keeping it enjoyable is a good thing to do.

I see so much abuse on Github (stuff like "your README is utter garbage" and other frustration, all over, all the time) and it's really disappointing. I don't ever expect the issue-reporting community to change so instead maintainers have to learn how to deal with it, which is unfortunate and leads to the type of burnout detailed here and in numerous other posts I've seen on HN.

Don't give in and quit! Ignore the trolls.

</comment><comment><USER13> Brett, thanks for your contributions to Python. This is coming from a person in the majority of silent users who simply enjoy the fruits of your and other contributor's labor, without complaining and admittedly without giving enough praise. Big props, and hang in there.

<comment><USER14> Brett, thanks for contributions to Python.

(... and thanks to the other contributors, [https://github.com/python/cpython/blob/master/Misc/ACKS](https://github.com/python/cpython/blob/master/Misc/ACKS), and to all people who volunteer their by contributing to open source...)

I am another silent user, someone who lurks on every Python thread on HackerNews but finds the discussion often too contentious to bear.

I know you personally, and I'm sure I've said this to you in person, but maybe you'll accept my sincerity if I say it in public:

You bring a certain sensitivity, a level-headedness and moderating influence to the Python community. Discussion within technical communities is rough, even when everyone is aligned toward the same goal. Any lurker on #python-dev can see how quickly discussion can break down.

These communities need people like you, even though they sometimes seemed designed to grind down people like you.

Double big props, and hang in there!

</comment></comment><comment><USER15> There's been a lot of discussion over years about open source communities, and how curating the community is an important part about that.

If people aren't paid in cash, they need to be paid in other things, like egoboo, kind words, gratitude, whatever.

When people get mistreated while volunteering their time for open source, looking at that from an economics perspective it's every bit as bad as when a company decides it'd rather not pay its employees. It's good if programming is fun, but "fun" doesn't pay the bills, and doesn't advance your career. Reputation and contribution could though.

But it's hard to fix, because the paymasters (the community) don't always care. I think in the long run, the true driver of open source is people scratching their own itch. Most I believe don't do it for altruistic reasons or even for fun, but because they use this piece of software themselves to do something productive, and need it to be better.

</comment><comment><USER7> For maintaining a small OSS tool, it's true that most of the people are rude.

Posting a "don't work with Windows" without any thing more. When asked for a backtrace or an explanation, copy/paste without formatting or anything else. Demanding for a feature without making a case for it. Not using any polite or nice phrasing in a thread.

I don't know the best to react to this. Maybe we should just close their issues without any explanation with just a link to a guideline or something. But, when you care about your project, you tolerate the abuse because you truly want to make your project better despite it.

It's like the rude kid of the article suggesting a new rule, but you actually find it's not that a bad of idea and deserve some thoughts into it.

It's hard to draw a line.

<comment><USER12> > Demanding for a feature without making a case for it. Not using any polite > or nice phrasing in a thread.

In virtually every case where I have seen impolite issues filed or even abusive issues filed, the biggest success has always been when the project maintainers simply ignore the abuse and respond respectfully, as if the request had been worded more politely. The abusive issue opener will often apologize for their tone or simply adopt a different, much more friendly tone.

This is an effective strategy. In the same way that people filing issues need to remember that maintainers are people and should be treated as people, maintainers can also remember that people filing issues are people.

There's no need to act adversarially in open source software development.

<comment><USER16> I'm not sure I agree that is a successful way. In most cases, the person either remains abusive, or doesn't post anything else.

I think the best thing to do is to just delete all abuse.

</comment></comment></comment><comment><USER17> One of the big troubles with OSS volunteering is the current state of technology to communicate with others on the Internet.

In our company we have been working from home for years. Using the telephone or teleconference is basic in order to really understand each other.

Only text communication is terrible because basically you filter all the emotions from the message. The worst thing is that you interpret or reconstruct those emotions based on your own state of mind. If you are burned out it is not pretty.

I can't tell you how bad it is when someone takes something trivial on text and interprets it as an aggression and responds aggressively and escalates and yet it happens every single day when you put an only text communication center in place.

The same thing told in another context, in a person to person meeting will be nothing because we are automatically using our tone of voice and body language in order to complete the message.

This has to improve some way.

<comment><USER18> If you know that implied emotions are filtered out, or can be mis-interpreted, why not add _explicit_ emotions?

Add praise and express gratitude for the project you're talking about. Expressly state when you have a strong option (preferably backed with data or something), and where you're humbly suggesting and asking for comments. Stay away from sounding like you're demanding something, and maybe even stay away from irony until you've created a good rapport with a person you're communicating with.

Do not remove all this "useless fluff", and work on adding some more in key parts of your message, it can improve communication.

</comment></comment><comment><USER19> I honestly don't understand why this happens. Do people really not understand that the OSS products they are using are typically created by people on their free time and that they don't owe you anything? If you want support pay for it, either through the OSS product itself or via a 3rd party consultant.

If you are not a developer or just don't have the time, I highly encourage you to support these projects in other ways: [https://esheavyindustries.com/2016/02/have-some-extra- cash-h...](https://esheavyindustries.com/2016/02/have-some-extra-cash-help- make-your-life-easier/)

For most of the OSS products I use I typically am not knowledgeable enough to submit code and I really don't have a lot of free time so I send them money or buy things off of their wishlist. A lot of these products make it capable for me to do my job and without them I'd likely be in a totally different spot. Sending them a few bucks a month or buying a book for them seems like the least I could do.

Just be nice and thankful for the work that these people/groups are putting out their and help where you can.

</comment><comment><USER20> I usually check in on open source projects I use and see what is going on in the issues and pull requests tabs on github. Almost every time I check, there is someone behaving in a rude and/or entitled way.

Some of these projects have implemented github's issue template, and the crazy thing is, these people actually just DELETE the entire template before writing their issue. They can't even be bothered to fill in the few fields the maintainers ask for.

I had hoped that Github would have translated the issue templates to actual forms, where you at least HAD to fill in the fields before getting to submit.

</comment><comment><USER21> As the author of the post being linked to, I just wanted to say thanks for all the kind words being said in this thread that are directed at me. For those that are curious, I'm still contributing to open source (I'm actually doing some on my vacation, but it's stuff I want to work on so it's all good). :)

I know the tone is rather dark here in the comments due to the fact that project maintainers are coming forward and saying how they end up suffering in a similar way as I have. But acknowledgment is the first step in dealing with a problem. My hope is we as an overall community of open source can come to terms with the problem at hand and start to develop solutions. (and if anyone cares, my current thinking on potential solutions all rely around improving our communication tools, but that's probably for another blog post :) ).

</comment><comment><USER22> We have likely hit the peak of this open source trend. Many companies rely on this model for ensuring their product is the most widely adopted however the individual contributor side of the story always seems to be ridden with experiences like the one stated in this article.

This sort of correction is necessary, the reason a contributors time is not valued is because of vast abundance of open source contributions out there today which people share for free.

</comment><comment><USER23> I'm one of the founding members of the FreeSWITCH Project, I've literally had people call my cellphone and demand I help them for free, because the software is free, it has free in its name and some how that translates into I must help them. This article is spot on, When you find the good contributors you help them, give them empowerment and you'll get rewards as a project, but every now and then you have that one person come along an just ruin your day over something that makes no sense at all. Bug reports that are incomplete, when you close them as incomplete they get reopened with NO additional details. Pasting logs into word docs and attaching them to the bug, uploading core files as if thats helpful.

I try my best to stay positive, I now think of those people as potential customers to help me make living. It does change your view of things. :)

</comment><comment><USER24> > [...] people have made demands on my free time simply because I previously > gave them that same gift to help make Python, as if the gift of my free time > is in perpetuity

A long time ago, I worked for a radio station as an audio engineer. Every piece of work I was assigned had a hard deadline for delivery or broadcast, so I often did the easy jobs first and delivered them early to get it out of the way.

My boss noticed this, and called me into his office one day to explain to me that if I kept doing this, people would _expect_ that work early every time, or give me less time to do it, and eventually it would bite me.

I tend to give some thought to managing expectations is most situations now. Paid or otherwise.

</comment><comment><USER25> Check out "Issues from hell"[1] Twitter account, they collected a ton of terrible behavior in open source forums:

[1] [https://twitter.com/issuesfromhell](https://twitter.com/issuesfromhell)

</comment><comment><USER26> This resonates with me. I've definitely been discouraged over years of OSS work by people that are rude or expect free labor. However, I try to remind myself that these are the vocal minority.

There are many people that are positive and help by contributing feedback, testing, answering other community members questions, and even submitting code to the various projects.

OSS can be exhausting at times, but over my career I haven't found anything that is quite as rewarding. It feels great to have another developer use code I've written to help get their job done. And that's why I keep coming back to OSS.

</comment><comment><USER27> To some extent, geek culture is self-deprecating. We give away our work and then, when we receive it, we don't know how to say thank you.

I feel awkward saying thank you on projects. Whenever I go to comment, it's like I feel the need to offer something in return, even if I don't have the time or money.

I do sincerely appreciate the many FOSS project contributors out there, however little I may say so, and I hope that at least a number of devs consider silence and a high download count to be a sign that everyone is happy and that they, the devs, are doing a great job.

</comment><comment><USER28> I'm late to the party on this discussion, but did want to say this brings to mind the similar troubles popular authors can have with their readers.

... and which prompted this wonderful essay/rant from Neil Gaiman "Entitlement issues" (aka "George R.R. Martin is not your bitch")

[http://journal.neilgaiman.com/2009/05/entitlement- issues.htm...](http://journal.neilgaiman.com/2009/05/entitlement-issues.html)

</comment><comment><USER29> Just wanted to offer a counterpoint to the general negativity in this comment thread: for my small OSS project I've always received respectful comments/issues on github. Some more or less helpful, but I've never felt used or abused.

Not intending to cast doubt on any of the experiences here, just to highlight that there's good experiences to be had too :-). I suspect one difference is that my project is dedicated towards education. As far as I know no-one is relying on it for their income.

</comment><comment><USER30> I have learned to detach myself some from open source, as some users are always going to be terrible, and IMO, more people should make an honest effort to contribute back to open source. If one gets too invested, it becomes too easy for negative contributors to affect your mental state, which affects the quality of solutions implemented.

For example, I encountered a bug this morning in one of the latest releases that came from the Angular team yesterday. Before opening an issue in GitHub, I did some deeper investigation in the code to figure out more details as to what was happening, as it was something that I could not give a nice minimal reproduction for them to fix as it dealt with something complicated. I posted the information, and along with help with two other contributors, we narrowed down the issue to one module. It was frustrating to encounter such breakage with minor version upgrades on packages, but as an open source maintainer of some major projects myself, I know it is more counterproductive to lash out at maintainers who are doing the best they can with the information & resources they have.

</comment><comment><USER31> I've been on both sides and I have to say that the road goes both ways.

When I was getting started with a language last year I found a missing feature in a module of an open source library and submitted a very simple PR to add the feature. The maintainer asked me to completely refactor the module. I admittedly overreacted to this request—as I perceived it to be way too big of an ask—before settling down and getting to work on it. Then it literally took almost six months for the maintainer to review and merge my PR because of the intensity of the refactoring and performance regressions. (I would get some small piece of feedback, submit a fix or more information, wait weeks and weeks to hear back again, repeat ad naseum.)

So yes, issue-reporters and PR-submitters can be irritating, demanding, and disrespectful of maintainers' time, but maintainers can be just as bad.

Postscript: I don't regret the time I spent on it because it was an awesome learning experience, but it was certainly frustrating at the time!

<comment><USER32> As a maintainer, I understand that this must have been frustrating for you.

On the other hand: the maintainer will have to maintain the changes you've contributed ~forever. Effectively, the contribution you're making, something that you can just throw at the maintainers, will have impact on their maintenance of the project for a long, long time.

As such, I disagree that maintainers are "bad" for doing this; there's just a large disbalance between the time your one-off contribution takes and the time they might have to spend refining it and/or fixing bugs in it. Given that they might also be juggling a day job and working with a bunch of other contributors, getting there can take a lot of time.

(Of course, they should still strive to be respectful about it, and as transparent as possible -- unfortunately, it's often hard to say in advance how much time it might take.)

</comment></comment><comment><USER33> The "relationships" section of the post did not mention quality assurance team members. I find that a strong QA team patrolling the bug tracker protects developers from a lot of noise. My own experience is with desktop software and I can imagine it might be harder to assemble a large team for a programming language, but I urge everyone to give it a shot.

I wrote a little something about the subject recently: [https://inkscape.org/en/news/2016/12/13/bug-testing- roadshow...](https://inkscape.org/en/news/2016/12/13/bug-testing-roadshow- hits-inkscape/)

</comment><comment><USER34> I can relate to most of this, and I try to be conscious of this when I come across a dependency of a dependency that I find out is under maintained and should be fixed. In many package managers it is difficult to modify sub dependencies without changing the whole structure of the project.

For some other things, like in the Android Open Source Project, these things are very intolerable. Google employees mostly have a monopoly on development, and ridiculous stuff still slips through the cracks and nobody can practically modify it.

</comment><comment><USER35> [https://snarky.ca/how-i-stay-happy-making-open-source- softwa...](https://snarky.ca/how-i-stay-happy-making-open-source-software/)

</comment><comment><USER36> I think we could all share plenty of stories of abuse and having our volunteer time abused or undervalued...

It's very overwhelming to have a large public project that your day job doesn't care about. When I find those rare moments of free time, and feeling like writing code, I feel guilty for not contributing it to my employer, and guilty for letting issues pile up in github, and guilty if I'd rather write new code.

I feel paralyzed and do nothing, I've mostly ignored FOSS this year, and they just pile up...

</comment><comment><USER37> Sometimes, I wonder if there's a market for a service to tell people off when they're being rude, inconsiderate or plain dicks. Sod Off as a Service. I just keep reading and reading examples of OSS maintainers receiving mails just like the first example given. Always bring me halfway between a laughing and being angry.

</comment><comment><USER38> _In order to help others more effectively share the maintenance burden, I need to stop fixing bugs and focus on helping them with patch submissions._

This is a good takeaway; I hope more maintainers are willing to prioritize patches.

</comment><comment><USER39> Sounds like a terrible country. You can't get paid without a registered business and your employer can tell you what you can't do on your own time?

Why do people vote for those sorts of policies?

<comment><USER40> > _Sounds like a terrible country_

That's gratuitous. Please drop the flamebait when commenting here.

We detached this subthread from [https://news.ycombinator.com/item?id=13233445](https://news.ycombinator.com/item?id=13233445) and marked it off-topic.

Edit: you've been using HN primarily for political and ideological battle. That is an abuse of this site. We ban accounts that do it, so please stop.

</comment></comment><comment><USER41> I could always smell this awful elitism and generally treating people like garbage from even the very early days of Stack Overflow and Github. Unfortunately any attempts to push back or criticize it will assure you are never allowed to participate in these self reinforcing "karma" based communities, so it's taken waaayyy longer for people to come around on this than it should have.

</comment><comment><USER42> > When the bug didn't get fixed, they personally emailed me asking me to fix > it as a consultant within three days. When I said I didn't have the time, > they then asked me to do it anyway for free because they still had their own > three-day deadline and shouldn't I just want to help them out?

I feel like we need a professional ethics code to handle situations like this. To me, if someone is willing to throw money at me to solve a problem, it behooves me to want to help them out. The only consideration here _should_ be, "how much." I would have looked at my current obligations, and quoted them a price at which I would have been willing to drop everything to come up with a patch for.

His unwillingness to help them out is, in the eyes of the business world, unprofessional. I get it, we're coders and we do this for fun. But how are we ever going to get the rest of the world to afford us the same respect that doctors and lawyers get if we're unwilling to play ball?

If I'm running a business and I need something, I should be able to pay a reasonable amount of money to get it. What's reasonable as determined by a negotiation between me and the party providing it. If I went to him and he was like, I need $10K to do this by Friday, that gives me a baseline. If I balk at the price, but I can get by if I push it to next Tuesday, can I get it for $6K?

If he tells me he can't do it at any price, then that means I _can 't rely on OSS as a pillar of my business_.

These are the problems I wish Stallman would apply his huge brain to solving. Not saving us from Facebook.

<comment><USER43> Not having time is not unprofessional. There are many different reasons why even throwing money at it might not be enough to get someone to work for you on short notice.

If your business depends on that piece of software to the degree that you might need a very quick fix on short notice at an almost arbitrary price, then you need to pay for a support contract with some company that offers it for that particular OSS software. That is possible for many big OSS projects, just like with closed source software.

<comment><USER42> > Not having time is not unprofessional.

Not being able to help someone out _at all_ is.

> That is possible for many big OSS projects, just like with closed source > software.

It should be possible for all of them. It's not, which is why OSS cannot be relied upon for business.

<comment><USER43> They could have previous commitments to their employer, breaking those without notice would be seriously unprofessional. They could have private obligations, which can't be weighed against money. They could be ill, ...

There is really no difference here between OSS and commercial closed source software. If you require that kind of guarantee, you need to pay someone in advance for them to make sure they'll have the capacity to help you on short notice.

<comment><USER42> > There is really no difference here between OSS and commercial closed source > software.

The difference is you can pay commercial software vendors for support. With OSS, you often can't.

<comment><USER44> No, you can hire programmers to hack on the software. You don't call the authors, wave money at them, and tell them to fix a problem for you.

The programmers you hire don't _have_ to be the authors (that wouldn't scale in most cases anyway), but they may very well become regular contributors.

<comment><USER42> Sure you can hire someone. But it's cheaper to buy commercial software.

<comment><USER44> Free Software does not mean "non-commercial" software. With Free Software you are not restricted to just one model of getting problems fixed.

It also doesn't seem correct to say that "it's cheaper" to buy software, when the issue here is fixing problems. Buying a software artifact is unrelated to getting service. Besides, it may very well be cheaper to hire a person to hack on a number of software projects than to pay for a service contract for each of the projects.

<comment><USER42> > Free Software does not mean "non-commercial" software.

If free software cannot work for business then that's exactly what it means.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Ask HN: Need help on Stripe Atlas - <AUTHOR> I've been applying for stripe atlas for a while now , everytime , i get to hear that they don't support a business that has a risk of chargeback , while my business will have absolutely zero because mine is an android app + ios app and would collect payments only through the stores ,so where's the risk ? , I'm missing something and i don't understand what , i could see that people with no revenue could be accepted too , but mine is a good idea and has been rejected , also , i've selected the website incomplete option as i still don't have anything on the website yet , could that be a factor ?
Please help out understand where i could be wrong . <comment><USER2> Your business is currently an android + ios app in a sector Stripe finds to be "high-risk". Stripe can't guarantee you're not going to later sell your software/product directly using Stripe, thus a risk of chargebacks.

If you're signing up to Atlas because you want to access Stripe for payment processing then you are out of luck it seems.

If you're signing up because you need a US LLC then you have other options that are more complex but would get you the same result. Have you considered using a service like LegalZoom (Not affiliated and have never used it so can't speak to how good they are) to incorporate your LLC?</comment>


It's Year 2011, Why Aren't People More Open-minded? - <AUTHOR> http://fredwu.me/post/8254974029/its-year-2011-why-arent-people-more-open-minded

<comment><USER2> Being open minded means admitting you don't know everything. Most people (myself included!) need to be frequently reminded that they don't know everything. It hurts, but its good for you in the long run like you say.

</comment><comment><USER3> Because people are psychologically much the same as they were 10,000 years ago. Because "open-minded" is generally code for "agrees with my preconceptions." Take your pick.</comment>


NASA, ESA capture comet collision with Sun - <AUTHOR> http://www.theweathernetwork.com/news/articles/nasa-esa-capture-comet-collision-with-sun/11518/

<comment><USER2> Another case of overly dramatic science-journalism. The title says "comet collision". Worse yet just before the video it says "The comet appears to explode upon impact but most likely only made it to within touching distance."

Touching distance? This writer clearly does not understand the subject at all. (Or else it's a crappy translation from an ESA item in a foreign language.)

<comment><USER3> This is The Weather Network's website, where every other week we are subjected to headlines of 'apocalyptic storms' or 'catastrophic weather'.

This entire news organization (if it even can be called that) is a terrible weather service, in my opinion. I cannot check the weather casually without noticing some overly exaggerated headline talking about the end of the earth tomorrow.

Frankly, I stopped visiting their website.

</comment></comment><comment><USER4> I went into a little more detail about this event here, [http://spaceindustrynews.com/30-meter-comet-hits-sun-at- same...](http://spaceindustrynews.com/30-meter-comet-hits-sun-at-same-time-as- coronal-mass-ejection-results-are-explosive-video/3899/)

Basically this sungrazing comet disappears into the sun and the CME happened at the same time. Though it looks like the comet created the CME, it in fact did not.

Very cool to see though!

</comment><comment><USER5> Sorry, it's not worth watching a 30-second commercial for a 15-second video.

<comment><USER6> Hosts file solves this : [http://winhelp2002.mvps.org/hosts.htm](http://winhelp2002.mvps.org/hosts.htm)

<comment><USER7> Cool... I've never heard of hosts (not a Windows user) but I use AdSuck from Conformal. It's a DNS server that spoofs blacklisted addresses and forwards all other queries, and is useful for blocking ads. I like AdSuck because things like Ad Block Plus don't really block connections the way AdSuck does.

[https://opensource.conformal.com/wiki/adsuck](https://opensource.conformal.com/wiki/adsuck)

<comment><USER8> Linux and Macs have hosts files too, at /etc/hosts.

<comment><USER7> Ah... hosts.allow & hosts.deny... I was wondering about that. Thanks for letting me know.

</comment></comment></comment></comment></comment><comment><USER9> I think this is second or third such video of a heavenly body colliding with the sun that I have seen. I am a bit curious why the impact from one side of the sun (which is diametrically huge in comparison to the incoming projectile) pushed out a large flare or material on the other side of it?

Is sun just a ball of _liquid+gases+plasma_ or there is a hard solid core in the middle of it? For if there was a solid core at all, or even a molten inelastic core, then perhaps the emission on the far side wouldn't have been this big. To me, the the ejecta on the other side is almost equal to the splash on the side the comet hit.

Any explanations?

<comment><USER10> Yes, the article states that (a) it's unlikely that the comet actually hit the sun (it probably burned up beforehand); and (b) there was a mass ejection event on the other side of the sun coincidentally around the same time that this comet was destroyed.

<comment><USER9> From the video the comet seems to be headed straight towards the _center_ of sun, and yes the ejection event seems to be strongly related to the event of impact.

<comment><USER10> Here's an animated gif (comet is at the bottom right within one of the brighter mass ejection beams, I missed it the first time around): [http://spaceweather.com/images2013/24aug13/deadcomet_anim.gi...](http://spaceweather.com/images2013/24aug13/deadcomet_anim.gif)

</comment></comment></comment></comment><comment><USER11> the headline made me imagine a comet going through a Sun Microsystems building.

</comment><comment><USER12> Is that Saturn in the upper left? I thought it was an icon or some artificial marking it's so stereotypically Saturn shaped I didn't think it was really Saturn.

<comment><USER13> It's Mercury being lit up by the Sun.

</comment></comment><comment><USER14> Spectacular! Looking forward to see comet Ison!

<comment><USER15> December right?

Unless I wasn't paying attention to entire vid, didn't they say that they are not sure if its path will be bend and it will survive sun's rendevouz, or it will be "swallowed" by it. But, if they don't know that, they cannot know if, upon bending/surviving, it won't get on its path with Earth, right?

Wouldn't they know already?

<comment><USER7> The text of the page mentions comet ISON arriving in November.

</comment></comment></comment><comment><USER16> There's a group claiming comets are solid rock and their tails are electrical in nature: [https://www.youtube.com/watch?v=wn_HqbMmn-4&list=FLvHqXK_Hz7...](https://www.youtube.com/watch?v=wn_HqbMmn-4&list=FLvHqXK_Hz79tjqRosK4tWYA)

The video is certainly interesting. Here's a longer one: [https://www.youtube.com/watch?v=34wtt2EUToo&feature=c4-overv...](https://www.youtube.com/watch?v=34wtt2EUToo&feature=c4-overview&list=UUvHqXK_Hz79tjqRosK4tWYA)

(I'm no expert on this topic, I don't feel I can judge these claims one way or the other)

</comment><comment><USER17> Look at the light coming off the far side of the sun post-impact.

It's almost unbelievable how an object "tens of meters" in diameter can affect an object nearly 1.4 Billion meters in diameter.

Just startling.

(Note, comets average 20k mph, so we're still talking maybe 2/1000th's of a percent of c, right? It's not like it's a relativistic bomb or anything... yet billions of meters away, a light burst nearly instantaneous upon impact.)

<comment><USER18> The comet only appears to explode because of a coronal mass ejection. The article attributes the coronal mass ejection to "an explosion on the other side of the star" and suggests that the timing was coincidental. It's unfortunate that the video does not make this clear.

<comment><USER19> Wow. I thought the article was downright misleading:

        Friday, August 23, 2013, 10:31 AM -	NASA and the European Space Agency's
        Solar and Heliospheric Observatory (SOHO) has managed to capture a comet
        colliding with the sun, **appearing to explode as it approaches.**

Upon seeing your comment, I scrolled down and looked a little closer:

        At approximately the same time, the sun let out a large coronal mass
        ejection (CME), looking as if the comet triggered the event.

        In fact, the CME was caused by an explosion on the other side of the star.
        The icy space body was simply too small to have any impact.

<comment><USER20> Whoever wrote the opening paragraph should have used the word "seeming". While "seeming" and "appearing" are synonyms, the ambiguity might confuse those who are unaccustomed to reading the entire article.

<comment><USER19> > the ambiguity might confuse those who are unaccustomed to reading the entire > article.

Indeed. I clicked to watch the video of a comet exploding---not read about it!</comment></comment></comment></comment></comment>


Simpler GitHub Pages publishing - <AUTHOR> https://github.com/blog/2228-simpler-github-pages-publishing <comment><USER2> I love github pages. Here is a web game I helped make, hosted entirely on github pages (made for the terrible ideas hackathon)

[http://scrollscore.com/](http://scrollscore.com/) "the more you scroll, the more you win!"

[https://github.com/amberrayh/scrollscore/tree/gh- pages](https://github.com/amberrayh/scrollscore/tree/gh-pages)

Thanks, Github, for making pages even better!

<comment><USER3> You're requesting people to put their credit card info without having HTTPS enforced by default? Doesn't sound suspicious at all.

What year is this? How is this still a thing?

<comment><USER2> Like i said, it was made for a terrible ideas hackathon.

Also, if you look at the source, you'll see that the form doesn't actually post anywhere. It's a joke demo.

<comment><USER4> That's explains why my $1000 donation didn't go through

</comment></comment></comment></comment><comment><USER5> Why make this such a limited set of options? Why not let me enter a path, for example, instead of hardcoding "/docs"? What if I want to serve my docs from a stable release branch or tag instead of "master"?

<comment><USER6> We may make things more flexible down the line, but for now, it was motivated by two primary reasons:

1\. The overwhelming majority of users use one of those three design patterns. For example, I can tell you that more than 98% of GitHub Pages sites use either `master` or `gh-pages` as their primary branch (with only about one tenth of one percent of sites using the `stable` branch).

2\. Our experience tells us that every option we add to GitHub Pages increases the learning curve for newer developers. With only those three options, if you're just learning HTML, you don't need to understand Git's branching model before you can create your first website.

We chose these options to start because we thought they struck a good balance between supporting collaborative documentation workflows for open source projects and encouraging "hello world" experimentation among new developers, but as with most features at GitHub, this is just the start.

<comment><USER7> That's what defaults are for.

You have two choices to make: which branch and which path within that branch. The defaults are "master" and "docs," but allowing maintainers to make different choices there doesn't need to impact the onboarding experience for new developers. The newbies use the defaults - people who need customization can customize. Software development is a broad field and projects work within various constraints and architectures. Asserting a convention here feels a bit misguided.

You already allow the default branch to be customized. It's a bit weird that I can specify a default branch (like "develop") and delete the master branch, but then won't be able to publish docs without recreating master or maintaining a gh-pages branch.

<comment><USER8> > Asserting a convention here feels a bit misguided.

Expecting GitHub to spend real money to cater to a tiny minority of users of their web service is misguided. The business models behind public internet services are simply not structured to cater to anything but the lowest/simplest common denominator users.

<comment><USER7> I expect a reasonable amount of flexibility in developer tools, especially since the difference between the current solution and the customizable one is most likely two inputs in a web form.

It's great to see new features shipping on GitHub.com (especially since it felt stagnant for so long). I have no idea what their codebase looks like, but prepopulating a text field with the contents of a template.md file and allowing the name of the publishing branch to be specified feel like they should have been fairly minor changes. Especially now that they clearly have the architecture to choose repo-specific publishing locations, allowing those to be user-specified should be a very low-effort way to make the tools useful for more projects.

</comment></comment></comment></comment></comment><comment><USER9> I recently switched to gitlab because they have a much more straightforward pages publishing system.

It works by setting up a (free) pipeline which can run arbitrary code (docker- ized) that you set up in a .gitlab-ci.yml file that outputs build artifacts (static assets). These assets are then copied to gitlab's pages system.

Keeps your git repo clear of compiled stuff.

Works the same for public/private repos, too. Also has option for a custom domain SSL cert and 404 pages.

<comment><USER10> You can use SSL with GitHub pages if you're using CloudFlare.

[https://blog.cloudflare.com/secure-and-fast-github-pages- wit...](https://blog.cloudflare.com/secure-and-fast-github-pages-with- cloudflare/)

And I think it works _only_ if you're using CloudFlare. I've always heard that you can't use custom domains _and_ SSL but this works perfectly for me. But can anyone say why? Since my website is now hosted by github, I'm not so paranoid about my website going down or DoS attacks, and would like to not depend on CF anymore.

<comment><USER11> It doesn't only work with Cloudflare but if you want to use a custom domain + SSL you need to use a provider that can proxy the request for you. GitHub and their Fastly setup won't serve custom certificates for you and the *.github.io certificate wouldn't be valid for your custom domain.

<comment><USER10> The last sentence didn't really make sense to me. I assume Fastly is some kind of backend tool? So why is it only working with CF? when I visit my custom domain, I get a cert from sni75146.cloudflaressl.com but no cert related to github to be seen anywhere. I'm assuming the cert I'm seeing is valid because I'm viewing the page on CF's CDN, or am I wrong?

Well, I think I'm better off asking objective questions, so: 1\. Can I change by DNS provider to something else and have SSL work? 2\. Can I keep using CF and use my own cert, say from LetsEncrypt? 3\. Do GitHub and CF have something in common/mutual agreement so this works?

<comment><USER11> Fastly is not "some backend tool". Two seconds of Google'ing would reveal to you that they're a Content Distribution Network, aka CDN. They're the ones actually serving the content hosted on *.github.io:

        host user.github.io
        user.github.io is an alias for github.map.fastly.net.
        github.map.fastly.net is an alias for prod.github.map.fastlylb.net.
        prod.github.map.fastlylb.net has address 220.127.116.11

Cloudflare doesn't act as a CDN in this case. What Cloudflare does is proxy the request for you, and by virtue of them terminating the request they can serve an SSL certificate for your domain (either handed out by them or custom if you pay them).

<comment><USER10> Please see your sibling comment

</comment></comment></comment></comment></comment></comment><comment><USER12> I would love to see a short guide on how to organize your open source website on github (say a react website, since it's pretty popular), i.e. a recommended workflow to store sources, implement new features, build artifacts/assets and publish them on gh pages.

I did it in multiple ways, lately I had master with the code, and was pulling gh-pages into the build/ directory, but I always wondered how other workflows look like. And this changes/hopefully simplifies a ton.

<comment><USER7> It'd also be nice if there was a way to specify an HTML page that is served for every path on the domain. That way, you could use an SPA architecture (a container HTML file and a JS bundle that manages the URL) without breaking deep links or needing to generate redundant pages to match every path in your SPA.

<comment><USER12> As a hack, I think you can set a custom 404.

<comment><USER7> Good tip - thanks!

[https://help.github.com/articles/creating-a- custom-404-page-...](https://help.github.com/articles/creating-a- custom-404-page-for-your-github-pages-site/)

</comment></comment></comment></comment><comment><USER13> Oh, God. This is truly the best thing out of all the things. Managing a gh- pages branch was always a pain.

</comment><comment><USER14> For generated HTML docs or websites, this is still not ideal because you have to commit generated code into your master branch.

You can even use Travis to automatically generate and deploy your docs/website, which I find much cleaner and convenient than manually publishing or committing generated code.

[https://github.com/L33T-KR3W/push-dir](https://github.com/L33T-KR3W/push-dir) makes it easy to publish a directory to gh-pages (even .gitignored directories i.e. build/).

<comment><USER15> The generated code is going to be "committed" somewhere, so I am not sure this is much of a down side. I suppose one might worry about storing too much history. Is there a way to pair down history for everything in docs/ ?

<comment><USER16> Slightly related, I push my site's generated code from the `public` directory of my repo directly to the `gh-pages` branch using git's subtree push:

      $ git subtree push --prefix=public origin gh-pages

</comment></comment></comment><comment><USER17> Fabulous. As it should have been from day one - this is great.

</comment><comment><USER18> Is there anyway to make readme.md publish to github pages? I'd like to put talk slide in readme.md, then load client side.

Like this, but without the duplicated file: [https://github.com/1wheel/talks/tree/master/graphical- web](https://github.com/1wheel/talks/tree/master/graphical-web)

<comment><USER3> I agree with you.

I think that at the very minimum automatic page generation should convert the README file to HTML by default.

I would love to see an option to sync the README file with the site without playing with Git hooks.

</comment></comment><comment><USER19> Aerobatic ([https://www.aerobatic.com/](https://www.aerobatic.com/)) takes a similar, though slightly more flexible, approach with their static site deployments for Bitbucket.

You pick a branch then (optionally) specify a sub-directory of your repository to deploy.

(full disclosure: I'm at Atlassian)

</comment><comment><USER20> TL;DR: For serving pages, you can now use `/docs` in your master branch instead of needing a `gh-pages` branch.

</comment><comment><USER21> Beyond not managing an extra branch, the best benefit imho is when you work on a feature branch, you can also update the docs while working on the feature, so the docs are part of the pull requests and only merged once the new code is merged, so it stays in sync without an extra step.

</comment><comment><USER22> This is great news for me, maybe now I can finally merge my documentation repository with my code repository and have it make sense again :)

On another note, I wonder how I could change my Nanoc deploy to support this new kind of Github Pages setup (currently, it follows this process: [http://nanoc.ws/doc/deploying/#with-github-pages-or- bitbucke...](http://nanoc.ws/doc/deploying/#with-github-pages-or-bitbucket)).

</comment><comment><USER23> They should also add a way to turn off Jekyll processing so you don't have to remember to add a .nojekyll file.

<comment><USER24> Well, adding a .nojekyll file _is_ a way to turn off Jekyll processing ;)

</comment></comment><comment><USER25> This is exactly how I wanted GitHub Pages to work since it was introduced. Thank you!

</comment><comment><USER26> So, does this mean that the folder is always "live" ?

</comment><comment><USER15> YEAH!!!!!!!!!!!!!!!!! Good job guys, you did it! Ok, one small peeve: I think a directory name like `site` would have been better than `docs` because it has a more generally applicable meaning. But hey, I can live with `docs`, even if it means having a `docs/docs` path. I'm just glad this is finally a feature! Kudos.

</comment><comment><USER27> Thanks GitHub and thanks for your Pages. I'm maintaining a web template editor [http://grapesjs.com/demo.html](http://grapesjs.com/demo.html) Where you can design, store and even export to zip responsive templates without much effort and totally free. Really, thank you

</comment><comment><USER28> I'm ecstatic for this! I was getting real sick of keeping the separate branches up to date, when I wanted to make a minor change.

</comment><comment><USER29> Fantastic news. Makes static sites publishing way easier. Looking forward to the upcoming gem-packaged themes (in Jekyll) on GitHub pages too.

PS: Anyone interested in static (web)site builder news (e.g. GitHub Pages, Jekyll, Middleman, Gatsby, Metalsmith, and friends)? Follow along @statictimes on twitter -> [https://twitter.com/statictimes](https://twitter.com/statictimes) PPS: Anyone interested in Jekyll - I've put together an Awesome Jekyll page -> [https://github.com/planetjekyll/awesome- jekyll](https://github.com/planetjekyll/awesome-jekyll) (incl. a history on GitHub Pages updates/news).</comment>


Google Abandons Open Standards for Instant Messaging - <AUTHOR> https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging <comment><USER2> As a Googler (who does not work on Hangsout) my own personal opinion is that I fully agree with the EFF here:

"In public explanations of its dropping XMPP support, Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable. Releasing the specifications for Google Hangouts would be a good first step. Releasing free/open source clients and servers should follow. It's clear that some of Hangouts' video features have been implemented in some very Google-specific ways. But that's no excuse for leading us toward a world where the only practical choices are proprietary chat clients and protocols."

I hope the specs at some point are opened. The Hangouts team probably has good reason at the moment to strictly focus on a core set of functionality and get it working with good UX on all the platforms. People are complaining that stuff like voice calling, and some Talk features are missing, but it's probably due to focus on shipping something that works good first. It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL. In the late 90s, early 2000s, I remember using reverse engineered Java libraries that could talk to these services.

Google Wave was done in the opposite way, as was Open Social. They came with specs, but they did not focus on core user experience in the beginning. It's hard to win with open specs without getting consumer traction.

<comment><USER3> As another Googler, I mostly agree with you, but I also sympathize with the product and engineering teams.

They keep seeing very popular apps and messaging products that are completely proprietary and locked in, and that are able to move and innovate fast because they either don't have to conform to an existing standard, or worry about publishing and support whatever internal protocol they do use.

Sure Hangouts could publish their protocol like Wave did, but Wave was a complex mess of different protocol formats and transports and publishing that as a "standard" was way premature. Who knows how good the current Hangout protocols are, or how well they might play with real standards like WebRTC. It's probably too early for them

I remain optimistic that these things can be standardized in the future.

<comment><USER4> i'm sorry i fail to see the argument. it's perfectly fine to have your own proprietary format, but publish the specs so others can interact with it. who said anything about ietf having to sign it off.

<comment><USER5> The problem is simple.

Once you've published it, you're under pressure to remain backwards compatible. But until you've got experience with it working in the real world, you don't know what really works. And then before publishing it, you need to go through a lot of work to make the published spec clear enough that someone else can reimplement from scratch and it will actually work.

For all of those reasons, there is pressure to not publish a spec until after the technology has matured.

<comment><USER6> This is mostly crap, to be honest. It's all about messaging.

I wrote most of the first version of the wave federation spec (I cannot remember how this happened, but im pretty sure it involved being in Sydney temporarily, alcohol, and Soren being Soren. I'm fairly sure I got the short end of the stick on this one).

It was absolute and complete crap. But it kinda worked. We were clear it was a first draft, and folks understood it would completely and utterly change.

Within an hour of publishing it, the wonderful XMPP folks emailed me and asked me to fix a few things (like accidentally using some reserved namespaces/etc), and asked how they could help, pointing out the XEP process, and pointing out we were doing some things others were working as well.

With their help, it ended up as a "mostly sane" spec.

Realistically, pressure comes from improper messaging. If you tell people "here's our current thoughts, in spec form, this is all gonna change", you can do a lot of work in the open without too much customer pressure.

Now, will this slow adoption? Maybe, it depends on what kind of product it is.

But the argument that you get this pressure out of thin air is wrong. Pressure is mostly caused by self-inflicted wounds where people are not being clear about the state of the world as they see it.

<comment><USER5> That is an excellent point, and I'm glad it worked out for you. What I'd be more curious about is how well it would have aged had it not been discontinued. Comments below suggest that if you had longer to do it you would have done it differently. Which suggests to me that developers 5-10 years later would likely have wanted something quite different.

The reason that I'm cautious is that I've suffered through code that has to jump through hoops to remain compatible with something someone thought was a good idea 10 years ago. Things that seem like a good idea now don't always a few years later. When you control both ends, you have a potential upgrade path to fix it. When you don't, you're stuck.

<comment><USER6> But for most of the API's and protocols we are talking about here, 5-10 years later, developers _always_ want something different, regardless of whether you designed it right or wrong. That's just the nature of the speed of our industry.

I'm, of course, not suggesting that you should never try to design something that will last 5-10 years, but in most cases, you can only standardize what people want to use _now_ , and hopefully design a way of extending the protocol to be able to standardize what people want to do in the future as well.

As you say, otherwise you have to try to remain compatible with something someone _thought_ was a good idea 10 years ago. That usually means it _wasn't_ a good idea 10 years ago, it was something that 10 years ago, they thought would be good in the future, and they predicted wrong.

Past that, sometimes you have to just accept that the useful design life span of some protocols is not going to be as long as some customers would like.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Google abandoning open standards is nothing new.

It seems they'll use open standards only as long as it serves them, but when they've grown big enough to dominate the competition, they'll turn around in a heartbeat and exploit that.

Just look at what they did to the open web with Chrome.

First they said "Web standards are important, so here is a good, fast and web- standards compliant browser. Feel free to try it". After a while that was not enough, and on every single web-page they had they had a _big_ "Use Chrome!" ad for every visitor not using it already.

Once they had gained enough dominance, suddenly Google started using non-W3C HTML in their _production_ web-sites. HTML which had not been fully drafted or ratified and which was only available as they saw fit in web-kit.

And then all the other non-Google browsers were suddenly "slow" on "adopting new HTML standards". Basically through its internet dominance, and now its browser, Google pushed through its own implementation of proprietary HTML features as standards other browsers had to implement, without any discussion, feedback or other input.

Google just decided that they alone should dictate how the HTML-standard is from now on.

After seeing that happen, I lost all belief in Google as a company which I will rely on for anything more than I strictly need to.

<comment><USER8> > It seems they'll use open standards only as long as it serves them, but when > they've grown big enough to dominate the competition, they'll turn around in > a heartbeat and exploit that.

I don't see how Google is dominating the competition. Gchat _used_ to be a dominant player, I believe, but that was before mobile existed. I think the dominant players now are:

iMessage. Propriety, only runs on Apple devices, can only communicate with other iMessage users.

Facebook Messenger. Proprietary, only runs in Facebook site and app, can only communicate with other Facebook users.

WhatsApp. I think based on XMPP? Only runs in WhatsApp application, can only communicate with other WhatsApp users.

Notice that every single one of those is a walled garden.

<comment><USER9> Unlike WhatsApp, Facebook chat is accessible via standard non-federated XMPP, so you can use it with any XMPP client.

</comment></comment></comment><comment><USER10> _Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable._

Indeed. If basic XMPP wasn't good enough for whatever reason, (or SIP or whatever other protocol already exists) then the "right thing to do" would have been to work with the respective standards body to extent / modify an existing standard to overcome whatever the restriction was. OR, as a secondary option, Google should at least release detailed specs for their new protocol, along with an open source reference implementation.

Creating more new walled-gardens is not a positive step forward here.

<comment><USER2> To be fair, releasing an open source reference implementation takes a separate engineering effort. You can't just take Google services engineered for Borg/Spanner/et al, and drop them in OSS. It took Google Wave team a lot of resources to open source a non-Google-datacenterized version. Hangouts is also intertwined with lots of other Google services, so it's not a matter of just code dumping.

Imagine that you have a small team trying to hit 3 platforms (Web, Android, iOS), in time for Google I/O launch, packaging up an OSS release along with spec document is probably the least priority.

<comment><USER11> If the reason they can't document is because they have a small team, then this is an easy solution for Google - hire some people to document the system. They don't even have to be in direct contact with the actual development team, just access to the source code and developer design documents should be enough. For a company the size of Google with the amount of profits they make, 'small team' is just not an excuse for anything.

The move is definitely deliberate, they can't have Skype come in and allow people with Skype to make calls to hangout when the hangout client can't make calls into Skype. It would make them look bad.

<comment><USER2> I think you've got it backwards. If Google was really concerned with making Hangouts a competitive moat by blocking interoperability, why would they be plowing so much effort into WebRTC, a technology which pretty much commodifies Hangouts and makes it possible for anyone to implement peer to peer video or audio group chat? Skype is actually trying to block WebRTC, as is Cisco WebEx, and Nokia.

I don't really see that Google would have anything to gain by blocking interoperability with Skype, Skype is the market leader, it is usually those who are not market leaders in a particular area to push for interop, and usually those who have a hold on the market to resist.

<comment><USER12> I think that the reason that these aren't contradictions is because Google isn't a person. So if they do one thing that is open and a second that is closed, we aren't using it as evidence to search out a human being's soul or true intentions. An organization of this size can do both things at the same time. If there was a master plan, you could say that the openness is great PR that allows them to do closed stuff without getting as much of a backlash. But again, that is just anthropomorphic BS. In one case people within a personalityless organization are doing one thing. In another case different people in the same organization are doing another. The two cases should be treated separately.

<comment><USER2> I work at Google, openness is not PR, it is part of the culture. People here believe in it, which is why I was the first person to bitch about this, and I'm not alone.

Often if someone is doing something that cries for an interop spec, but they aren't doing it, chances are they have some good reasons that don't involve a corporate master plan to "talk about openness to make people like us, but secretly silo-the-world" Often, it revolves around having a task list of a gazillion things to work on and prioritize, and often open-spec is 'nice to have, but not critical for launch' kind of thing.

Really, when you look at the market, 99% of the folks are shipping closed apps, where more time is spent on cute emoticons than on infrastructure. Google risks becoming "open, but irrelevent" in a market of iMessage/WhatsApp/FaceBook messenger, where a niche audience is supremely happy they can build third party clients, but which becomes a service unused by the great unwashed masses.

The network effect requires other users to increase value, so they've got to double down on things which delight and wow end users first, and developers second.

<comment><USER13> "Openness ... is part of the culture"

It seems that there are any of a number of non-open parts to the Google culture. How many server machines do you all have? How are dirty SEO methods detected and thwarted? What are the details on the influence made by the $18M spent in lobbying D.C. in 2012?

That's not to say they shouldn't be private. It's me asking you what it means to be "open" as part of the culture.

<comment><USER14> Openness being part of the culture doesn't mean that everything Google does is disclosed publicly. Openness to the public, and openness within a company are two entirely separate issues, and there are obvious practical limits to both (at different levels) if you want to be competitive.

<comment><USER13> I believe the previous poster was only talking about openness to the public. (Is Google distinctively more "open" internally than, say, Microsoft or SAP? I think that's a different topic, and one that I'm not so interested in.)

As I wrote, I agree with the view that parts of Google are not disclosed publicly.

My question is, we all know that Google has some closely held secrets. In that case, how do I tell if (public) openness is part of the culture? Can I use that to estimation method if the level of openness has increased or decreased at Google over the last decade?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Larry inspired me with his talk the other week, in which he lamented that Microsoft (and others) were playing silly zero-sum games in their own closed ecosystems.

I've immediately stopped using as many Google products as I can in response to this after trying out the new hangouts a few days ago and finding I couldn't connect with my friends that weren't on Google.

I'm sad - this directly removes choice and is a sort of lockin. I now can't use Google to communicate with people who choose not to participate in Google's ecosystem for whatever reason.

By leaving, I also make it harder to communicate with many friends who are on Google.

Google, you've alienated me.

</comment><comment><USER16> The bigger issue here is that Google is integrating everything into G+. They are moving away from being a search engine, towards being a social network with better search capabilities than Facebook. The problem is that the average Google users (read, non hacker, and generally not computer smart) does not understand the changes. They just go to Google to learn about a new chicken recipe, or what side-effects does Singulair has. They don't go there to socialize. And Google is forcing this into everybody. Which is a significant deal, because for a lot of people out there ( a lot) Google _is_ the internet. Just like AOL was in the 90's, Google is now. They are diluting their brand, and going in every direction. Before you say anything else, I use google products. I like Google. I remember their old nerdy logo. I loved how they took on the old search engines of yore, and beat them at their own game. But it has reached a point where Google is now a faceless corporation simply driven to profit. All of their actions point to that. They seem to no longer really care about the users. Just like IBM, MS, and all the old tech giants. Management has taken over. The true hacker spirit seems to not be found anymore.

<comment><USER17> Disclaimer: As a Google Engineer, this is my understanding of Google+.

I think Google+ could be understood better once you realize that Google+ is not a social network in the traditional terms. Google+ is truly a social layer across all Google services.

The average users who are just looking for a chicken recipe (as you mention) would always love to find the particular chicken recipe that their friends have recommended. Even more relevant to me (since I don't cook) is that if a friend finds a todo app useful, I'd definitely want to know.

If Google has this social layer, it'll really unleash more expressive search results that would help the vast majority of users. This is what Google+ is.

Google+ is literally Google Plus More.

Of course, to get these benefits you really have to start using Google+ on different Google services. I guess this is the reason that Google employees who actually use Google+ services continue using it and prefer if their friends do it too.

<comment><USER18> Those are all things that nobody wants. Not only do we not want them, we abhor the thought. That's what Google isn't getting.

We just want to search. Or keep using email like we have been for a decade. People switched to Gmail because it was like hotmail with a nicer interface and a large mailbox limit.

Maybe some people do want those other things. That's fine, give them their own corner, let them play with the toy social network or social layer or however you want to pitch it. Stop force-feeding it to the rest of us. I don't want to know what my friends are searching for or what recipes they like. It's just unwanted noise.

And let's call a spade a spade - "sharing" has very little to do with friends and everything to do with advertisers. It's very disingenuous and insulting of Google to pretend that the _primary_ purpose of +1 buttons is to "share with friends".

<comment><USER19> > And let's call a spade a spade - "sharing" has very little to do with > friends and everything to do with advertisers. It's very disingenuous and > insulting of Google to pretend that the primary purpose of +1 buttons is to > "share with friends".

This is calling a spade a turkey. How did you possibly come to that conclusion?

> I don't want to know what my friends are searching for or what recipes they > like. It's just unwanted noise.

On the right-hand side of your search page, there's a button for turning off personalisation.

<comment><USER20> _On the right-hand side of your search page, there's a button for turning off personalisation._

For now. Maybe not tomorrow. Google has already demonstrated its willing to run roughshod over some of its users in order to advance its agenda for Google+, which clearly is much more in Google's interest than the interest of Google's users.

The information I store with Google is actually quite a bit more valuable than anything I might post on Facebook so their recent willingness to stuff all their other services into a shitty social network with a creepy "real name" policy has me eying alternatives.

<comment><USER21> So you are blaming Google not for what it has done, but what it __could __do?

<comment><USER20> If they want me to trust them with that much information then what they seem likely to do with it is extremely relevant to my decisions about how much I rely on them today.

Even a few years ago I had no second thoughts about depending on Google for critical web services but their tactics with G+ have me seriously second guessing them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> That's one reason to dislike Google. They push free (as in beer) services and standards until they kill all competitors, then let it rot. To me what they do is even worse than going with proprietary solutions from the start and charging for it, at least that's honest and fosters competition. Just look at what they did with Google Apps.

Nowadays I only trust services where they profit (aka. anything that includes advertising), and none of the open standards they push forward.

<comment><USER23> Except this is just generic Google comment #4 and has nothing to do with the current situation. AFAIK Google Talk is nowhere near the most popular chat service, there are a ton of competitors, and the problem here is the exact opposite of letting it rot: it's changing the communication format so completely that it's breaking the former adherence to XMPP.

Google Apps doesn't seem especially relevant, but it _also_ has lots of competitors (including, just like chat, very active open source projects), hasn't been left to rot, and they've actually moved to _only_ charging for it, instead of having an ad-supported version.

...so, are you really just talking about Reader?

<comment><USER22> > AFAIK Google Talk is nowhere near the most popular chat service, there are a > ton of competitors, and the problem here is the exact opposite of letting it > rot: it's changing the communication format so completely that it's breaking > the former adherence to XMPP.

That's not how I see it at all.

You make it look like they are improving the service and that requires breaking compatibility with XMPP, but it's yet another strategy to force users into Google+ by consolidating Google Talk under the "Hangouts" feature. Commitment to open standards is only skin deep.

<comment><USER23> That's, again, something totally different from what you described in your original post.

Letting a service rot generally means abandonment. I'm certainly _not_ saying that the opposite of letting something rot means improvement, I'm saying that making a major change like this is not at all an example of letting that service rot.

</comment></comment></comment></comment><comment><USER24> I am not clear why EFF is lobbying on behalf of the XMPP standards foundation here. The entire computing industry is cluttered with opportunities for interoperable standards, some of which haven't been tried, some of which worked out, and some of which were attempted but (often correctly) jettisoned in favor of progress.

Standardization is a good thing, but not the only good thing, and it always worries me when people make arguments that effectively demand that new offerings justify themselves (either with time or money) to existing standards groups.

<comment><USER25> Why do you have a problem with EFF lobbying for a standard? They lobby whenever they feel like it's necessary and this isn't the first time they lobby for privacy or for open standards, after all, their motto is "defending your rights in the digital world" and I think that dropping support for _federation_ or for disabling the _archiving_ of chats is within their goals.

At this point, standardization for video chat is one of the most important steps forward. We already have proprietary video chat services. We already have the likes of Yahoo, Skype and Facebook.

Why do we need another proprietary protocol to throw in the mix? What could possibly be more important than an open standard at this point? And yeah, Hangouts has some cool stuff in it, but not enough to justify the breaking of a promise, but then again, it's not the first time where I feel like Google is disappointing.

<comment><USER24> Every time software progress threatens the status quo, partians of the standard argue that the new functionality proposed doesn't justify degrading standardization. Who are those partisans to say?

<comment><USER25> True, but at the very least they should keep the support for XMPP they had until now and make an effort to publish specs (not as standards, but as public documents), such that at the very least we can have third-party clients and not leave it up to third-parties to reverse-engineer the protocol badly, violating some TOS in the process.

Or at least commit to doing it in the future at some point. Nobody's rushing them into doing it right now, but changes such as these create anxiety. I mean, what next? Are they going to drop POP3/SMTP support from GMail or something?

<comment><USER24> If it costs $X dollars to retain XMPP support and $Y dollars to build their new offering out and their budget can't accomodate both $X and $Y, then the choice is indeed between progress and placating standards advocates.

I can't imagine a standards issue I would care less about (among standards I routinely use) than Google Mail dropping POP3 support, unlikely as that may be. Most mail users are better served by web interfaces. POP3 and IMAP are archaic. People that want those interfaces have plenty of options for maintaining them.

You have never had more freedom in how you can avail yourself of technology than you do in 2013, no matter how many restrictive app stores and giant email providers you choose to concern yourself with. (I don't mean that to sound snide.)

<comment><USER25> These standards, archaic as they may be, also allow you to export your emails should you want to. I pay for my wife's Yahoo email account, such that GMail can use POP3 to connect to it and retrieve the emails that she gets on that account. Not to mention that email clients work best if native. iOS users didn't have to wait for Google to release a half-baked client for them.

As an alternative, of course, we can do better than POP3 or IMAP. Sure, lets burn them, but name an alternative first and it has to be a standard supported by Google, no?

I can't believe that you think this. You're basically arguing for the sake of arguing.

Btw, you're mentioning " _web interfaces_ ". How would you have liked it if everybody had their own browser-like app, communicating through their own http-like protocol, speaking their own language for hyper-linked documents?

<comment><USER24> If you think I'm just arguing for the sake of arguing, let's you and I just stop arguing.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> _Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable._

Well said. Google made a bad move with breaking things before enabling interoperability by publishing their protocol. It's not the proper way of doing things. Firstly, they could extend XMPP, Jingle etc. instead of creating something from scratch.

If they can't (though they didn't explain why), they need first to develop a protocol, publish it, and then start deploying it. Not other way around! Right now they are moving towards cutting the connection between Google users and users of other XMPP servers. Connection which works already now. I can understand that they might envision new communication patterns, but it doesn't mean one has to break what already works _before_ enabling others to interoperate. It's completely immature on Google's part. Going the right way might take more time - but it will not increase the horrible mess that the IM scene is today. What Google does now is creating only more mess.

</comment><comment><USER27> I'm a lot more interested in them adding OTR encryption than having interoperability. However, if they never intend to add OTR (which being Google, seems very likely), then I'd want Hangouts to at least work with other IM's that _do_ offer OTR, like Gtalk has worked so far.

<comment><USER28> Is this out of date: <https://support.google.com/talk/answer/29291>

<comment><USER23> That's just turning off chat history, which is confusingly also referred to as "off the record". Usually when people talk about OTR for chat, they mean client-to-client encryption, so not even the chat provider knows what the content of the chats were, analogous to using something like PGP for email.

</comment></comment></comment><comment><USER29> This is quite sad, and what seems to be a growing trend at Google.

<comment><USER30> I've noticed this trend as well. Privacy is dead at Google. Sleep with dogs(US govt), don't get upset when you wake up with fleas.

</comment></comment><comment><USER31> Does facebook follow an open standard for their messaging system?

<comment><USER32> Also add WhatsApp, Line, KakaoTalk, Viber, Kik.

Google is getting clobbered in the messaging space by these apps. If Google thinks they can move faster by dropping XMPP support, I'm fine with it.

Imagine if Google sticks with XMPP and continue to lose market share in messaging. They might have to shut down Talk. We know what happens when Google sunsets a product, lots of angry people.

Lose-lose situation for Google here.

</comment></comment><comment><USER33> Google isn't abandoning open standards for instant messaging. They're abandoning instant messaging. They've moved from a real time communications tool to a messaging tool. This is incredibly frustrating for those who used previously used Google Talk for instant messaging purposes, but now have to look for other options outside the Google ecosystem.

</comment><comment><USER34> Google has dropped support for XMPP (chat) and calDAV (calendar syncing). What's next? cardDAV? IMAP?? Honestly I can see that Google is no longer interested in open protocols. They are afraid that it's too easy for their users to simply migrate everything away. Their response is to build a wall around their users. Enough red flags have been raised for me to, unfortunately, say goodbye.

Perhaps I may still buy their hardware, but they want to isolate my data from every company but them. They are no longer reliable.

</comment><comment><USER35> I would also like an open standard but I had to laugh at the final sentence of the EFF statement:

> To be clear, even the earlier [off-the-record] setting was far from perfect > from a privacy perspective: disabling chat history only kept the logged > messages out of your Gmail account, and didn't prevent other users, or > Google itself, from keeping a record of the conversation.

How on earth would you expect an open protocol to prevent the other keeping a record of a conversation? It's like asking for perfect DRM with open clients.

<comment><USER36> They _could_ [0] implement some client side actual OTR[1], at least blocking Google from keeping the clear-text message. No idea how they would want to force the intended recipient of the message not to store it, though.

[0] In theory with infinite resources and time. Maybe.

[1] Or any other sort of encryption.

</comment></comment><comment><USER37> 'dont be evil'

<comment><USER37> by down-voting this is getting even more evil, I don't mind what google does, just please don't wear a 'dont be evil' outfit while doing it, you can't have it both ways, why bother.

<comment><USER38> I'm pretty sure you're being downvoted because your comment didn't add any value to the conversation.

Beyond that, we see a "don't be evil" comment every time a Google-related post comes along.

<comment><USER37> I hope we can have a google competitor on the horizon, it does not matter what google claims, once it starts to monopoly, it starts to get evil, i.e. forget about the interoperability, forget the open source, my way is the best,etc. google is becoming microsoft quickly under the new CEO, like many others, I'm finding alternatives for all related google services, I'm ok with that actually, just find its 'dont be evil' slogan becomes even more so ridiculous.

<comment><USER39> Google doesn't have a monopoly in instant messaging. Far from it, they are lagging behind Facebook, WhatsApp, etc. What good is Google doing for the world having an open product that almost nobody uses?

</comment></comment></comment></comment></comment><comment><USER40> It's a defensive posture in response to what Apple has been doing with iMessage.

</comment><comment><USER41> It's often not in the best interest of private companies to use open standards. If using an open standard is a net financial loss, why should the company do that? It's simply the result of how the system works. I've been thinking whether the rules (=laws) can be changed somehow to provide incentive for using open standards, but it's quite a complicated problem.

<comment><USER42> Instead of adding more rules with their inevitable unintended consequences, I'd rather we'd kill the rules that promote closed protocols, like the anti- reverse-engineering clauses and overreaching "anti-hacking" laws.

</comment></comment><comment><USER43> It's just a matter of time before something like Vidyo [1] is replaced by WebRTC. There is too much at stake for Google to be the kitchen sink for all kind of technologies. They want you to connect to them.

[1] <http://blog.vidyo.com/technology/the-new-google-hangouts/>

</comment><comment><USER44> Internet abandons Google, heads back to the glory days of Prodigy and Compuserv.

Sales of animated gif skyrocket, solving financial crisis.

</comment><comment><USER45> IMAP in gmail next

<comment><USER46> got a source? Or just wildly speculating?

<comment><USER34> They killed calDAV. IMAP is a bit of a jump, but mark my words, cardDAV will be next.

</comment></comment></comment><comment><USER47> Actually makes total sense. Companies like Google should always remain ahead of the curve. They should innovate much faster than any of the open standards could grow.

<comment><USER36> They can use XMPP as a base and build extensions for everything they need atop of that, then use these extensions immediately while they go through the XSF and eventually become a standard.

XMPP has sort of been designed with extensibility and innovation in mind.

</comment></comment><comment><USER48> The Google mantra "Don't be evil" - not! Decision to drop XMPP is bad/evil. Seems more like the strategy of customer lock in.

</comment><comment><USER49> Thank god XMPP is disgusting.

</comment><comment><USER50> We abandoned xmpp for node.js and websockets at www.tesla.im

</comment><comment><USER51> I switched back.

</comment><comment><USER30> Does anyone else see the radical changes going on over at Google? They are in bed with the US government. It's now less about serving up search results and more about retaining all information on you. Google is evil.

<comment><USER52> What, concretely, does Google gain from spying on you? In contrast, they have a very clear profit motive for search: they get paid a lot of money to put ads next to the search results.

<comment><USER18> The same motive. This isn't even a secret conspiracy, their ToS says they do it and says that is why they do it. The more data they have on you, the more ad money they make.

Why do you think the ads you see in a search just happen to contain items you were just emailing your mother about a day prior?

</comment></comment></comment><comment><USER53> The sad thing is, no one has noticed that Hangouts is invoking a WebRTC plugin in my PulseAudio container, leading me to believe that they're already experimenting with WebRTC.

With WebRTC, a proper signaling protocol (they're probably using Jingle anyway, give the RTC history and the fact that RTC relies and builds on Jingle), and a relay server, there's not much to need to do to interoperate if they wanted to enable it.

This whole notion that they "can't" make it interoperable or that it will "slow them down", is complete and utter shit. Slow them down on what? All I've seen so far is more merging of GoogleTalk+GooglePlus and a rebranding effort. Basically no new feature, no integration with Google Voice, no seamless integration with SMS.

</comment><comment><USER54> Time for email, im, calendar, tasks, notes, docs and other services start-ups (for individual users).

Better if they are decentralized. You wouldn't have to move everything at once. But this will also increase costs.</comment>