An idea for commercial support for D

[Joakim via Digitalmars-d]

On Sunday, 4 January 2015 at 17:18:22 UTC, Iain Buclaw via 
Digitalmars-d wrote:
> On 4 January 2015 at 14:50, Joakim via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
> 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?)

I'd be interested in reading that, you should write it up 
somewhere.

>> 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'd say three are hybrids to varying degrees and iOS/OSX is 
largely cathedral nowadays, despite its bazaar BSD antecedents.

> 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 is no reason for the open source project to defer a PR 
because of closed patches that aren't available yet.  Once the 
closed patches are opened, the two implementations can be merged 
for their best aspects.

This is what happened with the AArch64 backend for llvm recently: 
devs were working on an OSS backend and Apple developed their own 
closed one quicker and shipped it for the recent port of iOS to 
64-bit.  Later, Apple opened up their closed backend, and the two 
were merged.  I believe they ended up going with the closed one 
and merging back pieces of the existing OSS one that they wanted.

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

I doubt either would preclude doing it now, as the closed patches 
would be continually rebased on the OSS frontend.

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

Your point seems to be that D moving from a one-man, closed 
project by Walter to an OSS project with several contributors 
greatly sped up its development.  Nobody is disputing that.

The question is how to attain the next level of growth, speeding 
it up a lot more, and I think this hybrid approach will do that.

On Sunday, 4 January 2015 at 16:54:17 UTC, Martin Nowak wrote:
> On 01/04/2015 09:31 AM, Joakim wrote:
> I don't think anyone has an interest of closed patches.
> Building a point release with the bug fixed might be of more 
> interest.

That's merely a matter of packaging, there are several ways it 
can be done with the closed patches.  Of course, initially only 
providing closed patches against the stable OSS point releases 
would be an easy way to start.