An idea for commercial support for D

[Joakim via Digitalmars-d]

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.