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.
