Understanding user support systems in open source | Hacker News Reader

Understanding user support systems in open source

nadiaeghbal.com

48 pointsryanar15 comments

I maintain a many projects which are not huge, but some are in the thousands of Github stars and often get an issue or two per day. Across all of my projects I probably see 10-20 new issues per week.

My approach is straightforward: help them help themselves. We have some easy things we can do to encourage people to find the information they need to sort out the problem, coaxing out of them debug logs, core dumps, and so on, and sometimes give them our suspicions about the problem. Then we tell them to start digging, and that we're around to answer questions if they need help finding their problem. This process ends with a patch from that user.

My projects also often have an IRC channel, where users often help each other with straightforward issues, and we never have to get involved. Sometimes a dev is paying attention and will give them the same rundown. If someone seems enthusiastic about digging and making a fix, they're invited to the dev IRC where they can receive more developer-oriented support in understanding the code and introducing them to the contribution workflow.

Sure, it's not the friendliest approach for anyone who isn't willing or able to figure it out themselves. But we're all volunteers and no one is going to volunteer their time to do something they dislike. We volunteered to write code because we like writing code. End-user support is not fun for us. If you like it, volunteering to do it is easy and has basically no onboarding time, you just show up in the support channels and start helping people.

I think it's a good approach and similarly it works for some projects I help out with.

But for some projects it's not working in my experience - especially if you have a lot of non-technical users, for example in a PHP web application.

I'm focusing on PHP because you don't just deploy a Python or Ruby web app without at least a bit of developer or *nix experience, whereas shared hosting with "follow these 3 steps and have an ftp client" still works in 2018.

In this case the bug reporters are probably not returning, the bug is often fixed in 10mins of developer time and just explaining what all the words mean takes longer than doing it yourself. Sadly these are often also the most ungrateful, so I'd be inclined to just ignore them - but at least we can improve the software after the bug report. Of course not all of them are bad, sometimes you literally have users that wouldn't know how to fix CSS, but they're testing all your new releases and provide feedback - awesome, but not technical.

For the "Issue Triage" analysis I would say lines_added,lines_remove,commits,number_issues_involved_in would be interesting to see as well.

For example caphrim007 is number 5 in commits over that period but added 5x as many lines of code as next closest committer. However, the code maybe against a new under-used feature so the actual end-user usage could be low.

It would also be interesting to juxtapose top committers commit graphs against issue assignment and resolution timeline. When does issue triage by top committers wax and wane? Do big commits (new features) overlap with issue assignment/resolution dates? Does high volume issue assignment/resolution follow big commits?

Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials.

Most of the dysfunction I see in open source projects that take an ambivalent attitude towards the bug fixes and urgent feature needs of long-term users seems based in pure ego. Core devs want to keep being the leading edge designers and implementers of the project and are extremely stingy about letting new or intermediate contributors to the project bring fresh perspective and excitement into big new feature implementation or refactoring.

You can make a lot of disingenuous arguments that this is to protect the style and design approach of the original core, but it’s not. It’s just ego.

Look, people are obviously free to say if they are dedicating their free time to some open source project, then they only want to work on the aspects of it they like or the aspects that might seem glamorous in a blog post or conference presentation or whatever.

Being “allowed” to take that attitude is pretty much inconsequential though. If you do that, your project is entering one of two modes: death mode where new developers realize you will only permit them to work on gruntwork and you lose any capacity to actually fix things because nobody joins your project, or North Korea mode like the linux kernel where some crazed monarch or oligarchs use intimidation and public shaming as primary code review techniques.

If you are a really smart core dev of open source, stop working on the big new features. I know it hurts your ego to let your baby into the hands of newbies. Instead, do more code review, tutorials, answers on SO, and go way out of your way to make new contributors feel like you are impressed with their skill, that you want to pair with them through meaningful PRs right away, no “good first task” grunt work ego crap.

> Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials.

At this point you need management and support staff. Trying to pound square peg developers into those round holes is rather hopeless, especially when it is free work not paid.

Sure, I agree it’s still logistically challenging. I’m just claiming the hard part is the ideological hurdle of getting the original core devs of the project to willingly facilitate frequent “changing of the guard” where the burden of critical new features and design is wholeheartedly given to new and intermediate developers of the project, to graciously let other people take the reins and have the core devs with an attitude of service to their community of users, fixing bugs, adding small feature enhancements, and particularly creating excellent documentation and tutorials.

That’s the first step. Templates, disqus boards, SO, etc., aren’t going to save you if the core devs view the open source project as a walled garden where they pick and choose what to work on based on a need to “be the one” who is responsible for milestones of implementation.

What's the incentive to those developers to take on this pain-in-the-ass corporate kind of work, rather than just doing the work that they enjoy that made the project noticeable in the first place? Nothing is owed to anybody, if it's being made into unpleasant management work, you can just pick up your ball and go home and do something else.

I'm not really sure I want new developers doing core work on a project, and would be somewhat skeptical of projects that did adopt such practices without heavy oversight.

The incentive is just if they want the project to survive and thrive and continue. They may not want this, or may value their pleasure of hacking on it higher than long-term liveness.

I’m not making any normative judgments about _whether_ they want one set of preferences or the other, only commenting that it turns out (normatively) badly, from the perspective of the community around the project, if they don’t prioritize the overall liveness of the project (which comes at the cost of “doing as they please”).

I think core developers should do whatever they want. Nobody is entitled to anything from a developer of an OSS project, unless there is a contract and/or money involved.

I think they have every freedom to do what they want. It will just turn out badly if they use that freedom to choose a walled-garden approach that expresses ambivalence to both user support and on-boarding new contributors by giving them tasks with visible impact and reasonable amounts of creative autonomy.

I only care about what core devs “should” do from the perspective of “what keeps a project healthy.”

If someone wants to optimize that choice for something else, like their personal enjoyment of hacking on a new feature, I think it would have unfortunate consequences, but other than stating my feeling about that, I couldn’t care less and it seems irrelevant to the discussion.

That’s why I characterize it as an ego problem. As far as the whole rest of the project and user base is concerned, what some particular person wants just doesn’t matter.

Yes, they’re free to make their choices that way. Then it just takes that particular case out of the discussion we’re having here about providing user support.

A perfect example is the TensorFlow project's support policy which the article references (i.e. they don't do support.) As long as a project is clear about what they will and won't do/provide, just about anything is workable. Far worse to claim to provide support and then be inconsistent about it... better to either say 'we don't provide support' or 'contact us for support options and pricing'.

TensorFlow is a very bad example of exactly the failure mode I’m talking about. In professional deep learning, TensorFlow is very widely regarded as a mess, with hostile developers who make breaking changes without warning and refuse to fix huge usability problems, let alone add important enhancements or support-specific bug fixes.

Nobody seriously uses TensorFlow without Keras, except in situations when they have to make custom modifications precisely to support broken things that the core devs won’t fix.

Contrast this with Keras and it’s night and day. Keras actually has support guidelines and a GitHub project and, even if lacking capacity, actually cares about its users instead of being willfully hostile to users like TensorFlow is. The original creator of Keras, Francois Chollet, can even be found very often in GitHub issue threads assisting totally novice newcomers to Keras and explaining tips and tricks with custom layers, etc.

I don't disagree, I find support across the board for Google products dismal. But isn't it better that they say 'we don't do support' than hold out hope that they might or provide spotty support? That way developers and users of the products, including TensorFlow, know what they're getting into. For the free projects that actually do provide good support, that's excellent and kudos to the developer/community that do so... they seem to be the exception these days.

I compare it to the 'old days' of software: it used to be common to have a phone number to call. Then it became email only and people complained there should be a support phone number. Then it was $0.99 apps and maybe you got a support forum. Now in the era of freemium, you're lucky if you get an online community support forum... and people complain when nobody monitors it. When you move to free, the support budget goes to $0 which leaves developers to shoulder support in addition to everything else. Unsurprisingly, many don't want to do this. If you're willing to pay, sure you can still get anything you want (up to and including on-site support for enterprise stuff if you have deep enough pockets) but as long as the default support model is clear at least one can make an informed decision. Support is one of those things that the $300+ (phone support), $30+ (email support), $10- (forum?), $0 (good luck) pays/paid for after all...

I guess I do agree with you that it’s better for a project to brazenly denounce support than to feign an effort.

In the case of TensorFlow in particular, it allows forward thinking people to realize it’s not a safe project to bet the farm on at all, not even anywhere close, even without factoring in Google’s tendency to sunset projects regardless of their relative success or community needs.

This is why nobody’s using it. Keras gives you the option of other backends, and there’s a large shift to PyTorch as well. Even being new and not as featureful, you simply just cannot stake the long term health of a project on the constant rug pull that is TensorFlow.

Reply on news.ycombinator.com