DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

Joakim joakim at airpost.net
Wed Jun 26 12:58:52 PDT 2013


On Wednesday, 26 June 2013 at 19:26:37 UTC, Iain Buclaw wrote:
> From a licensing perspective, the only part of the source that 
> can be "closed off" is the DMD backend.  Any optimisation fixes 
> in the DMD backend does not affect GDC/LDC.
This is flat wrong. I suggest you read the Artistic license, it 
was chosen for a reason, ie it allows closing of source as long 
as you provide the original, unmodified binaries with any 
modified binaries.  I suspect optimization fixes will be in both 
the frontend and backend.

> You should try reading The Cathedral and the Bazaar if you 
> don't understand why an open approach to development has caused 
> the D programming language to grow by ten fold over the last 
> year or so.
>
> If you still don't understand, read it again ad infinitum.
Never read it but I have corresponded with the author, and I 
found him to be as religious about pure open source as Stallman 
is about the GPL.  I suggest you try examining why D is still 
such a niche language even with "ten fold" growth.  If you're not 
sure why, I suggest you look at the examples and reasons I've 
given, as to why closed source and hybrid models do much better.

> Think I might just point out that GDC had SIMD support before 
> DMD. And that Remedy used GDC to get their D development off 
> the ground.  It was features such as UDAs, along with many 
> language bug fixes that were only available in DMD development 
> that caused them to switch over.
>
> In other words, they needed a faster turnaround for bugs at the 
> time they were adopting D, however the D front-end in GDC stays 
> pretty much stable on the current release.
Not sure what point you are trying to make, as both gdc and dmd 
are open source.  I'm suggesting closing such patches, for a 
limited time.

>> I see no reason why another "upcoming" project like D couldn't 
>> do the same. :)
>
> You seem to be confusing D for an Operating System, Smartphone, 
> or any general consumer product.
You seem to be confusing the dmd compiler to not be a piece of 
software, just like the rest, or the many proprietary C++ 
compilers out there.

> Having used closed source languages in the past, I strongly 
> believe that closed languages do not stimulate growth or 
> adoption at all.  And where adoption does occur, knowledge is 
> kept within specialised groups.
Perhaps there is some truth to that.  But nobody is suggesting a 
purely closed-source language either.

>> I don't think a "purely community-run project" is a worthwhile 
>> goal, particularly if you are aiming for a million users and 
>> professionalism.  I think there is always opportunity for 
>> mixing of commercial implementations and community 
>> involvement, as very successful hybrid projects like Android 
>> or Chrome have shown.
>
> Your argument seems lost on me as you seem to be taking a very 
> strange angle of association with the D language and/or 
> compiler, and you don't seem to understand how the development 
> process of D works either.
I am associating D, an open source project, with Android and 
Chrome, two of the most successful open source projects at the 
moment, which both benefit from hybrid models.  I find it strange 
that you cannot follow.  If I don't understand how the 
development process of D works, you could point out an example, 
instead of making basic mistakes in not knowing what licenses it 
uses and what they allow. :)

> - The language implementation is open source. This allows 
> anyone to take the current front-end code - or even write their 
> own clean-room implementation from ground-up - and integrate it 
> to their own backend X.
Sort of.  The dmd frontend is open source, but the backend is not 
under an open source license.  Someone can swap out the backend 
and go completely closed, for example, using ldc (ldc used to 
have one or two GPL files, those would obviously have to be 
removed).

> - The compiler itself is not associated with the development of 
> the language, so those who are owners of the copyright are free 
> to do what they want with their binary releases.
>
> - The development model of D on github has adopted a "pull, 
> review and merge" system, where any changes to the language or 
> compiler do not go in unless it goes through proper coding 
> review and testing (thank's to the wonderful auto-tester).  So 
> your suggestion of an "open core" model has a slight fallacy 
> here in that any changes to the closed off compiler would have 
> to go through the same process to be accepted into the open one 
> - and it might even be rejected.
I'm not sure why you think "open core" patches that are opened 
after a time limit would be any more likely to be rejected from 
that review process.  The only fallacy I see here is yours.

> - Likewise, because of licensing and copyright assignments in 
> place on the D front-end implementation.  Any closed D compiler 
> using it would have to make its sources of the front-end, with 
> local modifications, available upon request.  So it makes no 
> sense whatsoever to make language features - such as SIMD - 
> closed off.
I suggest you read the Artistic license.  You have no idea what 
you are talking about.

> DMD - as in refering to the binary releases - can be closed / 
> paid / whatever it likes.
>
> The D Programming Language - as in the D front-end 
> implementation - is under a dual GPL/Artistic license and 
> cannot be used by any closed source product without said 
> product releasing their copy of the front-end sources also.  
> This means that your "hybrid" proposal only works for code that 
> is not under this license - eg: the DMD backend - which is not 
> what the vast majority of contributors actually submit patches 
> for.
Wrong, you have clearly not read the Artistic license.

> If you strongly believe that a programming language can't be 
> big (as in 1M users) without being partly closed source, I 
> suggest you do your research better.
I have done my research and provided examples: you provide none.  
I suggest it is you who needs to research this topic.  Start with 
reading the Artistic license. :)

> </ End argument on feasibility of a hybrid development model >
</ End my demolition of your ignorant arguments >


More information about the Digitalmars-d-announce mailing list