An idea for commercial support for D

Joseph Rushton Wakeling via Digitalmars-d digitalmars-d at puremagic.com
Mon Jan 5 14:51:08 PST 2015


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.


More information about the Digitalmars-d mailing list