Re: An idea for commercial support for D

[psychoticRabbit via Digitalmars-d]

On Sunday, 4 February 2018 at 08:26:54 UTC, Joakim wrote:
I think you're missing the point entirely: _this is the model 
that the community uses to undermine the corporations_.


I really do think it's the other way around - indeed, it is 
probably too late - as corporations have *already* managed to 
highjack 'open source' for their own means.


Google is probably the best at doing it - having essentially 
highjacked the linux kernel, as well as deploying a variety of 
their own so-called 'open source' projects, in order to push its 
corporate agenda onto an unsuspecting world.


http://firstmonday.org/ojs/index.php/fm/article/view/4050/3271

Facebook does it pretty well too.

Microsoft is still 'working it out', cause they're model of doing 
business came about in very different times ... but they'll 
figure it out soon enough.


And people complain about GPL being viral ... just have a look at 
corporate agenda - which is only ever about dominance and control 
(despite its deceptive rhetoric).


That's why I like D - because corporations haven't yet worked out 
how to highjack it for their own agenda - 'yet' being a keyword.


But some ideas presented in this thread will get them started on 
it, no doubt ;-)

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 2 February 2018 at 11:21, Joakim via Digitalmars-d
 wrote:
> On Friday, 2 February 2018 at 09:26:51 UTC, Iain Buclaw wrote:
>>
>> On 31 January 2018 at 09:43, Joakim via Digitalmars-d
>>  wrote:
>>>
>>> I'm sure you can find much better D devs to contribute such work by
>>> posting bounties on the D or ldc bountysource pages:
>>>
>>> https://www.bountysource.com/teams/d
>>> https://www.bountysource.com/teams/ldc-developers
>>>
>>
>> I was surprised to see a gdc bounty page.  I was even more surprised that
>> the one notable bounty is an issue that's either blocked by Walter, or
>> waiting on someone to implement array op templates in druntume/object.d. :-)
>
>
> Heh, the lead gdc dev doesn't know that gdc bounties exist, not sure I could
> have made my case for their being hidden any better. :)
>
> On Friday, 2 February 2018 at 09:30:08 UTC, Iain Buclaw wrote:
>>
>> I'm reminded of airlines who have a "Priority" or "Privileged" queuing
>> system at the gate.  If you didn't want to wait in line to board, then you
>> should have paid up.
>>
>> Not sure if any parallels ring with you here. :-)
>
>
> Any system that requires payment can be superficially compared to any other,
> but the real salient point here is the discrepancy: to even get on the
> flight, you have to pay for a ticket, whereas he paid nothing for the
> open-source sections of a mixed codebase.  So, he's more like a guy who
> shows up at the gate without a ticket _and_ barges into the Priority queue,
> which is a sure way to get thrown out of the airport altogether. :D
>

The up-front cost to get yourself on the plane is irrelevant, you
could even think of it as a baseline cost that everyone pays to get
themselves there (OSS software has a cost, even though package is
free, someone's got to spend time on your money building/setting it
up).

Maybe it's just the British culture that I have firmly ingrained
inside. Ranting about queuing just comes more naturally, as its what
we do best. To undermine the queuing system is to undermine the
national way of life. :-)

Granted, there's not many great things that can be said about a
first-come, first-serve system - and in OSS projects, the meritocratic
communities do give sense to that we operate in such a fashion when it
comes to ownership of the code base, or fixing long-standing issues.
i.e: I arrived first as a contributor, therefore my opinion against
outranks your opinion for (this is a irrationally negative example,
however).


> And I have no problem with priority queues, baggage fees, etc., as the
> reason they charge for those is to _lower_ the ticket price for the cheapest
> consumer, a concept called price discrimination (and before I get the usual
> nonsense about how that's illegal, or it should be, it isn't and it
> shouldn't):
>
> https://en.m.wikipedia.org/wiki/Price_discrimination
>
> So I pay less for my cheap flights, while others who want to lug a ton of
> suitcases or get through the line faster pay more, which is only fair.
>

Fair enough. Me, I am frankly more disturbed by a money-talks culture
that gives preferential treatment to the highest bidder over the hoi
polloi. :-)

Re: An idea for commercial support for D

[psychoticRabbit via Digitalmars-d]

On Sunday, 4 February 2018 at 08:26:54 UTC, Joakim wrote:


I don't think it affects them much, as none of the motivations 
above would be hurt by paid contributors.  If anything, it 
_increases_ their drive, as they have a lot more OSS code to 
work on with mixed codebases.




Well, it's not clear cut, that is for sure, but, I remain 
concerned that this increasing move towards monetary 
contributions for participating in open source communities, will 
result in fewer contributors (i.e the more time a person has to 
dedicate, the more skilled they are, the more likely they'll be 
the one being paid - leaving all those other contributers at the 
mercy of the contributions from those paid contributors. Then the 
'community' aspect of open source is lost.


Sure, you can distrubute the same poison that corporations drink, 
and give it to the masses..  but guess what will happen... in the 
long run that is.


I would prefer to see a future where money was NOT the primary 
motivating force...  - because that is how open source 
communities came about, in the first place.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Sunday, 4 February 2018 at 02:15:32 UTC, psychoticRabbit wrote:

On Saturday, 3 February 2018 at 13:14:04 UTC, rjframe wrote:


Except it doesn't. The GPL can be used to keep a competitor 
from stepping up and using your work to create an alternative 
product, allowing you to have a mixed open/closed model 
without worrying about competition.


Many companies that have commercial and open source editions 
use the GPL for the open source code; if you submit a patch 
you also have to assign copyright (or maybe unrestricted right 
of use) to that company. Any would- be competitor would always 
lag behind the copyright-holding corp because they have to 
release all features they develop if they distribute the 
application, and the copyright holder is free to take any such 
work into their own product.


I don't understand the legalities of various forms of licencing.

I do understand (to some extent) human motivation.

"Why would any particular person choose to contribute -- 
voluntarily -- to a public good that he or she can partake of 
unchecked as a free-rider?"


And yet people do (contribute -- voluntarily). Why is that?


Many OSS volunteers like to tinker, look at all the people that 
hack their Xbox or iPhone, ie even closed systems.  Others take 
an OSS tool that is almost good enough for their needs and add a 
little more to it till it is: that's what I did when I ported D 
to Android.  There are a few for whom OSS is a religious quest, 
they work on OSS because they believe it's a moral imperative, ie 
those such as Stallman.


I think that these so called hybrid models undermine the 
aligned interests of such people, and instead move people's 
incentive to contibute, back towards monetary compensation.


I don't think it affects them much, as none of the motivations 
above would be hurt by paid contributors.  If anything, it 
_increases_ their drive, as they have a lot more OSS code to work 
on with mixed codebases.


There may well be some positive effect arising from these 
hybrid models, but I am concerned about the negative effects of 
these hybrid models, on such communities - particulary those 
they don't have funds.


There may be some negative effects in a few cases, as you say, 
for example, those who felt obligated to work on an OSS project 
that they valued but wasn't getting much contribution may back 
off once it's getting a lot of corporate-funded OSS patches, 
since they may not feel as needed.  However, that's a great 
problem to have, as it's only because there's a lot of work 
already being done, ie the positive effects way outweigh the 
negatives.


Is this the model corporations (or those with money) will use 
to undermine those communities?


I think you're missing the point entirely: _this is the model 
that the community uses to undermine the corporations_.  I 
alluded to this in my first post and went into it more in another 
post later in this thread, but didn't go too far down that road, 
as it's a second-order effect.


Open-source mixing like this allowed plucky startups like Next in 
the '90s and google in the '00s to build operating systems, 
macOS/iOS and Android, that competed with and demolished the 
former corporate giants.  New startups use OSS all the time now 
to do the same to Apple and Google.  We're heading towards a 
future where the corporation itself is obsoleted, this mixed 
model helps get us there.

Re: An idea for commercial support for D

[psychoticRabbit via Digitalmars-d]

On Saturday, 3 February 2018 at 13:14:04 UTC, rjframe wrote:


Except it doesn't. The GPL can be used to keep a competitor 
from stepping up and using your work to create an alternative 
product, allowing you to have a mixed open/closed model without 
worrying about competition.


Many companies that have commercial and open source editions 
use the GPL for the open source code; if you submit a patch you 
also have to assign copyright (or maybe unrestricted right of 
use) to that company. Any would- be competitor would always lag 
behind the copyright-holding corp because they have to release 
all features they develop if they distribute the application, 
and the copyright holder is free to take any such work into 
their own product.


I don't understand the legalities of various forms of licencing.

I do understand (to some extent) human motivation.

"Why would any particular person choose to contribute -- 
voluntarily -- to a public good that he or she can partake of 
unchecked as a free-rider?"


And yet people do (contribute -- voluntarily). Why is that?

I think that these so called hybrid models undermine the aligned 
interests of such people, and instead move people's incentive to 
contibute, back towards monetary compensation.


There may well be some positive effect arising from these hybrid 
models, but I am concerned about the negative effects of these 
hybrid models, on such communities - particulary those they don't 
have funds.


Is this the model corporations (or those with money) will use to 
undermine those communities?

Re: An idea for commercial support for D

[rjframe via Digitalmars-d]

On Sat, 03 Feb 2018 12:08:21 +, psychoticRabbit wrote:

> On Saturday, 3 February 2018 at 10:49:06 UTC, Joakim wrote:
>> And what we find is that when you allow such mixing with
>> permissively-licensed projects (that the GPL makes much more
>> difficult), .
> 
> I've never been a fan of the GPL.. until I read this thread.
> 
> It may well be, that more and more people will look towards the GPL as a
> means to protect their projects from the influence (and potential
> dangers) of this 'hybrid' model.

Except it doesn't. The GPL can be used to keep a competitor from stepping 
up and using your work to create an alternative product, allowing you to 
have a mixed open/closed model without worrying about competition.

Many companies that have commercial and open source editions use the GPL 
for the open source code; if you submit a patch you also have to assign 
copyright (or maybe unrestricted right of use) to that company. Any would-
be competitor would always lag behind the copyright-holding corp because 
they have to release all features they develop if they distribute the 
application, and the copyright holder is free to take any such work into 
their own product.

Re: An idea for commercial support for D

[psychoticRabbit via Digitalmars-d]

On Saturday, 3 February 2018 at 10:49:06 UTC, Joakim wrote:
And what we find is that when you allow such mixing with 
permissively-licensed projects (that the GPL makes much more 
difficult), .


I've never been a fan of the GPL.. until I read this thread.

It may well be, that more and more people will look towards the 
GPL as a means to protect their projects from the influence (and 
potential dangers) of this 'hybrid' model.


In any case, I do believe in people having the freedom to make 
their own choices - so I am ok with any model really, providing I 
have a model that suits (and protects) my needs, goals, and 
values.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 2 February 2018 at 13:48:12 UTC, psychotic Rabbit 
wrote:

On Friday, 2 February 2018 at 10:21:35 UTC, Joakim wrote:
I can't be bothered to strain through your tortured analogies 
that make no sense and explain to you all the ways you're 
wrong.  I'm respecting you enough to point out that none of 
your points make any sense, most would just ignore crazy 
analogies like this and move on, content to let you stew in 
this nonsense.


Well, that sure is an interesting way of responding to 
criticism.


By giving up, you've made your argument ever weaker that it was 
before.


But all power to you..and you're hybrid 'ransom the open source 
community' model ...just don't work on my projects, unless your 
contribution is free.


When you start by calling the dominant mixed licensing model, or 
at least my twist on it, "offensive," frankly a bizzare claim, 
you don't inspire confidence that you're actually looking for a 
discussion.  However, I liked a comment you made in another 
thread about why people should use D, which showed some insight, 
so I will respond a bit.


In most any open source community today, there are people who 
volunteer contributions and those who get paid to write 
open-source or sometimes even closed-source patches, particularly 
for mixed projects like Android or llvm.  In other words, it's 
already a mix of people volunteering work for free and those 
getting paid, and we don't see the breakdown you posit.  The fact 
is that some people are fine with volunteering and most aren't, 
as the vast majority of lines of source code written is 
closed-source, so mixing the two works just fine.


As for your lawn mower analogy, the difference is you don't own 
this lawn mower, the open-source code.  It is a shared resource, 
that anybody can do what they want with, especially for the 
non-GPL code that I mentioned in my article.  So building 
proprietary modules on an OSS codebase is more like building your 
own bricks-and-mortar store on your private land alongside a 
public road, something people have been doing for millenia.  OSS 
code works much better for this than any road, because you can 
copy it a million times at basically no cost, whereas only a 
couple dozen stores can be built alongside a road.


And what we find is that when you allow such mixing with 
permissively-licensed projects (that the GPL makes much more 
difficult), as we see with those using mixed models in the 
popular permissively-licensed projects I mentioned above, you can 
fund a _lot_ more development even on the OSS core, which is why 
Android is now the dominant operating system on the planet.


This experiment has been run over the last decade: mixed models 
have won.  That is why I think D should follow suit, leading such 
mixed use for programming languages too.

Re: An idea for commercial support for D

[psychotic Rabbit via Digitalmars-d]

On Friday, 2 February 2018 at 10:21:35 UTC, Joakim wrote:
I can't be bothered to strain through your tortured analogies 
that make no sense and explain to you all the ways you're 
wrong.  I'm respecting you enough to point out that none of 
your points make any sense, most would just ignore crazy 
analogies like this and move on, content to let you stew in 
this nonsense.


Well, that sure is an interesting way of responding to criticism.

By giving up, you've made your argument ever weaker that it was 
before.


But all power to you..and you're hybrid 'ransom the open source 
community' model ...just don't work on my projects, unless your 
contribution is free.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 2 February 2018 at 09:26:51 UTC, Iain Buclaw wrote:
On 31 January 2018 at 09:43, Joakim via Digitalmars-d 
 wrote:
I'm sure you can find much better D devs to contribute such 
work by posting bounties on the D or ldc bountysource pages:


https://www.bountysource.com/teams/d 
https://www.bountysource.com/teams/ldc-developers




I was surprised to see a gdc bounty page.  I was even more 
surprised that the one notable bounty is an issue that's either 
blocked by Walter, or waiting on someone to implement array op 
templates in druntume/object.d. :-)


Heh, the lead gdc dev doesn't know that gdc bounties exist, not 
sure I could have made my case for their being hidden any better. 
:)


On Friday, 2 February 2018 at 09:30:08 UTC, Iain Buclaw wrote:
I'm reminded of airlines who have a "Priority" or "Privileged" 
queuing system at the gate.  If you didn't want to wait in line 
to board, then you should have paid up.


Not sure if any parallels ring with you here. :-)


Any system that requires payment can be superficially compared to 
any other, but the real salient point here is the discrepancy: to 
even get on the flight, you have to pay for a ticket, whereas he 
paid nothing for the open-source sections of a mixed codebase.  
So, he's more like a guy who shows up at the gate without a 
ticket _and_ barges into the Priority queue, which is a sure way 
to get thrown out of the airport altogether. :D


And I have no problem with priority queues, baggage fees, etc., 
as the reason they charge for those is to _lower_ the ticket 
price for the cheapest consumer, a concept called price 
discrimination (and before I get the usual nonsense about how 
that's illegal, or it should be, it isn't and it shouldn't):


https://en.m.wikipedia.org/wiki/Price_discrimination

So I pay less for my cheap flights, while others who want to lug 
a ton of suitcases or get through the line faster pay more, which 
is only fair.


On Friday, 2 February 2018 at 09:50:32 UTC, psychoticRabbit wrote:

On Friday, 2 February 2018 at 08:56:04 UTC, Joakim wrote:


So given that all your claims are easily logically proven to 
be nonsense, there's no point in going any further.


You need to do better than that to convince me ;-)


I wasn't trying to convince you.  I pointed out that your 
statements were a mess of logical contradictions and suggested 
that we stop there.


Now.. I might entertain a model of paying someone, *after* they 
had committed there fix back to the community, as open source 
(and the fix has been formely approved and confirmed) - but 
certainly not beforehand.


But even that really worries me, as people may then refuse to 
contribute unless they know they're going to get paid. And, it 
assumes that people in that open source community project have 
the means to pay them. What happens to that open source 
community when the funds are not there?? Do the developers just 
go off and look for other projects that do have funds, like 
they were 'bounty' hunters. Is that the future we should be 
creating?


Your so called hybrid model, is like my neighbour borrowing my 
lawn mower, and while he's got it, he notices it needs an oil 
change, does the oil change, and then refuses to give me back 
the lawn mower till I've reimbursed him. But he never paid for 
the lawn mower did he??


Well.. my neigbour says, if you can't pay me for the oil, then 
I'll take the new oil out, put the old oil back in, and then 
you can have your lawn mower back.


I don't want neighbours like that.


I can't be bothered to strain through your tortured analogies 
that make no sense and explain to you all the ways you're wrong.  
I'm respecting you enough to point out that none of your points 
make any sense, most would just ignore crazy analogies like this 
and move on, content to let you stew in this nonsense.

Re: An idea for commercial support for D

[psychoticRabbit via Digitalmars-d]

On Friday, 2 February 2018 at 08:56:04 UTC, Joakim wrote:


So given that all your claims are easily logically proven to be 
nonsense, there's no point in going any further.


You need to do better than that to convince me ;-)

Now.. I might entertain a model of paying someone, *after* they 
had committed there fix back to the community, as open source 
(and the fix has been formely approved and confirmed) - but 
certainly not beforehand.


But even that really worries me, as people may then refuse to 
contribute unless they know they're going to get paid. And, it 
assumes that people in that open source community project have 
the means to pay them. What happens to that open source community 
when the funds are not there?? Do the developers just go off and 
look for other projects that do have funds, like they were 
'bounty' hunters. Is that the future we should be creating?


Your so called hybrid model, is like my neighbour borrowing my 
lawn mower, and while he's got it, he notices it needs an oil 
change, does the oil change, and then refuses to give me back the 
lawn mower till I've reimbursed him. But he never paid for the 
lawn mower did he??


Well.. my neigbour says, if you can't pay me for the oil, then 
I'll take the new oil out, put the old oil back in, and then you 
can have your lawn mower back.


I don't want neighbours like that.

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 2 February 2018 at 09:56, Joakim via Digitalmars-d
 wrote:
> On Friday, 2 February 2018 at 02:04:07 UTC, psychoticRabbit wrote:
>>
>> On Wednesday, 31 January 2018 at 08:43:46 UTC, Joakim wrote:
>>>
>>> ...
>>>
>>> My time-limited model makes sure all source is made open eventually, once
>>> the developers have been paid for their work.
>>>
>>
>> This deceptive hybrid model (based I my understanding of it per the
>> description above) is really offensive to those of us who understand the
>> concept of open-source, and the benefits that flow from it.
>>
>> You (not you personally - I mean the person implementing such a hybrid
>> model) lure people in with free open source, then, when something is found
>> to be wrong with it, you make them wait for the fix.. until.. .. .. your
>> ransom has been paid.
>>
>> Utterly offensive (the model that is).
>>
>> Open source means just that ...  Open source - It's turtles all the way
>> down.
>>
>> Ransom-ware is something very different.
>
>
> Except it's none of those things, as you yourself grasp that it's a "hybrid
> model," ie not purely open source.  So it cannot be deceptive, offensive, or
> ransom-ware, since it's perfectly clear that it's its own thing.  And that
> mixed model is pretty much the way all software is built these days,
> including the linux kernel as mentioned earlier in this thread, so you are
> clearly using such mixed software too, just by the fact that you posted in
> this thread.
>
> So given that all your claims are easily logically proven to be nonsense,
> there's no point in going any further.

I'm reminded of airlines who have a "Priority" or "Privileged" queuing
system at the gate.  If you didn't want to wait in line to board, then
you should have paid up.

Not sure if any parallels ring with you here. :-)

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 31 January 2018 at 09:43, Joakim via Digitalmars-d
 wrote:
> On Tuesday, 30 January 2018 at 19:45:51 UTC, Laeeth Isharc wrote:
>>
>> 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.
>
>
> I appreciate the offer, but I'm not looking for paying work on the D
> language.  I understand the assumption most make that I'm looking to make
> money off the D language itself by pushing this commercial model, but I'm
> actually not interested in developing language-related software like
> compilers, tooling, or the standard library, even if paid for it.  I got
> stuck porting much of those D tools for Android, but it's a one-time
> excursion for me.
>
> What I'm actually interested in is using D to make commercial Android apps,
> and while I think D is a great language already, I think it could be made
> better by using this commercial model I've sketched out.  And the better D
> is, obviously the better any commercial apps I develop with it.
>
> Back when I first wrote about mixing open and closed source like this in my
> 2010 Phoronix article, nobody considered it a world-beating model.  Maybe
> people now assume I'm just keying these ideas off the success of Android in
> using a similar mixed model, but my article was published when Android had
> only single-digit market share so I hardly paid attention to it, as it was
> only one of a gaggle of mobile OS's competing at the time:
>
> https://en.m.wikipedia.org/wiki/Android_(operating_system)#Market_share
>
> While I had heard of a few companies using similar mixed models here and
> there, none were that successful back then, so my article was based mostly
> on theory.  I think the evidence since then has proven that theory
> resoundingly accurate, given all the huge projects, such as Android, iOS,
> Safari, Chrome, LLVM/clang, using mixed models now.  Even Microsoft, who
> used to look askance at open source, has gotten in the game, open-sourcing
> .NET and several of their other projects.
>
> In my article, I added another elaboration where even closed-source patches
> are eventually open-sourced, which I still believe to be the endgame of how
> this market eventually develops, even though AFAIK I'm still the only person
> that ever used that time-limited model on an actual project, which is
> mentioned in the article's prologue.  Such open-sourcing happens in an
> ad-hoc manner right now, where a company will develop a proprietary module
> for a mixed codebase and then eventually open-source it if they feel like
> it:
>
> http://www.brianmadden.com/opinion/Samsung-contributes-KNOX-to-Android-Open-Source-Project-Is-this-the-end-of-Android-Fragmentation
>
> My time-limited model makes sure all source is made open eventually, once
> the developers have been paid for their work.
>
> As for the other paid work you mention, I'm actually not a very experienced
> D dev, probably about intermediate level.  I did take some assembly language
> programming classes back in my college days decades ago, so I was able to
> figure out the low-level details needed to get D working on Android.
>
> I'm sure you can find much better D devs to contribute such work by posting
> bounties on the D or ldc bountysource pages:
>
> https://www.bountysource.com/teams/d
> https://www.bountysource.com/teams/ldc-developers
>

I was surprised to see a gdc bounty page.  I was even more surprised
that the one notable bounty is an issue that's either blocked by
Walter, or waiting on someone to implement array op templates in
druntume/object.d. :-)

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 2 February 2018 at 02:04:07 UTC, psychoticRabbit wrote:

On Wednesday, 31 January 2018 at 08:43:46 UTC, Joakim wrote:

...

My time-limited model makes sure all source is made open 
eventually, once the developers have been paid for their work.




This deceptive hybrid model (based I my understanding of it per 
the description above) is really offensive to those of us who 
understand the concept of open-source, and the benefits that 
flow from it.


You (not you personally - I mean the person implementing such a 
hybrid model) lure people in with free open source, then, when 
something is found to be wrong with it, you make them wait for 
the fix.. until.. .. .. your ransom has been paid.


Utterly offensive (the model that is).

Open source means just that ...  Open source - It's turtles all 
the way down.


Ransom-ware is something very different.


Except it's none of those things, as you yourself grasp that it's 
a "hybrid model," ie not purely open source.  So it cannot be 
deceptive, offensive, or ransom-ware, since it's perfectly clear 
that it's its own thing.  And that mixed model is pretty much the 
way all software is built these days, including the linux kernel 
as mentioned earlier in this thread, so you are clearly using 
such mixed software too, just by the fact that you posted in this 
thread.


So given that all your claims are easily logically proven to be 
nonsense, there's no point in going any further.

Re: An idea for commercial support for D

[psychoticRabbit via Digitalmars-d]

On Wednesday, 31 January 2018 at 08:43:46 UTC, Joakim wrote:

...

My time-limited model makes sure all source is made open 
eventually, once the developers have been paid for their work.




This deceptive hybrid model (based I my understanding of it per 
the description above) is really offensive to those of us who 
understand the concept of open-source, and the benefits that flow 
from it.


You (not you personally - I mean the person implementing such a 
hybrid model) lure people in with free open source, then, when 
something is found to be wrong with it, you make them wait for 
the fix.. until.. .. .. your ransom has been paid.


Utterly offensive (the model that is).

Open source means just that ...  Open source - It's turtles all 
the way down.


Ransom-ware is something very different.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Thursday, 1 February 2018 at 20:52:43 UTC, Jacob Carlborg 
wrote:

On 2018-01-31 09:43, Joakim wrote:

Back when I first wrote about mixing open and closed source 
like this in
my 2010 Phoronix article, nobody considered it a world-beating 
model.
Maybe people now assume I'm just keying these ideas off the 
success of
Android in using a similar mixed model, but my article was 
published
when Android had only single-digit market share so I hardly 
paid
attention to it, as it was only one of a gaggle of mobile OS's 
competing

at the time:

https://en.m.wikipedia.org/wiki/Android_(operating_system)#Market_share

While I had heard of a few companies using similar mixed 
models here and
there, none were that successful back then, so my article was 
based
mostly on theory.  I think the evidence since then has proven 
that
theory resoundingly accurate, given all the huge projects, 
such as
Android, iOS, Safari, Chrome, LLVM/clang, using mixed models 
now.  Even
Microsoft, who used to look askance at open source, has gotten 
in the

game, open-sourcing .NET and several of their other projects.


Apple has been using a mix of open and closed source for 
decades. The source code for all versions of macOS, back to the 
first one, is available here [1].


[1] https://opensource.apple.com


I know, I was aware of it, but I wouldn't call OS X's 
single-digit market share or iOS's 16% market share in 2009 "that 
successful:"


https://www.canalys.com/newsroom/google’s-android-becomes-world’s-leading-smart-phone-platform

Also, they were notorious for having a mostly closed tech stack, 
and not getting almost any outside contribution to the OSS 
portions.

Re: An idea for commercial support for D

[Jacob Carlborg via Digitalmars-d]

On 2018-01-31 09:43, Joakim wrote:


Back when I first wrote about mixing open and closed source like this in
my 2010 Phoronix article, nobody considered it a world-beating model.
Maybe people now assume I'm just keying these ideas off the success of
Android in using a similar mixed model, but my article was published
when Android had only single-digit market share so I hardly paid
attention to it, as it was only one of a gaggle of mobile OS's competing
at the time:

https://en.m.wikipedia.org/wiki/Android_(operating_system)#Market_share

While I had heard of a few companies using similar mixed models here and
there, none were that successful back then, so my article was based
mostly on theory.  I think the evidence since then has proven that
theory resoundingly accurate, given all the huge projects, such as
Android, iOS, Safari, Chrome, LLVM/clang, using mixed models now.  Even
Microsoft, who used to look askance at open source, has gotten in the
game, open-sourcing .NET and several of their other projects.


Apple has been using a mix of open and closed source for decades. The 
source code for all versions of macOS, back to the first one, is 
available here [1].


[1] https://opensource.apple.com

--
/Jacob Carlborg

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 30 January 2018 at 19:45:51 UTC, Laeeth Isharc wrote:

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.


I appreciate the offer, but I'm not looking for paying work on 
the D language.  I understand the assumption most make that I'm 
looking to make money off the D language itself by pushing this 
commercial model, but I'm actually not interested in developing 
language-related software like compilers, tooling, or the 
standard library, even if paid for it.  I got stuck porting much 
of those D tools for Android, but it's a one-time excursion for 
me.


What I'm actually interested in is using D to make commercial 
Android apps, and while I think D is a great language already, I 
think it could be made better by using this commercial model I've 
sketched out.  And the better D is, obviously the better any 
commercial apps I develop with it.


Back when I first wrote about mixing open and closed source like 
this in my 2010 Phoronix article, nobody considered it a 
world-beating model.  Maybe people now assume I'm just keying 
these ideas off the success of Android in using a similar mixed 
model, but my article was published when Android had only 
single-digit market share so I hardly paid attention to it, as it 
was only one of a gaggle of mobile OS's competing at the time:


https://en.m.wikipedia.org/wiki/Android_(operating_system)#Market_share

While I had heard of a few companies using similar mixed models 
here and there, none were that successful back then, so my 
article was based mostly on theory.  I think the evidence since 
then has proven that theory resoundingly accurate, given all the 
huge projects, such as Android, iOS, Safari, Chrome, LLVM/clang, 
using mixed models now.  Even Microsoft, who used to look askance 
at open source, has gotten in the game, open-sourcing .NET and 
several of their other projects.


In my article, I added another elaboration where even 
closed-source patches are eventually open-sourced, which I still 
believe to be the endgame of how this market eventually develops, 
even though AFAIK I'm still the only person that ever used that 
time-limited model on an actual project, which is mentioned in 
the article's prologue.  Such open-sourcing happens in an ad-hoc 
manner right now, where a company will develop a proprietary 
module for a mixed codebase and then eventually open-source it if 
they feel like it:


http://www.brianmadden.com/opinion/Samsung-contributes-KNOX-to-Android-Open-Source-Project-Is-this-the-end-of-Android-Fragmentation

My time-limited model makes sure all source is made open 
eventually, once the developers have been paid for their work.


As for the other paid work you mention, I'm actually not a very 
experienced D dev, probably about intermediate level.  I did take 
some assembly language programming classes back in my college 
days decades ago, so I was able to figure out the low-level 
details needed to get D working on Android.


I'm sure you can find much better D devs to contribute such work 
by posting bounties on the D or ldc bountysource pages:


https://www.bountysource.com/teams/d
https://www.bountysource.com/teams/ldc-developers

I now see you posted some recurring funding on that first page, 
would be better if you allocated it to issues you actually need, 
as I'm not sure how such recurring funding is even allocated.


You may need to cross-post the backed issues here in the forum 
once in a while to publicize them, as I don't think many are 
aware that those bounties even exist, as we don't link them on 
the front page like some other languages do.

Re: An idea for commercial support for D

[sclytrack via Digitalmars-d]

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.

Re: An idea for commercial support for D

[Laeeth Isharc via Digitalmars-d]

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.

Re: An idea for commercial support for D

[Dicebot via Digitalmars-d]

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 

Re: An idea for commercial support for D

[Dicebot via Digitalmars-d]

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.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

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

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

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

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?  ;-)

Re: An idea for commercial support for D

[Joakim via Digitalmars-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.

Re: An idea for commercial support for D

[Zach the Mystic via Digitalmars-d]

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!

Re: An idea for commercial support for D

[Zach the Mystic via Digitalmars-d]

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?

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 9 January 2015 at 18:01:50 UTC, anonymous wrote:

On Friday, 9 January 2015 at 06:43:01 UTC, Joakim wrote:

On Tuesday, 6 January 2015 at 22:37:40 UTC, anonymous wrote:

[...]
As far as I know there are companies that employ developers 
to work on open source software, with their patches 
open-sourced immediately. I'm assuming the employer can 
direct where exactly the effort goes. That's essentially it, 
no?


A few companies may do that, but he referred to paying for 
fixes you want right away but getting patches other companies 
paid for for free.  I don't know of any commercial support 
model where that happens.


When two companies hire two different guys to work on the same 
OSS project, each company pays for the patches of their guy, 
while getting the patches of the other guy for free.


We were talking about commercial support models, so presumably he 
was talking about a single support company that will both fix 
your problem on demand for money and give you other such fixes 
for free.  I pointed out that they usually use support 
subscriptions, where it's more accurate to say that you're paying 
for all those other fixes too, just less than the ones you 
directly asked for.


As for outside companies, as long as they release their fixes, 
sure, you get them.  But that's also true in the hybrid model 
I've laid out, after the funding/time limit has passed, ie you'll 
eventually get outside fixes you didn't pay for.


For example, I just googled paid linux developers and came 
across an article [1] that states:
Within that field Red Hat topped that chart with 12% followed 
by Inte with 8% IBM and Novell with 6% each and Oracle 3%. 
Despite the clear commercial rivalry between those players 
central kernel development worked well Corbet noted.


Now it might be that they hold back patches for some time to 
gain an advantage over the competition. But it's my uneducated 
impression that they don't.


These consulting companies likely don't hold back many patches, 
because the GPL requires that they give them to at least their 
customers who deploy the software.  But the companies deploying 
the software in their own offices can hold back the patches.



[...]

Yes, _anything_ you pay for is a competitive advantage for you.
He seems to think only the direct features of your product are 
your competitive advantage, but indirect costs like this also 
affect the price and overall quality of your product, at least 
relative to other products in the market, which are just as 
important.

[...]
Businesses generally don't sink money into stuff that provides 
them no competitive advantage.  Therefore, the 
counter-proposal is pure fantasy.


I would have guessed that business is happy to invest when the 
return is right. Business wouldn't say no to making more money 
just because someone else makes more money, too, would they? Of 
course, strategic considerations have to be factored in there. 
Like harming or benefitting a competitor. But also brand image 
and whatever else.


You maximize your return by keeping the patches to yourself, at 
least for a while.  So yes, they may invest, but they may not 
release right away.



[...]
The win for the customer is that they're getting a patch that 
would not otherwise exist, not sure what's more clear than 
that.


Sure, but this is all about how it's a bigger win than 
open-sourcing the patch right away.


I'm just countering your claim that there is no win for the 
customer in the hybrid model.  It is also a bigger win than 
open-sourcing right away.



[...]
I'm not sure exactly what you by mean by competitors buying 
patches collectively.  If you mean that all the companies pool 
together and fund OSS development, how do you keep some 
outlier from not contributing any money, using the resulting 
OSS code, then undercutting you on price?


I assumed that the competitors know each other. That would make 
it an all-or-none deal. And the obvious choice would be to 
split the cost. When there may be serious unkown competition, 
it becomes unfeasible, I guess.


Paid closed-source patches are simply another way of splitting 
the cost between customers, where you make sure there are no 
holdouts, because they don't get the patch unless they pay.



[...]
I don't know what the minor/occasional contributors think, so 
who knows how they'd react to such a move, but D could well 
afford to lose them if it gets several paid devs and some new 
OSS contributors from the resulting larger D community in 
return. :) The cost-benefit on that is a no-brainer, you have 
to go paid.


The 'if' is the thing. Lose too many volunteers while 
attracting not enough business and whoops you're going in the 
wrong direction.


If they're minor/occasional contributors as you said, they won't 
make much of a difference.



Also, personally I like volunteerism. But that's just me.


D has gotten very far as a volunteer project.  But it has 
essentially no uptake in medium to 

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 9 January 2015 at 14:43:02 UTC, Dicebot wrote:

On Friday, 9 January 2015 at 12:21:35 UTC, Joakim wrote:
To be honest if something like this would ever happen my 
first move would be to reach company leadership and discuss 
possible full forking of D compiler as a simple matter of 
ensuring business safety. This scheme introduces unacceptable 
amount of risks for customer.


I see, so some outside devs selling patches to other companies 
poses unacceptable risk for your company.  Funny how such a 
stone-age relic move seems to have such an effect on you. ;) 
In essence, Sociomantic is already running a forked compiler, 
D1, as it isn't publicly maintained anymore, so I'm not sure 
what the difference is or why we should care what you do.


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.


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.


Selling of software in any for is a relict of stone age and 
we must help it get forgotten.


Funny, how does Sociomantic make money again?  Oh right, by 
selling access to their closed-source software.  I guess 
because it's on a server and the business logic doesn't run on 
the customer's device, that's _completely_ different from 
selling of software. ;)  Or maybe Sociomantic is about to 
open source all their code and go pure FOSS!  I look forward 
to the announcement.


There are so many ridiculous statements here.

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.


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.


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.


At the same time offering more commercial support is 
something very desired for business and something I'd like to 
see extended. Right now pretty much only available option is 
to reach Walter personally and agree on some contract with 
DigitalMars which is both limited by manpower of a single 
person and not advertised in any way.


I have no doubt that you'd rather someone worked for you for 
peanuts on a support contract, rather than making more money 
off a productized D compiler.  But what you should consider is 
the latter is likely better for D and your preferred approach 
is not preferred by everybody else.


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 

Re: An idea for commercial support for D

[via Digitalmars-d]

On Friday, 9 January 2015 at 04:33:53 UTC, Joakim wrote:
I have little idea why you're going into all these detailed 
business cases that have nothing to do with the two separate 
concepts I've laid out, but what the hell, I'll bite.


Start listing:

1. What alternatives the seller has.

2. What alternatives the buyer has for all likely use scenarios.

And you you'll see why your model is either inferior or similar 
to existing models.


Selling patches is basically no different from selling plugins 
without QA. That's not very attractive. For plugins to work in 
the market you need a customer that buys incremental upgrades 
(like musicians who spend all their money on gear hunting for the 
next big sound).


D is not ready for 3., I don't see many using it for that.  
It's mostly 1. and 2., and they will pay some amount for 
features or polish they need, though obviously not as much as 
3.  However, D has been used for 3. at Sociomantic, where they 
were willing to develop a concurrent GC and other features to 
make it more capable for their particular use.  It is possible 
that other companies would similarly try to use it for 3. but 
outsource development of such key features that they need, 
though unlikely, simply because 3. is just a much bigger bet.


You are speaking as if people don't sell customized systems. They 
do. They sell a customization service or they sell niche products 
where you negotiate the price with each customer. That way you 
can give the customer good value and still be able to charge a 
premium. Make your pricing public and you end up with lower 
margins and have to sell more. The problem is, if there is a 
market for more, then there is a market for a new independent 
product too.


This is all general business strategy that has essentially 
nothing to do with the specific ideas in this thread.  I'm not 
sure what connection you're trying to make.


Then read it again. You are writing as if you are offering 
something new. You are not.


So every development tool vendor in the world who gives away a 
free starter tool and then charges for an upgrade, or even 
those in-store displays where they let you try out some food 
for free before you buy more of it, is a drug dealer?  Yes, 
there are some superficial similarities, but I'd call it more 
try before you buy.


Vendors of expensive software ignored (turned a blind eye to) 
piracy for a long time because it eroded the market for the less 
expensive competing products and gave themselves increased market 
share. Then they formed an alliance to address piracy to combat 
piracy and enforce purchases.


Other vendors sell cheap LE versions of their products to erode 
the market for competitors, then they stop selling LE versions of 
their product forcing an upgrade to a more expensive product for 
customers who are then locked in.


The differences are in the original post.  A regular closed 
source vendor is simply a collection of developers who pool 
their patches together and sell them compiled into a closed 
build of the compiler.  In this case, the developers would not 
all work for a single company, but the customer would still get 
a build with some assortment of closed patches from some 
selection of independent paid devs compiled in.


Why would a company want to depend on a conglomerate of 
individuals? No contract, no sale. You need to be accountable if 
you are going to charge real money. Without being accountable 
there is no quality. The quality of FOSS is entirely dependent on 
volume (lots of users testing it).


Also, the customer would eventually receive the patches under 
an OSS license, the boost license which this project uses, 
after a delay based on a funding and time limit.  A regular 
closed source vendor usually does not do this.


But the customer don't want the patches. They want a working tool 
with support. Building your own tool is more expensive than 
buying an expensive ready-made.


Who are you customers? Define scenarios that are concrete. 
Without concrete scenarios all you are left with is hand-waving.

Re: An idea for commercial support for D

[anonymous via Digitalmars-d]

On Friday, 9 January 2015 at 06:43:01 UTC, Joakim wrote:

On Tuesday, 6 January 2015 at 22:37:40 UTC, anonymous wrote:

[...]
As far as I know there are companies that employ developers to 
work on open source software, with their patches open-sourced 
immediately. I'm assuming the employer can direct where 
exactly the effort goes. That's essentially it, no?


A few companies may do that, but he referred to paying for 
fixes you want right away but getting patches other companies 
paid for for free.  I don't know of any commercial support 
model where that happens.


When two companies hire two different guys to work on the same 
OSS project, each company pays for the patches of their guy, 
while getting the patches of the other guy for free.


For example, I just googled paid linux developers and came 
across an article [1] that states:
Within that field Red Hat topped that chart with 12% followed by 
Inte with 8% IBM and Novell with 6% each and Oracle 3%. Despite 
the clear commercial rivalry between those players central kernel 
development worked well Corbet noted.


Now it might be that they hold back patches for some time to gain 
an advantage over the competition. But it's my uneducated 
impression that they don't.


[...]

Yes, _anything_ you pay for is a competitive advantage for you.
 He seems to think only the direct features of your product are 
your competitive advantage, but indirect costs like this also 
affect the price and overall quality of your product, at least 
relative to other products in the market, which are just as 
important.

[...]
Businesses generally don't sink money into stuff that provides 
them no competitive advantage.  Therefore, the counter-proposal 
is pure fantasy.


I would have guessed that business is happy to invest when the 
return is right. Business wouldn't say no to making more money 
just because someone else makes more money, too, would they? Of 
course, strategic considerations have to be factored in there. 
Like harming or benefitting a competitor. But also brand image 
and whatever else.


[...]
The win for the customer is that they're getting a patch that 
would not otherwise exist, not sure what's more clear than that.


Sure, but this is all about how it's a bigger win than 
open-sourcing the patch right away.


[...]
I'm not sure exactly what you by mean by competitors buying 
patches collectively.  If you mean that all the companies pool 
together and fund OSS development, how do you keep some outlier 
from not contributing any money, using the resulting OSS code, 
then undercutting you on price?


I assumed that the competitors know each other. That would make 
it an all-or-none deal. And the obvious choice would be to split 
the cost. When there may be serious unkown competition, it 
becomes unfeasible, I guess.


[...]
I don't know what the minor/occasional contributors think, so 
who knows how they'd react to such a move, but D could well 
afford to lose them if it gets several paid devs and some new 
OSS contributors from the resulting larger D community in 
return. :) The cost-benefit on that is a no-brainer, you have 
to go paid.


The 'if' is the thing. Lose too many volunteers while attracting 
not enough business and whoops you're going in the wrong 
direction.


Also, personally I like volunteerism. But that's just me.

[...]
Since no core dev has expressed any interest in this thread, 
that is the likely route.  But even if they did, no other 
member of the D community has any claim on their time.  Their 
contributions to D are donations of their time.  For a member 
of the D community to say they can't also sell some of their 
D-related time to willing buyers is utter nonsense.


Again, it's not that anyone has any right to make demands of 
anyone. Of course, anyone can start their own closed fork of D 
[2]. But, depending on a thousand details, if the right/wrong 
people do it, it may hurt the popularity of D.


Similarly, if Walter proclaimed that D was a big mistake and that 
he favours Go or Rust or whatever now, no one has any right to 
demand he keeps working on D, but it would probably be a bad move 
for the popularity of D.


[1] http://apcmag.com/linux-now-75-corporate.htm
[2] As far as the involved licences allow for that. Not a lawyer. 
Not legal advice. etc. yadda yadda

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Wednesday, 7 January 2015 at 02:08:45 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

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.


That's because it _is_ a fundamentalist position, that almost 
nobody holds.  You yourself point out that you don't hold it, 
because you're perfectly willing to use linux with binary blobs.


The only bad habit I see here is your repeated imposition of such 
a silly position on D, despite my repeatedly engaging with the 
substance and detail of the issues you raise and pointing out 
all the flaws with such thinking.


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.


So your point is that non-free is _not_ a deal-breaker when it 
comes to the OS or some other tech further down the stack, which 
doesn't _directly_ impinge on your commercial and product goals 
like a compiler does.  That's perfectly pragmatic, but it doesn't 
sound like non-free is really a deal-breaker for you, maybe just 
for certain key tools.


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.


That _is_ zealotry: it's so paranoid that it's _not_ basic 
business sense for the vast majority of developers who employ 
proprietary toolchains, like MS Visual Studio or Embarcadero.  
The way the bulk of devs avoid the Pay us more or we stop 
support problem is by using programming languages with a common 
spec and with multiple competing commercial implementations, so 
they can always switch compilers.


Switching is certainly not costless, but it puts a cap on how 
much your original compiler vendor can extort you, because if the 
cost of switching is less than their extortion attempt, you'll 
switch.  Also, the ultimate deterrent to such potential extortion 
is all the other customers who'd then switch when you publicized 
such behavior, as they know they'd be next to receive such a 
shakedown.


In any case, I suggest you reread the linked Phoronix article 
from my original post where I wrote about the benefits of such 
hybrid models.  One of the major benefits of hybrid models is 
that if you don't like what a vendor is doing, you can still fork 
their OSS code.  So if one paid D compiler vendor tried to pull 
such a move on you, there would very likely be other vendors you 
could easily switch to. :)


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


This would mean something if you would lay out why there's no 
conflict, rather than hand-waving about important distinctions 
that you don't know either.  Since you can't, I must be right. :)


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 

Re: An idea for commercial support for D

[Dicebot via Digitalmars-d]

You have already proposed this idea once and were explained in 
great detail why it doesn't work. To be honest if something like 
this would ever happen my first move would be to reach company 
leadership and discuss possible full forking of D compiler as a 
simple matter of ensuring business safety. This scheme introduces 
unacceptable amount of risks for customer.


Selling of software in any for is a relict of stone age and we 
must help it get forgotten.


At the same time offering more commercial support is something 
very desired for business and something I'd like to see extended. 
Right now pretty much only available option is to reach Walter 
personally and agree on some contract with DigitalMars which is 
both limited by manpower of a single person and not advertised in 
any way.


This is same issue as one that was mentioned when discussing 
vibe.d - having clearly communicated option to get a paid support 
to fix any issues you may encounter is possible deal-breaker for 
anyone considering risks of putting bet on D for next project.

Re: An idea for commercial support for D

[via Digitalmars-d]

On Friday, 9 January 2015 at 11:40:47 UTC, Joakim wrote:
 Perhaps you're not a native speaker of the English language, 
but it is difficult to follow all the logical leaps you're 
making, as one point seems completely disconnected from the 
other and none seem connected to the topics from this thread.


I expect you to connect the dots when they are obvious.


But that's just distracting to those of us who are
only interested in the narrow topic under discussion.  Where 
you stick to the topic, I've often agreed with you.


Everything needs a context, and you need to try connect the dots. 
You don't seem particulary interested in making the connections.


But you are not the only person in the D forums who are 
struggling with the bigger picture. Which is why D probably never 
will be finished.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 9 January 2015 at 11:50:30 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 9 January 2015 at 11:40:47 UTC, Joakim wrote:
Perhaps you're not a native speaker of the English language, 
but it is difficult to follow all the logical leaps you're 
making, as one point seems completely disconnected from the 
other and none seem connected to the topics from this thread.


I expect you to connect the dots when they are obvious.


My point is that they're not obvious.  Rather than simply stating 
that they're obviously connected, you could show that.  
Presumably you can't. :)



But that's just distracting to those of us who are
only interested in the narrow topic under discussion.  Where 
you stick to the topic, I've often agreed with you.


Everything needs a context, and you need to try connect the 
dots. You don't seem particulary interested in making the 
connections.


I don't think I'd be reading your posts if I weren't interested.  
The problem is with you and your tendency to ramble onto 
unconnected points.


But you are not the only person in the D forums who are 
struggling with the bigger picture. Which is why D probably 
never will be finished.


Perhaps we struggle with the bigger picture, but your constant 
rambling onto completely unconnected topics that have nothing to 
do with the bigger picture can only make that struggle worse. :D

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 9 January 2015 at 11:52:19 UTC, Dicebot wrote:
You have already proposed this idea once and were explained in 
great detail why it doesn't work.


You are right that I previously suggested in another thread that 
D use a hybrid model, but in that case I suggested that Walter 
sell a single paid compiler to go along with the official OSS 
one, while here I'm proposing that any random devs sell their own 
patches.  So yes, both use the same underlying idea of a hybrid 
model, but both are pitched at different audiences and are 
somewhat different approaches.


I don't remember any great detail why it doesn't work, just 
ludicrous assertions like yours below that selling software is a 
stone-age relic.


To be honest if something like this would ever happen my first 
move would be to reach company leadership and discuss possible 
full forking of D compiler as a simple matter of ensuring 
business safety. This scheme introduces unacceptable amount of 
risks for customer.


I see, so some outside devs selling patches to other companies 
poses unacceptable risk for your company.  Funny how such a 
stone-age relic move seems to have such an effect on you. ;) In 
essence, Sociomantic is already running a forked compiler, D1, as 
it isn't publicly maintained anymore, so I'm not sure what the 
difference is or why we should care what you do.


Selling of software in any for is a relict of stone age and we 
must help it get forgotten.


Funny, how does Sociomantic make money again?  Oh right, by 
selling access to their closed-source software.  I guess because 
it's on a server and the business logic doesn't run on the 
customer's device, that's _completely_ different from selling of 
software. ;)  Or maybe Sociomantic is about to open source all 
their code and go pure FOSS!  I look forward to the announcement.


At the same time offering more commercial support is something 
very desired for business and something I'd like to see 
extended. Right now pretty much only available option is to 
reach Walter personally and agree on some contract with 
DigitalMars which is both limited by manpower of a single 
person and not advertised in any way.


I have no doubt that you'd rather someone worked for you for 
peanuts on a support contract, rather than making more money off 
a productized D compiler.  But what you should consider is the 
latter is likely better for D and your preferred approach is not 
preferred by everybody else.


This is same issue as one that was mentioned when discussing 
vibe.d - having clearly communicated option to get a paid 
support to fix any issues you may encounter is possible 
deal-breaker for anyone considering risks of putting bet on D 
for next project.


Perhaps Sonke will be interested in providing such paid support.  
Or perhaps he's more interested in creating a product using 
vibe.d, whether it runs on the server or the users' premises, and 
making much more money that way. :)

Re: An idea for commercial support for D

[via Digitalmars-d]

On Friday, 9 January 2015 at 13:15:55 UTC, Joakim wrote:
If you have any specific criticism of my business model, I'm 
glad to listen to it and take into account.  I can't do much 
with suggestions that I enumerate how businesses work and 
figure out what you have in mind for myself, or digressions on 
general business strategy that don't seem to have any relevance 
to this business model.


Let me put it this way: I rarely write on topics I have no 
interest in and am old enough to stumbled over many topics 
related to computers (being a middle aged geek). I've spent a lot 
of thought over the past year on both designing a better C++ 
(which was what D originally promised) and if there is a way to 
fund the implementation of it. One option is to make a commercial 
version of D with a smaller scope than D2.


Then I ask myself what would it take for me to be willing to pay 
for such a language. The answer is basically:


1. A small company or a consultant which care about the product 
and is giving support so that I can be assured that all problems 
related to it will be fixed.


2. An alternative path if (1) should cease to exist.

3. A ready-made stable compiler supporting a subset of D, with 
parity to C++. With source available, sans optimizer 
enhancements.


4. Solid implementation on the platform I care about (e.g. Linux 
64-bit).


Why would I prefer a ready-made? Because support is more valuable 
if they can be held accountable.


I would not be interested in buying individual features. I would 
be interested in something that has been polished over time. A 
stable release is the only way to achieve that.


But what I would be paying for is essentially the support of a 
stable foundation with hot-fixes available. The product is more 
like a carrot to purchase the support ahead of time. So you 
basically pay for support you don't receive, if the product 
works, ahead of time. Or to put it in another way: you pay 
insurance to ensure that you don't get stuck.


I still think it would be a hard sell without some substantial 
feature…

Re: An idea for commercial support for D

[via Digitalmars-d]

On Friday, 9 January 2015 at 12:02:33 UTC, Joakim wrote:
Perhaps we struggle with the bigger picture, but your constant 
rambling onto completely unconnected topics that have nothing 
to do with the bigger picture can only make that struggle 
worse. :D


My points always have something to do with the bigger picture. 
When doing design you have to move between the big picture and 
the details.


You cannot design a business-model without looking at the use 
context and competing models.


Likewise, doing language design without studying other languages 
and reading up on the relevant fields of type theory and 
semantics is asking for a very slow ascension, if at all.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 9 January 2015 at 13:05:29 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 9 January 2015 at 12:02:33 UTC, Joakim wrote:
Perhaps we struggle with the bigger picture, but your constant 
rambling onto completely unconnected topics that have nothing 
to do with the bigger picture can only make that struggle 
worse. :D


My points always have something to do with the bigger picture. 
When doing design you have to move between the big picture and 
the details.


You cannot design a business-model without looking at the use 
context and competing models.


Likewise, doing language design without studying other 
languages and reading up on the relevant fields of type theory 
and semantics is asking for a very slow ascension, if at all.


I think you are very knowledgeable about those related fields and 
often bring important points of view to the discussion.  As I 
said, I often agree with your conclusions.  The only problem is 
that your conclusion is often preceded by a lot of verbiage that 
isn't really necessary to make your point.


If you have any specific criticism of my business model, I'm glad 
to listen to it and take into account.  I can't do much with 
suggestions that I enumerate how businesses work and figure out 
what you have in mind for myself, or digressions on general 
business strategy that don't seem to have any relevance to this 
business model.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Friday, 9 January 2015 at 08:48:49 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 9 January 2015 at 04:33:53 UTC, Joakim wrote:
I have little idea why you're going into all these detailed 
business cases that have nothing to do with the two separate 
concepts I've laid out, but what the hell, I'll bite.


Start listing:

1. What alternatives the seller has.

2. What alternatives the buyer has for all likely use scenarios.

And you you'll see why your model is either inferior or similar 
to existing models.


Selling patches is basically no different from selling plugins 
without QA. That's not very attractive. For plugins to work in 
the market you need a customer that buys incremental upgrades 
(like musicians who spend all their money on gear hunting for 
the next big sound).


You are focusing on packaging, particularly related to how people 
often do it today.  As I already said earlier in this thread, the 
initial packaging will likely be that all the independent devs 
bundle all their paid patches together into a single patchset 
against the official point releases, sell a single closed build 
with that patchset compiled in, and split the proceeds, simply 
because the software infrastructure for buyers to select, 
compile, and audit individual paid patches doesn't really exist 
yet.


But I believe that over time, the market will develop so that 
it's common for buyers to pay for custom builds that only have 
the patches they pick out, ie compilers and other software will 
become fairly customized.


D is not ready for 3., I don't see many using it for that.  
It's mostly 1. and 2., and they will pay some amount for 
features or polish they need, though obviously not as much as 
3.  However, D has been used for 3. at Sociomantic, where they 
were willing to develop a concurrent GC and other features to 
make it more capable for their particular use.  It is possible 
that other companies would similarly try to use it for 3. but 
outsource development of such key features that they need, 
though unlikely, simply because 3. is just a much bigger bet.


You are speaking as if people don't sell customized systems. 
They do. They sell a customization service or they sell niche 
products where you negotiate the price with each customer. That 
way you can give the customer good value and still be able to 
charge a premium. Make your pricing public and you end up with 
lower margins and have to sell more. The problem is, if there 
is a market for more, then there is a market for a new 
independent product too.


Again, I see no connection between these general business 
statements and my quoted analysis of what types of customers D 
might be able to attract.  You seem to have a problem with 
rambling onto unconnected topics, then acting as though it all 
makes sense. :)


This is all general business strategy that has essentially 
nothing to do with the specific ideas in this thread.  I'm not 
sure what connection you're trying to make.


Then read it again. You are writing as if you are offering 
something new. You are not.


Looked over them again, still don't see the connection.  Since 
you seem to have problems keeping my two separate ideas above 
straight, I'm not even sure which one you're saying is not new.  
Perhaps you're not a native speaker of the English language, but 
it is difficult to follow all the logical leaps you're making, as 
one point seems completely disconnected from the other and none 
seem connected to the topics from this thread.


I have noticed you do this several times in various threads on 
this forum, and the only reason I can see is that you want to 
show that you know a lot about the field by rambling on about 
completely unrelated subjects to the particular narrow topic of 
the thread.  But that's just distracting to those of us who are 
only interested in the narrow topic under discussion.  Where you 
stick to the topic, I've often agreed with you.


So every development tool vendor in the world who gives away a 
free starter tool and then charges for an upgrade, or even 
those in-store displays where they let you try out some food 
for free before you buy more of it, is a drug dealer?  Yes, 
there are some superficial similarities, but I'd call it more 
try before you buy.


Vendors of expensive software ignored (turned a blind eye to) 
piracy for a long time because it eroded the market for the 
less expensive competing products and gave themselves increased 
market share. Then they formed an alliance to address piracy to 
combat piracy and enforce purchases.


Other vendors sell cheap LE versions of their products to erode 
the market for competitors, then they stop selling LE versions 
of their product forcing an upgrade to a more expensive product 
for customers who are then locked in.


Yet, I did not mention piracy at all.

As for vendors getting rid of the low-end version, there's always 
other vendors.  I mentioned in an earlier reply in this thread to 
another 

Re: An idea for commercial support for D

[Dicebot via Digitalmars-d]

On Friday, 9 January 2015 at 12:21:35 UTC, Joakim wrote:
To be honest if something like this would ever happen my first 
move would be to reach company leadership and discuss possible 
full forking of D compiler as a simple matter of ensuring 
business safety. This scheme introduces unacceptable amount of 
risks for customer.


I see, so some outside devs selling patches to other companies 
poses unacceptable risk for your company.  Funny how such a 
stone-age relic move seems to have such an effect on you. ;) In 
essence, Sociomantic is already running a forked compiler, D1, 
as it isn't publicly maintained anymore, so I'm not sure what 
the difference is or why we should care what you do.


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.


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.


Selling of software in any for is a relict of stone age and we 
must help it get forgotten.


Funny, how does Sociomantic make money again?  Oh right, by 
selling access to their closed-source software.  I guess 
because it's on a server and the business logic doesn't run on 
the customer's device, that's _completely_ different from 
selling of software. ;)  Or maybe Sociomantic is about to 
open source all their code and go pure FOSS!  I look forward to 
the announcement.


There are so many ridiculous statements here.

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.


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


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.


At the same time offering more commercial support is something 
very desired for business and something I'd like to see 
extended. Right now pretty much only available option is to 
reach Walter personally and agree on some contract with 
DigitalMars which is both limited by manpower of a single 
person and not advertised in any way.


I have no doubt that you'd rather someone worked for you for 
peanuts on a support contract, rather than making more money 
off a productized D compiler.  But what you should consider is 
the latter is likely better for D and your preferred approach 
is not preferred by everybody else.


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.


You won't get customers in the long term if they feel like being 
extorted money. Your proposed scheme does exactly that.

Re: An idea for commercial support for D

[via Digitalmars-d]

On Thursday, 8 January 2015 at 15:27:57 UTC, Joakim wrote:
the customer not being very price-sensitive.  As for estimating 
the total cost, the seller also needs to estimate his expected 
revenue, ie how much demand there is and at what price.  With 
this model, you are allowing the seller to get a better 
estimate and more certainty.  Meanwhile, the buyer takes on 
more risk, but if he wants that product to exist, he may be 
willing to do that.


Realistically, a software development project can be either:

1. A small project the developer will pick pre-existing tools 
for, but can afford failure, and possibly let the programmers 
pick the language as a motivational bonus. Not a customer.


2. A pilot for a larger project evaluating existing tools. Your 
tool will be one of many, so you need to be available, or the 
developer will select another one.


3. A larger/critical project where you get rid of unknown factors 
before you start.


In order to attract a category 3 customer you need to offer 
something substantial and solid. If it isn't substantial the 
customer would be better off hiring a local consultant which she 
or he can bring in whenever they get stuck.


The you have to consider this:

1. If the feature you want to sell is substantial then it also 
means you will have to cover the costs until you can deliver. 
Nobody will pay a large sum in advance unless there is a 
guarantee (like insurance or a very big company behind it).


2. Maybe only 30% of your products break even. That means you 
have to recoup all the 70% losses  from the profits of those 30%. 
That means you cannot afford small margins on the features that 
are useful. That also means that competitors can wait to see what 
you do and implement them when they see them being successful 
(which makes it cheaper for them). So you have to offer something 
that can recoup the costs+losses from other projects in the 
within the timeframe you have before other solutions pop up.


3. No sane business can afford to give a away a product that is 
still selling, and if you are able to sell it to N customers 
today with no marketing, it means that you with more marketing 
can sell it to N*M customers until a competitor offers a better 
product.


4. If you have something that sells, it will be better for you to 
enhance it so that you can charge more for it by giving the 
customer features they would otherwise not pay for individually. 
And it will make your product too expensive to wipe out for 
competitors (the Adobe approach). It's psychological.


I have no idea why you're talking about bugs and performance, 
as a variable pricing model has nothing to do with those 
software features.  Maybe you're talking about the paid patches 
idea I laid out earlier, but that's a completely separate 
concept from this variable pricing model.  Suffice to say, paid 
patches can be written for both bugfixes and performance: I 
never limited it to just bugfixes.


On the contrary, a pricing model and the product is related.

Product differentiation has been the norm for development tools 
for ages. There is nothing new about it. You identify different 
market segments and pick the feature set. Then you leave out that 
one feature that breaks that segments apart (like team features 
or optimization).


Another option is to allow plugins: photoshop, audio/music 
editors etc, or precompiled libraries. Many tool developers offer 
additional options to their base product, even if just libraries. 
Nothing new here.


The model you are advocating fits more for the casual market as 
can be seen in iOS appstore, the freemium model. The drug 
dealer model. You give away a free dose of the drug, then charge 
for upgrades in a slippery slope fashion.


Sure, the first to pay will be existing companies using D, but 
you could attract a lot of new companies with paid patches, as 
what they really care about is having access to good tools.


Ok, but then you are just selling a different compiler which uses 
DMD as a framework. So then I don't really understand how that 
is different from a regular closed source vendor who submit 
patches when it makes sense for their business.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Thursday, 8 January 2015 at 23:22:19 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 8 January 2015 at 15:27:57 UTC, Joakim wrote:
the customer not being very price-sensitive.  As for 
estimating the total cost, the seller also needs to estimate 
his expected revenue, ie how much demand there is and at what 
price.  With this model, you are allowing the seller to get a 
better estimate and more certainty.  Meanwhile, the buyer 
takes on more risk, but if he wants that product to exist, he 
may be willing to do that.


Realistically, a software development project can be either:

1. A small project the developer will pick pre-existing tools 
for, but can afford failure, and possibly let the programmers 
pick the language as a motivational bonus. Not a customer.


2. A pilot for a larger project evaluating existing tools. Your 
tool will be one of many, so you need to be available, or the 
developer will select another one.


3. A larger/critical project where you get rid of unknown 
factors before you start.


In order to attract a category 3 customer you need to offer 
something substantial and solid. If it isn't substantial the 
customer would be better off hiring a local consultant which 
she or he can bring in whenever they get stuck.


I have little idea why you're going into all these detailed 
business cases that have nothing to do with the two separate 
concepts I've laid out, but what the hell, I'll bite.


D is not ready for 3., I don't see many using it for that.  It's 
mostly 1. and 2., and they will pay some amount for features or 
polish they need, though obviously not as much as 3.  However, D 
has been used for 3. at Sociomantic, where they were willing to 
develop a concurrent GC and other features to make it more 
capable for their particular use.  It is possible that other 
companies would similarly try to use it for 3. but outsource 
development of such key features that they need, though unlikely, 
simply because 3. is just a much bigger bet.



The you have to consider this:

1. If the feature you want to sell is substantial then it also 
means you will have to cover the costs until you can deliver. 
Nobody will pay a large sum in advance unless there is a 
guarantee (like insurance or a very big company behind it).


2. Maybe only 30% of your products break even. That means you 
have to recoup all the 70% losses  from the profits of those 
30%. That means you cannot afford small margins on the features 
that are useful. That also means that competitors can wait to 
see what you do and implement them when they see them being 
successful (which makes it cheaper for them). So you have to 
offer something that can recoup the costs+losses from other 
projects in the within the timeframe you have before other 
solutions pop up.


3. No sane business can afford to give a away a product that is 
still selling, and if you are able to sell it to N customers 
today with no marketing, it means that you with more marketing 
can sell it to N*M customers until a competitor offers a better 
product.


4. If you have something that sells, it will be better for you 
to enhance it so that you can charge more for it by giving the 
customer features they would otherwise not pay for 
individually. And it will make your product too expensive to 
wipe out for competitors (the Adobe approach). It's 
psychological.


This is all general business strategy that has essentially 
nothing to do with the specific ideas in this thread.  I'm not 
sure what connection you're trying to make.


I have no idea why you're talking about bugs and performance, 
as a variable pricing model has nothing to do with those 
software features.  Maybe you're talking about the paid 
patches idea I laid out earlier, but that's a completely 
separate concept from this variable pricing model.  Suffice to 
say, paid patches can be written for both bugfixes and 
performance: I never limited it to just bugfixes.


On the contrary, a pricing model and the product is related.


Yes, but nobody has proposed this variable pricing model for D.  
Zach and I were just talking about other pricing models, and I 
pointed out that this kind of variable pricing can and should be 
used for all kinds of IP.  However, I did not relate it to the 
earlier paid patches idea.  I do think variable pricing will be 
applied to paid patches someday, but I have not suggested doing 
it right away.


Product differentiation has been the norm for development tools 
for ages. There is nothing new about it. You identify different 
market segments and pick the feature set. Then you leave out 
that one feature that breaks that segments apart (like team 
features or optimization).


Another option is to allow plugins: photoshop, audio/music 
editors etc, or precompiled libraries. Many tool developers 
offer additional options to their base product, even if just 
libraries. Nothing new here.


The model you are advocating fits more for the casual market as 
can be seen 

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 22:32:22 UTC, uri wrote:

On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote:

Before you make such claims, you should probably think about 
them a little bit first.  Please tell me one company that does 
not buy outside commercial software which they then use to 
build their own products.  Some companies will want to cherry 
pick features, others will just buy an accumulated patchset 
against the point release from many devs.  The suggestion that 
all companies will have to spend a great deal of time picking 
what patches they want is just silly.


To me it doesn't make sense for a company to cherry pick 
compiler patches. The model you propose may work for 
applications where there is a clean distinction between user 
needs and wants but in a compiler you generally need all the 
features to work effectively and produce reasonable code. The 
optimizer may be a different story so perhaps that aspect of 
compilation could be split.


Besides splitting the compiler will result in a maintenance 
headache. Missing features in the compiler will not result in 
subset-D and complete-D but half-baked-nearly-working-D and 
working-D, if you're lucky.


It really doesn't matter what makes sense to you: a few companies 
will prefer the lower cost of a custom build and go that route.  
The compiler is already missing features, shared still has not 
been implemented to Andrei's spec in his book five years ago and 
all the bugs mean several features do not work as intended.  D is 
already half-baked: you always have to pick and choose what 
features you use with a new tech like this, whether employing the 
current OSS project or with paid patches.


This means A and B can't make any money off their patches, so 
they have to get some other job. That means they only have 
time to work on M and X on the occasional weekend and each of 
those patches takes six months to finish.  You are obviously 
okay with that glacial pace as long as you get their work for 
free, but others are willing to pay to get the pace of D 
development sped up.


This is only true if all patches are equally priced. Otherwise 
it breaks down and has been proven mathematically.


You are referencing my paragraph detailing the current OSS route 
that _you_ preferred, where there are _no_ prices.  If you're 
referring to the last sentence about paying for D development, I 
have no idea why you think all patches should be equally priced.  
If you think anything about business has been proven 
mathematically, I can only laugh. :)


Glad you brought this up, there are several possibilities.  
Many users would probably just buy all the closed patches 
against a point release, so there is no question of splitting 
features.  But a handful of paying customers may be more 
adventurous, or cheap, ;) and choose to only buy a custom 
build with their needed features X,Y,Z.  This probably 
wouldn't happen right away, as it will take more time to setup 
a build process to support it, but supporting custom builds 
like that is definitely worthwhile.


OK, but the D devs still need to split the release between paid 
patches and non-paid patches. This is non-trivial in a compiler 
and adds additional work for the volunteers. Companies won't 
pay for the split because it isn't value adding for them so it 
will fall on the volunteers.


The OSS project and its devs would not have access to the paid 
patches, as they are _closed-source_, so the only ones doing such 
maintenance would be the paid devs who wrote them.  Once the 
patches are open-sourced and submitted back upstream, they would 
need to be maintained by the OSS project, but that is no 
different from any other OSS patches.


As stated earlier, the patches would need to be funded up to 
some monetary and time limits before they would be released 
back to the OSS project.  So party A might contract with their 
paying customers that they'll release patches X,Y,Z once they 
accumulate $5k in payments from all the customers who buy 
those patches, plus a six month delay after that.  If they 
don't make $5k for a long time, the patches won't be released 
for a long time.


Then I think most OSS users would move on to another language. 
There is no point working with a compiler that is half-baked 
unless you pay for it. This is an issue because it's the OSS 
community that provides ongoing maintenance to the paid for 
patches. If OSS isn't there anymore then Digital Mars needs to 
start charging maintenance costs to upkeep the codebase. I 
don't think that will work, but it's only my opinion.


It's _already_ half-baked unless you pay for it, :) ie current 
companies employing D, like Sociomantic, employ in-house devs to 
add proprietary features that they pay their employees to 
develop.  Providing paid patches from independent external devs 
changes nothing in that regard.  I have no idea how you think an 
OSS community would provide maintenance for closed-source 
patches: 

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 22:37:40 UTC, anonymous wrote:

On Tuesday, 6 January 2015 at 19:46:51 UTC, Joakim wrote:

On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:

[...]
I don't know of any commercial support model where you only 
pay for the fixes you need at any given moment and the fixes 
that others paid for are provided to you for free.


I'm not knowledgeable about any of this business stuff, and I 
don't mean to pretend I am. I just wanted to clarify what I 
think Joseph meant there, as I understood it.


As far as I know there are companies that employ developers to 
work on open source software, with their patches open-sourced 
immediately. I'm assuming the employer can direct where exactly 
the effort goes. That's essentially it, no?


A few companies may do that, but he referred to paying for fixes 
you want right away but getting patches other companies paid for 
for free.  I don't know of any commercial support model where 
that happens.


I presume you're referring to support subscriptions, where you 
pay a monthly fee to subscribe to an stream of ongoing fixes 
and pay extra for fixes you need right away.  But that's not 
free, you're paying a monthly fee for that ongoing 
subscription, which subsidizes the cost of those fixes that 
others paid for first.


No, I didn't have that in mind.


Well, unless either of you can articulate exactly what model you 
have in mind and who's using it, it's irrelevant.



[...]
My point was that he's wrong that the patch's value doesn't 
change if others have access to it.  Just because that patch 
doesn't clearly differentiate your product on a spec sheet 
doesn't mean those patches in aggregate don't differentiate 
your time to market and cost of making the product, which will 
all affect your bottom line.


So, the point is that competitors can't leech off my paid 
patches, right? I mean, sure, that's a thing. I'm definitely 
not business enough to put a number on it. Seems like the 
number you put on it is higher than the one Joseph puts on it.


Yes, _anything_ you pay for is a competitive advantage for you.  
He seems to think only the direct features of your product are 
your competitive advantage, but indirect costs like this also 
affect the price and overall quality of your product, at least 
relative to other products in the market, which are just as 
important.


There is no disadvantage to paying for the patch in this 
model, because otherwise you don't get the patch.  You are 
paying someone to write the patch so that it exists in the 
first place.  Otherwise, you can hope that some OSS dev gets 
to it someday when he gets some spare time.


The counter-proposal is not to rely on the free (as in beer) 
devs, but to hire someone to write OSS patches. This would of 
course allow your competition to leech off of you. But if 
others do the same, the benefits may be greater than if 
everyone is protective of their stuff. Again, I don't want to 
pretend to know what's best business-wise.


Businesses generally don't sink money into stuff that provides 
them no competitive advantage.  Therefore, the counter-proposal 
is pure fantasy.



[...]
It _is_ win-win, that's the whole point.  It's even 
win-win-win, to crib a term from The Office, ;) because the 
OSS project eventually also gets the patch after a delay.


I don't think the win for the customer is so clear. The win 
that your competitors have to pay, too, seems rather slim to me 
(remember, not a business guy). And if competitors would buy 
patches collectively, eliminating the need for an exclusive 
access period, they could be better off than when each of them 
pays for it separately. But this may not be realistic, of 
course.


The win for the customer is that they're getting a patch that 
would not otherwise exist, not sure what's more clear than that.  
As for competitors, let's say you pay for a bunch of patches 
which you open-source right away and your competitors use those, 
then don't pay for any patches of their own.  So they save a 
bunch of money that you're spending, then release their product 
cheaper than yours.  Which company do you think is going to do 
better?


I'm not sure exactly what you by mean by competitors buying 
patches collectively.  If you mean that all the companies pool 
together and fund OSS development, how do you keep some outlier 
from not contributing any money, using the resulting OSS code, 
then undercutting you on price?  It is difficult to coordinate 
companies this way, though I have sometimes pointed out 
non-profits like Linaro, which are funded by various companies 
and do something similar.  What I think you're describing is 
possible, but can never garner as much investment as a paid 
business model.


I don't know who this hypothetical competitor is who provides 
immediate-access-for-everyone and is cranking out a ton of 
patches.  They currently don't exist.


Neither exists at the moment for D. It's all hypothetical.

Re: An idea for commercial support for D

[via Digitalmars-d]

On Thursday, 8 January 2015 at 10:37:57 UTC, Joakim wrote:
supply/demand curve for his product.  In this variable pricing 
model, the customer also takes some of that risk, ie you'll pay 
more if enough other people don't also want the product.


Businesses don't like risk. They need to estimate the total cost 
before starting the project. I don't think you can advertising 
less bugs as a feature. It has to be a real feature like better 
performance.


Your assumption is that businesses start on a project and then 
later discover that they cannot work within the limits of the 
tools and are willing to pay a premium for it. Sure, that is 
possible, but your business model is flawed because it is based 
on your customers having a embarked on a project with a flawed 
plan in order to become a customer.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 20:21:50 UTC, Zach the Mystic wrote:

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.


The notion is that individual developers could work on patches 
to fix bugs or add features to ldc/druntime/phobos then sell 
those closed patches to paying customers.  After enough time 
has passed, so that sufficient customers have adequately paid 
for the work or after a set time limit beyond that, the patch 
is open sourced and merged back upstream.  It would have to be 
ldc and not dmd, as the dmd backend is not open source and the 
gdc backend license doesn't allow such closed patches.


A funny scenario based on this proposal: Company A wants 
feature B, and signs a contract with a developer for a certain 
amount, receiving the feature as soon as possible, releasing 
the paid-for software to the public after a year. During that 
year, company C comes to the same developer wanting the same 
feature. They say, It's already paid for, but you can pay 
company A half the development cost, minus the proportion of 
time left before it's open to everyone, and you can both have 
it! Or something like that.


You're on the right track: I've talked in the past about a more 
advanced version of such a pricing model, that could be used for 
any intellectual property, not just for software.  How it would 
work is that the developer sets a price for all the work to 
develop the feature, say $3k, and picks a reasonable minimum 
amount of customers, say 20.  So he then sets the initial price 
at $150, which may seem high for a single feature.


But assuming he gets to 20 customers, the price drops for each 
subsequent customer, and the first 20 get a proportionate refund. 
 So when he gets to 30 customers, each of the last 10 to buy get 
charged $100, not $150, and each of the first 20 customers get 
their prices dropped to $100, so that the total for the developer 
is always $3k.  Right now, this may work better for an up-front 
payment model, say on a site like kickstarter, or some such 
marketplace where the customers have ongoing accounts and it's 
easy to credit money back to them without having to keep issuing 
refunds to their payment provider, avoiding the accompanying fees.


What are the advantages of such a model?  Well, usually the 
creator has to set a fixed price, whether $50 or $200, and take 
the risk that it is the sweet spot and will actually get enough 
customers to garner $3k, ie he has to guess at the supply/demand 
curve for his product.  In this variable pricing model, the 
customer also takes some of that risk, ie you'll pay more if 
enough other people don't also want the product.  But just like 
on kickstarter, that's a risk you may want to take, as long as 
you get the feature.  There are other elaborations on this model 
to account for some other factors, but the basic idea is here.


This kind of variable pricing model would have been too costly 
decades ago, with all the paper bookkeeping and chargebacks.  It 
would be trivial to implement today though and would be a much 
better model for many products.  Why isn't it done already?  
People are stupid, no other reason.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Thursday, 8 January 2015 at 12:06:18 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 8 January 2015 at 10:37:57 UTC, Joakim wrote:
supply/demand curve for his product.  In this variable pricing 
model, the customer also takes some of that risk, ie you'll 
pay more if enough other people don't also want the product.


Businesses don't like risk. They need to estimate the total 
cost before starting the project. I don't think you can 
advertising less bugs as a feature. It has to be a real 
feature like better performance.


Yes, I've already established the risk aspect, this variable 
pricing model is fundamentally about better risk sharing and the 
customer not being very price-sensitive.  As for estimating the 
total cost, the seller also needs to estimate his expected 
revenue, ie how much demand there is and at what price.  With 
this model, you are allowing the seller to get a better estimate 
and more certainty.  Meanwhile, the buyer takes on more risk, but 
if he wants that product to exist, he may be willing to do that.


I have no idea why you're talking about bugs and performance, as 
a variable pricing model has nothing to do with those software 
features.  Maybe you're talking about the paid patches idea I 
laid out earlier, but that's a completely separate concept from 
this variable pricing model.  Suffice to say, paid patches can be 
written for both bugfixes and performance: I never limited it to 
just bugfixes.


Your assumption is that businesses start on a project and then 
later discover that they cannot work within the limits of the 
tools and are willing to pay a premium for it. Sure, that is 
possible, but your business model is flawed because it is based 
on your customers having a embarked on a project with a flawed 
plan in order to become a customer.


I assume nothing about when a business discovers limits.  
Presumably you're talking about the completely unrelated paid 
patches idea here, but if D becomes much more capable because of 
paid patches, companies will be much more willing to come in new 
and use D, regardless of whether they have to pay or not.  Sure, 
the first to pay will be existing companies using D, but you 
could attract a lot of new companies with paid patches, as what 
they really care about is having access to good tools.

Re: An idea for commercial support for D

[Zach the Mystic via Digitalmars-d]

On Thursday, 8 January 2015 at 10:37:57 UTC, Joakim wrote:
You're on the right track: I've talked in the past about a more 
advanced version of such a pricing model, that could be used 
for any intellectual property, not just for software.  How it 
would work is that the developer sets a price for all the work 
to develop the feature, say $3k, and picks a reasonable minimum 
amount of customers, say 20.  So he then sets the initial price 
at $150, which may seem high for a single feature.


But assuming he gets to 20 customers, the price drops for each 
subsequent customer, and the first 20 get a proportionate 
refund.
 So when he gets to 30 customers, each of the last 10 to buy 
get charged $100, not $150, and each of the first 20 customers 
get their prices dropped to $100, so that the total for the 
developer is always $3k.  Right now, this may work better for 
an up-front payment model, say on a site like kickstarter, or 
some such marketplace where the customers have ongoing accounts 
and it's easy to credit money back to them without having to 
keep issuing refunds to their payment provider, avoiding the 
accompanying fees.


What are the advantages of such a model?


Another advantage is that the developer avoids being perceived as 
a money-grubbing scoundrel, which seems to be a significant issue 
in open-source development. There seems to be a moral hazard if a 
developer, whose work is not substantially different in quality 
or quantity from the work of myriad others who contribute for 
free, stands to reap royalties indefinitely.


Actually, this could work even with the existing developers. A 
marketplace is opened where developers offer features they would 
be willing to work on. It's like the bounty system but where 
developers also have a say in letting customers know what they'd 
be willing to do. The functionality of this system relies on the 
devastating fact that while hobbyists would like to always work 
on their own pet projects for free, they also need money just as 
much. This gives a way to compromise between what customers 
(bounty posters, i.e.) want, and what developers want, saying 
what they'd be willing to divert their attention towards if the 
price was right. And, seeing that actual money was to be made in 
programming for the D community, more programmers might just 
start jumping in.


The big key is to make it so hobbyists who already contribute so 
much great work for free don't feel in any way abused. Inviting 
them to post their own offers on the marketplace might actually 
work. I mean, isn't the real problem with the bounty system that 
existing developers with the time and resources to do great work 
don't even really have a say, other than yes or no? Well, 
that and it's not always perfectly clear when the terms of a 
bounty have been met, due to more parties than just the developer 
and the customer being involved.


This kind of variable pricing model would have been too costly 
decades ago, with all the paper bookkeeping and chargebacks.  
It would be trivial to implement today though and would be a 
much better model for many products.


Yeah, the internet's great.


Why isn't it done already?  People are stupid, no other reason.


Or, they are distrustful of new ideas, afraid of change, and need 
to be shown good things first - all of which are perfectly 
understandable. Also, don't tell people they're stupid... it's 
bad for business! :-)

Re: An idea for commercial support for D

[via Digitalmars-d]

On Wednesday, 7 January 2015 at 12:16:39 UTC, Iain Buclaw via 
Digitalmars-d wrote:
I feel that the same is for the reverse too.  If you remove 
features,

you again enter the realm of being another language.


Yes, but would a business care? What they care about is 
productivity and risk assessment. Going with a reduced feature 
set means they can move to open source D later on. So the risk is 
low.


You also have source-to-source compilation as an alternative 
(introduce new features, but provide source-to-source utility to 
mitigate perceived risk).


There may be many implementation details that you can omit or 
improve,

such as how you go about dealing with closures, moduleinfo,
thread-local GC - but features listed in the D specification 
are not optional.


It is optional until you have an installed base. Specifications 
mean nothing unless it is backed up with a valuable (for the 
business) corpus that depends on it.


For a game developer the features used by the selected third 
party physics engine means more than what the C++11 standard 
says...

Re: An idea for commercial support for D

[uri via Digitalmars-d]

On Wednesday, 7 January 2015 at 02:16:47 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

On 06/01/15 23:32, uri via Digitalmars-d wrote:
The dmd backend is not under an OSS license, why haven't they 
left?  I suspect
there are not very many of the type of people you're talking 
about in the D

community.


It's possible that you're right but I don't see it happening. 
The backend
doesn't provide any benefit to GDC and LDC and Walter has a 
very good reason for

closing the backend sources which is understood by all.


Small point: the DMD backend may not be released under a free 
software license, but it is not closed -- the source is 
available, development happens in the open, and in a de facto 
(rather than de jure) sense there is little to distinguish from 
an open source project.  The licensing situation is obviously 
unfortunate, but it makes little practical difference 
considering that the vast majority of D language development is 
in the freely-licensed frontend, runtime or standard library, 
and there are two excellent free backends available.


This is a pretty good example of what I have referred to 
elsewhere in this thread, about the contextual nature of 
objections to non-free.


Thanks for the correction, and a very important one at that in 
the context of this thread. I wasn't aware the backend was open 
source.


Cheers,
uri

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 7 January 2015 at 12:00, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Wednesday, 7 January 2015 at 11:46:19 UTC, Iain Buclaw via Digitalmars-d
 wrote:

 That is where the value-for-money factor comes in.  I cannot see any
 traction occurring in Joakim's badly thought out idea unless you have
 some *new* to give.


 I somehow feel that there is a commercial closed source opportunity in
 reducing the feature set somewhat (and fix critical bugs) then redo the
 memory model so that it performs well in production.


I feel that the same is for the reverse too.  If you remove features,
you again enter the realm of being another language.

There may be many implementation details that you can omit or improve,
such as how you go about dealing with closures, moduleinfo,
thread-local GC - but features listed in the D specification are not
optional.

Re: An idea for commercial support for D

[via Digitalmars-d]

On Wednesday, 7 January 2015 at 11:46:19 UTC, Iain Buclaw via 
Digitalmars-d wrote:
That is where the value-for-money factor comes in.  I cannot 
see any
traction occurring in Joakim's badly thought out idea unless 
you have

some *new* to give.


I somehow feel that there is a commercial closed source 
opportunity in reducing the feature set somewhat (and fix 
critical bugs) then redo the memory model so that it performs 
well in production.


It makes sense for a business that have 5 developers working on a 
product to pay $10.000/year to get more productive. Of course, 
this is a shaky business model since the ROI could go out the 
window if the D community decides that a stable polished version 
of D is a worthy goal...

Re: An idea for commercial support for D

[Joseph Rushton Wakeling via Digitalmars-d]

On 07/01/15 13:08, uri via Digitalmars-d wrote:

Thanks for the correction, and a very important one at that in the context of
this thread. I wasn't aware the backend was open source.


Er, I have to clarify again :-)  The backend license is not an open source one; 
it is, strictly speaking, proprietary:

https://github.com/D-Programming-Language/dmd/blob/master/src/backendlicense.txt

However, the code is available, development on it is public, and Walter is very 
liberal in giving permissions to use, distribute and so on.  I think that it's 
only constraints on Walter himself that mean it is not under an open source licence.


That's what I mean when I say it is de facto open, rather than de jure.  But in 
practice, not in law is an important distinction.

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 7 January 2015 at 02:08, Joseph Rushton Wakeling via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 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.


Frankly, I gave up reading at - The alternative is to use the
bug-ridden OSS implementation you're using now for free, and not have
a paid version for those who want those bugs fixed.

No use talking to someone who is convinced that OSS means bug-ridden.



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

I can see an opportunity - but not with any existing compilers we have
at the moment.

Giving away closed-but-free software occasionally works in certain
consumer markets, but you are really going to struggle with this if
your consumers are comprised of mostly RD.

No - you can't reverse a project into a closed source one.  History
can tell you that (read up on The Cautionary Tale of XFree86)

If you are going to make this work, the specification of D needs to be
rubber stamped either with an ANSI or ISO sticker.  This will allow
interested parties to start their own competing compiler - ground up
or forked from the existing implementation, it doesn't matter which.

This will have a desired effect that said group/company will not be
able to invent new features of D.  They are free however to add any
__extensions__ or pragmas to the language.

This does not mean that they have no say in the direction of the
language (popular extensions could still become standardised), but it
gives the current community security that our current procedures for
language changes don't get bypassed by some closed-source party.

This then leads up to second point in matter.  If our D spec is set in
stone, there would be little compelling differences between the paid
and OSS versions of the compiler.  So why in the first place would
people bother going down the proprietary route?

Nope, you need something to blow the others out the water that
attracts the non-RD community.  I would proposed that such a killer
thing would need to be an integrated IDE to tied in with your closed
compiler.  Whilst being a good editor, you need a tool that
automates/simplifies complex processes - highlight build errors whilst
you type, tell the IDE to go build ARM binaries for my project.

That is where the value-for-money factor comes in.  I cannot see any
traction occurring in Joakim's badly thought out idea unless you have
some *new* to give.

Iain.

Re: An idea for commercial support for D

[uri via Digitalmars-d]

Hi,

Your business model is flawed for a number of reasons. Firstly, 
companies make money from their own products, not paying staff to 
figure out which bug fixes/features to cherry pick for the tool 
chain.


Secondly, no one makes money by locking out others when they 
themselves can be locked out in the same manner. This is 
basically what your model seems to boil down to.


Party 'A' provides patches X,Y,Z in the compiler and others have 
to pay for them. Party 'B' provides patches M,N,O and similarly, 
others pay for them.  Now party A does not benefit from M,N,O 
unless they pay for it and party B does not benefit from X,Y,Z 
unless they pay for it. So no one wins.


So the best solution is A and B both open their patches and both 
benefit from all contributions.


Thirdly, how can one separate the features? For example, say I'm 
willing to pay for features X,Y,Z but not M,N,O. How do the D 
devs split the features out so I only get M,N,O? Separate and 
special builds for each paying customer?


Fourthly, what about the OSS people using D?  Are the X,Y,Z and 
M,N,O features released GPL so they can benefit immediately or do 
they wait 6 months?


If it's 6 months why would anyone pay for the features? If it's 
longer than 6 months, or even if its GPL I think most will 
abandon D and go to Nim or Rust.



Cheers,
uri

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 12:05:34 UTC, uri wrote:
Your business model is flawed for a number of reasons. Firstly, 
companies make money from their own products, not paying staff 
to figure out which bug fixes/features to cherry pick for the 
tool chain.


Before you make such claims, you should probably think about them 
a little bit first.  Please tell me one company that does not buy 
outside commercial software which they then use to build their 
own products.  Some companies will want to cherry pick features, 
others will just buy an accumulated patchset against the point 
release from many devs.  The suggestion that all companies will 
have to spend a great deal of time picking what patches they want 
is just silly.


Secondly, no one makes money by locking out others when they 
themselves can be locked out in the same manner. This is 
basically what your model seems to boil down to.


Party 'A' provides patches X,Y,Z in the compiler and others 
have to pay for them. Party 'B' provides patches M,N,O and 
similarly, others pay for them.  Now party A does not benefit 
from M,N,O unless they pay for it and party B does not benefit 
from X,Y,Z unless they pay for it. So no one wins.


I was with you until no one wins, what the hell does that mean? 
 If party A wants to run patches M,N,O with their D compiler and 
vice versa for party B, they can just pay for them, just like 
everybody else.  Since party A will be making money off X,Y,Z, 
they shouldn't have any problem using some of that money to pay 
for the other patches they need.


So the best solution is A and B both open their patches and 
both benefit from all contributions.


This means A and B can't make any money off their patches, so 
they have to get some other job. That means they only have time 
to work on M and X on the occasional weekend and each of those 
patches takes six months to finish.  You are obviously okay with 
that glacial pace as long as you get their work for free, but 
others are willing to pay to get the pace of D development sped 
up.


Thirdly, how can one separate the features? For example, say 
I'm willing to pay for features X,Y,Z but not M,N,O. How do the 
D devs split the features out so I only get M,N,O? Separate and 
special builds for each paying customer?


Glad you brought this up, there are several possibilities.  Many 
users would probably just buy all the closed patches against a 
point release, so there is no question of splitting features.  
But a handful of paying customers may be more adventurous, or 
cheap, ;) and choose to only buy a custom build with their needed 
features X,Y,Z.  This probably wouldn't happen right away, as it 
will take more time to setup a build process to support it, but 
supporting custom builds like that is definitely worthwhile.


Fourthly, what about the OSS people using D?  Are the X,Y,Z and 
M,N,O features released GPL so they can benefit immediately or 
do they wait 6 months?


To begin with, D is not a GPL project, so why would they release 
them under the GPL?  As stated earlier, the patches would need to 
be funded up to some monetary and time limits before they would 
be released back to the OSS project.  So party A might contract 
with their paying customers that they'll release patches X,Y,Z 
once they accumulate $5k in payments from all the customers who 
buy those patches, plus a six month delay after that.  If they 
don't make $5k for a long time, the patches won't be released for 
a long time.


If it's 6 months why would anyone pay for the features? If it's 
longer than 6 months, or even if its GPL I think most will 
abandon D and go to Nim or Rust.


Why does anyone pay for software now?  It doesn't much matter to 
a paying customer that the feature will probably be free in a 
year or two if they need to use it to make money _now_.


As for people leaving because somebody else has developed a 
proprietary feature for D and not given it to them for free, 
companies like Sociomantic have already developed such features 
and they haven't been integrated upstream, why haven't most 
left already?  The dmd backend is not under an OSS license, why 
haven't they left?  I suspect there are not very many of the type 
of people you're talking about in the D community.


Maybe a handful of FOSS zealots would leave, but the resulting 
commercially supported D would be so much better, they'd be 
swamped by the new people coming on board. :)

Re: An idea for commercial support for D

[via Digitalmars-d]

On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote:
Maybe a handful of FOSS zealots would leave, but the resulting 
commercially supported D would be so much better, they'd be 
swamped by the new people coming on board. :)


If there is a market for a commercial version of D then I think 
the most sensible thing for a company would be to create a 
dialect and only distribute binary versions. Maybe a free edition 
for non-commercial use. The reasons for this is simple: the D 
community is not large enough to keep a commercial vendor from 
improving the language semantics. There is no installed base...


I don't think that would be a bad thing either... It would not 
kill D, it would just create a newD.

Re: An idea for commercial support for D

[Zach the Mystic via Digitalmars-d]

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.


The notion is that individual developers could work on patches 
to fix bugs or add features to ldc/druntime/phobos then sell 
those closed patches to paying customers.  After enough time 
has passed, so that sufficient customers have adequately paid 
for the work or after a set time limit beyond that, the patch 
is open sourced and merged back upstream.  It would have to be 
ldc and not dmd, as the dmd backend is not open source and the 
gdc backend license doesn't allow such closed patches.


A funny scenario based on this proposal: Company A wants feature 
B, and signs a contract with a developer for a certain amount, 
receiving the feature as soon as possible, releasing the paid-for 
software to the public after a year. During that year, company C 
comes to the same developer wanting the same feature. They say, 
It's already paid for, but you can pay company A half the 
development cost, minus the proportion of time left before it's 
open to everyone, and you can both have it! Or something like 
that.

Re: An idea for commercial support for D

[anonymous via Digitalmars-d]

On Tuesday, 6 January 2015 at 06:14:37 UTC, Joakim wrote:
On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

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


In the first option, you pay for a fix now, or you get it for 
free when it's done independently of you, e.g. because someone 
else paid.
In the second option, you pay for a fix. If it's done 
independently of you, you still pay.


[...]
I also think you assume far too much value on the part of 
privileged/early access to bugfixes.  A bug in a programming 
language toolchain is either a commercial problem for you or 
it isn't.  If it's a commercial problem, you need it fixed, 
and that fix in itself has a value to you.  There is not 
really any comparable change in value if that fix also gets 
delivered to other users (who may or may not be competitors of 
yours), because that isn't what differentiates your product.


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.


If I get him right, Joseph's point is that the patch's value (not 
its cost) for the customer doesn't change whether others have 
access to it or not. So there's no advantage for the customer in 
the early-access model. But there's a disadvantage: have to pay 
for every patch. And so, an early-access model may not be 
attractive to paying customers.


If I get you right, you're saying that the revenue for the patch 
writer changes depending on if they sell the patch once or twice. 
And therefore, there's an advantage for the patch writer in the 
early-access model: can sell one patch multiple times.


You're both not wrong. If it works as planned, the early-access 
isn't benefitial to the buyer, but to the seller. And that's the 
point: move (more) money from customers to patch writers. It's 
not a win-win. It's not supposed to be. But if there's nothing 
to gain in an early-access for the customer, why should they 
prefer it over a competitor with immediate-access-for-everyone?


[...]
On the contrary, D is a programming language, and as such is 
used by people to make commercial projects, and so those 
people have a very strong interest in paying for commercial 
support, based around the principle If we need something 
fixed, it will be fixed.


But they don't have an interest in a situation where, If 
something gets fixed, we have to pay.


The first of those options delivers value.  The second is 
exploitation.


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.  If your point is that 
in the first model they're paying up front through a support 
subscription, whereas in the second model they're paying after 
they identify the fix- a distinction I'm stretching to find as 
you haven't really made it- both are still paying for a fix.


In the first model, they pay for specific fixes and get any 
others for free.

In the second model, they pay for all fixes.

I think calling it exploitation may have been a bit inciting, 
but I can understand the concern. Charging for bug fixes is a bit 
shady, when we introduced the bugs ourselves.


And the whole thing could put off existing users, maybe even 
contributors. Especially when core developers would work on the 
early-access patches, the larger community could feel left out in 
the rain.

Re: An idea for commercial support for D

[anonymous via Digitalmars-d]

On Tuesday, 6 January 2015 at 19:46:51 UTC, Joakim wrote:

On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:

[...]
I don't know of any commercial support model where you only pay 
for the fixes you need at any given moment and the fixes that 
others paid for are provided to you for free.


I'm not knowledgeable about any of this business stuff, and I 
don't mean to pretend I am. I just wanted to clarify what I think 
Joseph meant there, as I understood it.


As far as I know there are companies that employ developers to 
work on open source software, with their patches open-sourced 
immediately. I'm assuming the employer can direct where exactly 
the effort goes. That's essentially it, no?


 I presume you're referring to support subscriptions, where you 
pay a monthly fee to subscribe to an stream of ongoing fixes 
and pay extra for fixes you need right away.  But that's not 
free, you're paying a monthly fee for that ongoing 
subscription, which subsidizes the cost of those fixes that 
others paid for first.


No, I didn't have that in mind.

[...]
My point was that he's wrong that the patch's value doesn't 
change if others have access to it.  Just because that patch 
doesn't clearly differentiate your product on a spec sheet 
doesn't mean those patches in aggregate don't differentiate 
your time to market and cost of making the product, which will 
all affect your bottom line.


So, the point is that competitors can't leech off my paid 
patches, right? I mean, sure, that's a thing. I'm definitely not 
business enough to put a number on it. Seems like the number you 
put on it is higher than the one Joseph puts on it.


There is no disadvantage to paying for the patch in this model, 
because otherwise you don't get the patch.  You are paying 
someone to write the patch so that it exists in the first 
place.  Otherwise, you can hope that some OSS dev gets to it 
someday when he gets some spare time.


The counter-proposal is not to rely on the free (as in beer) 
devs, but to hire someone to write OSS patches. This would of 
course allow your competition to leech off of you. But if others 
do the same, the benefits may be greater than if everyone is 
protective of their stuff. Again, I don't want to pretend to know 
what's best business-wise.


[...]
It _is_ win-win, that's the whole point.  It's even 
win-win-win, to crib a term from The Office, ;) because the OSS 
project eventually also gets the patch after a delay.


I don't think the win for the customer is so clear. The win 
that your competitors have to pay, too, seems rather slim to me 
(remember, not a business guy). And if competitors would buy 
patches collectively, eliminating the need for an exclusive 
access period, they could be better off than when each of them 
pays for it separately. But this may not be realistic, of course.


I don't know who this hypothetical competitor is who provides 
immediate-access-for-everyone and is cranking out a ton of 
patches.  They currently don't exist.


Neither exists at the moment for D. It's all hypothetical.

[...]
I think calling it exploitation may have been a bit 
inciting, but I can understand the concern. Charging for bug 
fixes is a bit shady, when we introduced the bugs ourselves.


Who is the we?  Paid devs fixing bugs in the existing OSS 
project that were introduced by OSS devs is not a we.


The OSS devs is we. If others write the patches that argument 
doesn't apply, of course.


And the whole thing could put off existing users, maybe even 
contributors. Especially when core developers would work on 
the early-access patches, the larger community could feel left 
out in the rain.


Who cares.  First off, D's core OSS devs have given no 
indication they'd be interested in working on such paid 
patches, so the paid devs would likely be a completely separate 
group.


If it's not current developers selling the patches, then I think 
it's much less likely to back-fire.


Even if some of the existing OSS devs wrote some paid patches, 
the D OSS project exists because of the generosity of Walter, 
Andrei, Kenji, and a couple dozen other volunteer contributors 
who give away their work for free under an OSS license.  To 
suggest that they are therefore bound to always provide future 
patches for free is frankly ridiculous.  They could all just 
stop working on D tomorrow, they have no responsibility to keep 
providing all this free work.


Similarly, they have no responsibility to not sell some patches 
to paying customers, simply because some spoiled handful will 
throw a hissy fit because they're not getting _everything_ for 
free anymore.  If they really want those patches, they can pay 
for them or write them themselves.


It's not so much about responsibilites, definitely not legal 
ones. It's more about keeping good relations with the community. 
I'm also thinking more about minor/occasional contributors, like 
myself, not so much about pure consumers (or potential 

Re: An idea for commercial support for D

[uri via Digitalmars-d]

On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote:

Before you make such claims, you should probably think about 
them a little bit first.  Please tell me one company that does 
not buy outside commercial software which they then use to 
build their own products.  Some companies will want to cherry 
pick features, others will just buy an accumulated patchset 
against the point release from many devs.  The suggestion that 
all companies will have to spend a great deal of time picking 
what patches they want is just silly.


To me it doesn't make sense for a company to cherry pick compiler 
patches. The model you propose may work for applications where 
there is a clean distinction between user needs and wants but in 
a compiler you generally need all the features to work 
effectively and produce reasonable code. The optimizer may be a 
different story so perhaps that aspect of compilation could be 
split.


Besides splitting the compiler will result in a maintenance 
headache. Missing features in the compiler will not result in 
subset-D and complete-D but half-baked-nearly-working-D and 
working-D, if you're lucky.




This means A and B can't make any money off their patches, so 
they have to get some other job. That means they only have time 
to work on M and X on the occasional weekend and each of those 
patches takes six months to finish.  You are obviously okay 
with that glacial pace as long as you get their work for free, 
but others are willing to pay to get the pace of D development 
sped up.


This is only true if all patches are equally priced. Otherwise it 
breaks down and has been proven mathematically.



Glad you brought this up, there are several possibilities.  
Many users would probably just buy all the closed patches 
against a point release, so there is no question of splitting 
features.  But a handful of paying customers may be more 
adventurous, or cheap, ;) and choose to only buy a custom build 
with their needed features X,Y,Z.  This probably wouldn't 
happen right away, as it will take more time to setup a build 
process to support it, but supporting custom builds like that 
is definitely worthwhile.


OK, but the D devs still need to split the release between paid 
patches and non-paid patches. This is non-trivial in a compiler 
and adds additional work for the volunteers. Companies won't pay 
for the split because it isn't value adding for them so it will 
fall on the volunteers.


To begin with, D is not a GPL project, so why would they 
release them under the GPL?


So we wait some time period for the patch to be released.

As stated earlier, the patches would need to be funded up to 
some monetary and time limits before they would be released 
back to the OSS project.  So party A might contract with their 
paying customers that they'll release patches X,Y,Z once they 
accumulate $5k in payments from all the customers who buy those 
patches, plus a six month delay after that.  If they don't make 
$5k for a long time, the patches won't be released for a long 
time.


Then I think most OSS users would move on to another language. 
There is no point working with a compiler that is half-baked 
unless you pay for it. This is an issue because it's the OSS 
community that provides ongoing maintenance to the paid for 
patches. If OSS isn't there anymore then Digital Mars needs to 
start charging maintenance costs to upkeep the codebase. I don't 
think that will work, but it's only my opinion.


Why does anyone pay for software now?  It doesn't much matter 
to a paying customer that the feature will probably be free in 
a year or two if they need to use it to make money _now_.


But that's assuming an entity needs D to make money now. They 
don't because we have C++, Java, C# already. Why not just use one 
of those more mature languages?




As for people leaving because somebody else has developed a 
proprietary feature for D and not given it to them for free, 
companies like Sociomantic have already developed such features 
and they haven't been integrated upstream, why haven't most 
left already?


The features from Sociomantic features are all D1 and also there 
are devs from Sociomantic are trying to get features released 
upstream. Sociomantic isn't the blocker it's integrating the 
features into D2.



The dmd backend is not under an OSS license, why haven't they 
left?  I suspect there are not very many of the type of people 
you're talking about in the D community.


It's possible that you're right but I don't see it happening. The 
backend doesn't provide any benefit to GDC and LDC and Walter has 
a very good reason for closing the backend sources which is 
understood by all.


Maybe a handful of FOSS zealots would leave, but the resulting 
commercially supported D would be so much better, they'd be 
swamped by the new people coming on board. :)


We'll see :)

Cheers,
uri

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:

On Tuesday, 6 January 2015 at 06:14:37 UTC, Joakim wrote:
On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

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


In the first option, you pay for a fix now, or you get it for 
free when it's done independently of you, e.g. because someone 
else paid.


I don't know of any commercial support model where you only pay 
for the fixes you need at any given moment and the fixes that 
others paid for are provided to you for free.  I presume you're 
referring to support subscriptions, where you pay a monthly fee 
to subscribe to an stream of ongoing fixes and pay extra for 
fixes you need right away.  But that's not free, you're paying 
a monthly fee for that ongoing subscription, which subsidizes the 
cost of those fixes that others paid for first.


In the second option, you pay for a fix. If it's done 
independently of you, you still pay.


You pay for both types of fixes in both models.


[...]
I also think you assume far too much value on the part of 
privileged/early access to bugfixes.  A bug in a programming 
language toolchain is either a commercial problem for you or 
it isn't.  If it's a commercial problem, you need it fixed, 
and that fix in itself has a value to you.  There is not 
really any comparable change in value if that fix also gets 
delivered to other users (who may or may not be competitors 
of yours), because that isn't what differentiates your 
product.


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.


If I get him right, Joseph's point is that the patch's value 
(not its cost) for the customer doesn't change whether others 
have access to it or not. So there's no advantage for the 
customer in the early-access model. But there's a disadvantage: 
have to pay for every patch. And so, an early-access model may 
not be attractive to paying customers.


My point was that he's wrong that the patch's value doesn't 
change if others have access to it.  Just because that patch 
doesn't clearly differentiate your product on a spec sheet 
doesn't mean those patches in aggregate don't differentiate your 
time to market and cost of making the product, which will all 
affect your bottom line.


There is no disadvantage to paying for the patch in this model, 
because otherwise you don't get the patch.  You are paying 
someone to write the patch so that it exists in the first place.  
Otherwise, you can hope that some OSS dev gets to it someday when 
he gets some spare time.


If I get you right, you're saying that the revenue for the 
patch writer changes depending on if they sell the patch once 
or twice. And therefore, there's an advantage for the patch 
writer in the early-access model: can sell one patch multiple 
times.


Yes, that's one of the big benefits, the patches become his 
product.


You're both not wrong. If it works as planned, the early-access 
isn't benefitial to the buyer, but to the seller. And that's 
the point: move (more) money from customers to patch writers. 
It's not a win-win. It's not supposed to be. But if there's 
nothing to gain in an early-access for the customer, why should 
they prefer it over a competitor with 
immediate-access-for-everyone?


It _is_ win-win, that's the whole point.  It's even win-win-win, 
to crib a term from The Office, ;) because the OSS project 
eventually also gets the patch after a delay.


I don't know who this hypothetical competitor is who provides 
immediate-access-for-everyone and is cranking out a ton of 
patches.  They currently don't exist.



[...]
On the contrary, D is a programming language, and as such is 
used by people to make commercial projects, and so those 
people have a very strong interest in paying for commercial 
support, based around the principle If we need something 
fixed, it will be fixed.


But they don't have an interest in a situation where, If 
something gets fixed, we have to pay.


The first of those options delivers value.  The second is 
exploitation.


I suggest you actually read what you're writing:

people have a very strong interest in paying for commercial 
support, 

Re: An idea for commercial support for D

[Joseph Rushton Wakeling via Digitalmars-d]

On 06/01/15 23:32, uri via Digitalmars-d wrote:

The dmd backend is not under an OSS license, why haven't they left?  I suspect
there are not very many of the type of people you're talking about in the D
community.


It's possible that you're right but I don't see it happening. The backend
doesn't provide any benefit to GDC and LDC and Walter has a very good reason for
closing the backend sources which is understood by all.


Small point: the DMD backend may not be released under a free software license, 
but it is not closed -- the source is available, development happens in the 
open, and in a de facto (rather than de jure) sense there is little to 
distinguish from an open source project.  The licensing situation is obviously 
unfortunate, but it makes little practical difference considering that the vast 
majority of D language development is in the freely-licensed frontend, runtime 
or standard library, and there are two excellent free backends available.


This is a pretty good example of what I have referred to elsewhere in this 
thread, about the contextual nature of objections to non-free.

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

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

On 05/01/15 21:57, Joakim via Digitalmars-d wrote:
If you're not paying, you're not a customer.  The alternative 
is to use the
bug-ridden OSS implementation you're using now for free, and 
not have a paid
version for those who want those bugs fixed.  I don't doubt 
that some irrational
people interpret the existence of a paid version in the way 
you laid out, and in
extreme cases that _can_ happen (just as there are OSS vendors 
who write bad OSS
code just so they can make more money off your favored support 
model), but
that's more an issue with their sloppy thinking than anything 
else.


See, this is where I find _your_ point of view irrational, 
because you fail to see how straightforwardly damaging closed 
source can be to adoption.  The fact of the matter is that for 
a great many users, and particularly for a great many corporate 
adopters of development toolchains, today it matters hugely 
that the toolchain is free-as-in-freedom.  Not free 6 months 
down the line -- free, now, in its entirety.


Non-free code (even temporarily), secret development, etc., are 
simply deal-breakers for a great many people.  A smart business 
model will engage with this fact and find a way to drive money 
to development without closing things up.


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.


There are also fully open source languages which are fully 
commercially
supported.  How do your managers wrap their minds around such 
a paradox? ;)


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


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.


My point is that such artificial distinctions are silly, 
whether because of the
amount of support or source available.  The alternative to 
paid bug fixes is not
that all the bugs you want fixed get done for free: it's _no_ 
bug fixes, as we
see today. For example, selective imports at module scope has 
been broken for
more than eight years now, as those symbols are leaked into 
any module that
imports the module with the selective import. There are many 
more bugs like
that, that could actually be fixed much faster if there were 
more paid devs

working on D.


You're talking about the alternative to paid bug fixes as if 
the only way of having paid bug fixes is to follow your model 
of locking them away from the wider community.  That's simply 
not true.


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.


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.


A company is not going to just write a bunch of patches and 
open source all of
them unless they have some complementary business model to go 
with it, whether
google making more mobile revenue off Android or Apple 
providing clang as the

system compiler on OS X and making money off the bundled Mac.


So why not focus on creating those complementary business 
models?


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.  This is why google doesn't care that much 
if AOSP and 

Re: An idea for commercial support for D

[Joseph Rushton Wakeling via Digitalmars-d]

On 05/01/15 21:57, Joakim via Digitalmars-d wrote:

If you're not paying, you're not a customer.  The alternative is to use the
bug-ridden OSS implementation you're using now for free, and not have a paid
version for those who want those bugs fixed.  I don't doubt that some irrational
people interpret the existence of a paid version in the way you laid out, and in
extreme cases that _can_ happen (just as there are OSS vendors who write bad OSS
code just so they can make more money off your favored support model), but
that's more an issue with their sloppy thinking than anything else.


See, this is where I find _your_ point of view irrational, because you fail to 
see how straightforwardly damaging closed source can be to adoption.  The fact 
of the matter is that for a great many users, and particularly for a great many 
corporate adopters of development toolchains, today it matters hugely that the 
toolchain is free-as-in-freedom.  Not free 6 months down the line -- free, now, 
in its entirety.


Non-free code (even temporarily), secret development, etc., are simply 
deal-breakers for a great many people.  A smart business model will engage with 
this fact and find a way to drive money to development without closing things up.



There are also fully open source languages which are fully commercially
supported.  How do your managers wrap their minds around such a paradox? ;)


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.


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.


My point is that such artificial distinctions are silly, whether because of the
amount of support or source available.  The alternative to paid bug fixes is not
that all the bugs you want fixed get done for free: it's _no_ bug fixes, as we
see today. For example, selective imports at module scope has been broken for
more than eight years now, as those symbols are leaked into any module that
imports the module with the selective import. There are many more bugs like
that, that could actually be fixed much faster if there were more paid devs
working on D.


You're talking about the alternative to paid bug fixes as if the only way of 
having paid bug fixes is to follow your model of locking them away from the 
wider community.  That's simply not true.



Having both paid and free versions available is not a paywall on a language.


Unless those versions are identical, yes it is.


A company is not going to just write a bunch of patches and open source all of
them unless they have some complementary business model to go with it, whether
google making more mobile revenue off Android or Apple providing clang as the
system compiler on OS X and making money off the bundled Mac.


So why not focus on creating those complementary business models?


That community involvement would still be there for the OSS core with D, but you
would get support for a closed patch from the developer who wrote it.

...

There is essentially nothing different from this situation and the hybrid model
I've described, in terms of the product you'd be using.  The only difference is
that it wouldn't be a company, but some selection of independent devs.


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.


However, I don't see it making any sense for a company to invest in proprietary 
patches to a toolchain, because 99% of the time, when you need a patch written, 
it's a bugfix.  And when you want a bugfix, you don't want a patch that applies 
only to your version of the toolchain and which you (or your friendly 
proprietary-patch-writing consultant) have to keep rebasing on top of upstream 
for the next 6 months -- you want upstream fixed.  Otherwise you'll wind up 
paying far more merely for maintenance of your proprietary extensions, than you 
would have just to get someone to write a patch and get it straight into the 
open-source upstream.


I also think you assume far too much value on the part of privileged/early 
access to bugfixes.  A bug in a programming language toolchain is either a 
commercial problem for you or it isn't.  If it's a commercial problem, you need 
it fixed, and that fix in itself has a value to you.  There is not really any 
comparable change in value if that 

Re: An idea for commercial support for D

[Daniel Murphy via Digitalmars-d]

Joseph Rushton Wakeling via Digitalmars-d  wrote in message 
news:mailman.4177.1420498284.9932.digitalmar...@puremagic.com...



 A company is not going to just write a bunch of patches and open source 
 all of
 them unless they have some complementary business model to go with it, 
 whether
 google making more mobile revenue off Android or Apple providing clang 
 as the

 system compiler on OS X and making money off the bundled Mac.


However, I don't see it making any sense for a company to invest in 
proprietary patches to a toolchain, because 99% of the time, when you need 
a patch written, it's a bugfix.  And when you want a bugfix, you don't 
want a patch that applies only to your version of the toolchain and which 
you (or your friendly proprietary-patch-writing consultant) have to keep 
rebasing on top of upstream for the next 6 months -- you want upstream 
fixed.  Otherwise you'll wind up paying far more merely for maintenance of 
your proprietary extensions, than you would have just to get someone to 
write a patch and get it straight into the open-source upstream.


This is very important - upstreaming your patches means that the community 
will maintain them for you.  This is why it's useful for a company to 
develop their own patches and still contribute back upstream. 

Re: An idea for commercial support for D

[Jarrett Tierney via Digitalmars-d]

As a user of D in a corporate environment and personal at home 
environment, I have to say this model won't work for me. In fact 
if this model were implemented, I would more than likely have to 
move my project to a different language because of it. Let me 
explain the issues I see here.


You've proposed a hybrid open and closed source model. Where 
certain segments of code (latest patches) are behind a per patch 
paywall. As a customer I don't want to have to pay for each bug 
fix in the compiler. If there is a bug in the language/compiler 
then I want it fixed. I shouldn't be charged to have the language 
I'm using work properly. It basically says to customers, here you 
can use this language for free, unless you want it to work 
properly, in which case you need to pay for each fix you need or 
wait till developers don't care about making money off a fix 
anymore.


This will also diminish the growth rate of D. I can tell you, it 
would be significantly harder for me to use D at my workplace if 
this model were in place. Managers are okay in letting me use D 
because its an open source project (minus the backend of DMD) and 
it doesn't cost them a cent. If all of the sudden I have to ask 
them to pay for fixes in order for my project to work, that makes 
it a different situation entirely. My company would also frown on 
the free option of waiting for fixes to pass out of the pay wall. 
Companies like actively supported projects. As such, companies 
(at least the one I work for) prefer either fully commercially 
supported languages (C# through VS) or fully open source.


Remember, that there are ways to provide commercial support 
without putting a paywall on using the language itself. What is 
really needed here is buy-in from corporations on the language. 
Having engineers from a company working on D would provide one 
form of commercial support. But this model is very difficult to 
find and the closest to it I've seen is Facebook's involvement 
with D. I agree having developers who are paid to work on D would 
be a great thing, but reaching that point is a very difficult 
road.


While I understand, that D needs some form of commercial support 
for some parties, there is also a stigma that the current model 
doesn't provide support. I've found to the contrary actually. I 
find the full open source model employed here, has a better 
support system than a lot of other commercial support models. The 
reason is the community, there is always someone around to answer 
a question. I find with most commercially supported models the 
development team can't be reached and you have to depend on your 
coworkers or friends who may know of a workaround (Microsoft 
model). Most of the time I see bugs get fixed fairly promptly for 
a compiler project despite the fragmented development that is 
inherent to open source projects.


I think commercial support for D really comes down to one of two 
situations in the future:


* A company decides to make a commercial D compiler that is 
closed source but compatible with phobos, etc. They fully support 
the compiler. (Doesn't necessarily mean they charge for the 
compiler itself, they could but they can also charge for support 
plans and/or a IDE tool).
* A company decides to invest engineers in working on the open 
source D compiler. Thus providing commercially supported 
developers to the project. (This would be a hybrid too, where the 
open source developers can still contribute and work but now 
there are a group of paid engineers working to advance the 
language as well).


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.


The notion is that individual developers could work on patches 
to fix bugs or add features to ldc/druntime/phobos then sell 
those closed patches to paying customers.  After enough time 
has passed, so that sufficient customers have adequately paid 
for the work or after a set time limit beyond that, the patch 
is open sourced and merged back upstream.  It would have to be 
ldc and not dmd, as the dmd backend is not open source and the 
gdc backend license doesn't allow such closed patches.


This works better than bounties because it avoids the tragedy 
of the commons problem inherent to open source and bounties, 
ie any user can just wait for some other contributor or any 
potential individual paying customer has an incentive to wait 
and let somebody else pay a bounty, then use the resulting work 
for free right away.  With this approach, non-paying users only 
get the resulting paid work after the work has been paid for 
and perhaps an additional delay after that.


Two big benefits come out of this approach.  Obviously, this 
would provide commercial support for paying customers, but the 
other big benefit is that it doesn't depend on some company 
providing that support.  A decentralized group of 

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Monday, 5 January 2015 at 18:28:39 UTC, Jarrett Tierney wrote:
As a user of D in a corporate environment and personal at home 
environment, I have to say this model won't work for me. In 
fact if this model were implemented, I would more than likely 
have to move my project to a different language because of it. 
Let me explain the issues I see here.


You've proposed a hybrid open and closed source model. Where 
certain segments of code (latest patches) are behind a per 
patch paywall. As a customer I don't want to have to pay for 
each bug fix in the compiler. If there is a bug in the 
language/compiler then I want it fixed. I shouldn't be charged 
to have the language I'm using work properly. It basically says 
to customers, here you can use this language for free, unless 
you want it to work properly, in which case you need to pay for 
each fix you need or wait till developers don't care about 
making money off a fix anymore.


If you're not paying, you're not a customer.  The alternative is 
to use the bug-ridden OSS implementation you're using now for 
free, and not have a paid version for those who want those bugs 
fixed.  I don't doubt that some irrational people interpret the 
existence of a paid version in the way you laid out, and in 
extreme cases that _can_ happen (just as there are OSS vendors 
who write bad OSS code just so they can make more money off your 
favored support model), but that's more an issue with their 
sloppy thinking than anything else.


This will also diminish the growth rate of D. I can tell you, 
it would be significantly harder for me to use D at my 
workplace if this model were in place. Managers are okay in 
letting me use D because its an open source project (minus the 
backend of DMD) and it doesn't cost them a cent. If all of the 
sudden I have to ask them to pay for fixes in order for my 
project to work, that makes it a different situation entirely. 
My company would also frown on the free option of waiting for 
fixes to pass out of the pay wall. Companies like actively 
supported projects. As such, companies (at least the one I work 
for) prefer either fully commercially supported languages (C# 
through VS) or fully open source.


There are also fully open source languages which are fully 
commercially supported.  How do your managers wrap their minds 
around such a paradox? ;)


My point is that such artificial distinctions are silly, whether 
because of the amount of support or source available.  The 
alternative to paid bug fixes is not that all the bugs you want 
fixed get done for free: it's _no_ bug fixes, as we see today.  
For example, selective imports at module scope has been broken 
for more than eight years now, as those symbols are leaked into 
any module that imports the module with the selective import.  
There are many more bugs like that, that could actually be fixed 
much faster if there were more paid devs working on D.


Remember, that there are ways to provide commercial support 
without putting a paywall on using the language itself. What is 
really needed here is buy-in from corporations on the language. 
Having engineers from a company working on D would provide one 
form of commercial support. But this model is very difficult to 
find and the closest to it I've seen is Facebook's involvement 
with D. I agree having developers who are paid to work on D 
would be a great thing, but reaching that point is a very 
difficult road.


Having both paid and free versions available is not a paywall 
on a language.  A company is not going to just write a bunch of 
patches and open source all of them unless they have some 
complementary business model to go with it, whether google making 
more mobile revenue off Android or Apple providing clang as the 
system compiler on OS X and making money off the bundled Mac.


While I understand, that D needs some form of commercial 
support for some parties, there is also a stigma that the 
current model doesn't provide support. I've found to the 
contrary actually. I find the full open source model employed 
here, has a better support system than a lot of other 
commercial support models. The reason is the community, there 
is always someone around to answer a question. I find with most 
commercially supported models the development team can't be 
reached and you have to depend on your coworkers or friends who 
may know of a workaround (Microsoft model). Most of the time I 
see bugs get fixed fairly promptly for a compiler project 
despite the fragmented development that is inherent to open 
source projects.


That community involvement would still be there for the OSS core 
with D, but you would get support for a closed patch from the 
developer who wrote it.


I think commercial support for D really comes down to one of 
two situations in the future:


* A company decides to make a commercial D compiler that is 
closed source but compatible with phobos, etc. They fully 
support the compiler. (Doesn't 

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 4 Jan 2015 08:35, Joakim via Digitalmars-d digitalmars-d@puremagic.com
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.

 The notion is that individual developers could work on patches to fix
bugs or add features to ldc/druntime/phobos then sell those closed patches
to paying customers.  After enough time has passed, so that sufficient
customers have adequately paid for the work or after a set time limit
beyond that, the patch is open sourced and merged back upstream.  It would
have to be ldc and not dmd, as the dmd backend is not open source and the
gdc backend license doesn't allow such closed patches.


Do what you want, but I don't think you could or should call it D from the
moment you deviate.


 http://www.phoronix.com/scan.php?page=articleitem=sprewell_licensing

There's no such thing as a hybrid.  You're either a cathedral or a bazaar,
and a hybrid approach is looking pretty cathedral to me.

From a technical standpoint, how do you propose to deal with splitbrain
situations?  If your proposed closed solution is source-incompatible with
the open then you have failed as a model.

From a pragmatic (though maybe philosophical) standpoint, having been in
active development in or around the core for 4 years, my observation (which
I believe Walter shared as well) is that back when DMD was partially
closed, there just wasn't much traction in development or adoption.  Right
now things are moving pretty fast, and I don't think DMD *can* get any more
open than what it already is.  Given the compelling correlation between
both popularity and contribution with the openness of development at the
core (ie: moving to github), history tells us that closing will only serve
to stifle and stop.

Regards
Iain.

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via 
Digitalmars-d wrote:
On 4 Jan 2015 08:35, Joakim via Digitalmars-d 
digitalmars-d@puremagic.com

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.


The notion is that individual developers could work on patches 
to fix
bugs or add features to ldc/druntime/phobos then sell those 
closed patches
to paying customers.  After enough time has passed, so that 
sufficient
customers have adequately paid for the work or after a set time 
limit
beyond that, the patch is open sourced and merged back 
upstream.  It would
have to be ldc and not dmd, as the dmd backend is not open 
source and the

gdc backend license doesn't allow such closed patches.




Do what you want, but I don't think you could or should call it 
D from the

moment you deviate.


I'm not doing anything, I'm putting an idea out here for 
consideration.  I'm uninterested in doing this on my own and 
seeding such paid patches entirely by myself, so if there aren't 
enough people interested in both paid development and paying for 
patches, it won't get done.


As for what to call it, ldc and gdc both differ from dmd in 
non-trivial ways and still call themselves D compilers.  I don't 
think the name really matters, but for what it's worth, I agree 
with you that if such a commercial model goes in a completely 
different direction with the language, a name change is probably 
best.



http://www.phoronix.com/scan.php?page=articleitem=sprewell_licensing


There's no such thing as a hybrid.  You're either a cathedral 
or a bazaar,

and a hybrid approach is looking pretty cathedral to me.


Tell that to the most widely used open-source projects these 
days, ie hybrid projects like Android, iOS/OS X, llvm/clang, 
Chrome, etc.  There are advantages to both the cathedral and the 
bazaar model, which is why it's best to mate the two, as has been 
done by the listed highly successful software.


From a technical standpoint, how do you propose to deal with 
splitbrain
situations?  If your proposed closed solution is 
source-incompatible with

the open then you have failed as a model.


Not sure if you're referring to users' D source that can't be 
compiled by both compilers or patches from the closed D frontend 
that might be difficult to merge back upstream into the dmd 
frontend.  Obviously both can be handled with some effort.  Since 
the idea is not to completely fork the frontend but to provide 
patches on it that are eventually upstreamed, I doubt either will 
be a problem.


From a pragmatic (though maybe philosophical) standpoint, 
having been in
active development in or around the core for 4 years, my 
observation (which
I believe Walter shared as well) is that back when DMD was 
partially
closed, there just wasn't much traction in development or 
adoption.  Right
now things are moving pretty fast, and I don't think DMD *can* 
get any more
open than what it already is.  Given the compelling correlation 
between
both popularity and contribution with the openness of 
development at the
core (ie: moving to github), history tells us that closing will 
only serve

to stifle and stop.


Was Walter selling a paid compiler with the then-closed dmd 
backend?  If not, the comparison is not valid.  The idea here is 
for paying customers to fund closed patches for a limited time, 
and speed up D bug-fixing and development much more.  If Walter 
was not getting paid for his closed backend but only keeping it 
closed because of licensing issues, the situations are completely 
different.


Also, this is a _hybrid_ approach, not a closed one.  There will 
always be an OSS core that potential devs can look at.  They just 
may not have access to all the closed-source patches that others 
are selling.


Recent history of the explosively successful hybrid projects I 
listed suggests that a hybrid approach is the most scalable one.

Re: An idea for commercial support for D

[Martin Nowak via Digitalmars-d]

On 01/04/2015 09:31 AM, Joakim wrote:


The notion is that individual developers could work on patches to fix
bugs or add features to ldc/druntime/phobos then sell those closed
patches to paying customers.  After enough time has passed, so that
sufficient customers have adequately paid for the work or after a set
time limit beyond that, the patch is open sourced and merged back
upstream.  It would have to be ldc and not dmd, as the dmd backend is
not open source and the gdc backend license doesn't allow such closed
patches.


I don't think anyone has an interest of closed patches.
Building a point release with the bug fixed might be of more interest.

Re: An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 4 January 2015 at 14:50, Joakim via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via Digitalmars-d
 wrote:

 On 4 Jan 2015 08:35, Joakim via Digitalmars-d
 digitalmars-d@puremagic.com
 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.


 The notion is that individual developers could work on patches to fix

 bugs or add features to ldc/druntime/phobos then sell those closed patches
 to paying customers.  After enough time has passed, so that sufficient
 customers have adequately paid for the work or after a set time limit
 beyond that, the patch is open sourced and merged back upstream.  It would
 have to be ldc and not dmd, as the dmd backend is not open source and the
 gdc backend license doesn't allow such closed patches.



 Do what you want, but I don't think you could or should call it D from the
 moment you deviate.


 I'm not doing anything, I'm putting an idea out here for consideration.  I'm
 uninterested in doing this on my own and seeding such paid patches entirely
 by myself, so if there aren't enough people interested in both paid
 development and paying for patches, it won't get done.

 As for what to call it, ldc and gdc both differ from dmd in non-trivial ways
 and still call themselves D compilers.  I don't think the name really
 matters, but for what it's worth, I agree with you that if such a commercial
 model goes in a completely different direction with the language, a name
 change is probably best.


Right - though I may just point out that the differences between ldc,
gdc, dmd are more from a low-level perspective.  Want access to simd
intrinsics?  Sure different compilers expose different intrinsics, but
at least you can distinguish between who implemented what -
version(D_SIMD)? This compiler implements __simd; version(GNU)? This
compiler has a gcc.builtins module, etc.

The exact same is with any other bare-metal features.  Inline ASM?
There's version(D_InlineAsm) and _x86 and _x86_64 variants for being
able to test whether or not this compiler supports that.  Whereas
version(GNU_InlineAsm) means that we are using a compiler that
implements GCC extended assembler.

Is this annoying?  For a user writing a library, I would say Yes, but
only if your work requires stepping outside the language norms.
Annoyance also extends out to maintainers too (I could write a book
about Where DMD went wrong? Some more of DMD's greatest mistakes, and
Just who is this DMD compiler anyway?)


 http://www.phoronix.com/scan.php?page=articleitem=sprewell_licensing


 There's no such thing as a hybrid.  You're either a cathedral or a bazaar,
 and a hybrid approach is looking pretty cathedral to me.


 Tell that to the most widely used open-source projects these days, ie hybrid
 projects like Android, iOS/OS X, llvm/clang, Chrome, etc.  There are
 advantages to both the cathedral and the bazaar model, which is why it's
 best to mate the two, as has been done by the listed highly successful
 software.


At least three of those projects I would see as anything but bazaar.  :)

I can see this turning into a moral argument - one that will neither
be the first nor last, so I'll end with accepting my view is not
yours.

 From a technical standpoint, how do you propose to deal with splitbrain

 situations?  If your proposed closed solution is source-incompatible with
 the open then you have failed as a model.


 Not sure if you're referring to users' D source that can't be compiled by
 both compilers or patches from the closed D frontend that might be difficult
 to merge back upstream into the dmd frontend.  Obviously both can be handled
 with some effort.  Since the idea is not to completely fork the frontend but
 to provide patches on it that are eventually upstreamed, I doubt either will
 be a problem.


I was referring to patches from closed merging upstream.

One example would be, oh, DIP-25 being implemented in the closed
frontend - let's say Walter implemented it, then someone from the
community implements DIP-25 in a differing way and raises a PR a
couple months later.  Should the PR be accepted?  If it is should the
closed implementation be dropped?  Because of the closed nature
there's no way to compare which one is more technically sound than the
other.

There's also a question of timing too.  Obviously such an undertaking
shouldn't happen until the frontend switches to D, nor when there are
still plenty of visitor re-writes being done in the frontend.


 From a pragmatic (though maybe philosophical) standpoint, having been in

 active development in or around the core for 4 years, my observation
 (which
 I believe Walter shared as well) is that back when DMD was partially
 closed, there just wasn't much traction in development or adoption.  Right
 now things are moving pretty fast, and I don't think DMD *can* get any
 more
 open than what it 

An idea for commercial support for D

[Joakim via Digitalmars-d]

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.


The notion is that individual developers could work on patches to 
fix bugs or add features to ldc/druntime/phobos then sell those 
closed patches to paying customers.  After enough time has 
passed, so that sufficient customers have adequately paid for the 
work or after a set time limit beyond that, the patch is open 
sourced and merged back upstream.  It would have to be ldc and 
not dmd, as the dmd backend is not open source and the gdc 
backend license doesn't allow such closed patches.


This works better than bounties because it avoids the tragedy of 
the commons problem inherent to open source and bounties, ie any 
user can just wait for some other contributor or any potential 
individual paying customer has an incentive to wait and let 
somebody else pay a bounty, then use the resulting work for free 
right away.  With this approach, non-paying users only get the 
resulting paid work after the work has been paid for and perhaps 
an additional delay after that.


Two big benefits come out of this approach.  Obviously, this 
would provide commercial support for paying customers, but the 
other big benefit is that it doesn't depend on some company 
providing that support.  A decentralized group of devs could work 
on and get paid for these individual patches on their own, 
without having to get together and start a company.


I'm writing about this idea to see how much interest there is 
from D developers for doing such paid work and from paying 
customers to pay for such work.  For those who believe this isn't 
part of the open source aspect of D, it isn't.  This doesn't have 
to be a part of the D open source project, even if the work 
ultimately often ends up back in the official github repos, after 
a delay.


I believe this is the needed step to turn the D community from a 
tribe into an organization, as Andrei said recently.  More 
rationale about this hybrid licensing model can be found in this 
article I wrote almost five years ago:


http://www.phoronix.com/scan.php?page=articleitem=sprewell_licensing

Re: An idea for commercial support for D

[Jack via Digitalmars-d]

On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:



Two big benefits come out of this approach.  Obviously, this 
would provide commercial support for paying customers, but the 
other big benefit is that it doesn't depend on some company 
providing that support.  A decentralized group of devs could 
work on and get paid for these individual patches on their own, 
without having to get together and start a company.




Now to get those paying customers...

Re: An idea for commercial support for D

[Joakim via Digitalmars-d]

On Sunday, 4 January 2015 at 17:18:22 UTC, Iain Buclaw via 
Digitalmars-d wrote:

On 4 January 2015 at 14:50, Joakim via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Annoyance also extends out to maintainers too (I could write a 
book
about Where DMD went wrong? Some more of DMD's greatest 
mistakes, and

Just who is this DMD compiler anyway?)


I'd be interested in reading that, you should write it up 
somewhere.


Tell that to the most widely used open-source projects these 
days, ie hybrid
projects like Android, iOS/OS X, llvm/clang, Chrome, etc.  
There are
advantages to both the cathedral and the bazaar model, which 
is why it's
best to mate the two, as has been done by the listed highly 
successful

software.



At least three of those projects I would see as anything but 
bazaar.  :)


I'd say three are hybrids to varying degrees and iOS/OSX is 
largely cathedral nowadays, despite its bazaar BSD antecedents.



I was referring to patches from closed merging upstream.

One example would be, oh, DIP-25 being implemented in the closed
frontend - let's say Walter implemented it, then someone from 
the

community implements DIP-25 in a differing way and raises a PR a
couple months later.  Should the PR be accepted?  If it is 
should the

closed implementation be dropped?  Because of the closed nature
there's no way to compare which one is more technically sound 
than the

other.


There is no reason for the open source project to defer a PR 
because of closed patches that aren't available yet.  Once the 
closed patches are opened, the two implementations can be merged 
for their best aspects.


This is what happened with the AArch64 backend for llvm recently: 
devs were working on an OSS backend and Apple developed their own 
closed one quicker and shipped it for the recent port of iOS to 
64-bit.  Later, Apple opened up their closed backend, and the two 
were merged.  I believe they ended up going with the closed one 
and merging back pieces of the existing OSS one that they wanted.


There's also a question of timing too.  Obviously such an 
undertaking
shouldn't happen until the frontend switches to D, nor when 
there are

still plenty of visitor re-writes being done in the frontend.


I doubt either would preclude doing it now, as the closed patches 
would be continually rebased on the OSS frontend.


Was Walter selling a paid compiler with the then-closed dmd 
backend?  If
not, the comparison is not valid.  The idea here is for paying 
customers to
fund closed patches for a limited time, and speed up D 
bug-fixing and
development much more.  If Walter was not getting paid for his 
closed
backend but only keeping it closed because of licensing 
issues, the

situations are completely different.



For me, the comparison is between these key timelines:

- No source code
- D1 Frontend released as Artistic/GPL
- Backend released under restricted license
- Moving to Github
- Creating a 'core' team
- Everyone (even Walter!) switching over to the PR patch
submission/review system
- Re-license Frontend as Boost

Each point over a 14 year history has been a step in the 
direction of
being 'open' and each brought a boost in development.  The 
number of
changes between each release compared to back in 2.020 days is 
a clear

sign of this - as well as the three digit open PRs.


Your point seems to be that D moving from a one-man, closed 
project by Walter to an OSS project with several contributors 
greatly sped up its development.  Nobody is disputing that.


The question is how to attain the next level of growth, speeding 
it up a lot more, and I think this hybrid approach will do that.


On Sunday, 4 January 2015 at 16:54:17 UTC, Martin Nowak wrote:

On 01/04/2015 09:31 AM, Joakim wrote:
I don't think anyone has an interest of closed patches.
Building a point release with the bug fixed might be of more 
interest.


That's merely a matter of packaging, there are several ways it 
can be done with the closed patches.  Of course, initially only 
providing closed patches against the stable OSS point releases 
would be an easy way to start.