DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

[Joakim]

On Wednesday, 26 June 2013 at 17:28:22 UTC, Joseph Rushton 
Wakeling wrote:
> Perhaps you'd like to explain to the maintainers of GDC and LDC 
> why, after all they've done for D, you think it would be 
> acceptable to turn to them and say: "Hey guys, we're going to 
> make improvements and keep them from you for 9 months so we can 
> make money" ... ?
Why are they guaranteed such patches?  They have advantages 
because they use different compiler backends.  If they think 
their backends are so great, let them implement their own 
optimizations and compete.

> Or doesn't the cooperative relationship between the 3 main D 
> compilers mean much to you?
As I've noted in an earlier response, LDC could also provide a 
closed version and license those patches.

> Leaving aside the moral issues, you might consider that any 
> work paid for by revenues would be offset by a drop in 
> voluntary contributions, including corporate contributors.  And 
> sensible companies will avoid "open core" solutions.
Or maybe the work paid by revenues would be far more and even 
more people would volunteer, when D becomes a more successful 
project through funding from the paid compiler.  Considering how 
dominant "open core" and other hybrid models are these days, it 
is laughable that you suggest that anyone is avoiding it. :)

> A few articles worth reading on these factors:
> http://webmink.com/essays/monetisation/
> http://webmink.com/essays/open-core/
> http://webmink.com/essays/donating-money/
I have corresponded with the author of that blog before.  I found 
him to be a religious zealot who recounted the four freedoms of 
GNU to me like a mantra.  Perhaps that's why Sun was run into the 
ground when they followed his ideas about open sourcing most 
everything.  I don't look to him for worthwhile reading on these 
issues.

>> I think this ignores the decades-long history we have with 
>> open source software by now.  It is not merely "wanting to 
>> make the jump," most volunteers simply do not want to do 
>> painful tasks like writing documentation or cannot put as much 
>> time into development when no money is coming in.  Simply 
>> saying "We have to try harder to be professional" seems naive 
>> to me.
>
> Odd that you talk about ignoring things, because the general 
> trend we've seen in the decades-long history of free software 
> is that the software business seems to getting more and more 
> open with every year.  These days there's a strong expectation 
> of free licensing.
Yes, it is getting "more and more open," because hybrid models 
are being used more. :) Pure open source software, with no binary 
blobs, has almost no adoption, so it isn't your preferred purist 
approach that is doing well.  And the reasons are the ones I 
gave, volunteers can do a lot of things, but there are a lot of 
things they won't do.

> It's hardly fair to compare languages without also taking into 
> account their relative age.  C++ has its large market share 
> substantially due to historical factors -- it was a major 
> "first mover", and until the advent of D, it was arguably the 
> _only_ language that had that combination of power/flexibility 
> and performance.
Yes, C++ has been greatly helped by its age.

> So far as compiler implementations are concerned, I'd say that 
> it was the fact that there were many different implementations 
> that helped C++.  On the other hand, proprietary 
> implementations may in some ways have damaged adoption, as 
> before standardization you'd have competing, incompatible 
> proprietary versions which limited the portability of code.
But you neglect to mention that most of those "many different 
implementations" were closed.  I agree that completely closed 
implementations can also cause incompatibilities, which is why I 
have suggested a hybrid model with limited closed-source patches.

> The binary blobs are nevertheless part of the vanilla kernel, 
> not something "value added" that gets charged for.  They're 
> irrelevant to the development model of the kernel -- they are 
> an irritation that's tolerated for practical reasons, rather 
> than a design feature.
They are not always charged for, but they put the lie to the 
claims that linux uses a pure open source model.  Rather, it is 
usually a different kind of hybrid model.  If it were so pure, 
there would be no blobs at all.  The blobs are certainly not 
irrelevant, as linux wouldn't run on all the hardware that needs 
those binary blobs, if they weren't included.  Not sure what to 
make of your non sequitur of binary blobs not being a "design 
feature."

As for paying for blobs, I'll note that the vast majority of 
linux kernels installed are in Android devices, where one pays 
for the hardware _and_ the development effort to develop the 
blobs that run the hardware.  So paying for the "value added" 
from blobs seems to be a very successful model. :)

>> So if one looks at linux in any detail, hybrid models are more 
>> the norm than the exception, even with the GPL. :)
>
> But no one is selling proprietary extensions to the kernel (not 
> that they could anyway, but ...).  They're building services 
> that _use_ the kernel, and in building those services they 
> sometimes write patches to serve particular needs.
Nobody said they were writing "proprietary extensions to the 
kernel."  The point is that almost all linux kernels in use are 
used with binary blobs or a proprietary-patched Android stack on 
top.  Therefore, linux implementations benefit from a different 
kind of hybrid model, but linux certainly isn't purely open 
source most of the time.

> In a similar way, other companies are building services using D 
> and sometimes they write replacements for existing D 
> functionality that better serve their needs (e.g. Leandro's GC 
> work).
And I'm similarly proposing that there be a D compiler that has 
better, closed-source optimizations but is paid, with the 
optimizations guaranteed to be open sourced after some time.  I'm 
not sure why you draw the line there.

> C++'s popularity is most likely largely down to historical 
> contingency.  It was a first-mover in its particular design, 
> and use begets use.
You keep trying to pin C++'s age as the only reason why it is 
popular, and while I don't deny that its early entry helped, I 
don't think it is quite as determinative as you do.

> What you should rather be thinking of is: can you think of 
> _any_ major new programming language (as in, rising to 
> prominence in the last 10 years and enjoying significant 
> cross-platform success) that wasn't open source?
Java wasn't open source initially, but it was open sourced after 
its success.  Objective-C has become very popular recently with 
the rise of iOS.  I read that Apple open-sourced their patches to 
gcc, because of the GPL, but kept their Obj-C runtime libraries 
closed.  More recently, they have switched to the BSD-licensed 
LLVM/clang and they may be using a hybrid model there, tough to 
tell.  I cannot think of any other language that is in the same 
stratosphere as C and C++:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

> The only one I can think of is C#, which was able to succeed 
> simply because if Microsoft makes a particular language a key 
> tool for Windows development, that language will get used.
>
> But the others?  The reference versions are all open.
Nobody has suggested otherwise for D.  I've suggested an open 
reference version and a faster, paid version with some 
closed-source patches.  This sort of mix of commercial and OSS 
implementations appears to be the dominant model, for a language 
with any adoption.

> No one is scared of the idea of a slightly or even wholly 
> closed, paid compiler -- anyone is free to implement one and 
> try to sell it.
Of course.  You could even take ldc and do it, as the license 
allows it.

> People are objecting to the idea of the reference 
> implementation of the D language being distributed in a 
> two-tier version with advanced features only available to 
> paying customers.
>
> You need to understand the difference between proprietary 
> implementations of a language existing, versus the mainstream 
> development work on the language following any kind of 
> proprietary model.
Nobody is unaware of the difference; I have always said that 
Walter would put out an open reference version alongside a 
slightly-closed paid version.  Why do you object to that?

> Microsoft is a virtual monopolist in at least two areas of 
> commercial software -- desktop OS and office document suites.  
> The business models that work for them are not necessarily 
> going to bring success for other organizations.  A large part 
> of Red Hat's success comes from the fact that it offers 
> customers a different deal from Microsoft.
I can list dozens of other product companies that make orders of 
magnitude more revenue than the consulting/support companies, OSS 
or not, that you prefer: Oracle, SAP, Apple, on and on, not to 
mention all the hybrid models I've already listed.  I simply 
mentioned Microsoft because they sell the most compilers, but if 
you want to compare all such product companies, it's a rout. :)

> I suggest that you have not thought through the variety of 
> different business options available.  It is a shame that your 
> first thought for commercialization of D was "Let's close bits 
> of it up!" instead of, "How can I make a successful commercial 
> model of D that works _with_ its wonderful open community?"
On the contrary, I have examined many of these business options 
over the years.  I _was_ answering the latter need, I just think 
the former is the best way to do it, as long as you open source 
the closed patches after a guaranteed time limit.  I suggest 
instead that it is you who has not thought through or examined 
the evidence that your preferred pure-OSS models don't work as 
well.

>> First off, they both have commercial implementations.  Second, 
>> they still only have a small fraction of the share as C++: 
>> part of this is probably because they don't have as many 
>> closed, performant implementations as C++ does.
>
> The reference implementations are free software, and if they 
> weren't, they'd never have got any decent traction.
I believe C++ was originally licensed by AT&T, so it wasn't free 
software when it got popular.  The others you may have in mind 
are nowhere near as popular.

>> I realize this is a religious issue for some people and they 
>> cannot be convinced.  In a complex, emerging field like this, 
>> it is easy to claim that if OSS projects just try harder, they 
>> can succeed.  But after two decades, it has never happened, 
>> without stepping back and employing a hybrid model.
>
> I think your understanding of free software history is somewhat 
> flawed, and that you conflate rather too many quite different 
> business models under the single title of "hybrid".  (To take 
> just one of your examples, Red Hat's consulting/support model 
> is not the same as paying for closed additions to the software.
>  The _software_ of Red Hat Enterprise Linux is still free!)
If my history is flawed, you could provide an example. :) I 
believe Red Hat uses the same binary blobs that the linux kernel 
provides, so it is not pure open source and can be classified as 
hybrid.  I think they also bundle in their own closed-source 
software on top, though I've never paid them.

> You also don't seem to readily appreciate the differences 
> between what works for software services, versus what works for 
> programming languages -- or the impact that free vs. non-free 
> can have on adoption rates.  (D might have gained more traction 
> much earlier, if not for fears around the DMD backend.)
I suggest that this assertion is best leveled at you. :) I think 
D would gain much more traction now, if it were making money from 
a paid version.

>> I have examined the evidence and presented arguments for those 
>> who are willing to listen, as I'm just about pragmatically 
>> using whatever model works best.  I think recent history has 
>> shown that hybrid models work very well, possibly the best. :)
>
> Please name a recent successful programming language (other 
> than those effectively imposed by diktat by big players like 
> Microsoft or Apple) that did not build its success around a 
> reference implementation that is free software.  Then we'll 
> talk. :-)
I am not going to attack your strawman, as I have not suggested 
that there shouldn't be a reference implementation for D that is 
open source.  I have simply suggested an additional paid version 
that funds development for both versions.

Let me throw your request back at you, with the _appropriate_ 
details: please name a recent successful programming language 
that achieved any kind of success and _didn't_ have commercial 
support or implementations.  Alternately, name one that came 
anywhere close to the massive popularity of C++ with only a 
consulting/support model.

The evidence is not on your side. :)