DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

[Iain Buclaw]

I can't be bothered to read all points the both of you have 
mentioned thus far, but I do hope to add a voice of reason to 
calm you down. ;)



On Wednesday, 26 June 2013 at 17:42:23 UTC, Joakim wrote:
> On Wednesday, 26 June 2013 at 12:02:38 UTC, Joseph Rushton 
> Wakeling wrote:
>> Now, in trying to drive more funding and professional effort 
>> towards D development, do you _really_ think that the right 
>> thing to do is to turn around to all those people and say: 
>> "Hey guys, after all the work you put in to make D so great, 
>> now we're going to build on that, but you'll have to wait 6 
>> months for the extra goodies unless you pay"?
> Yes, I think it is the right thing to do.  I am only talking 
> about closing off the optimization patches, all bugfixes and 
> feature patches would likely be applied to both the free and 
> paid compilers, certainly bugfixes.  So not _all_ the "extra 
> goodies" have to be paid for, and even the optimization patches 
> are eventually open-sourced.
>

 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.


>> How do you think that will affect the motivation of all those 
>> volunteers -- the code contributors, the bug reporters, the 
>> forum participants?  What could you say to the maintainers of 
>> GDC or LDC, after all they've done to enable people to use the 
>> language, that could justify denying their compilers 
>> up-to-date access to the latest features?  How would it affect 
>> the atmosphere of discussion about language development -- 
>> compared to the current friendly, collegial approach?
> I don't know how it will affect their motivation, as they 
> probably differ in the reasons they contribute.
>
> If D becomes much more popular because the quality of 
> implementation goes up and their D skills and contributions 
> become much more prized, I suspect they will be very happy. :) 
> If they are religious zealots about having only a single, 
> completely open-source implementation- damn the superior 
> results from hybrid models- perhaps they will be unhappy.  I 
> suspect the former far outnumber the latter, since D doesn't 
> employ the purely-GPL approach the zealots usually insist on.
>

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.



>> ... and -- how do you think it would affect uptake, if it was 
>> announced that access to the best features would come at a 
>> price?
> Please stop distorting my argument.  There are many different 
> types of patches added to the dmd frontend every day: bugfixes, 
> features, optimizations, etc.  I have only proposed closing the 
> optimization patches.
>
> However, I do think some features can also be closed this way.  
> For example, Walter has added features like SIMD modifications 
> only for Remedy.  He could make this type of feature closed 
> initially, available only in the paid compiler.  As the feature 
> matures and is paid for, it would eventually be merged into the 
> free compiler.  This is usually not a problem as those who want 
> that kind of performance usually make a lot of money off of it 
> and are happy to pay for that performance: that is all I'm 
> proposing with my optimization patches idea also.
>

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.


>> In another email you mentioned Microsoft's revenues from 
>> Visual Studio but -- leaving aside for a moment all the moral 
>> and strategic concerns of closing things up -- Visual Studio 
>> enjoys that success because it's a virtually essential tool 
>> for professional development on Microsoft Windows, which still 
>> has an effective monopoly on modern desktop computing.  
>> Microsoft has the market presence to be able to dictate terms 
>> like that -- no one else does.  Certainly no upcoming 
>> programming language could operate like that!
> Yes, Microsoft has unusual leverage.  But Visual Studio's 
> compiler is not the only paid C++ compiler in the market, hell, 
> Walter still sells C and C++ compilers.
>
> I'm not proposing D operate just like Microsoft.  I'm 
> suggesting a subtle compromise, a mix of that familiar closed 
> model and the open source model you prefer, a hybrid model that 
> you are no doubt familiar with, since you correctly pegged the 
> licensing lingo earlier, when you mentioned "open core."
>
> These hybrid models are immensely popular these days: the two 
> most popular software projects of the last decade, iOS and 
> Android, are hybrid models.  Of course, that is partly because 
> mobile is such a hot field, but the explosion of mobile 
> software didn't mean success for the closed models of RIM, 
> Nokia, or Microsoft.  Android's hybrid model is a big reason 
> why it succeeded.
>
> 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.

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.


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


My thoughts in summary:

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

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

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


tl/dr;

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.

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.


</ End argument on feasibility of a hybrid development model >


Regards
Iain "That GDC Developer" Bucław