This is an idea I've been kicking around for a while, and given the need for commercial support for D, would perhaps work well here.

The notion is that individual developers could work on patches to fix bugs or add features to ldc/druntime/phobos then sell those closed patches to paying customers.  After enough time has passed, so that sufficient customers have adequately paid for the work or after a set time limit beyond that, the patch is open sourced and merged back upstream.  It would have to be ldc and not dmd, as the dmd backend is not open source and the gdc backend license doesn't allow such closed patches.

This works better than bounties because it avoids the "tragedy of the commons" problem inherent to open source and bounties, ie any user can just wait for some other contributor or any potential individual paying customer has an incentive to wait and let somebody else pay a bounty, then use the resulting work for free right away.  With this approach, non-paying users only get the resulting paid work after the work has been paid for and perhaps an additional delay after that.

Two big benefits come out of this approach.  Obviously, this would provide commercial support for paying customers, but the other big benefit is that it doesn't depend on some company providing that support.  A decentralized group of devs could work on and get paid for these individual patches on their own, without having to get together and start a company.

I'm writing about this idea to see how much interest there is from D developers for doing such paid work and from paying customers to pay for such work.  For those who believe this isn't part of the open source aspect of D, it isn't.  This doesn't have to be a part of the D open source project, even if the work ultimately often ends up back in the official github repos, after a delay.

I believe this is the needed step to turn the D community from a tribe into an organization, as Andrei said recently.  More rationale about this hybrid licensing model can be found in this article I wrote almost five years ago:

http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing

On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
>
>
> Two big benefits come out of this approach.  Obviously, this would provide commercial support for paying customers, but the other big benefit is that it doesn't depend on some company providing that support.  A decentralized group of devs could work on and get paid for these individual patches on their own, without having to get together and start a company.
>

Now to get those paying customers...

On 4 Jan 2015 08:35, "Joakim via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
>
> This is an idea I've been kicking around for a while, and given the need
for commercial support for D, would perhaps work well here.
>
> The notion is that individual developers could work on patches to fix
bugs or add features to ldc/druntime/phobos then sell those closed patches to paying customers.  After enough time has passed, so that sufficient customers have adequately paid for the work or after a set time limit beyond that, the patch is open sourced and merged back upstream.  It would have to be ldc and not dmd, as the dmd backend is not open source and the gdc backend license doesn't allow such closed patches.
>

Do what you want, but I don't think you could or should call it D from the moment you deviate.

>
> http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing

There's no such thing as a hybrid.  You're either a cathedral or a bazaar, and a hybrid approach is looking pretty cathedral to me.

>From a technical standpoint, how do you propose to deal with splitbrain
situations?  If your proposed closed solution is source-incompatible with the open then you have failed as a model.

>From a pragmatic (though maybe philosophical) standpoint, having been in
active development in or around the core for 4 years, my observation (which I believe Walter shared as well) is that back when DMD was partially closed, there just wasn't much traction in development or adoption.  Right now things are moving pretty fast, and I don't think DMD *can* get any more open than what it already is.  Given the compelling correlation between both popularity and contribution with the openness of development at the core (ie: moving to github), history tells us that closing will only serve to stifle and stop.

Regards
Iain.

On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via Digitalmars-d wrote:
> On 4 Jan 2015 08:35, "Joakim via Digitalmars-d" <digitalmars-d@puremagic.com>
> wrote:
>>
>> This is an idea I've been kicking around for a while, and given the need
> for commercial support for D, would perhaps work well here.
>>
>> The notion is that individual developers could work on patches to fix
> bugs or add features to ldc/druntime/phobos then sell those closed patches
> to paying customers.  After enough time has passed, so that sufficient
> customers have adequately paid for the work or after a set time limit
> beyond that, the patch is open sourced and merged back upstream.  It would
> have to be ldc and not dmd, as the dmd backend is not open source and the
> gdc backend license doesn't allow such closed patches.
>>
>
> Do what you want, but I don't think you could or should call it D from the
> moment you deviate.

I'm not doing anything, I'm putting an idea out here for consideration.  I'm uninterested in doing this on my own and seeding such paid patches entirely by myself, so if there aren't enough people interested in both paid development and paying for patches, it won't get done.

As for what to call it, ldc and gdc both differ from dmd in non-trivial ways and still call themselves D compilers.  I don't think the name really matters, but for what it's worth, I agree with you that if such a commercial model goes in a completely different direction with the language, a name change is probably best.

>> http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing
>
> There's no such thing as a hybrid.  You're either a cathedral or a bazaar,
> and a hybrid approach is looking pretty cathedral to me.

Tell that to the most widely used open-source projects these days, ie hybrid projects like Android, iOS/OS X, llvm/clang, Chrome, etc.  There are advantages to both the cathedral and the bazaar model, which is why it's best to mate the two, as has been done by the listed highly successful software.

>>From a technical standpoint, how do you propose to deal with splitbrain
> situations?  If your proposed closed solution is source-incompatible with
> the open then you have failed as a model.

Not sure if you're referring to users' D source that can't be compiled by both compilers or patches from the closed D frontend that might be difficult to merge back upstream into the dmd frontend.  Obviously both can be handled with some effort.  Since the idea is not to completely fork the frontend but to provide patches on it that are eventually upstreamed, I doubt either will be a problem.

>>From a pragmatic (though maybe philosophical) standpoint, having been in
> active development in or around the core for 4 years, my observation (which
> I believe Walter shared as well) is that back when DMD was partially
> closed, there just wasn't much traction in development or adoption.  Right
> now things are moving pretty fast, and I don't think DMD *can* get any more
> open than what it already is.  Given the compelling correlation between
> both popularity and contribution with the openness of development at the
> core (ie: moving to github), history tells us that closing will only serve
> to stifle and stop.

Was Walter selling a paid compiler with the then-closed dmd backend?  If not, the comparison is not valid.  The idea here is for paying customers to fund closed patches for a limited time, and speed up D bug-fixing and development much more.  If Walter was not getting paid for his closed backend but only keeping it closed because of licensing issues, the situations are completely different.

Also, this is a _hybrid_ approach, not a closed one.  There will always be an OSS core that potential devs can look at.  They just may not have access to all the closed-source patches that others are selling.

Recent history of the explosively successful hybrid projects I listed suggests that a hybrid approach is the most scalable one.

On 01/04/2015 09:31 AM, Joakim wrote:
>
> The notion is that individual developers could work on patches to fix
> bugs or add features to ldc/druntime/phobos then sell those closed
> patches to paying customers.  After enough time has passed, so that
> sufficient customers have adequately paid for the work or after a set
> time limit beyond that, the patch is open sourced and merged back
> upstream.  It would have to be ldc and not dmd, as the dmd backend is
> not open source and the gdc backend license doesn't allow such closed
> patches.

I don't think anyone has an interest of closed patches.
Building a point release with the bug fixed might be of more interest.

On 4 January 2015 at 14:50, Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via Digitalmars-d wrote:
>>
>> On 4 Jan 2015 08:35, "Joakim via Digitalmars-d"
>> <digitalmars-d@puremagic.com>
>> wrote:
>>>
>>>
>>> This is an idea I've been kicking around for a while, and given the need
>>
>> for commercial support for D, would perhaps work well here.
>>>
>>>
>>> The notion is that individual developers could work on patches to fix
>>
>> bugs or add features to ldc/druntime/phobos then sell those closed patches to paying customers.  After enough time has passed, so that sufficient customers have adequately paid for the work or after a set time limit beyond that, the patch is open sourced and merged back upstream.  It would have to be ldc and not dmd, as the dmd backend is not open source and the gdc backend license doesn't allow such closed patches.
>>>
>>>
>>
>> Do what you want, but I don't think you could or should call it D from the moment you deviate.
>
>
> I'm not doing anything, I'm putting an idea out here for consideration.  I'm uninterested in doing this on my own and seeding such paid patches entirely by myself, so if there aren't enough people interested in both paid development and paying for patches, it won't get done.
>
> As for what to call it, ldc and gdc both differ from dmd in non-trivial ways and still call themselves D compilers.  I don't think the name really matters, but for what it's worth, I agree with you that if such a commercial model goes in a completely different direction with the language, a name change is probably best.
>

Right - though I may just point out that the differences between ldc, gdc, dmd are more from a low-level perspective.  Want access to simd intrinsics?  Sure different compilers expose different intrinsics, but at least you can distinguish between who implemented what - version(D_SIMD)? This compiler implements __simd; version(GNU)? This compiler has a gcc.builtins module, etc.

The exact same is with any other bare-metal features.  Inline ASM? There's version(D_InlineAsm) and _x86 and _x86_64 variants for being able to test whether or not this compiler supports that.  Whereas version(GNU_InlineAsm) means that we are using a compiler that implements GCC extended assembler.

Is this annoying?  For a user writing a library, I would say Yes, but only if your work requires stepping outside the language norms. Annoyance also extends out to maintainers too (I could write a book about Where DMD went wrong? Some more of DMD's greatest mistakes, and Just who is this DMD compiler anyway?)


>>> http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing
>>
>>
>> There's no such thing as a hybrid.  You're either a cathedral or a bazaar, and a hybrid approach is looking pretty cathedral to me.
>
>
> Tell that to the most widely used open-source projects these days, ie hybrid projects like Android, iOS/OS X, llvm/clang, Chrome, etc.  There are advantages to both the cathedral and the bazaar model, which is why it's best to mate the two, as has been done by the listed highly successful software.
>

At least three of those projects I would see as anything but bazaar.  :)

I can see this turning into a moral argument - one that will neither be the first nor last, so I'll end with accepting my view is not yours.

>>> From a technical standpoint, how do you propose to deal with splitbrain
>>
>> situations?  If your proposed closed solution is source-incompatible with the open then you have failed as a model.
>
>
> Not sure if you're referring to users' D source that can't be compiled by both compilers or patches from the closed D frontend that might be difficult to merge back upstream into the dmd frontend.  Obviously both can be handled with some effort.  Since the idea is not to completely fork the frontend but to provide patches on it that are eventually upstreamed, I doubt either will be a problem.
>

I was referring to patches from closed merging upstream.

One example would be, oh, DIP-25 being implemented in the closed frontend - let's say Walter implemented it, then someone from the community implements DIP-25 in a differing way and raises a PR a couple months later.  Should the PR be accepted?  If it is should the closed implementation be dropped?  Because of the closed nature there's no way to compare which one is more technically sound than the other.

There's also a question of timing too.  Obviously such an undertaking shouldn't happen until the frontend switches to D, nor when there are still plenty of visitor re-writes being done in the frontend.


>>> From a pragmatic (though maybe philosophical) standpoint, having been in
>>
>> active development in or around the core for 4 years, my observation
>> (which
>> I believe Walter shared as well) is that back when DMD was partially
>> closed, there just wasn't much traction in development or adoption.  Right
>> now things are moving pretty fast, and I don't think DMD *can* get any
>> more
>> open than what it already is.  Given the compelling correlation between
>> both popularity and contribution with the openness of development at the
>> core (ie: moving to github), history tells us that closing will only serve
>> to stifle and stop.
>
>
> Was Walter selling a paid compiler with the then-closed dmd backend?  If not, the comparison is not valid.  The idea here is for paying customers to fund closed patches for a limited time, and speed up D bug-fixing and development much more.  If Walter was not getting paid for his closed backend but only keeping it closed because of licensing issues, the situations are completely different.
>

For me, the comparison is between these key timelines:

- No source code
- D1 Frontend released as Artistic/GPL
- Backend released under restricted license
- Moving to Github
- Creating a 'core' team
- Everyone (even Walter!) switching over to the PR patch
submission/review system
- Re-license Frontend as Boost

Each point over a 14 year history has been a step in the direction of being 'open' and each brought a boost in development.  The number of changes between each release compared to back in 2.020 days is a clear sign of this - as well as the three digit open PRs.

Iain.

On Sunday, 4 January 2015 at 17:18:22 UTC, Iain Buclaw via Digitalmars-d wrote:
> On 4 January 2015 at 14:50, Joakim via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
> Annoyance also extends out to maintainers too (I could write a book
> about Where DMD went wrong? Some more of DMD's greatest mistakes, and
> Just who is this DMD compiler anyway?)

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

>> Tell that to the most widely used open-source projects these days, ie hybrid
>> projects like Android, iOS/OS X, llvm/clang, Chrome, etc.  There are
>> advantages to both the cathedral and the bazaar model, which is why it's
>> best to mate the two, as has been done by the listed highly successful
>> software.
>>
>
> At least three of those projects I would see as anything but bazaar.  :)

I'd say three are hybrids to varying degrees and iOS/OSX is largely cathedral nowadays, despite its bazaar BSD antecedents.

> I was referring to patches from closed merging upstream.
>
> One example would be, oh, DIP-25 being implemented in the closed
> frontend - let's say Walter implemented it, then someone from the
> community implements DIP-25 in a differing way and raises a PR a
> couple months later.  Should the PR be accepted?  If it is should the
> closed implementation be dropped?  Because of the closed nature
> there's no way to compare which one is more technically sound than the
> other.

There is no reason for the open source project to defer a PR because of closed patches that aren't available yet.  Once the closed patches are opened, the two implementations can be merged for their best aspects.

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

> There's also a question of timing too.  Obviously such an undertaking
> shouldn't happen until the frontend switches to D, nor when there are
> still plenty of visitor re-writes being done in the frontend.

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

>> Was Walter selling a paid compiler with the then-closed dmd backend?  If
>> not, the comparison is not valid.  The idea here is for paying customers to
>> fund closed patches for a limited time, and speed up D bug-fixing and
>> development much more.  If Walter was not getting paid for his closed
>> backend but only keeping it closed because of licensing issues, the
>> situations are completely different.
>>
>
> For me, the comparison is between these key timelines:
>
> - No source code
> - D1 Frontend released as Artistic/GPL
> - Backend released under restricted license
> - Moving to Github
> - Creating a 'core' team
> - Everyone (even Walter!) switching over to the PR patch
> submission/review system
> - Re-license Frontend as Boost
>
> Each point over a 14 year history has been a step in the direction of
> being 'open' and each brought a boost in development.  The number of
> changes between each release compared to back in 2.020 days is a clear
> sign of this - as well as the three digit open PRs.

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

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

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

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

As a user of D in a corporate environment and personal at home environment, I have to say this model won't work for me. In fact if this model were implemented, I would more than likely have to move my project to a different language because of it. Let me explain the issues I see here.

You've proposed a hybrid open and closed source model. Where certain segments of code (latest patches) are behind a per patch paywall. As a customer I don't want to have to pay for each bug fix in the compiler. If there is a bug in the language/compiler then I want it fixed. I shouldn't be charged to have the language I'm using work properly. It basically says to customers, here you can use this language for free, unless you want it to work properly, in which case you need to pay for each fix you need or wait till developers don't care about making money off a fix anymore.

This will also diminish the growth rate of D. I can tell you, it would be significantly harder for me to use D at my workplace if this model were in place. Managers are okay in letting me use D because its an open source project (minus the backend of DMD) and it doesn't cost them a cent. If all of the sudden I have to ask them to pay for fixes in order for my project to work, that makes it a different situation entirely. My company would also frown on the free option of waiting for fixes to pass out of the pay wall. Companies like actively supported projects. As such, companies (at least the one I work for) prefer either fully commercially supported languages (C# through VS) or fully open source.

Remember, that there are ways to provide commercial support without putting a paywall on using the language itself. What is really needed here is buy-in from corporations on the language. Having engineers from a company working on D would provide one form of commercial support. But this model is very difficult to find and the closest to it I've seen is Facebook's involvement with D. I agree having developers who are paid to work on D would be a great thing, but reaching that point is a very difficult road.

While I understand, that D needs some form of commercial support for some parties, there is also a stigma that the current model doesn't provide support. I've found to the contrary actually. I find the full open source model employed here, has a better support system than a lot of other commercial support models. The reason is the community, there is always someone around to answer a question. I find with most commercially supported models the development team can't be reached and you have to depend on your coworkers or friends who may know of a workaround (Microsoft model). Most of the time I see bugs get fixed fairly promptly for a compiler project despite the fragmented development that is inherent to open source projects.

I think commercial support for D really comes down to one of two situations in the future:

* A company decides to make a commercial D compiler that is closed source but compatible with phobos, etc. They fully support the compiler. (Doesn't necessarily mean they charge for the compiler itself, they could but they can also charge for support plans and/or a IDE tool).
* A company decides to invest engineers in working on the open source D compiler. Thus providing commercially supported developers to the project. (This would be a hybrid too, where the open source developers can still contribute and work but now there are a group of paid engineers working to advance the language as well).

On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
> This is an idea I've been kicking around for a while, and given the need for commercial support for D, would perhaps work well here.
>
> The notion is that individual developers could work on patches to fix bugs or add features to ldc/druntime/phobos then sell those closed patches to paying customers.  After enough time has passed, so that sufficient customers have adequately paid for the work or after a set time limit beyond that, the patch is open sourced and merged back upstream.  It would have to be ldc and not dmd, as the dmd backend is not open source and the gdc backend license doesn't allow such closed patches.
>
> This works better than bounties because it avoids the "tragedy of the commons" problem inherent to open source and bounties, ie any user can just wait for some other contributor or any potential individual paying customer has an incentive to wait and let somebody else pay a bounty, then use the resulting work for free right away.  With this approach, non-paying users only get the resulting paid work after the work has been paid for and perhaps an additional delay after that.
>
> Two big benefits come out of this approach.  Obviously, this would provide commercial support for paying customers, but the other big benefit is that it doesn't depend on some company providing that support.  A decentralized group of devs could work on and get paid for these individual patches on their own, without having to get together and start a company.
>
> I'm writing about this idea to see how much interest there is from D developers for doing such paid work and from paying customers to pay for such work.  For those who believe this isn't part of the open source aspect of D, it isn't.  This doesn't have to be a part of the D open source project, even if the work ultimately often ends up back in the official github repos, after a delay.
>
> I believe this is the needed step to turn the D community from a tribe into an organization, as Andrei said recently.  More rationale about this hybrid licensing model can be found in this article I wrote almost five years ago:
>
> http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing

On Monday, 5 January 2015 at 18:28:39 UTC, Jarrett Tierney wrote:
> As a user of D in a corporate environment and personal at home environment, I have to say this model won't work for me. In fact if this model were implemented, I would more than likely have to move my project to a different language because of it. Let me explain the issues I see here.
>
> You've proposed a hybrid open and closed source model. Where certain segments of code (latest patches) are behind a per patch paywall. As a customer I don't want to have to pay for each bug fix in the compiler. If there is a bug in the language/compiler then I want it fixed. I shouldn't be charged to have the language I'm using work properly. It basically says to customers, here you can use this language for free, unless you want it to work properly, in which case you need to pay for each fix you need or wait till developers don't care about making money off a fix anymore.

If you're not paying, you're not a customer.  The alternative is to use the bug-ridden OSS implementation you're using now for free, and not have a paid version for those who want those bugs fixed.  I don't doubt that some irrational people interpret the existence of a paid version in the way you laid out, and in extreme cases that _can_ happen (just as there are OSS vendors who write bad OSS code just so they can make more money off your favored support model), but that's more an issue with their sloppy thinking than anything else.

> This will also diminish the growth rate of D. I can tell you, it would be significantly harder for me to use D at my workplace if this model were in place. Managers are okay in letting me use D because its an open source project (minus the backend of DMD) and it doesn't cost them a cent. If all of the sudden I have to ask them to pay for fixes in order for my project to work, that makes it a different situation entirely. My company would also frown on the free option of waiting for fixes to pass out of the pay wall. Companies like actively supported projects. As such, companies (at least the one I work for) prefer either fully commercially supported languages (C# through VS) or fully open source.

There are also "fully open source" languages which are "fully commercially supported."  How do your managers wrap their minds around such a paradox? ;)

My point is that such artificial distinctions are silly, whether because of the amount of support or source available.  The alternative to paid bug fixes is not that all the bugs you want fixed get done for free: it's _no_ bug fixes, as we see today.  For example, selective imports at module scope has been broken for more than eight years now, as those symbols are leaked into any module that imports the module with the selective import.  There are many more bugs like that, that could actually be fixed much faster if there were more paid devs working on D.

> Remember, that there are ways to provide commercial support without putting a paywall on using the language itself. What is really needed here is buy-in from corporations on the language. Having engineers from a company working on D would provide one form of commercial support. But this model is very difficult to find and the closest to it I've seen is Facebook's involvement with D. I agree having developers who are paid to work on D would be a great thing, but reaching that point is a very difficult road.

Having both paid and free versions available is not a "paywall" on a language.  A company is not going to just write a bunch of patches and open source all of them unless they have some complementary business model to go with it, whether google making more mobile revenue off Android or Apple providing clang as the system compiler on OS X and making money off the bundled Mac.

> While I understand, that D needs some form of commercial support for some parties, there is also a stigma that the current model doesn't provide support. I've found to the contrary actually. I find the full open source model employed here, has a better support system than a lot of other commercial support models. The reason is the community, there is always someone around to answer a question. I find with most commercially supported models the development team can't be reached and you have to depend on your coworkers or friends who may know of a workaround (Microsoft model). Most of the time I see bugs get fixed fairly promptly for a compiler project despite the fragmented development that is inherent to open source projects.

That community involvement would still be there for the OSS core with D, but you would get support for a closed patch from the developer who wrote it.

> I think commercial support for D really comes down to one of two situations in the future:
>
> * A company decides to make a commercial D compiler that is closed source but compatible with phobos, etc. They fully support the compiler. (Doesn't necessarily mean they charge for the compiler itself, they could but they can also charge for support plans and/or a IDE tool).

There is essentially nothing different from this situation and the hybrid model I've described, in terms of the product you'd be using.  The only difference is that it wouldn't be a company, but some selection of independent devs.

> * A company decides to invest engineers in working on the open source D compiler. Thus providing commercially supported developers to the project. (This would be a hybrid too, where the open source developers can still contribute and work but now there are a group of paid engineers working to advance the language as well).

As I said above, this is unlikely.  Just because it has happened before with some OSS projects, many OSS users/devs fantasize that it will happen for their favored project.

IBM and Red Hat didn't contribute to linux because they believe in FOSS or wanted to "give back" to the community, but because they saw real economic advantages to leveraging an existing OS code base in their consulting/support businesses.  The GPL and the fact that their businesses distribute software to their customers made them give back their patches.  Meanwhile, google runs a patched linux kernel on a gazillion search servers and doesn't distribute their patches, because the license doesn't say they have to and they see no economic advantage to doing so.

D is not an OS like linux, so the consulting/support model doesn't apply.  While such free corporate investment is theoretically possible for D, it is very unlikely and as I mentioned in my linked article, such support models are not as successful.

Turning D into a paid product by using the hybrid model I laid out would make its development go much faster.  There would always be an OSS core for OSS devs to work on and for users to download for free, while those who want to pay for quality and features would do so.  It's similar to how other compiler vendors put out a free but less capable compiler and sell a more capable one.

On 05/01/15 21:57, Joakim via Digitalmars-d wrote:
> If you're not paying, you're not a customer.  The alternative is to use the
> bug-ridden OSS implementation you're using now for free, and not have a paid
> version for those who want those bugs fixed.  I don't doubt that some irrational
> people interpret the existence of a paid version in the way you laid out, and in
> extreme cases that _can_ happen (just as there are OSS vendors who write bad OSS
> code just so they can make more money off your favored support model), but
> that's more an issue with their sloppy thinking than anything else.

See, this is where I find _your_ point of view irrational, because you fail to see how straightforwardly damaging closed source can be to adoption.  The fact of the matter is that for a great many users, and particularly for a great many corporate adopters of development toolchains, today it matters hugely that the toolchain is free-as-in-freedom.  Not free 6 months down the line -- free, now, in its entirety.

Non-free code (even temporarily), secret development, etc., are simply deal-breakers for a great many people.  A smart business model will engage with this fact and find a way to drive money to development without closing things up.

> There are also "fully open source" languages which are "fully commercially
> supported."  How do your managers wrap their minds around such a paradox? ;)

See, if I was in your shoes, I'd be trying to take on board the feedback about why your proposed model would be unattractive to his managers, rather than making sarcastic points that don't actually identify a conflict with their position.

Most commercial adopters are going to consider it very important to have a support option that says, "If you have a serious blocker, you can pay us money to guarantee that it gets fixed."

They are not going to be at all happy about a support option that says, "If we develop a fix, then you are not going to get it in a timely manner unless you pay."

Understanding that distinction is very important.

> My point is that such artificial distinctions are silly, whether because of the
> amount of support or source available.  The alternative to paid bug fixes is not
> that all the bugs you want fixed get done for free: it's _no_ bug fixes, as we
> see today. For example, selective imports at module scope has been broken for
> more than eight years now, as those symbols are leaked into any module that
> imports the module with the selective import. There are many more bugs like
> that, that could actually be fixed much faster if there were more paid devs
> working on D.

You're talking about "the alternative to paid bug fixes" as if the only way of having paid bug fixes is to follow your model of locking them away from the wider community.  That's simply not true.

> Having both paid and free versions available is not a "paywall" on a language.

Unless those versions are identical, yes it is.

> A company is not going to just write a bunch of patches and open source all of
> them unless they have some complementary business model to go with it, whether
> google making more mobile revenue off Android or Apple providing clang as the
> system compiler on OS X and making money off the bundled Mac.

So why not focus on creating those complementary business models?

> That community involvement would still be there for the OSS core with D, but you
> would get support for a closed patch from the developer who wrote it.
>
> ...
>
> There is essentially nothing different from this situation and the hybrid model
> I've described, in terms of the product you'd be using.  The only difference is
> that it wouldn't be a company, but some selection of independent devs.

Bottom line: if some individual or group of devs want to try and make a business selling proprietary patches to the DMD frontend, or phobos, the licensing allows them to do that.  Good luck to them, and if they want to submit those patches to D mainline in future, good luck to them again.

However, I don't see it making any sense for a company to invest in proprietary patches to a toolchain, because 99% of the time, when you need a patch written, it's a bugfix.  And when you want a bugfix, you don't want a patch that applies only to your version of the toolchain and which you (or your friendly proprietary-patch-writing consultant) have to keep rebasing on top of upstream for the next 6 months -- you want upstream fixed.  Otherwise you'll wind up paying far more merely for maintenance of your proprietary extensions, than you would have just to get someone to write a patch and get it straight into the open-source upstream.

I also think you assume far too much value on the part of privileged/early access to bugfixes.  A bug in a programming language toolchain is either a commercial problem for you or it isn't.  If it's a commercial problem, you need it fixed, and that fix in itself has a value to you.  There is not really any comparable change in value if that fix also gets delivered to other users (who may or may not be competitors of yours), because that isn't what differentiates your product.

> D is not an OS like linux, so the consulting/support model doesn't apply.  While
> such free corporate investment is theoretically possible for D, it is very
> unlikely and as I mentioned in my linked article, such support models are not as
> successful.

On the contrary, D is a programming language, and as such is used by people to make commercial projects, and so those people have a very strong interest in paying for commercial support, based around the principle "If we need something fixed, it will be fixed."

But they don't have an interest in a situation where, "If something gets fixed, we have to pay."

The first of those options delivers value.  The second is exploitation.

> Turning D into a paid product by using the hybrid model I laid out would make
> its development go much faster.  There would always be an OSS core for OSS devs
> to work on and for users to download for free, while those who want to pay for
> quality and features would do so.  It's similar to how other compiler vendors
> put out a free but less capable compiler and sell a more capable one.

Name me an example of such a vendor that isn't a massive, huge corporate behemoth whose ability to sign contracts and make sales is largely dependent on business factors entirely separate from their product licensing.

I'm really happy that you're trying to think about how to generate money for D development, but I think your insistence on the necessity of selling closed components is based on a misunderstanding both of how free software flourishes and of the business factors at play in the projects you cite as inspiration.