I would prefer to pay 20% more for product which works perfectly, than for product which almost works. But no one asked me.
More revenue -> company grows
Less revenue -> company shrinks
Regarding the new conversation topic: some open source software does have revenue. Forms of revenue include: donations, selling support, selling licenses that are less restrictive than the original open source license, ads, and selling addons. Yes, revenue for open source software is generally less than for-profit software, and despite that the open source software is often higher quality. I didn't claim that a higher quality product will always have more revenue than a lower quality product. I just made a claim about where the money goes.
The above statement of course raises more questions than answers;
A) you believe Open Source should be funded. Are you willing to be a funder?
B) do you believe me when I say I write Open Source? (You shouldn't, I don't)
C) since you won't be managing this project, can I assume you'll just hope the feature you want will materialze at some point? In the form you are hoping for?
D) will you fund "any" Open Source, or only the OSS you are using? Or want changed?
I'd rather take a step in the right direction than none at all. If the management can be convinced that there's more money to be made this way then that gives us engineers more power to convince them to solve other such problems. If they care about quality then that gives us back negotiating power. You don't outsource to a third world software mill or AI when your concern is quality. But you do when you were trying to sell the cheapest piece of shit that people will still buy. So yeah, I'm okay with this
> You don't outsource to a third world software mill or AI when your concern is quality.
That's a disastrously fallacious set of presuppositions. A good engineer will use AI well to improve their software, whereas a bad engineer will use it to produce junk.
> but it's not going to solve the problem
I want to stress that this is a highly complex problem that needs to be solved and that means we need to break it down into smaller manageable tasks. You're not going to change everything overnight, a single person won't change things, nor will a single action change things. There's no clear definitive objective that needs to be solved to sole this problem. Nor is there a magic wizard in the tower that needs to be defeated.
In other words, I gave you my explanation for why I think this can be a step in the right direction (in a sister comment I said even more if you want to read that). But you have complained and given no alternative. Your only critique is that it does not solve the problem in one fell swoop. That was never an assumption I made, it is not a reasonable assumption to make (as you yourself are noting), and I explicitly said it is not an assumption being made. Do not invent problems to win an argument. All you've done is attempt to turn a conversation into an argument.
> it would be a step in the right direction, but only a single step.
> That's a disastrously fallacious set of presuppositions.
Do we need to fight or can we actually have a discussion to help figure out this problem together? You do not need agree with me, contention can be beneficial to the process, but you do need to listen. I have no interest in fighting, so I'll leave the choice to you.
> I would prefer to pay 20% more
As a simple version think about it this way: if a customer can't tell the difference in quality at time of purchase then the only signal they have is price.
I think even here on HN if we're being honest with ourselves it's hard to tell quality prior to purchase. Let alone the average nontechnical person. It's crazy hard to evaluate software even hands on. How much effort you need you put in these days. The difficulty of differentiating sponsored "reviews" from legitimate ones. Even all the fake reviews or how Amazon allows changing a product and inheriting the reviews of the old product.
No one asks you because all the sellers rely too heavily on their metrics. It's not just AI people treat like black boxes, it's algorithms and metrics in general. But you can't use any of that effectively without context.
At engineers I think we should be a bit more grumpy. Our job is to find problems and fix them. Be grumpy to find them. Don't let the little things slip because even though a papercut isn't a big deal, a thousand is. Go in and fix bugs without being asked to. Push back against managers who don't understand. You're the technical expert, not them (even if they were once an engineer, those skills atrophy and you get disconnected from a system when you aren't actively working on it). Don't let them make you make arguments about some made up monetary value for a feature or a fix. It's managements job to worry about money and our job to worry about the product. There needs to be a healthy adversarial process here. When push comes to shove, we should prioritize the product over the profit while they should do the opposite. This contention is a feature, not a bug. Because if we always prioritize profits, well, that's a race to the bottom. It kills innovation. It asks "what's the shittiest cheapest thing we can sell but people will still buy". It enables selling hype rather than selling products. So please, be a grumpy engineer. It's in the best interest of the company. Maybe not for the quarter, but it is for the year and the decade. (You don't need to be an asshole or even fight with your boss. Simply raising concerns about foreseeable bugs can be a great place to start. Filling bug reports for errors you find too! Or bugs your friends and family find. Or even help draft them with people like on HN that raise concerns about a product your company works on. Doesn't need to be your specific team, but file the bug report for someone who can't)
And as the techies, we should hold high standards. Others rely on us for recommendations. We need to distill the nuances and communicate better with our nontechnical friends and family.
These won't solve everything but I believe they are actionable, do not require large asks, and can push some progress. Better something than nothing, otherwise there will be no quality boots to buy
> Being grumpy works locally. It won't fix the industry, but it fixes your team. And when enough teams refuse to normalize this, the pattern shifts.
We solve big problems by turning them into many small problems. There is no difference here. One step at a time.