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. In the second option, you pay for a fix. If it's done independently of you, you still pay.

[...]
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.

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.

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?

[...]
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.

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.

Reply via email to