An idea for commercial support for D

[Joakim via Digitalmars-d]

On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:
> 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.

I don't think such people matter, ie they're a very small but 
vocal minority.  Also, these people are deeply irrational, as 
every piece of hardware they're using comes with many closed 
binary blobs.  They are either ignorant of this fact or just 
choose to make silly demands anyway.

>> 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.

Heh, the whole point of the sarcastic comment was to point out 
the obvious conflict in 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.

Haha, you do realize that those two quotes you laid out are the 
exact same option?  In the first option, you pay for a fix.  In 
the second option, you pay for a fix.  What distinction you're 
hoping to draw has not been made.

>> 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.

I wait with bated breath for your model of paid bug fixes that 
doesn't involve closing the code for the bug fixes at all.  You 
must have discovered some billion-dollar scheme, because every 
software company in the world is waiting to copy your brilliant 
method.

>> Having both paid and free versions available is not a 
>> "paywall" on a language.
>
> Unless those versions are identical, yes it is.

No, it isn't.  Your being able to use the always OSS dmd/gdc for 
free means the language is always available to you.  Just because 
someone else is using an enhanced version of ldc doesn't make the 
free version any less available to you.  To suggest otherwise is 
to distort the language to make your argument, ie flat out lying.

>> 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?

If you have a complementary business model for a D compiler, feel 
free to suggest one and get people to use it.  I don't think 
complementary business models are generally a good idea, because 
the people making money are usually going to focus on the place 
they're making money.  This is why google doesn't care that much 
if AOSP and Nexus devices are fairly buggy (I bought a Nexus 
device, will never buy one again for this reason), because they 
don't really make money off Android but off the complementary 
mobile ads.

> 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.

Given all your other responses, I suspect this is not the case, 
ie you don't want to see it happen.  But you're right, nobody can 
stop paid devs from doing this.

> 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.

These merging and rebasing issues you raise are fairly trivial.  
I've had PRs sit unmerged on github for many months and 
occasionally they'll go out of date with git HEAD.  Updating them 
to work again takes a negligible amount of time.  If paid devs 
only focus on point releases initially, as mentioned above, the 
problem doesn't really exist.

> 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.

Of course there's a change in value.  If another user or 
competitor also needs that fix and pays for it and upstreams it 
before you do, that's a cost you don't have to pay at all.  Hence 
the whole "tragedy of the commons" I laid out in my first post.

>> 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.

I suggest you actually read what you're writing:

"people have a very strong interest in paying for commercial 
support, based around the principle 'If we need something fixed, 
it will be fixed.'"

"If something gets fixed, we have to pay."

In both cases, they're paying for fixes.  If your point is that 
in the first model they're paying up front through a support 
subscription, whereas in the second model they're paying after 
they identify the fix- a distinction I'm stretching to find as 
you haven't really made it- both are still paying for a fix.  
Certainly some companies would prefer the financial certainty of 
up-front recurring subscriptions to paying on a case-by-case 
basis, just as some would prefer the potential savings of the 
latter model, but the former certainly wouldn't save them any 
money.

>> 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 not sure what point you're trying to make, that only 
"massive, huge corporate behemoths" can sell paid compilers 
alongside a free base model?  There are many smaller companies 
selling paid compilers, hell, Borland C++ is still around as 
embarcadero C++ Builder.

Guess what?  Embarcadero provides a starter edition, for those 
who aren't making much money to try out, and a full paid version, 
for once you go over $1k/year in revenue.  Embarcadero is a 
good-sized software company at 500 employees and $100 million in 
yearly revenue, but I certainly wouldn't call them a "massive, 
huge corporate behemoth."

The dual free and paid model I've laid out is commonplace in the 
compiler world.

> 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.

I'd argue that such a criticism best applies to you.  The most 
widely used OSS  projects these days are inevitably hybrid 
projects, that is incontrovertible.  You prefer that all the 
source is available to you, so you make such statements that are 
contrary to the facts or hand-wave away their success with vague 
allusions to other "business factors at play," which you of 
course do not lay out.

Obviously no one factor is determinative in success: it's always 
theoretically possible that the main reason Android succeeded is 
because it used Java, and that the source licensing played little 
part.  In that case, D can't succeed by using a similar hybrid 
model, because it's not Java. ;)

But proper rational examination of Android and other hybrid 
projects' success suggests hybrid licensing had a very large role 
to play.  I suspect you're not interested in such a rational 
analysis, because you have an ideological or emotional connection 
to all source being available, ie pure FOSS.  That's fine, just 
don't expect me to respect your position, that others must always 
work you for free and give you _all_ the source.