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@puremagic.com>

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.


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.

Reply via email to