An idea for commercial support for D

Sun Jan 4 09:18:09 PST 2015

On 4 January 2015 at 14:50, Joakim via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.
>

Right - though I may just point out that the differences between ldc,
gdc, dmd are more from a low-level perspective.  Want access to simd
intrinsics?  Sure different compilers expose different intrinsics, but
at least you can distinguish between who implemented what -
version(D_SIMD)? This compiler implements __simd; version(GNU)? This
compiler has a gcc.builtins module, etc.

The exact same is with any other bare-metal features.  Inline ASM?
There's version(D_InlineAsm) and _x86 and _x86_64 variants for being
able to test whether or not this compiler supports that.  Whereas
version(GNU_InlineAsm) means that we are using a compiler that
implements GCC extended assembler.

Is this annoying?  For a user writing a library, I would say Yes, but
only if your work requires stepping outside the language norms.
Annoyance also extends out to maintainers too (I could write a book
about Where DMD went wrong? Some more of DMD's greatest mistakes, and
Just who is this DMD compiler anyway?)

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

At least three of those projects I would see as anything but bazaar.  :)

I can see this turning into a moral argument - one that will neither
be the first nor last, so I'll end with accepting my view is not
yours.

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

I was referring to patches from closed merging upstream.

One example would be, oh, DIP-25 being implemented in the closed
frontend - let's say Walter implemented it, then someone from the
community implements DIP-25 in a differing way and raises a PR a
couple months later.  Should the PR be accepted?  If it is should the
closed implementation be dropped?  Because of the closed nature
there's no way to compare which one is more technically sound than the
other.

There's also a question of timing too.  Obviously such an undertaking
shouldn't happen until the frontend switches to D, nor when there are
still plenty of visitor re-writes being done in the frontend.

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

For me, the comparison is between these key timelines:

- No source code
- D1 Frontend released as Artistic/GPL
- Backend released under restricted license
- Moving to Github
- Creating a 'core' team
- Everyone (even Walter!) switching over to the PR patch
submission/review system
- Re-license Frontend as Boost

Each point over a 14 year history has been a step in the direction of
being 'open' and each brought a boost in development.  The number of
changes between each release compared to back in 2.020 days is a clear
sign of this - as well as the three digit open PRs.

Iain.