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.
