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.
