An idea for commercial support for D

[Joakim via Digitalmars-d]

On Thursday, 8 January 2015 at 23:22:19 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 8 January 2015 at 15:27:57 UTC, Joakim wrote:
>> the customer not being very price-sensitive.  As for 
>> estimating the total cost, the seller also needs to estimate 
>> his expected revenue, ie how much demand there is and at what 
>> price.  With this model, you are allowing the seller to get a 
>> better estimate and more certainty.  Meanwhile, the buyer 
>> takes on more risk, but if he wants that product to exist, he 
>> may be willing to do that.
>
> Realistically, a software development project can be either:
>
> 1. A small project the developer will pick pre-existing tools 
> for, but can afford failure, and possibly let the programmers 
> pick the language as a motivational bonus. Not a customer.
>
> 2. A pilot for a larger project evaluating existing tools. Your 
> tool will be one of many, so you need to be "available", or the 
> developer will select another one.
>
> 3. A larger/critical project where you get rid of unknown 
> factors before you start.
>
> In order to attract a category 3 customer you need to offer 
> something substantial and solid. If it isn't substantial the 
> customer would be better off hiring a local consultant which 
> she or he can bring in whenever they get stuck.

I have little idea why you're going into all these detailed 
business cases that have nothing to do with the two separate 
concepts I've laid out, but what the hell, I'll bite.

D is not ready for 3., I don't see many using it for that.  It's 
mostly 1. and 2., and they will pay some amount for features or 
polish they need, though obviously not as much as 3.  However, D 
has been used for 3. at Sociomantic, where they were willing to 
develop a concurrent GC and other features to make it more 
capable for their particular use.  It is possible that other 
companies would similarly try to use it for 3. but outsource 
development of such key features that they need, though unlikely, 
simply because 3. is just a much bigger bet.

> The you have to consider this:
>
> 1. If the feature you want to sell is substantial then it also 
> means you will have to cover the costs until you can deliver. 
> Nobody will pay a large sum in advance unless there is a 
> guarantee (like insurance or a very big company behind it).
>
> 2. Maybe only 30% of your products break even. That means you 
> have to recoup all the 70% losses  from the profits of those 
> 30%. That means you cannot afford small margins on the features 
> that are useful. That also means that competitors can wait to 
> see what you do and implement them when they see them being 
> successful (which makes it cheaper for them). So you have to 
> offer something that can recoup the costs+losses from other 
> projects in the within the timeframe you have before other 
> solutions pop up.
>
> 3. No sane business can afford to give a away a product that is 
> still selling, and if you are able to sell it to N customers 
> today with no marketing, it means that you with more marketing 
> can sell it to N*M customers until a competitor offers a better 
> product.
>
> 4. If you have something that sells, it will be better for you 
> to enhance it so that you can charge more for it by giving the 
> customer features they would otherwise not pay for 
> individually. And it will make your product too expensive to 
> wipe out for competitors (the Adobe approach). It's 
> psychological.

This is all general business strategy that has essentially 
nothing to do with the specific ideas in this thread.  I'm not 
sure what connection you're trying to make.

>> I have no idea why you're talking about bugs and performance, 
>> as a variable pricing model has nothing to do with those 
>> software features.  Maybe you're talking about the paid 
>> patches idea I laid out earlier, but that's a completely 
>> separate concept from this variable pricing model.  Suffice to 
>> say, paid patches can be written for both bugfixes and 
>> performance: I never limited it to just bugfixes.
>
> On the contrary, a pricing model and the product is related.

Yes, but nobody has proposed this variable pricing model for D.  
Zach and I were just talking about other pricing models, and I 
pointed out that this kind of variable pricing can and should be 
used for all kinds of IP.  However, I did not relate it to the 
earlier paid patches idea.  I do think variable pricing will be 
applied to paid patches someday, but I have not suggested doing 
it right away.

> Product differentiation has been the norm for development tools 
> for ages. There is nothing new about it. You identify different 
> market segments and pick the feature set. Then you leave out 
> that one feature that breaks that segments apart (like team 
> features or optimization).
>
> Another option is to allow plugins: photoshop, audio/music 
> editors etc, or precompiled libraries. Many tool developers 
> offer additional options to their base product, even if just 
> libraries. Nothing new here.
>
> The model you are advocating fits more for the casual market as 
> can be seen in iOS appstore, the "freemium" model. The drug 
> dealer model. You give away a free dose of the drug, then 
> charge for "upgrades" in a slippery slope fashion.

So every development tool vendor in the world who gives away a 
free starter tool and then charges for an upgrade, or even those 
in-store displays where they let you try out some food for free 
before you buy more of it, is a "drug dealer?"  Yes, there are 
some superficial similarities, but I'd call it more "try before 
you buy."

>> Sure, the first to pay will be existing companies using D, but 
>> you could attract a lot of new companies with paid patches, as 
>> what they really care about is having access to good tools.
>
> Ok, but then you are just selling a different compiler which 
> uses DMD as a "framework". So then I don't really understand 
> how that is different from a regular closed source vendor who 
> submit patches when it makes sense for their business.

The differences are in the original post.  A "regular closed 
source vendor" is simply a collection of developers who pool 
their patches together and sell them compiled into a closed build 
of the compiler.  In this case, the developers would not all work 
for a single company, but the customer would still get a build 
with some assortment of closed patches from some selection of 
independent paid devs compiled in.

Also, the customer would eventually receive the patches under an 
OSS license, the boost license which this project uses, after a 
delay based on a funding and time limit.  A regular closed source 
vendor usually does not do this.  Even the hybrid Android model 
that I've referenced doesn't do this, as the closed patches and 
binary blobs that companies like Qualcomm and Samsung add into 
Android builds are usually never open-sourced.