An idea for commercial support for D

[Joseph Rushton Wakeling via Digitalmars-d]

On 06/01/15 07:14, Joakim via Digitalmars-d wrote:
> 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.

This is a pretty bad habit you have, to just dismiss people rather than to try 
and understand the substance and detail of their concerns and requirements.

You seem to see "non-free is a deal-breaker" as some sort of fundamentalist 
position.  In fact, it's almost invariably contextual and highly dependent on 
the particular use-case and the particular needs that someone has in a 
particular piece of software.

For example, I'm not particularly happy about the existence of binary blobs or 
drivers in my Linux kernel, but it has very little practical effect on my 
ability to use Linux-based OS's, the sustainability of Linux development, or its 
reliability as a platform.  It's mostly a PITA for the kernel devs themselves 
and distro manufacturers who have to debug problems caused by these proprietary 
components.

But by contrast I would be extremely reluctant to base my software business 
around a development toolchain with proprietary components, or where I feared 
that might become part of the toolchain's business model in future.  Why? 
Because that enables someone else, whose interests may be different to mine, to 
exert control over my ability to fulfil my commercial and product goals.  The 
moment you accept a proprietary component into your toolchain, you're at risk of 
"Pay us more or we stop supporting this thing you are dependent on," and because 
it's proprietary, you simply don't have the same options to find another supplier.

That's not zealotry or moralism or absolutist, it's basic business sense, and 
it's not a hard decision to reach when there are so many excellent free 
development toolchains out there, whose development models are _not_ based on 
limiting access to new features or fixes.

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

There isn't any conflict in their position.  If you don't see it, that's 
probably because you don't perceive some important distinctions that they are 
concerned with ...

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

... such as the distinction between paying for a new fix to be created, versus 
being forbidden from accessing already-existing fixes _unless_ you pay.

You seem to think that the only dividing line is whether a fix is paid for or 
not.  It isn't.  If you're paying for a new fix or feature, then you're paying 
for the creation of new value.  If you're paying in order to access fixes or 
features that have already been created, then money is being extracted from you 
on the basis of artificial scarcity.  The two create very different incentives 
on the part of both suppliers and purchasers.

Note that the above isn't a moral judgement.  We don't need to assume there is 
anything ethically suspect about business based around artificial scarcity.  But 
it is certainly true that, from a purchaser's point of view, it is generally 
preferable to avoid being dependent on such businesses.

That's fundamentally the decision that Jarrett's managers are making: not 
between projects that do or don't have paid support, but between projects whose 
support options are based around creation of new value versus projects whose 
support model is based around the creation of artificial scarcity.

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

There's a very simple and straightforward model of paid bug fixes.  The core 
development team charges a retainer that enables the payer to request 
prioritization of fixes and/or features they require.  You pay on a subscription 
basis, you put in your priority requests as and when they arise.  Effectively, 
this is taking out insurance against blockers, and as with regular insurance, 
there can be different scales of fee depending on what it is you want "coverage" 
for (just bugfixes? new features too? or do you just care about getting priority 
for merges of fixes that your own team will create?), on the anticipated volume 
of requests you are going to make, and on exactly how much you want to be first 
on the list where there are conflicting priorities.  And of course, if you don't 
make any "claims" for a period of time, this can also bump you up the priority 
list for when you finally do need something.

This is a win-win all round -- the core development team gets a regular supply 
of money; commercial users have a predictable cost for protecting themselves 
against bugs, and are not "locked in" in any way; costs are spread across 
commercial users, so there shouldn't need to be any disincentive to request a 
fix when you do actually need it.  (You can guard against reluctance to put in 
claims by ensuring that if multiple customers all request a fix, it gets higher 
priority, and that it counts less towards their individual volume of claims.) 
Finally, everything remains free software for everyone, both the commercial 
users and the wider developer and user community, which means that there's no 
potential disincentive to community contributions ("Why should I contribute to a 
project that locks away the latest features from me?").

What about the freeloaders?  Well, the basis of this model is that if someone 
depends on a particular piece of software for their own value-creating 
activities, then it's in their interest to insure against the reliability of 
that tool.  Someone who chooses not to is basically gambling that they will 
never encounter a blocker; I'd say that's their call to make, but I also think 
that if the tool is valuable enough, there will be plenty of people who _do_ 
value being insured.

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

There are really only two options here.  If the proprietary, enhanced features 
are part of the language/standard library spec, then there is a paywall around 
the language.  If they are not officially part of the spec, but they are 
supplied by the official language project and the performance of the language is 
in practice much worse without them, then I'd still count that as a paywall 
around the language, because it's the official project withholding functionality 
on the basis of payment.  If neither, then you're simply talking about a 
3rd-party library or toolchain, in which case -- well, businesses can be based 
around such things, and if they drive benefits back to the core project that's nice.

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

The second half of your last sentence here summarizes rather well why I don't 
like the idea of generating money by restricting access to features and fixes. 
They have an incentive to restrict as much as possible and release as little as 
they can.

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

I believe it could be divisive to the development community, but I'm prepared to 
be proven wrong by someone actually making it work.

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

I've described one payment model to avoid that; there are surely others.  But 
ultimately even without that, there isn't really a "tragedy of the commons" at 
work in the scenario you describe, because in this case, people pay not in order 
to solve some problem for "the commons", but to solve problems that are blockers 
to their own value-creating activity.  Yes, you can gamble on someone else 
solving your problem for you, but your ability to do that largely rests on the 
degree to which that solution is actually really vital for you.

BTW, in reference to the "tragedy of the commons", it's worth mentioning that 
the canonical example often cited -- the farmers who have a shared interest in 
common land being available for grazing but no individual motive to maintain it 
-- ignores all the historical mechanisms and institutions that were employed to 
ensure that common land was indeed maintained.  It's not surprising that it does 
so either, because this "example" originates during the final stages of the 
enclosure movement in the United Kingdom, as intellectual justification for what 
was in practice simply a mass appropriation of land (and the value created from 
working the land) into a much narrower set of hands.  It's been claimed that 
this had the long-term benefit to everyone of increasing overall productivity, 
but there are good reasons to doubt this; what isn't in doubt is that the 
benefits of that productivity were skewed to such an extent that the enclosure 
movement caused the first mass starvation in England for centuries, _despite 
being in the middle of a food surplus_.

I tell you this little tale not as some sort of metaphor for proprietary 
software, but simply to suggest that it's a good idea to be be cautious around 
this idea of the "tragedy of the commons".  All too often people promote it 
because they have a personal vested interest in preventing the creation of the 
institutional or economic structures that would permit a viable commons to exist.

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

I think I've already responded to this.

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

My point was that I can't think of any recent example of a highly-successful 
_new_ language whose default toolchain has proprietary components, apart from 
those supplied by corporate behemoths.

I accept that there are commercially successful proprietary implementations of 
already-successful languages, but I think that absent a major corporate driver, 
a proprietary implementation of a not-yet-major language is likely to be a 
turn-off rather than a turn-on for adoption.  There's simply too much 
competition from many excellent free toolchains, both for longstanding and new 
languages.

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

It is entirely possible that we are disagreeing at least in part based on 
alternative definitions of "success".

For example, if I look at Android as an example, I don't see a free software 
success story.  What I see is a _very_ controlled platform (access to the actual 
development edge is highly restricted) whose wider community is largely made up 
of hardware manufacturers competing to make proprietary extensions that never 
get sent upstream, and whose code never gets released; and when you receive an 
Android device, in most cases you have no way, as a user, to access the source 
of the code it is actually running.

There's a huge amount of wasted effort, duplication of effort, and so on, which 
is sustained by the fact that, on the one hand, the mobile hardware industry is 
huge and these software development costs are trivial by comparison to the 
investment required to produce, market and distribute a new hardware device; and 
on the other hand, for Google themselves, the cost of developing the core 
Android platform is small compared to the commercial benefits of the huge 
amounts of extra data it brings in.

Is Android making a lot of money for a lot of people and being put on a lot of 
devices?  Yes.  How much of that distributed software is actually free?  Very 
little, compounded by the fact that as a platform, its "killer apps" are 
proprietary.

In other words, the development of one high-quality piece of open source 
software -- the core Android platform -- has been achieved at the cost of the 
creation of a massive proprietary ecosystem.  That's not a free software success 
in any meaningful sense.

Of course, you're arguing about making D a success in terms of adoption, levels 
of development activity and so on.  Here I'll happily concede that, for example, 
if (say) a major commercial OS platform were to adopt D as one of its primary 
development languages, create its own (proprietary or not) D-based development 
libraries and create its own proprietary extension of the compiler that offered 
extra features, it would certainly drive adoption of D, and it would almost 
certainly result in lots of nice code eventually making its way back to the core 
D project.  This is pretty much analogous to what I see happening with Apple and 
clang/llvm.

However, that situation of a major OS provider deriving from a free language 
implementation to create its (proprietary) primary development toolchain, is 
very different from the situation of a language provider standing alone trying 
to gain adoption.  Apple are in a position to be able to say to devs, "You use 
this toolchain or you don't get to target our platform."  That's the kind of 
business factor that I'm talking about, which doesn't exist for D: absent that 
kind of driving force, a proprietary implementation would be a blocker both to 
uptake and contributions, for reasons already discussed above.

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

I'll thank you not to put words in my mouth.  Where have I said "Others must 
always work for me for free and give me all the source"?

Would I like a world where all software was free-as-in-freedom?  Certainly, and 
I see this as both a moral and a practical good.  Am I enthusiastic about the 
idea of free software also being available without cost for access?  Again, yes, 
and I think it's important to identify business and development models that make 
this possible (a position quite different from "Others must...").  Do my 
preferences mean I can't understand or appreciate the social, economic and 
technical dynamics of doing things differently?  Well, a cynic might try and 
dodge the question by suggesting that you yourself seem rather too emotionally 
attached to the cleverness of your hybrid idea to be able to discuss it entirely 
rationally -- as evidenced by your eagerness to label people as "zealots" or 
"irrational" or "ideological" because they have problems with your proposed way 
of doing things.

However, I'd rather not be such a cynic, and so I'll simply say: I think I've 
engaged, in quite a lot of detail and depth, with almost all of the points 
you've raised.  You're not obliged to agree with either my analysis or my 
principles, but if you do want to dispute them, it might be a good idea to do so 
on the basis of their content rather than your assumptions or prejudices about 
why I think this way.

And really, if you want to sell a business model to people, don't go dismissing 
people who tell you "this won't work for me".  Those people are your potential 
customers.  Find out what _will_ work for them, and give it to 'em. ;-)