On 26 June 2013 15:04, eles <eles@eles.com> wrote:
> On Tuesday, 25 June 2013 at 08:21:38 UTC, Mike Parker wrote:
>>
>> On Tuesday, 25 June 2013 at 05:57:30 UTC, Peter Williams wrote:
>> D Season of Code! Then we don't have to restrict ourselves to one time of
>> the year.
>
>
> D Seasons of Code! Why to restrict to a single season? Let's code all the year long! :)

Programmers need to hibernate too, you know. ;)

--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wednesday, 26 June 2013 at 11:08:17 UTC, Leandro Lucarella wrote:
> Joakim, el 25 de June a las 23:37 me escribiste:
>> I don't know the views of the key contributors, but I wonder if they
>> would have such a knee-jerk reaction against any paid/closed work.
>
> Against being paid no, against being closed YES. Please don't even think
> about it. It was a hell of a ride trying to make D more open to step back now.
I suggest you read my original post more carefully.  I have not suggested closing up the entire D toolchain, as you seem to imply.  I have suggested working on optimization patches in a closed-source manner and providing two versions of the D compiler: one that is faster, closed, and paid, with these optimization patches, another that is slower, open, and free, without the optimization patches.

Over time, the optimization patches are merged back to the free branch, so that the funding from the closed compiler makes even the free compiler faster, but only after some delay so that users who value performance will actually pay for the closed compiler.  There can be a hard time limit, say nine months, so that you know any closed patches from nine months back will be opened and applied to the free compiler.  I suspect that the money will be good enough so that any bugfixes or features added by the closed developers will be added to the free compiler right away, with no delay.

> What we need is companies paying to people to improve the
> compiler and toolchain. This is slowly starting to happen, in
> Sociomantic we are already 2 people dedicating some time to improve D as
> part of our job (Don and me).
Thanks for the work that you and Don have done with Sociomantic.  Why do you think more companies don't do this?  My point is that if there were money coming in from a paid compiler, Walter could fund even more such work.

> We need more of this, and to get this, we need companies to start using
> D, and to get this, we need professionalism (I agree 100% with Andrei on
> this one). Is a bootstrap effort, and is not like volunteers need more
> time to be professional, is just that you have to want to make the jump.
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.

> I think is way better to do less stuff but with higher quality, nobody
> is asking people for more time, is just changing the focus a bit, at
> least for some time. Again, this is only bootstrapping, and is always
> hard and painful. We need to make the jump to make companies comfortable
> using D, then things will start rolling by themselves.
If I understand your story right, the volunteers need to put a lot of effort into "bootstrapping" the project to be more professional, companies will see this and jump in, then they fund development from then on out?  It's possible, but is there any example you have in mind?  The languages that go this completely FOSS route tend not to have as much adoption as those with closed implementations, like C++.

> First of all, your examples are completely wrong. The projects you are
> mentioning are 100% free, with no closed components (except for
> components done by third-party).
You are misstating what I said: I said "commercial," not "closed," and gave different examples of commercial models.  But lets look at them.

> Your examples are just reinforcing what
> I say above. Linux is completely GPL, so it's not even only open source.
> Is Free Software, meaning the license if more restrictive than, for
> example, phobos. This means is harder to adopt by companies and you
> can't possibly change it in a closed way if you want to distribute
> a binary.
And yet the linux kernel ships with many binary blobs, almost all the time.  I don't know how they legally do it, considering the GPL, yet it is much more common to run a kernel with binary blobs than a purely FOSS version.  The vast majority of linux installs are due to Android and every single one has significant binary blobs and closed-source modifications to the Android source, which is allowed since most of Android is under the more liberal Apache license, with only the linux kernel under the GPL.

Again, I don't know how they get away with all the binary drivers in the kernel, perhaps that is a grey area with the GPL.  For example, even the most open source Android devices, the Nexus devices sold directly by Google and running stock Android, have many binary blobs:

https://developers.google.com/android/nexus/drivers

Other than Android, linux is really only popular on servers, where you can "change it in a closed way" because you are not "distributing a binary."  Google takes advantage of this to run linux on a million servers powering their search engine, but does not release the proprietary patches for their linux kernel.

So if one looks at linux in any detail, hybrid models are more the norm than the exception, even with the GPL. :)

> Same for C++, which is not a project, is a standards, but the
> most successful and widespread compiler, GCC, not only is free, is the
> battle horse of free software, of the GNU project and created by the
> most extremist free software advocate ever.
D is not just a project but a standard also.  I wouldn't say gcc is the "most successful and widespread compiler," that's probably Microsoft's compiler, since Windows market share is still much more than linux.  But yes, gcc is a very popular open-source implementation: I didn't say there wouldn't be an open-source D compiler also.  But I don't think C++ would be where it is today if only open-source implementations like gcc supported it, which is the case today with D.

> Android might be the only
> valid case (but I'm not really familiar with Android model), but the
> kernel, since is based on Linux, has to have the source code when
> released. Maybe the drivers are closed source.
As I said earlier, most devices' drivers are almost always closed and the non-GPL parts of Android, which are the majority, are usually customized and the source is usually not released, because most of Android is Apache-licensed.  I think this closed option is a key reason for the success of Android.  Hell, the hardware vendors would never have adopted Android if not for this, as Google well knew.

> You are missing more closely related projects, like Python, Haskel,
> Ruby, Perl, and probably 90% of the newish programming languages, which
> are all 100% open source. And very successful I might say. The key is
> always breaking into the corporate ground and make those corporations
> contribute.
I believe all of these projects have commercial implementations, with the possible exception of Haskell.  Still, all of them combined have much less market share than C++, possibly because they use the weaker consulting/support commercial model most of the time.  One of the main reasons C++ is much more popular is that it has very high-performance closed implementations, do you disagree?  I'm suggesting D will need something similar to get as popular.

> There are valid examples of project using hybrid models but they are
> usually software as a service models, not very applicable to
> a compiler/language, like Wordpress, or other web applications. Other
> valid examples are MySQL, or QT I think used an hybrid model at least
> once. Lots of them died and were resurrected as 100% free projects, like
> StarOffice -> OpenOffice -> LibreOffice.
There are all kinds of hybrid models out there, some would work for compilers also.  I think it's instructive that you are listing some of the largest and most successful, mostly-OSS projects in this list. :)

> And finally making the *optimizer* (or some optimizations) closed will
> be hardly a good business, being that there are 2 other backends out
> there that usually kicks DMD backend ass already, so people needing more
> speed will probably just switch to gdc or ldc.
Let me turn this argument around on you: if there is always competition from ldc and gdc, why are you so scared of another option of a slightly-closed, paid compiler?  If it's not "a good business," it will fail and go away.  I think it would be very successful.

> As in breaking into the commercial world? Then agreed. If you imply
> commercial == closing some parts of the source, then I think you are WAY
> OFF.
OK, so it looks like you are fine with commercial models that keep all the source open, but not with those that close _any_ of the source.

The problem is that your favored consulting or support models are much weaker business models than a product model, which is much of the reason why Microsoft still makes almost two orders of magnitude more revenue with their software products than Red Hat makes with their consulting/support model.

I am suggesting a unique hybrid product model because I think it will bring in the most money for the least discomfort.  That ratio is one that D developers often talk about optimizing in technical terms, I'm suggesting the same in business terms. :)

>> It is amazing how far D has gotten with no business model: money
>> certainly isn't everything.  But it is probably impossible to get to
>> a million users or offer professionalism without commercial
>> implementations.
>
> Yeah, right, probably Python and Ruby have only 5k users...
>
> This argument is BS.
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.

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

On 2013-06-26 15:18, Joseph Rushton Wakeling wrote:

> They don't own them, though -- they commit resources to them because the
> language's ongoing development serves their business needs.

Yes, exactly.

-- 
/Jacob Carlborg

On Wednesday, 26 June 2013 at 15:52:33 UTC, Joakim wrote:
> I suggest you read my original post more carefully.  I have not suggested closing up the entire D toolchain, as you seem to imply.  I have suggested working on optimization patches in a closed-source manner and providing two versions of the D compiler: one that is faster, closed, and paid, with these optimization patches, another that is slower, open, and free, without the optimization patches.
>
> Over time, the optimization patches are merged back to the free branch, so that the funding from the closed compiler makes even the free compiler faster, but only after some delay so that users who value performance will actually pay for the closed compiler.  There can be a hard time limit, say nine months, so that you know any closed patches from nine months back will be opened and applied to the free compiler.  I suspect that the money will be good enough so that any bugfixes or features added by the closed developers will be added to the free compiler right away, with no delay.

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

Or doesn't the cooperative relationship between the 3 main D compilers mean much to you?

> Thanks for the work that you and Don have done with Sociomantic.  Why do you think more companies don't do this?  My point is that if there were money coming in from a paid compiler, Walter could fund even more such work.

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.

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

> If I understand your story right, the volunteers need to put a lot of effort into "bootstrapping" the project to be more professional, companies will see this and jump in, then they fund development from then on out?  It's possible, but is there any example you have in mind?  The languages that go this completely FOSS route tend not to have as much adoption as those with closed implementations, like C++.

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.

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.

> And yet the linux kernel ships with many binary blobs, almost all the time.  I don't know how they legally do it, considering the GPL, yet it is much more common to run a kernel with binary blobs than a purely FOSS version.  The vast majority of linux installs are due to Android and every single one has significant binary blobs and closed-source modifications to the Android source, which is allowed since most of Android is under the more liberal Apache license, with only the linux kernel under the GPL.

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.

> Again, I don't know how they get away with all the binary drivers in the kernel, perhaps that is a grey area with the GPL.  For example, even the most open source Android devices, the Nexus devices sold directly by Google and running stock Android, have many binary blobs:
>
> https://developers.google.com/android/nexus/drivers
>
> Other than Android, linux is really only popular on servers, where you can "change it in a closed way" because you are not "distributing a binary."  Google takes advantage of this to run linux on a million servers powering their search engine, but does not release the proprietary patches for their linux kernel.
>
> 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.

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

> I believe all of these projects have commercial implementations, with the possible exception of Haskell.  Still, all of them combined have much less market share than C++, possibly because they use the weaker consulting/support commercial model most of the time.  One of the main reasons C++ is much more popular is that it has very high-performance closed implementations, do you disagree?  I'm suggesting D will need something similar to get as popular.

C++'s popularity is most likely largely down to historical contingency.  It was a first-mover in its particular design, and use begets use.

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?

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.

> Let me turn this argument around on you: if there is always competition from ldc and gdc, why are you so scared of another option of a slightly-closed, paid compiler?  If it's not "a good business," it will fail and go away.  I think it would be very successful.

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.

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.

> OK, so it looks like you are fine with commercial models that keep all the source open, but not with those that close _any_ of the source.

For the reference implementation of the D language?  Absolutely.

> The problem is that your favored consulting or support models are much weaker business models than a product model, which is much of the reason why Microsoft still makes almost two orders of magnitude more revenue with their software products than Red Hat makes with their consulting/support model.

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 am suggesting a unique hybrid product model because I think it will bring in the most money for the least discomfort.  That ratio is one that D developers often talk about optimizing in technical terms, I'm suggesting the same in business terms. :)

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?"

> 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 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!)

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

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.

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

We could poll them and find out.  You keep talking about closed patches as though they can only piss off the volunteers.  But if I'm right and a hybrid model would lead to a lot more funding and adoption of D, their volunteer work places them in an ideal position, where their D skills and contributions are much more valued and they can then probably do paid work in D.  I suspect most will end up happier.

I have not proposed denying GDC and LDC "access to the latest features," only optimization patches.  LDC could do the same as dmd and provide a closed, paid version with the optimization patches, which it could license from dmd.  GDC couldn't do this, of course, but that is the result of their purist GPL-only approach.

Why do you think a hybrid model would materially "affect the atmosphere of discussion about language development?"  Do you believe that the people who work on hybrid projects like Android, probably the most widely-used, majority-OSS project in the world, are not able to collaborate effectively?

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

As for how it would "affect uptake," I think most people know that free products are usually less capable than paid products.  The people who don't need the capability use Visual Studio Express, those who need it pay for the full version of Visual Studio.  There's no reason D couldn't employ a similar segmented model.

>  There are orders of magnitude of difference between uptake of free and non-free services no matter what the domain, and software is one where free (as in freedom and beer) is much more strongly desired than in many other fields.
Yes, you're right, non-free services have orders of magnitude more uptake. :p

I think there are advantages to both closed and open source, which is why hybrid open/closed source models are currently very popular.  Open source allows more collaboration from outside, while closed source allows for _much_ more funding from paying customers.  I see no reason to dogmatically insist that these source models not be mixed.

> There's a big difference between introducing commercial models with a greater degree of paid professional work, and introducing closed components.  Red Hat is a good example of that -- I can get, legally and for free, a fully functional copy of Red Hat Enterprise Linux without paying a penny.  It's just missing the Red Hat name and logos and the support contract.
Yes, it's a consulting or support model.  These don't scale as well as a product model with closed components.  If all closed components are guaranteed to be open sourced after some time limit, as I've suggested above, I see no reason for OSS proponents to protest.

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

> It's more likely that closing off parts of the offering would limit that uptake, for reasons already given.  On the other hand, with more and more organizations coming to use and rely on D, there are plenty of other ways professional development could be brought in.  Just to take one example: companies with a mission-critical interest in D have a corresponding interest in their developers giving time to the language itself.  How many such companies do you think there need to be before D has a stable of skilled professional developers being paid explicitly to maintain and develop the language?
I disagree that having a slightly-closed paid version would limit uptake, I think it would greatly increase it, for the same reasons that closed-source Windows is still on the vast majority of PCs and the hybrid model of Android led it to dominating on mobile devices.

It is possible that your alternative of corporate backers providing paid development for D will materialize, even if solely for their own benefit, though it would benefit the wider community also.  I'm suggesting that the hybrid model I'm proposing will provide such funding much faster and better, for the reasons given.

> Your citation of the Linux kernel is relevant here.  Do you think that Linux would have had all that diverse success if parts of it had been closed up and sold at a premium?  D's status as a purely community-run project is an asset compared to corporate-backed languages, not a liability.
As I noted in my response to Luca, linux has always had binary blobs.  Do I think it would have been as successful if more parts of it had been closed up?  Well, much of it cannot be closed because of the GPL, so it is just not possible in many respects.

But to take a recent example where it is possible, a recent rumor is that Sony is using FreeBSD for the Playstation 4:

http://www.vgleaks.com/some-details-about-playstation-4-os-development/

Even if it isn't used on the final PS4, FreeBSD is known to be used in commercial, closed products like Juniper routers or NetApp file servers.  I don't think this has limited its uptake, if anything, it has helped as they have eventually contributed back towards the project.

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.

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

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

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 >

On Wednesday, 26 June 2013 at 19:26:37 UTC, Iain Buclaw wrote:
> 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. ;)

Quick, nurse, the screens!

... or perhaps, "Someone throw a bucket of water over them"? :-P

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

To be honest, I can't see the "sales value" of optimization fixes in the DMD backend given that GDC and LDC already have such strong performance.  The one strong motivation to use DMD over the other two compilers is (as you describe) access to the bleeding edge of features, but I'd have thought this will stop being an advantage in time as/when the frontend becomes a genuinely "plug-and-play" component.

By the way, I hope you didn't feel I was trying to speak on behalf of GDC -- wasn't my intention. :-)

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

Last year I had the dubious privilege of having to work with MS Visual Basic for a temporary job.  What was strikingly different from the various open source languages was that although there was an extensive quantity of documentation available from Microsoft, it was incredibly badly organized, much of it was out of date, and there was no meaningful community support that I could find.

I got the job done, but I would surely have had a much easier experience with any of the open source languages out there.  Suffice to say that the only reason I used VB in this case was because it was an obligatory part of the work -- I'd never use it by choice.

> - 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 had a similar thought but from a slightly different angle -- that allowing "open core" in the frontend would damage the effectiveness of the review process.  How can you restrict certain features to proprietary versions without having also a two-tier hierarchy of reviewers?  And would you be able to maintain the broader range of community review if some select, paid few had privileged review access?

On Jun 26, 2013 9:00 PM, "Joakim" <joakim@airpost.net> wrote:
>
> 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.
>

Code generation is in the back end, so the answer to that is simply 'no'.

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

Then you should read it, as the 'cathedral' in question was GCC - a project started by Stallman. :)

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

Closing patches benefit no one.  And more to the point,  you can't say that two compiler's implement the same language if both have different language features.

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

You seem to think when I say D I'm referring to dmd, or any other D compiler out there.

>
>> - 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 backend is not part of the D language implementation / specification. (for starters, it's not documented anywhere except as code).

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

Where did I say that? I only invited you to speculate on what would happen if a 'closed patch' got rejected.  This leads back to the point that you can't call it a compiler for the D programming language if it derives from the specification / implementation.

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

I'll allow you to keep on thinking that for a while longer...

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

All I've seen from you from my skim,  snore, skip,  skim are projects started by multi-millionaire companies who have both resource, influence, and marketing behind them.  The contributors who have helped design and shape the D programming language are neither of these.