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.

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

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.

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

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

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

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

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

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

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

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.

> There are very few "monopolies" in software, essentially none nowadays.

:D :D :D :D :D

I have not laughed so hard for quite a while. Modern IT industry is absolutely dominated by monopolies / oligopolies.

Hard to reason with you if this is what you see.

On Sunday, 11 January 2015 at 16:13:01 UTC, Dicebot wrote:
>> There are very few "monopolies" in software, essentially none nowadays.
>
> :D :D :D :D :D
>
> I have not laughed so hard for quite a while. Modern IT industry is absolutely dominated by monopolies / oligopolies.
>
> Hard to reason with you if this is what you see.

You should really try to keep up to date with recent market share stats:

http://www.businessinsider.in/In-Case-You-Dont-Appreciate-How-Fast-The-Windows-Monopoly-Is-Getting-Destroyed-/articleshow/21123434.cms

On 11 January 2015 at 16:23, Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 11 January 2015 at 16:13:01 UTC, Dicebot wrote:
>>>
>>> There are very few "monopolies" in software, essentially none nowadays.
>>
>>
>> :D :D :D :D :D
>>
>> I have not laughed so hard for quite a while. Modern IT industry is absolutely dominated by monopolies / oligopolies.
>>
>> Hard to reason with you if this is what you see.
>
>
> You should really try to keep up to date with recent market share stats:
>
> http://www.businessinsider.in/In-Case-You-Dont-Appreciate-How-Fast-The-Windows-Monopoly-Is-Getting-Destroyed-/articleshow/21123434.cms

Why should Monopoly automatically mean Microsoft?  ;-)

On Sunday, 11 January 2015 at 16:02:59 UTC, Joakim wrote:
> 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.

Yeah, it seems to be a big deal. D may end up needing what it doesn't appear to have: some business genius to go along with its language design prowess. The "switching costs" are far too high right now. Even the ideal programming language could only be so much better than what already exists. I'm not a marketing expert (well, perhaps ipso facto), but I think that in order to prosper in the current climate D needs a better brand. "Modern convenience. Modeling power. Native efficiency."...  isn't good enough. Not to disparage the effort that went into creating that slogan, but for one thing, it's not even honest, insofar as D does not yet provide modern convenience, as Manu Evans has so dishearteningly pointed out. (It's becoming painfully obvious that convenience is absolutely not about language - it's about ecosystem, and D simply doesn't have that yet.)

The most important thing about a brand is that you know who you are. D still doesn't know what it is yet, and so it hasn't found the need to create a brand that matches that identity.

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

I'm not managing a huge codebase, so I have nothing to lose by sticking with D!

On Sunday, 11 January 2015 at 19:27:15 UTC, Iain Buclaw via Digitalmars-d wrote:
> On 11 January 2015 at 16:23, Joakim via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Sunday, 11 January 2015 at 16:13:01 UTC, Dicebot wrote:
>>>>
>>>> There are very few "monopolies" in software, essentially none nowadays.
>>>
>>>
>>> :D :D :D :D :D
>>>
>>> I have not laughed so hard for quite a while. Modern IT industry is
>>> absolutely dominated by monopolies / oligopolies.
>>>
>>> Hard to reason with you if this is what you see.
>>
>>
>> You should really try to keep up to date with recent market share stats:
>>
>> http://www.businessinsider.in/In-Case-You-Dont-Appreciate-How-Fast-The-Windows-Monopoly-Is-Getting-Destroyed-/articleshow/21123434.cms
>
> Why should Monopoly automatically mean Microsoft?  ;-)

It doesn't, it's just the only company he mentioned and the one most think of.  If you have another in mind, feel free to mention it.

On Monday, 12 January 2015 at 04:17:11 UTC, Zach the Mystic wrote:
> On Sunday, 11 January 2015 at 16:02:59 UTC, Joakim wrote:
>> 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.
>
> Yeah, it seems to be a big deal. D may end up needing what it doesn't appear to have: some business genius to go along with its language design prowess. The "switching costs" are far too high right now. Even the ideal programming language could only be so much better than what already exists.

I don't know about "genius," simply a small to mid-sized company like Embarcadero that's willing to invest into putting 10-20 paid devs on producing and selling a polished compiler/runtime/stdlib would do.

I disagree that the ideal programming language would "only be so much better:" we can do a _lot_ better than C++ and all its legacy issues.  D certainly makes a stab at it, but is missing good commercial implementations like C++ has.

> I'm not a marketing expert (well, perhaps ipso facto), but I think that in order to prosper in the current climate D needs a better brand. "Modern convenience. Modeling power. Native efficiency."...  isn't good enough. Not to disparage the effort that went into creating that slogan, but for one thing, it's not even honest, insofar as D does not yet provide modern convenience, as Manu Evans has so dishearteningly pointed out. (It's becoming painfully obvious that convenience is absolutely not about language - it's about ecosystem, and D simply doesn't have that yet.)

I don't have a problem with the brand.  D is convenient enough for me in terms of features, though I certainly don't push it as far as Manu does.  As for the library ecosystem, that's always a slog to bootstrap for any new language.

> The most important thing about a brand is that you know who you are. D still doesn't know what it is yet, and so it hasn't found the need to create a brand that matches that identity.

I'd argue that D knows what it is by now, but doesn't know how to get it done, ie a volunteer project won't make any headway against C++.

>> 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.
>
> I'm not managing a huge codebase, so I have nothing to lose by sticking with D!

Nor am I, I have no problem tinkering with a hobby language like D in my spare time.

On Monday, 12 January 2015 at 05:02:36 UTC, Joakim wrote:
>> Yeah, it seems to be a big deal. D may end up needing what it doesn't appear to have: some business genius to go along with its language design prowess. The "switching costs" are far too high right now. Even the ideal programming language could only be so much better than what already exists.
>
> I don't know about "genius," simply a small to mid-sized company like Embarcadero that's willing to invest into putting 10-20 paid devs on producing and selling a polished compiler/runtime/stdlib would do.

I'm saying that assembling and funding such a team will require some business genius at this point. Maybe Sociomantic will provide, a couple years from now, when Dicebot and others are finished porting their codebase? But seriously, let's keep the question simple. How do you get to that 10-20 dev team? Who wants D that bad, and is willing to suffer the capital investment? I don't want to sound negative, but it strikes me as a *really* hard sell.

>> I'm not a marketing expert (well, perhaps ipso facto), but I think that in order to prosper in the current climate D needs a better brand. "Modern convenience. Modeling power. Native efficiency."...  isn't good enough. Not to disparage the effort that went into creating that slogan, but for one thing, it's not even honest, insofar as D does not yet provide modern convenience, as Manu Evans has so dishearteningly pointed out. (It's becoming painfully obvious that convenience is absolutely not about language - it's about ecosystem, and D simply doesn't have that yet.)
>
> I don't have a problem with the brand.  D is convenient enough for me in terms of features, though I certainly don't push it as far as Manu does.  As for the library ecosystem, that's always a slog to bootstrap for any new language.

A newbie goes to the front page of dlang.org, tries D and has the kind of experience Manu recently lamented with his own team. Modern convenience? It's false advertising. It's not knowing who you are. It doesn't how matter much anybody *wants* D to be convenient. Modern convenience would be a gamer changer, absolutely, if we had it. But it's about infrastructure - that's what convenience *is*. Convenience is not about core product. What the slogan is saying is completely different from what D's leaders think it's saying. It's saying that D is for language geeks who know how to bypass all lack of modern convenience. It's saying that D is for people who think convenience is only about language and not infrastructure, documentation, and tooling, i.e. language geeks - people who love to try new languages and will put up with lack of everything else, etc. - perhaps 10% of programmers. I'm not saying D really *is* for language geeks. I'm saying that's what D is *saying* it is, *without even knowing it*.

Convenience, to me, is one-click downloading from the home page, one click installation, and full IDE support akin to what Apple, Microsoft and any other behemoth has done for their language. The language has nothing to do with it. D can't even remotely compete with these languages in terms of convenience. It needs a new slogan, and it can't get one until it knows what it is. Here's a suggestion: "A Language for Programmers". It would obviously need to be vetted by the big wigs, but from my perspective, it's already a real brand without any extra work. I wonder if they'll agree with me?

On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
> This is an idea I've been kicking around for a while, and given the need for commercial support for D, would perhaps work well here.
>
> [...]

By the way, in case you are interested in this path personally still, I'd be willing to pay for D support, tuition, help with getting stuck, code review etc for colleagues. Not for patches that aren't immediately open sourced, but we fixed windows paths on DMD for example, and there might be scope for occasional paid work on dmd and dub like that.  Also porting headers.

On Monday, 12 January 2015 at 06:30:20 UTC, Zach the Mystic wrote:
> Convenience, to me, is one-click downloading from the home page, one click installation, and full IDE support akin to what Apple, Microsoft and any other behemoth has done for their language. The language has nothing to do with it. D can't even remotely compete with these languages in terms of convenience. It needs a new slogan, and it can't get one until it knows what it is. Here's a suggestion: "A Language for Programmers". It would obviously need to be vetted by the big wigs, but from my perspective, it's already a real brand without any extra work. I wonder if they'll agree with me?


pgModeler (for postgres) sells the binaries for a small price.
The source code is GPL so it is available in linux distributions.


https://www.pgmodeler.com.br/


Text from their website:

"pgModeler is an open source software and you can get its source code anytime if you want to compile it for yourself. As a facility, we provide compiled binary packages at a really small price. Also, if you're interested in evaluate a binary package, you can get a demo copy before proceed with the purchase. Since this is an independent project by purchasing any binary package you'll help to keep its development alive and at full speed! "

There you go, full speed.