An idea for commercial support for D

[uri via Digitalmars-d]

On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote:

> Before you make such claims, you should probably think about 
> them a little bit first.  Please tell me one company that does 
> not buy outside commercial software which they then use to 
> build their own products.  Some companies will want to cherry 
> pick features, others will just buy an accumulated patchset 
> against the point release from many devs.  The suggestion that 
> all companies will have to spend a great deal of time picking 
> what patches they want is just silly.

To me it doesn't make sense for a company to cherry pick compiler 
patches. The model you propose may work for applications where 
there is a clean distinction between user needs and wants but in 
a compiler you generally need all the features to work 
effectively and produce reasonable code. The optimizer may be a 
different story so perhaps that aspect of compilation could be 
split.

Besides splitting the compiler will result in a maintenance 
headache. Missing features in the compiler will not result in 
subset-D and complete-D but half-baked-nearly-working-D and 
working-D, if you're lucky.

>
> This means A and B can't make any money off their patches, so 
> they have to get some other job. That means they only have time 
> to work on M and X on the occasional weekend and each of those 
> patches takes six months to finish.  You are obviously okay 
> with that glacial pace as long as you get their work for free, 
> but others are willing to pay to get the pace of D development 
> sped up.

This is only true if all patches are equally priced. Otherwise it 
breaks down and has been proven mathematically.


> Glad you brought this up, there are several possibilities.  
> Many users would probably just buy all the closed patches 
> against a point release, so there is no question of splitting 
> features.  But a handful of paying customers may be more 
> adventurous, or cheap, ;) and choose to only buy a custom build 
> with their needed features X,Y,Z.  This probably wouldn't 
> happen right away, as it will take more time to setup a build 
> process to support it, but supporting custom builds like that 
> is definitely worthwhile.

OK, but the D devs still need to split the release between paid 
patches and non-paid patches. This is non-trivial in a compiler 
and adds additional work for the volunteers. Companies won't pay 
for the split because it isn't value adding for them so it will 
fall on the volunteers.

> To begin with, D is not a GPL project, so why would they 
> release them under the GPL?

So we wait some time period for the patch to be released.

> As stated earlier, the patches would need to be funded up to 
> some monetary and time limits before they would be released 
> back to the OSS project.  So party A might contract with their 
> paying customers that they'll release patches X,Y,Z once they 
> accumulate $5k in payments from all the customers who buy those 
> patches, plus a six month delay after that.  If they don't make 
> $5k for a long time, the patches won't be released for a long 
> time.

Then I think most OSS users would move on to another language. 
There is no point working with a compiler that is half-baked 
unless you pay for it. This is an issue because it's the OSS 
community that provides ongoing maintenance to the paid for 
patches. If OSS isn't there anymore then Digital Mars needs to 
start charging maintenance costs to upkeep the codebase. I don't 
think that will work, but it's only my opinion.

> Why does anyone pay for software now?  It doesn't much matter 
> to a paying customer that the feature will probably be free in 
> a year or two if they need to use it to make money _now_.

But that's assuming an entity needs D to make money now. They 
don't because we have C++, Java, C# already. Why not just use one 
of those more mature languages?

>
> As for people leaving because somebody else has developed a 
> proprietary feature for D and not given it to them for free, 
> companies like Sociomantic have already developed such features 
> and they haven't been integrated upstream, why haven't "most" 
> left already?

The features from Sociomantic features are all D1 and also there 
are devs from Sociomantic are trying to get features released 
upstream. Sociomantic isn't the blocker it's integrating the 
features into D2.


> The dmd backend is not under an OSS license, why haven't they 
> left?  I suspect there are not very many of the type of people 
> you're talking about in the D community.

It's possible that you're right but I don't see it happening. The 
backend doesn't provide any benefit to GDC and LDC and Walter has 
a very good reason for closing the backend sources which is 
understood by all.

> Maybe a handful of FOSS zealots would leave, but the resulting 
> commercially supported D would be so much better, they'd be 
> swamped by the new people coming on board. :)

We'll see :)

Cheers,
uri