An idea for commercial support for D

[via Digitalmars-d]

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.

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.

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

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.

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