
Understanding user support systems in open source - ryanar
https://nadiaeghbal.com/user-support
======
Sir_Cmpwn
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.

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

------
whatupmd
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?

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

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

~~~
blihp
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'.

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

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

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

