On Friday, 9 January 2015 at 04:33:53 UTC, Joakim wrote:
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.
Start listing:
1. What alternatives the seller has.
2. What alternatives the buyer has for all likely use scenarios.
And you you'll see why your model is either inferior or similar
to existing models.
Selling patches is basically no different from selling plugins
without QA. That's not very attractive. For plugins to work in
the market you need a customer that buys incremental upgrades
(like musicians who spend all their money on gear hunting for the
next big sound).
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.
You are speaking as if people don't sell customized systems. They
do. They sell a customization service or they sell niche products
where you negotiate the price with each customer. That way you
can give the customer good value and still be able to charge a
premium. Make your pricing public and you end up with lower
margins and have to sell more. The problem is, if there is a
market for more, then there is a market for a new independent
product too.
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.
Then read it again. You are writing as if you are offering
something new. You are not.
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."
Vendors of expensive software ignored (turned a blind eye to)
piracy for a long time because it eroded the market for the less
expensive competing products and gave themselves increased market
share. Then they formed an alliance to address piracy to combat
piracy and enforce purchases.
Other vendors sell cheap LE versions of their products to erode
the market for competitors, then they stop selling LE versions of
their product forcing an upgrade to a more expensive product for
customers who are then locked in.
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.
Why would a company want to depend on a conglomerate of
individuals? No contract, no sale. You need to be accountable if
you are going to charge real money. Without being accountable
there is no quality. The quality of FOSS is entirely dependent on
volume (lots of users testing it).
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.
But the customer don't want the patches. They want a working tool
with support. Building your own tool is more expensive than
buying an expensive ready-made.
Who are you customers? Define scenarios that are concrete.
Without concrete scenarios all you are left with is hand-waving.
