An idea for commercial support for D

[Jarrett Tierney via Digitalmars-d]

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