Yosefk (and to a lesser extent, even Gabriel) fails to foreground the most obvious interpretation: that market fit & human needs are not identical (and in some cases even conflict).
When we talk about something being “technically superior”, we’re really talking about how well it meets the needs of the kinds of users who argue about technical superiority (which is a subset of users, and not necessarily a rareified one). When we talk about something being “successful”, we’re talking about deploy scale (which is desirable in a market context – if you’re getting a cut from every copy then you want to ship as many copies as possible, whether or not the resulting situation is desirable for anybody else – but is a bit strange from the perspective of an open source project, since the occasional benefits of popularity don’t remotely make up for the increased maintenance demands).
There’s no particular reason for these to be aligned: we all admit that technical quality is only a minor factor in success. But, ultimately, a more inclusive idea of technical quality (how much is the average user’s life improved by this piece of software) is an objective measure of value – one that doesn’t take into account all the elements in a market context that inflate cost-value or deploy scale while failing to add to use-value.
Worse is Better brings up the division, but it doesn’t clarify it to the extent where it becomes obvious to a casual reader which we should optimize for. Thinking about it in a market context clarifies it. Markets are a lot better at inflating existing stores of cost-value than they are at creating new use-value, so we should only optimize for scale when we get a cut per deploy. If we aren’t being paid, or if we are being paid a flat salary, we should optimize for technical excellence.
market fit & human needs are not identical (and in some cases even conflict).
the more I think about this, the more I think that the majority of problems societies face today are just different manifestations of this same root cause.
That, or the tendency to pretend market fit is the best approximation for human needs even when a better one is obvious. Economists are generally pretty well-aware of the failure modes of markets, but economics fans often stan markets when they aren’t the right tool for the job.
I think this article dances around the point without stating it. Users just don’t care about the things you do, and they’re not going to no matter how mad it makes you.
Yosefk (and to a lesser extent, even Gabriel) fails to foreground the most obvious interpretation: that market fit & human needs are not identical (and in some cases even conflict).
When we talk about something being “technically superior”, we’re really talking about how well it meets the needs of the kinds of users who argue about technical superiority (which is a subset of users, and not necessarily a rareified one). When we talk about something being “successful”, we’re talking about deploy scale (which is desirable in a market context – if you’re getting a cut from every copy then you want to ship as many copies as possible, whether or not the resulting situation is desirable for anybody else – but is a bit strange from the perspective of an open source project, since the occasional benefits of popularity don’t remotely make up for the increased maintenance demands).
There’s no particular reason for these to be aligned: we all admit that technical quality is only a minor factor in success. But, ultimately, a more inclusive idea of technical quality (how much is the average user’s life improved by this piece of software) is an objective measure of value – one that doesn’t take into account all the elements in a market context that inflate cost-value or deploy scale while failing to add to use-value.
Worse is Better brings up the division, but it doesn’t clarify it to the extent where it becomes obvious to a casual reader which we should optimize for. Thinking about it in a market context clarifies it. Markets are a lot better at inflating existing stores of cost-value than they are at creating new use-value, so we should only optimize for scale when we get a cut per deploy. If we aren’t being paid, or if we are being paid a flat salary, we should optimize for technical excellence.
the more I think about this, the more I think that the majority of problems societies face today are just different manifestations of this same root cause.
That, or the tendency to pretend market fit is the best approximation for human needs even when a better one is obvious. Economists are generally pretty well-aware of the failure modes of markets, but economics fans often stan markets when they aren’t the right tool for the job.
From that perspective the critical variable is the time constant Tc
ie. “X is better than Y when evaluated Tc months after start of project”.
For the CEO driven by quarterly reports point of view, Tc is 4 months.
For a programmer herding the code for years, Tc is probably years.
For a Fix Term contracto,r Tc is slightly less time than his contract is for.
In the Torvald’s “market for ideas” environment, it’s how long does it take for an alternate idea to become mature enough to be a viable competitor….
…which then tends to depend on just how bad the original idea was as the original idea keeps evolving.
If we take the history of ip tables as an example…. Tc is measured in years.
If we take init systems, it took init.d dominated for decades before systemd made serious inroads.
I think this article dances around the point without stating it. Users just don’t care about the things you do, and they’re not going to no matter how mad it makes you.