An idea for commercial support for D

[Joakim via Digitalmars-d]

On Sunday, 11 January 2015 at 12:39:03 UTC, Dicebot wrote:
> On Friday, 9 January 2015 at 15:39:13 UTC, Joakim wrote:
>>> It poses unacceptable risk of company becoming hostage of 
>>> ecosystem were "buying" closed patches is only way to use the 
>>> tool effectively. In software world where even .NET goes 
>>> open-source there is simply no reason why would one agree on 
>>> such terms.
>>
>> See my response to Joe above, most devs rely on closed 
>> toolchains.  Funny how they all avoid becoming "hostages."
>
> It doesn't match my observations at all. Of 5 places I worked, 
> 4 actively avoided any closed toolchains unless those promised 
> too much of a benefit and where considered worth the risk. I'd 
> expect this probably to be more common attitude among smaller 
> companies as enterprise relies on lawyers to address such risks 
> and does not care that much.

So you're aware that most programmers do not avoid closed 
toolchains like four of the places you worked, especially since 
you worked one place where that wasn't the case.

>>> Right now quite some of other developers contribute to D2 
>>> toolchain and related projects even if it is not directly 
>>> used. It makes sense exactly because project is fully open - 
>>> there is a good trust that such work won't get wasted and/or 
>>> abused and sit there until its actually needed, encouraging 
>>> other people to contribute in the meanwhile. It won't work 
>>> that way with hybrid model.
>>
>> I don't see how other devs selling paid patches will affect 
>> the mentioned aspects of OSS devs working on D.  Simply 
>> claiming that "it won't work that way" anymore is not an 
>> argument.
>
> It is matter of licensing. Right now it is all open and company 
> using D can be absolutely sure that it is possible to fork the 
> project at any time while keeping both own contributions and 
> all stuff that was paid for. Closed patches would need to 
> restrict that to prevent simple sharing of such patches 
> resulting in much more complicated situation.

Only until those closed patches are paid for.  You pay less for a 
patch than if you were to do the work yourself, since the cost is 
shared across all the customers who pay for that patch, then you 
receive it after a funding/time limit.  If you really want that 
patch early, you can always buy out the funding limit or come to 
some accommodation with the dev, where he licenses it to you with 
the source.

> It also prevents clash of interests - upstream would be 
> interested in preventing open contributions to areas that are 
> covered by closed patches to make buying them more tempting.

You're assuming that the upstream OSS project devs are also 
selling closed patches, which none have indicated any interest in 
doing.  Even if they did, I doubt they'd be able to get away with 
such a move, as it would only make them look bad, and it's 
trivially easy for the author of the open contribution to make it 
available in his own github branch.  This is quite a silly 
objection.

>>> 1) Selling services is indeed much different from selling 
>>> software and much more honest. When you sell a program you 
>>> don't really sell anything of value - it is just bunch of 
>>> bytes that costs you nothing to copy. When you sell service 
>>> you don't just sell "access" to same software running on the 
>>> server but continuous efforts for maintaining and improving 
>>> that software, including developer team costs and server h/w 
>>> costs over time. This is actually something of value and 
>>> charging for that is more widely accepted as just.
>>
>> The only ridiculous statement I see here is your claim that 
>> building a desktop/mobile program doesn't also require 
>> "continuous efforts for maintaining and improving that 
>> software, including developer team costs and server h/w costs 
>> over time."  Both server and desktop/mobile software are 
>> widely considered worth charging for: it is highly 
>> idiosyncratic and self-rationalizing for you to claim that one 
>> is significantly different from the other.
>
> Building requires. Selling/maintaining - doesn't.

Really?  Selling/maintaining cloud services requires "continuous 
efforts for maintaining and improving that software, including 
developer team costs and server h/w costs over time," but 
desktop/mobile locally-installed software doesn't?  News to me.

> And pure sell-the-software model pretty much never includes and 
> guaranteed support from the developer. Quite the contrary, 
> those are always tempted to abandon support in favor of making 
> new major version of same software and selling it again for 
> same money.

I see, so making major new versions of desktop/mobile software 
every so often is not "continuous efforts for maintaining and 
improving that software," but updating server software more often 
is.  Funny how you set a magic threshold and define it in your 
favor.

As for the issues you raise with desktop vendors, those are less 
of a concern with hybrid models, because the buyers have more of 
an option to fork the OSS core and go elsewhere.

> There is also inherent economical issue as such model 
> introduces huge gap between successful companies and contenders 
> (either you cover development losses and get any income on top 
> "for free" or you don't and go bankrupt) favoring creation of 
> monopolies.

This is utter nonsense.  There are very few "monopolies" in 
software, essentially none nowadays.  Even assuming your theory 
had some credence, you provide no reason why it would apply only 
to desktop products, especially given the equally strong service 
providers out there, like google in search.

> It isn't about "desktop" vs "server" but about "product" vs 
> "service".

None of the issues you mentioned apply only towards products but 
not to services.

>>> 2) We don't even sell plain service access - it is more 
>>> delicate than that, exactly to ensure that our client don't 
>>> feel like product hostages and get encouraged to try with no 
>>> big commitment. You can contact our sales department for more 
>>> details ;)
>>
>> You take money and create mostly closed-source software: those 
>> are the only details that matter in this discussion.
>
> Nope, this wasn't at all what I was talking about. My 
> objections is not as much against the fact patches are closed 
> but the fact that you propose to sell _patches_. I despise 
> copyright, not closed software.

Well, this is a unique concern, :) and I must say awfully 
convenient for you considering you create closed-source software 
that you run on a server, so you do not need copyright since you 
don't sell it to others to deploy.

I am not a fan of copyright myself, so for people like us, 
there's an easy way out.  The sellers of paid patches simply 
contract with the buyers not to release their builds/patches, 
voila, no copyright necessary!

> I am pretty sure company leadership won't me as radical as me 
> on this matter but so far our business model matches my 
> personal beliefs and that keeps me happy :)

Nice for you, but it doesn't change the fact that all the 
problems you raise with desktop closed-source software could also 
be raised with your closed-source services, ie you might force 
the consumer to pay more to upgrade and the same factors that 
lead to monopolies would apply to you.

>>> 3) There are indeed plans for open-sourcing at least base 
>>> libraries we use. It is taking very long because making 
>>> something public in a way that won't hit you back is damn 
>>> tricky legally these days and it is blocked in legal 
>>> department for quite a while. No announcement because no idea 
>>> how long may it take.
>>
>> Sociomantic has always been generous with the D community, I 
>> don't mean to imply you haven't.  But unless you open-source 
>> all your code, you're employing a hybrid closed-source model, 
>> exactly the kind of model you're objecting to here. :) Funny 
>> how it's good for Sociomantic but not anybody else.
>
> I hope earlier statements explain the difference.

They don't.

>>> Yes, I am much in favor of paying for actual effort and not 
>>> helping make money from nothing like it has happened with 
>>> Microsoft. It both more honest from the point of view of 
>>> commercial relations and motivates faster development by 
>>> paying exactly for stuff that matters. With your proposed 
>>> scheme best strategy is to hold off adding new stuff upstream 
>>> as long as possible to force more people buy it.
>>
>> Microsoft is an extreme example of product software, most 
>> software product companies didn't connive their way into a 
>> similar monopoly position.  Android is the product I keep 
>> using as an example, no "actual effort" there?
>
> It is hard to reason about Android business model. It is rather 
> complicated and partly so to ensure that vendors won't be 
> afraid of unfair competition from Google motivating ongoing 
> trust inside the ecosystem. I don't see any similarities with 
> your proposal despite the claims.

Your claim was that product software leads to situations like 
Microsoft.  I pointed out that Android is a very similar product, 
that happens to be hybrid-sourced instead, but it has not led to 
the same situation.  You dodged the question of whether their 
success was based on "actual effort."

As for the similarities with my proposal, they are essentially 
exactly the same.  Google provides an OSS core and a handful of 
hardware and software vendors customize it with proprietary 
patches and sell the resulting software, often bundled with 
hardware since it's an OS.  I'm suggesting that D devs do the 
same, sell paid patches on the OSS core compiler.  I'm not sure 
how you can miss the similarities.

The only difference is that all paid patches are eventually 
guaranteed to be open-sourced in my proposal, which is not the 
case with Android, a big improvement provided by my hybrid model.

>>> You won't get customers in the long term if they feel like 
>>> being extorted money. Your proposed scheme does exactly that.
>>
>> I see no arguments for why that would happen, simply bald 
>> statements with no real reasoning and seemingly ignoring the 
>> funding/time limits involved with my hybrid model.
>
> I see exactly the same from your side.

Heh, all the reasoning and arguments that I've filled this thread 
with put the lie to that claim.

> Fortunately you seem to be the only person for now that thinks 
> something like that even remotely makes sense and thus there is 
> no real value in trying to convince you. Because of that I'd 
> prefer to respectfully retire from the discussion.

Yes, I'm the only one who believes in hybrid models, not Google, 
Apple, Samsung, and all the other hybrid-source vendors out 
there.  You may be right that nobody else in the _D_ community 
sees the value, but engineers are notorious for being ignorant of 
business and economics, so nothing unusual if that's the case.

In any case, D's license allows it, so I'm sure somebody will try 
out a hybrid model with a D compiler someday, or D will be 
obsoleted by a language that does.