On Friday, 9 January 2015 at 08:48:49 UTC, Ola Fosheim Grøstad
wrote:
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).
You are focusing on packaging, particularly related to how people
often do it today. As I already said earlier in this thread, the
initial packaging will likely be that all the independent devs
bundle all their paid patches together into a single patchset
against the official point releases, sell a single closed build
with that patchset compiled in, and split the proceeds, simply
because the software infrastructure for buyers to select,
compile, and audit individual paid patches doesn't really exist
yet.
But I believe that over time, the market will develop so that
it's common for buyers to pay for custom builds that only have
the patches they pick out, ie compilers and other software will
become fairly customized.
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.
Again, I see no connection between these general business
statements and my quoted analysis of what types of customers D
might be able to attract. You seem to have a problem with
rambling onto unconnected topics, then acting as though it all
makes sense. :)
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.
Looked over them again, still don't see the connection. Since
you seem to have problems keeping my two separate ideas above
straight, I'm not even sure which one you're saying is not new.
Perhaps you're not a native speaker of the English language, but
it is difficult to follow all the logical leaps you're making, as
one point seems completely disconnected from the other and none
seem connected to the topics from this thread.
I have noticed you do this several times in various threads on
this forum, and the only reason I can see is that you want to
show that you know a lot about the field by rambling on about
completely unrelated subjects to the particular narrow topic of
the thread. But that's just distracting to those of us who are
only interested in the narrow topic under discussion. Where you
stick to the topic, I've often agreed with you.
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.
Yet, I did not mention piracy at all.
As for vendors getting rid of the low-end version, there's always
other vendors. I mentioned in an earlier reply in this thread to
another commenter that as long as you're using a language with a
common spec and multiple commercial implementations, as most do
today, it's not a big deal.
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).
Ah, finally something approaching a valid criticism, glad to read
it. :)
Why do companies depend on AOSP or other OSS projects today?
They're also written by a random conglomerate of individuals and
companies. In the case of this paid patches idea, the companies
_would_ contract with each of the paid devs to provide both the
patches and support. You could keep the contracts fairly
lightweight and standard across devs, certainly initially. I
hope you're not arguing that coming up with a workable, reusable
contract initially would be a giant cost, it isn't.
Any time you contract with a single company that writes the
compiler, you're contracting with "a conglomerate of
individuals." The advantage of not incorporating them all under
a single company instead is the initial cost of organizing such a
company, plus the fact that it's not really necessary these days.
Allowing devs more independence to work on what they want,
rather than what the managers direct, has a lot of potential
benefits for productivity and innovation.
Is this commonly done today? No, even highly decentralized OSS
projects like MySQL had many of their devs working for a single
company to produce the commercial version. But I believe it's
where the market is inevitably heading.
It doesn't matter that a lot of users test FOSS, if nobody is
willing to pay devs to fix the bugs they may find. D has tens of
thousands of users, yet only a handful of OSS devs fixing bugs,
and many bugs that go unfixed for long periods of time.
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.
Nobody has suggested that they build their own tool. You
expressed above a fear that proprietary compiler vendors would
hold their control of the compiler over the buyer's head and
force them to "upgrade" at high prices.
Well, if your contract with the compiler vendor provides that all
patches must be released after a funding/time limit and 70-90% of
the source for the compiler is always available, as I've detailed
with the hybrid model in this thread, then your switching costs
are greatly reduced. You can always fund other compiler vendors
who fork that OSS core and clone the proprietary features you
want. I suggest you read the Phoronix article I linked in my
original post.
Who are you customers? Define scenarios that are concrete.
Without concrete scenarios all you are left with is hand-waving.
I gave a concrete reply to which of your three categories of
customers above would use D and pay for this model, then you went
off on an unrelated tangent about other customized models and
public pricing. If you don't tell me in what way you'd like me
to be more concrete, I can't satisfy your request.
I can only offer concrete scenarios in response to specific
questions or concepts you'd like me to explain. Hand-waving
about how I'm not being concrete enough, but without giving a
specific reason or concept you'd like me to be concrete about is
just that, hand-waving.
