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
