An idea for commercial support for D

[Joakim via Digitalmars-d]

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.