An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 22:32:22 UTC, uri wrote:
> 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.

It really doesn't matter what makes sense to you: a few companies 
will prefer the lower cost of a custom build and go that route.  
The compiler is already missing features, shared still has not 
been implemented to Andrei's spec in his book five years ago and 
all the bugs mean several features do not work as intended.  D is 
already half-baked: you always have to pick and choose what 
features you use with a new tech like this, whether employing the 
current OSS project or with paid patches.

>> 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.

You are referencing my paragraph detailing the current OSS route 
that _you_ preferred, where there are _no_ prices.  If you're 
referring to the last sentence about paying for D development, I 
have no idea why you think all patches should be equally priced.  
If you think anything about business "has been proven 
mathematically," I can only laugh. :)

>> 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.

The OSS project and its devs would not have access to the paid 
patches, as they are _closed-source_, so the only ones doing such 
maintenance would be the paid devs who wrote them.  Once the 
patches are open-sourced and submitted back upstream, they would 
need to be maintained by the OSS project, but that is no 
different from any other OSS patches.

>> 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.

It's _already_ half-baked unless you pay for it, :) ie current 
companies employing D, like Sociomantic, employ in-house devs to 
add proprietary features that they pay their employees to 
develop.  Providing paid patches from independent external devs 
changes nothing in that regard.  I have no idea how you think an 
OSS community would provide maintenance for closed-source 
patches: that would not happen, as they wouldn't have access to 
them.  Why would Digital Mars pay for anything?  AFAIK, it's just 
one guy who makes almost no money off it.

Perhaps paid patches from independent devs won't work, but you 
haven't been able to articulate a single reason why it won't.

>> 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?

Because D provides features and benefits those languages don't 
provide?  Don from Sociomantic, a company built on D1, has said, 
"Our infrastructure costs are 4X lower than the rest of our 
industry."  Now imagine how much better it'd be if a D compiler 
had the same commercial polish and quality of implementation as 
the best paid C++ compilers.

>> 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.

I doubt that Sociomantic has released all their proprietary 
additions to D1.  But the key question is related to this: the 
objection to paid patches seems to be that someone somewhere is 
keeping a proprietary feature to themselves.

If so, then what about any person or company that is currently 
adding and using proprietary features with their D compiler?  Why 
isn't that already a deal-breaker for those FOSS purists you're 
talking about and why haven't they left?  Is there something 
magical about when a paid dev sells a bugfix patch to a company, 
but not when the company employs an in-house paid dev to write 
that bugfix patch for them?

The disconnect I see with your stated viewpoint is that there are 
already people using D and adding proprietary additions to it 
themselves.  All I'm proposing is a marketplace in such 
proprietary additions, so they can buy them from outside.  If you 
believe proprietary additions are so bad that "most" would leave, 
even when always given when a core OSS option for free, why 
haven't they left already?