An idea for commercial support for D

[Joakim via Digitalmars-d]

On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via 
Digitalmars-d wrote:
> On 4 Jan 2015 08:35, "Joakim via Digitalmars-d" 
> <digitalmars-d at puremagic.com>
> wrote:
>>
>> This is an idea I've been kicking around for a while, and 
>> given the need
> for commercial support for D, would perhaps work well here.
>>
>> The notion is that individual developers could work on patches 
>> to fix
> bugs or add features to ldc/druntime/phobos then sell those 
> closed patches
> to paying customers.  After enough time has passed, so that 
> sufficient
> customers have adequately paid for the work or after a set time 
> limit
> beyond that, the patch is open sourced and merged back 
> upstream.  It would
> have to be ldc and not dmd, as the dmd backend is not open 
> source and the
> gdc backend license doesn't allow such closed patches.
>>
>
> Do what you want, but I don't think you could or should call it 
> D from the
> moment you deviate.

I'm not doing anything, I'm putting an idea out here for 
consideration.  I'm uninterested in doing this on my own and 
seeding such paid patches entirely by myself, so if there aren't 
enough people interested in both paid development and paying for 
patches, it won't get done.

As for what to call it, ldc and gdc both differ from dmd in 
non-trivial ways and still call themselves D compilers.  I don't 
think the name really matters, but for what it's worth, I agree 
with you that if such a commercial model goes in a completely 
different direction with the language, a name change is probably 
best.

>> http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing
>
> There's no such thing as a hybrid.  You're either a cathedral 
> or a bazaar,
> and a hybrid approach is looking pretty cathedral to me.

Tell that to the most widely used open-source projects these 
days, ie hybrid projects like Android, iOS/OS X, llvm/clang, 
Chrome, etc.  There are advantages to both the cathedral and the 
bazaar model, which is why it's best to mate the two, as has been 
done by the listed highly successful software.

>>From a technical standpoint, how do you propose to deal with 
>>splitbrain
> situations?  If your proposed closed solution is 
> source-incompatible with
> the open then you have failed as a model.

Not sure if you're referring to users' D source that can't be 
compiled by both compilers or patches from the closed D frontend 
that might be difficult to merge back upstream into the dmd 
frontend.  Obviously both can be handled with some effort.  Since 
the idea is not to completely fork the frontend but to provide 
patches on it that are eventually upstreamed, I doubt either will 
be a problem.

>>From a pragmatic (though maybe philosophical) standpoint, 
>>having been in
> active development in or around the core for 4 years, my 
> observation (which
> I believe Walter shared as well) is that back when DMD was 
> partially
> closed, there just wasn't much traction in development or 
> adoption.  Right
> now things are moving pretty fast, and I don't think DMD *can* 
> get any more
> open than what it already is.  Given the compelling correlation 
> between
> both popularity and contribution with the openness of 
> development at the
> core (ie: moving to github), history tells us that closing will 
> only serve
> to stifle and stop.

Was Walter selling a paid compiler with the then-closed dmd 
backend?  If not, the comparison is not valid.  The idea here is 
for paying customers to fund closed patches for a limited time, 
and speed up D bug-fixing and development much more.  If Walter 
was not getting paid for his closed backend but only keeping it 
closed because of licensing issues, the situations are completely 
different.

Also, this is a _hybrid_ approach, not a closed one.  There will 
always be an OSS core that potential devs can look at.  They just 
may not have access to all the closed-source patches that others 
are selling.

Recent history of the explosively successful hybrid projects I 
listed suggests that a hybrid approach is the most scalable one.