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.
