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.

Reply via email to