After my third “per my previous email…” or “I’ve asked thrice for documentation regarding…” I realize I need to basically scrap the whole response and start over.
Working with FOSS software has set extremely high expectations that vendors cannot seem to meet. Like, all these projects are built by unpaid volunteers and have amazing documentation. We’re paying you a lot of money - what’s your excuse?
EXACTLY! I mean I’m coming from a sysadmin side, but I’ve definitely been spoilt by all the manpages, flexibility, stability, etc of foss. It’s insane how some vendors can ship a product with pretty much no logging and call it a day.
That’s where I’m at: sysadmin side of things. We spent 2 weeks going back and forth on an issue with the reporting component that was only solved by a Zoom meeting. The culprit was a missing config key/value, and they had the gall to say “oh, you should have had that configuration option set; this isn’t our fault.”
And I pointed to the documentation they gave us regarding that:
Like, the config is an uncommented JSON file with no defaults/examples whatsoever. There is literally no way for us to know what key/values are valid because none of it is documented. And that’s just the tip of the iceberg. lol
At least our project manager was on my side and fought them to not charge us for that “support” call.
My god. Per-call charges should really cease existing. If it’a number of support calls that’s making you money and not the product - your product sucks.
Like, all these projects are built by unpaid volunteers and have amazing documentation. We’re paying you a lot of money - what’s your excuse?
This is so true and it boggles my mind.
I understand the open source side of things. I write good documentation because every minute I spend on that saves me an hour in answering questions. It also helps any new employees get up to speed. And honestly, it helps me keep up to speed because I’m way too old to keep all this stuff in my brain long-term. I can’t remember half the shit I did last year. Not in sufficient detail, anyway. I’m kicking myself now for not documenting all the steps I took configuring my personal Linux desktop, because I hopped distros and now I have to re-learn things I haven’t done in years.
I don’t understand the commercial side of things, because…aren’t you paying your support people? Isn’t that time costing you money?
Is the issue that the salary of the people with the technical knowledge to write good documentation is much higher than the support staff? Is it that paying customers by and large will not read documentation anyway? Is it because they are reserving the right to change everything radically without notice, and to hell with semantic version numbering?
Or is it that operational/ongoing expenses are easier to justify to beancounters than capital/one-time expenses in general? (Which seems totally backwards to me.)
Anecdotal, but in my org’s case, vendors providing little to no documentation seems to be due to one (or more) of a few things:
Ensuring an ongoing support contract that wouldn’t be needed if the product were properly documented (this is in addition to the software maintenance contract for updates/patches).
Nudging us toward their hosted, SaaS solution (and significantly higher ongoing costs)
They’re just generally terrible in one or more ways: writing documentation, disorganized development and project management practices, etc.
My org is a non-profit that deals with environmental remediation and often has to electronically submit data to the US EPA to qualify for grants, so pretty much all of the software we use is niche; more often than not, the lowest bidder is also the only bidder and we have to take what we can get. :sigh:
Here’s the thing, people who suck at what they do are usually either
A. Stupid
B. Overworked
C. Under-qualified
D. Under-compensated
It doesn’t matter which one(s) of those apply to them, your interactions with them should be adjusted the same regardless of why they suck. Limit all emails, all requests, and all questions to one topic only. Don’t try to get answers to 3 different things because it’s not going to happen. Address one subject, and only move onto the next after you have resolved that subject. Trying to do anything else is an exercise in futility.
I carry the attitude that withholding the fact they suck is being selfish and ignorant. How else are they supposed to improve? 😁
After my third “per my previous email…” or “I’ve asked thrice for documentation regarding…” I realize I need to basically scrap the whole response and start over.
Working with FOSS software has set extremely high expectations that vendors cannot seem to meet. Like, all these projects are built by unpaid volunteers and have amazing documentation. We’re paying you a lot of money - what’s your excuse?
😆
EXACTLY! I mean I’m coming from a sysadmin side, but I’ve definitely been spoilt by all the manpages, flexibility, stability, etc of foss. It’s insane how some vendors can ship a product with pretty much no logging and call it a day.
That’s where I’m at: sysadmin side of things. We spent 2 weeks going back and forth on an issue with the reporting component that was only solved by a Zoom meeting. The culprit was a missing config key/value, and they had the gall to say “oh, you should have had that configuration option set; this isn’t our fault.”
And I pointed to the documentation they gave us regarding that:
Like, the config is an uncommented JSON file with no defaults/examples whatsoever. There is literally no way for us to know what key/values are valid because none of it is documented. And that’s just the tip of the iceberg. lol
At least our project manager was on my side and fought them to not charge us for that “support” call.
My god. Per-call charges should really cease existing. If it’a number of support calls that’s making you money and not the product - your product sucks.
This is so true and it boggles my mind.
I understand the open source side of things. I write good documentation because every minute I spend on that saves me an hour in answering questions. It also helps any new employees get up to speed. And honestly, it helps me keep up to speed because I’m way too old to keep all this stuff in my brain long-term. I can’t remember half the shit I did last year. Not in sufficient detail, anyway. I’m kicking myself now for not documenting all the steps I took configuring my personal Linux desktop, because I hopped distros and now I have to re-learn things I haven’t done in years.
I don’t understand the commercial side of things, because…aren’t you paying your support people? Isn’t that time costing you money?
Is the issue that the salary of the people with the technical knowledge to write good documentation is much higher than the support staff? Is it that paying customers by and large will not read documentation anyway? Is it because they are reserving the right to change everything radically without notice, and to hell with semantic version numbering?
Or is it that operational/ongoing expenses are easier to justify to beancounters than capital/one-time expenses in general? (Which seems totally backwards to me.)
Anecdotal, but in my org’s case, vendors providing little to no documentation seems to be due to one (or more) of a few things:
My org is a non-profit that deals with environmental remediation and often has to electronically submit data to the US EPA to qualify for grants, so pretty much all of the software we use is niche; more often than not, the lowest bidder is also the only bidder and we have to take what we can get. :sigh:
Here’s the thing, people who suck at what they do are usually either
A. Stupid
B. Overworked
C. Under-qualified
D. Under-compensated
It doesn’t matter which one(s) of those apply to them, your interactions with them should be adjusted the same regardless of why they suck. Limit all emails, all requests, and all questions to one topic only. Don’t try to get answers to 3 different things because it’s not going to happen. Address one subject, and only move onto the next after you have resolved that subject. Trying to do anything else is an exercise in futility.