On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:
On Tuesday, 6 January 2015 at 06:14:37 UTC, Joakim wrote:
On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
[...]
Most commercial adopters are going to consider it very
important to have a support option that says, "If you have a
serious blocker, you can pay us money to guarantee that it
gets fixed."
They are not going to be at all happy about a support option
that says, "If we develop a fix, then you are not going to
get it in a timely manner unless you pay."
Understanding that distinction is very important.
Haha, you do realize that those two quotes you laid out are
the exact same option? In the first option, you pay for a
fix. In the second option, you pay for a fix. What
distinction you're hoping to draw has not been made.
In the first option, you pay for a fix now, or you get it for
free when it's done independently of you, e.g. because someone
else paid.
I don't know of any commercial support model where you only pay
for the fixes you need at any given moment and the fixes that
others paid for are provided to you for free. I presume you're
referring to support subscriptions, where you pay a monthly fee
to subscribe to an stream of ongoing fixes and pay extra for
fixes you need right away. But that's not "free," you're paying
a monthly fee for that ongoing subscription, which subsidizes the
cost of those fixes that others paid for first.
In the second option, you pay for a fix. If it's done
independently of you, you still pay.
You pay for both types of fixes in both models.
[...]
I also think you assume far too much value on the part of
privileged/early access to bugfixes. A bug in a programming
language toolchain is either a commercial problem for you or
it isn't. If it's a commercial problem, you need it fixed,
and that fix in itself has a value to you. There is not
really any comparable change in value if that fix also gets
delivered to other users (who may or may not be competitors
of yours), because that isn't what differentiates your
product.
Of course there's a change in value. If another user or
competitor also needs that fix and pays for it and upstreams
it before you do, that's a cost you don't have to pay at all.
Hence the whole "tragedy of the commons" I laid out in my
first post.
If I get him right, Joseph's point is that the patch's value
(not its cost) for the customer doesn't change whether others
have access to it or not. So there's no advantage for the
customer in the early-access model. But there's a disadvantage:
have to pay for every patch. And so, an early-access model may
not be attractive to paying customers.
My point was that he's wrong that the patch's value doesn't
change if others have access to it. Just because that patch
doesn't clearly differentiate your product on a spec sheet
doesn't mean those patches in aggregate don't differentiate your
time to market and cost of making the product, which will all
affect your bottom line.
There is no disadvantage to paying for the patch in this model,
because otherwise you don't get the patch. You are paying
someone to write the patch so that it exists in the first place.
Otherwise, you can hope that some OSS dev gets to it someday when
he gets some spare time.
If I get you right, you're saying that the revenue for the
patch writer changes depending on if they sell the patch once
or twice. And therefore, there's an advantage for the patch
writer in the early-access model: can sell one patch multiple
times.
Yes, that's one of the big benefits, the patches become his
product.
You're both not wrong. If it works as planned, the early-access
isn't benefitial to the buyer, but to the seller. And that's
the point: move (more) money from customers to patch writers.
It's not a "win-win". It's not supposed to be. But if there's
nothing to gain in an early-access for the customer, why should
they prefer it over a competitor with
immediate-access-for-everyone?
It _is_ win-win, that's the whole point. It's even win-win-win,
to crib a term from The Office, ;) because the OSS project
eventually also gets the patch after a delay.
I don't know who this hypothetical competitor is who provides
"immediate-access-for-everyone" and is cranking out a ton of
patches. They currently don't exist.
[...]
On the contrary, D is a programming language, and as such is
used by people to make commercial projects, and so those
people have a very strong interest in paying for commercial
support, based around the principle "If we need something
fixed, it will be fixed."
But they don't have an interest in a situation where, "If
something gets fixed, we have to pay."
The first of those options delivers value. The second is
exploitation.
I suggest you actually read what you're writing:
"people have a very strong interest in paying for commercial
support, based around the principle 'If we need something
fixed, it will be fixed.'"
"If something gets fixed, we have to pay."
In both cases, they're paying for fixes. If your point is
that in the first model they're paying up front through a
support subscription, whereas in the second model they're
paying after they identify the fix- a distinction I'm
stretching to find as you haven't really made it- both are
still paying for a fix.
In the first model, they pay for specific fixes and get any
others for free.
In the second model, they pay for all fixes.
I think calling it "exploitation" may have been a bit inciting,
but I can understand the concern. Charging for bug fixes is a
bit shady, when we introduced the bugs ourselves.
Who is the "we?" Paid devs fixing bugs in the existing OSS
project that were introduced by OSS devs is not a "we."
Of course, it is always possible for some devs to try and game
the system, just as people sometimes accuse OSS companies using
his favored support model of making their software overly complex
so that they ensure more support contracts.
But you could probably go a long way just finishing features or
fixing existing bugs in the OSS project.
And the whole thing could put off existing users, maybe even
contributors. Especially when core developers would work on the
early-access patches, the larger community could feel left out
in the rain.
Who cares. First off, D's core OSS devs have given no indication
they'd be interested in working on such paid patches, so the paid
devs would likely be a completely separate group.
Even if some of the existing OSS devs wrote some paid patches,
the D OSS project exists because of the generosity of Walter,
Andrei, Kenji, and a couple dozen other volunteer contributors
who give away their work for free under an OSS license. To
suggest that they are therefore bound to always provide future
patches for free is frankly ridiculous. They could all just stop
working on D tomorrow, they have no responsibility to keep
providing all this free work.
Similarly, they have no responsibility to not sell some patches
to paying customers, simply because some spoiled handful will
throw a hissy fit because they're not getting _everything_ for
free anymore. If they really want those patches, they can pay
for them or write them themselves.