An idea for commercial support for D

Joakim via Digitalmars-d digitalmars-d at puremagic.com
Thu Jan 8 02:37:56 PST 2015


On Tuesday, 6 January 2015 at 20:21:50 UTC, Zach the Mystic wrote:
> On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
>> This is an idea I've been kicking around for a while, and 
>> given the need for commercial support for D, would perhaps 
>> work well here.
>>
>> The notion is that individual developers could work on patches 
>> to fix bugs or add features to ldc/druntime/phobos then sell 
>> those closed patches to paying customers.  After enough time 
>> has passed, so that sufficient customers have adequately paid 
>> for the work or after a set time limit beyond that, the patch 
>> is open sourced and merged back upstream.  It would have to be 
>> ldc and not dmd, as the dmd backend is not open source and the 
>> gdc backend license doesn't allow such closed patches.
>
> A funny scenario based on this proposal: Company A wants 
> feature B, and signs a contract with a developer for a certain 
> amount, receiving the feature as soon as possible, releasing 
> the paid-for software to the public after a year. During that 
> year, company C comes to the same developer wanting the same 
> feature. They say, "It's already paid for, but you can pay 
> company A half the development cost, minus the proportion of 
> time left before it's open to everyone, and you can both have 
> it!" Or something like that.

You're on the right track: I've talked in the past about a more 
advanced version of such a pricing model, that could be used for 
any intellectual property, not just for software.  How it would 
work is that the developer sets a price for all the work to 
develop the feature, say $3k, and picks a reasonable minimum 
amount of customers, say 20.  So he then sets the initial price 
at $150, which may seem high for a single feature.

But assuming he gets to 20 customers, the price drops for each 
subsequent customer, and the first 20 get a proportionate refund. 
  So when he gets to 30 customers, each of the last 10 to buy get 
charged $100, not $150, and each of the first 20 customers get 
their prices dropped to $100, so that the total for the developer 
is always $3k.  Right now, this may work better for an up-front 
payment model, say on a site like kickstarter, or some such 
marketplace where the customers have ongoing accounts and it's 
easy to credit money back to them without having to keep issuing 
refunds to their payment provider, avoiding the accompanying fees.

What are the advantages of such a model?  Well, usually the 
creator has to set a fixed price, whether $50 or $200, and take 
the risk that it is the sweet spot and will actually get enough 
customers to garner $3k, ie he has to guess at the supply/demand 
curve for his product.  In this variable pricing model, the 
customer also takes some of that risk, ie you'll pay more if 
enough other people don't also want the product.  But just like 
on kickstarter, that's a risk you may want to take, as long as 
you get the feature.  There are other elaborations on this model 
to account for some other factors, but the basic idea is here.

This kind of variable pricing model would have been too costly 
decades ago, with all the paper bookkeeping and chargebacks.  It 
would be trivial to implement today though and would be a much 
better model for many products.  Why isn't it done already?  
People are stupid, no other reason.


More information about the Digitalmars-d mailing list