[tyingq]

Great article, though he's benefitting from a specific slice of Linux users that are great to work with.

On the other end of the spectrum, try releasing a php plugin for Wordpress, OpenCart, Magento, etc. I released a mildly popular, open-source, free add on in this space. The Linux users there are decidedly less technical, but still doing it themselves.

What I got for "bug reports" was mostly terrible, few details/logs/etc. And a weird entitlement thing where people had really high support expectations over something that was open source and free. Even a few expletive-laden emails. I did receive a few really helpful reports, pull-requests, and thank you emails...but they were very much the exception.

[chias]

I think the difference is:

With a game that supports Linux, you get people who have chosen to run Linux instead of Windows because they prefer it. They have also worked enough with their system to get their Linux system capable of running games well, which may not be trivial for the given distro.

With a Wordpress plugin or whatever, you get people who are running Linux because they "have" to. Trying not to sound "true Scottsman"y here, but most of the time these are not actually Linux users, these are Windows users who are further confounded by having to use an unfamiliar platform.

[Moru]

There are even a few php users trying to run windows server...

[tapland]

Yes, you get users who have linux as their 'daily driver', as opposed to those to dabble in it a bit on the side :)

[conductr]

For similar reason, I think the level of experience is probably different. Meaning those could be the same person and time is the important variable. After they’re used to developing, they better understand what useful feedback looks like.

[franga2000]

This is actually how I got started with development. I learned how to use Linux just enough to set up WordPress (and SMB) on an old computer. This got me into PHP development (I'm recovered now) which turned out to be unbearable on Windows. I started running Linux in a VM for development, but my pathetic hardware couldn't really handle it, so I tried it on bare metal. I'm now running some flavor of Linux on my workstation, laptop and multiple servers and am exactly the sort of crazy person who will spend hours of their unpaid time compiling a detailed bug report with stack traces and all for even fully proprietary software.

[oefrha]

In addition, in my experience maintaining a developer tool, an outsized source of bug reports is Linux users reporting already fixed issues in their outdated distro packages, or even problems introduced by their packager (e.g. flatpak/snap permission problems). And they typically won’t identify the version despite clear instructions in the issue template asking for the debug output containing everything I need, including the version.

[Arch-TK]

If you support distro packaging of your software (which you should, since it should ideally reduce the load on you when it comes to triaging bugs) and users are coming to you with distro specific bugs then you should:

- Immediately close issues where the user has indicated that they did not test against the latest version or where the user has not answered the question "did you reproduce this issue with the current version of the software built from source?" (You should just automate this)

- If users continue pestering you and they seem to come from a specific distribution: complain to the maintainers of the distribution and ask that they inform their users of the proper bug reporting channels.

New users are coming to linux on a regular basis and they're coming in with a windows mindset. It is important for the smooth functioning of both linux distributions and software projects to make users aware that the proper channels for reporting bugs they experience when using software which was packaged for their distribution is the distribution's maintainers.

Users need to be made aware that unless they're compiling directly from source and using a supported version then they have no business going to upstream with their bug reports.

You may think this is harsh but if you get backlash, distributions should have your back on this (they usually do have information somewhere to inform users that bug reports should go to them first). I recommend any open source project take this stance when it comes to bug reports. If someone finds a real bug and they are certain it's not one caused by their distribution then they can easily build your project and reproduce the bug there.

(Aside: If you are providing a library then an appropriate level of API stability is a must have if you want people to be able to actually test bugs in a newer library version.)

[account42]

I strongly disagree - I'd rather all my users filed their bugs directly on the upstream issue tracker for my projects so that I can get a proper view of what bugs are being encountered. If there are steps to reproduce then most of the time it will be a lot easier for you as the developer to just check if the bug still happens with the latest version than having the user or packager build it themselves. Don't expect users just have a build environment laying around or can quickly set one up. Don't expect that building the latest version is always easy on every distribution.

If its not easy to reproduce or if there are no reproduction steps then sure, ask for more information. It's also OK to refer to a distribution bug tracker if the user is not able to produce a useful report or if you suspect there is a packaging issue, but doing that for all reports of problemsx with distro builds, especially when using automation, is disrespectful of the time the user has spent on reporting the bug. So sure, you can do that (you don't owe users anything after all) but I think its rude and will only turn potental future contributors away. I'm definitely glad that that is not how most projects handle user reports.

If you are being overwhelmed by user reports then maybe you can find some dedicated people from your userbase that would be willing to help with bug triage?

[Arch-TK]

> Don't expect users just have a build environment laying around or can quickly set one up. Don't expect that building the latest version is always easy on every distribution.

In the case when a user is not technically skilled enough to test for the bug in the latest version themselves they should go to the maintainer whose job it is to be able to do that.

> but doing that for all reports of problemsx with distro builds, especially when using automation, is disrespectful of the time the user has spent on reporting the bug.

What? How is it disrespectful? They're helping their distribution and their distribution should be forwarding the bug onto you if it's not their fault.

In fact, if the distribution is aware of it then the user is more likely to get a hotfix sooner than if they go straight to you.

> So sure, you can do that (you don't owe users anything after all) but I think its rude and will only turn potental future contributors away. I'm definitely glad that that is not how most projects handle user reports.

It is actually how most old style open source projects operate. If you're happy to accept direct bug reports which are either already fixed in the latest version or which may be distro specific issues then go ahead. Please don't burden every other project with this kind of noise by making it clear that this is a project specific policy.

[ajvs]

Don't blame the user here - your bug reporting template should have users declare what package version they're using so that you can easily tell them they're on an outdated package. Flatpak is usually a boon in this regard since you can ensure your users are all on the latest packages, though you're making the tradeoff of having to deal with any Flatpak-specific bugs (which I'd say is a decent tradeoff for solo maintainers).

[oefrha]

> your bug reporting template should have users declare what package version they're using so that you can easily tell them they're on an outdated package

Of course I do that, and I said so. I do everything I can to make it trivial for users to give me all the information I need. They just don't give a shit. Some people won't read.

(And the extra irony here is that my original comment already mentioned issue template asking for everything, yet you didn't read it and jumped in to tell me "don't blame the user".)

Edit: I should also mention that this is FOSS work. I’m doing free support for these users who supposedly shouldn’t be blamed for wasting my time.

[tyingq]

Bug templates help, of course. But people do still just dump the wrong stuff in until the report is accepted. Like some kind of OS version in the App version field, for example. Or some ambiguous thing like "latest". Or copy/paste from an existing bug report from some other person. You can see this on many public repos.

[oefrha]

> Like some kind of OS version in the App version field, for example.

Oh, I would be grateful for even that. Often enough, the bug template is simply deleted, the last line of the error in non-debugging mode is pasted in along with a "doesn't work"; or just "doesn't work".

[efreak]

While I don't do this intentionally, I do use a native Android app (fasthub) to submit issues. So far as I know, there isn't any GitHub app that has support for issue templates. Occasionally I'll submit an issue without remembering to check for a template first, though I usually remember before actually submitting.

[oblio]

Congratulations for acting exactly like his bad bug reporters.

[5e92cb50239222b]

Most of the Wordpress developers I know are Windows users. (I don't know too many of them, but still.)

[tyingq]

That's interesting. Most of the WP devs I encountered are deploying on old-school shared Linux hosting, like BlueHost, GoDaddy, etc. Maybe some use Windows for local dev stuff, but I doubt many deploy their "prod" there.

[mAritz]

I think that's the issue though: You're seeing "Linux users" that only use Linux on their servers because they are somewhat forced to do so.

I would actually expect that almost all of those people use Windows or MacOS for their local development.

[grawprog]

And those hosts often are not using up to date packages and don't even have up to date security fixes at times.

I recently moved a wordpress site I was working on from a local dev setup onto a live bluehost server and was immediately hit with a bunch of out of date package warnings. As the customer was using some cheap shared hosting service, there wasn't much I could really do about it.

[linedash]

Shared hoster here. More likely the app arbitrarily decided 'these versions of PHP are EOL', where the reality is that they're being maintained by a number of OS vendors.

Too many customers run really old versions of code that need older versions of PHP and so on. We can't not provide them without losing the business. We do of course, make newer versions available.

The other fun one we periodically get is customers doing PCI scans or similar and getting warnings for out of date versions of OpenSSL, Apache, etc. Nope; just backporting showing the old version numbers.

[tyingq]

That's sort of funny, as one of the remaining few value pitches for something like Bluehost (versus a $5/month vps) is "somebody else does apt-get update && apt-get upgrade for you".

[lixtra]

Keep in mind that WP has a vast installation base, so your local sample is not necessarily representative. I only know WP admins that a fairly comfortable with Linux and use it on a daily basis.

[donatzsky]

Not a lot of Windows in the shared hosting space. And what little there is tends to be more expensive, from what I have seen.

And, perhaps other than knowing about permissions, you don't really need any Linux knowledge to use these hosts.

[midasuni]

Back in 1996 I had a website running on a shared unix of some sort. I could barely upload files in the correct binary/ascii mode, or copy and paste a “chmod” command.

My 1996 self would be the exact nightmare wordpress user today, although I guess I wanted to learn even though I didn’t know what I was doing, which is different to many comments I’ve seen on places like GitHub.