An idea for commercial support for D

[Joakim via Digitalmars-d]

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.