www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - An idea for commercial support for D

reply "Joakim" <dlang joakim.fea.st> writes:
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=article&item=sprewell_licensing
Jan 04 2015
next sibling parent "Jack" <Jackoz530 gmail.com> writes:
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...
Jan 04 2015
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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=article&item=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.



 Jan 04 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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=article&item=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.



 Jan 04 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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=article&item=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 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.


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.

Iain.



 Jan 04 2015



  parent  "Joakim" <dlang joakim.fea.st>  writes:


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.



 Jan 04 2015



prev sibling next sibling parent  Martin Nowak <code+news.digitalmars dawg.eu>  writes:


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.



 Jan 04 2015



prev sibling next sibling parent reply "Jarrett Tierney" <serates gmail.com>  writes:


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 


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 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=article&item=sprewell_licensing





 Jan 05 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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 

 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 necessarily mean they charge for 
 the compiler itself, they could but they can also charge for 
 support plans and/or a IDE tool).


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.


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


As I said above, this is unlikely.  Just because it has happened 
before with some OSS projects, many OSS users/devs fantasize that 
it will happen for their favored project.

IBM and Red Hat didn't contribute to linux because they believe 
in FOSS or wanted to "give back" to the community, but because 
they saw real economic advantages to leveraging an existing OS 
code base in their consulting/support businesses.  The GPL and 
the fact that their businesses distribute software to their 
customers made them give back their patches.  Meanwhile, google 
runs a patched linux kernel on a gazillion search servers and 
doesn't distribute their patches, because the license doesn't say 
they have to and they see no economic advantage to doing so.

D is not an OS like linux, so the consulting/support model 
doesn't apply.  While such free corporate investment is 
theoretically possible for D, it is very unlikely and as I 
mentioned in my linked article, such support models are not as 
successful.

Turning D into a paid product by using the hybrid model I laid 
out would make its development go much faster.  There would 
always be an OSS core for OSS devs to work on and for users to 
download for free, while those who want to pay for quality and 
features would do so.  It's similar to how other compiler vendors 
put out a free but less capable compiler and sell a more capable 
one.



 Jan 05 2015



  parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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 fix also gets delivered to other users (who 
may or may not be competitors of yours), because that isn't what differentiates 
your product.


 D is not an OS like linux, so the consulting/support model doesn't apply. 
While
 such free corporate investment is theoretically possible for D, it is very
 unlikely and as I mentioned in my linked article, such support models are not
as
 successful.


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.


 Turning D into a paid product by using the hybrid model I laid out would make
 its development go much faster.  There would always be an OSS core for OSS devs
 to work on and for users to download for free, while those who want to pay for
 quality and features would do so.  It's similar to how other compiler vendors
 put out a free but less capable compiler and sell a more capable one.


Name me an example of such a vendor that isn't a massive, huge corporate 
behemoth whose ability to sign contracts and make sales is largely dependent on 
business factors entirely separate from their product licensing.

I'm really happy that you're trying to think about how to generate money for D 
development, but I think your insistence on the necessity of selling closed 
components is based on a misunderstanding both of how free software flourishes 
and of the business factors at play in the projects you cite as inspiration.



 Jan 05 2015



 next sibling parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Joseph Rushton Wakeling via Digitalmars-d"  wrote in message 
news:mailman.4177.1420498284.9932.digitalmars-d 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. 



 Jan 05 2015



prev sibling  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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 Nexus devices are fairly buggy (I bought a Nexus 
device, will never buy one again for this reason), because they 
don't really make money off Android but off the complementary 
mobile ads.


 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.


Given all your other responses, I suspect this is not the case, 
ie you don't want to see it happen.  But you're right, nobody can 
stop paid devs from doing this.


 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.


These merging and rebasing issues you raise are fairly trivial.  
I've had PRs sit unmerged on github for many months and 
occasionally they'll go out of date with git HEAD.  Updating them 
to work again takes a negligible amount of time.  If paid devs 
only focus on point releases initially, as mentioned above, the 
problem doesn't really exist.


 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.


 D is not an OS like linux, so the consulting/support model 
 doesn't apply.  While
 such free corporate investment is theoretically possible for 
 D, it is very
 unlikely and as I mentioned in my linked article, such support 
 models are not as
 successful.


 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.  
Certainly some companies would prefer the financial certainty of 
up-front recurring subscriptions to paying on a case-by-case 
basis, just as some would prefer the potential savings of the 
latter model, but the former certainly wouldn't save them any 
money.


 Turning D into a paid product by using the hybrid model I laid 
 out would make
 its development go much faster.  There would always be an OSS 
 core for OSS devs
 to work on and for users to download for free, while those who 
 want to pay for
 quality and features would do so.  It's similar to how other 
 compiler vendors
 put out a free but less capable compiler and sell a more 
 capable one.


 Name me an example of such a vendor that isn't a massive, huge 
 corporate behemoth whose ability to sign contracts and make 
 sales is largely dependent on business factors entirely 
 separate from their product licensing.


I'm not sure what point you're trying to make, that only 
"massive, huge corporate behemoths" can sell paid compilers 
alongside a free base model?  There are many smaller companies 
selling paid compilers, hell, Borland C++ is still around as 
embarcadero C++ Builder.

Guess what?  Embarcadero provides a starter edition, for those 
who aren't making much money to try out, and a full paid version, 
for once you go over $1k/year in revenue.  Embarcadero is a 
good-sized software company at 500 employees and $100 million in 
yearly revenue, but I certainly wouldn't call them a "massive, 
huge corporate behemoth."

The dual free and paid model I've laid out is commonplace in the 
compiler world.


 I'm really happy that you're trying to think about how to 
 generate money for D development, but I think your insistence 
 on the necessity of selling closed components is based on a 
 misunderstanding both of how free software flourishes and of 
 the business factors at play in the projects you cite as 
 inspiration.


I'd argue that such a criticism best applies to you.  The most 
widely used OSS  projects these days are inevitably hybrid 
projects, that is incontrovertible.  You prefer that all the 
source is available to you, so you make such statements that are 
contrary to the facts or hand-wave away their success with vague 
allusions to other "business factors at play," which you of 
course do not lay out.

Obviously no one factor is determinative in success: it's always 
theoretically possible that the main reason Android succeeded is 
because it used Java, and that the source licensing played little 
part.  In that case, D can't succeed by using a similar hybrid 
model, because it's not Java. ;)

But proper rational examination of Android and other hybrid 
projects' success suggests hybrid licensing had a very large role 
to play.  I suspect you're not interested in such a rational 
analysis, because you have an ideological or emotional connection 
to all source being available, ie pure FOSS.  That's fine, just 
don't expect me to respect your position, that others must always 
work you for free and give you _all_ the source.



 Jan 05 2015



 next sibling parent reply "uri" <uri.grill gmail.com>  writes:


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



 Jan 06 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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



 Jan 06 2015



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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.



 Jan 06 2015



prev sibling  parent reply "uri" <uri.grill gmail.com>  writes:


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 

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



 Jan 06 2015



 next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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



 Jan 06 2015



  parent reply "uri" <uri.grill gmail.com>  writes:


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



 Jan 07 2015



  parent  Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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.



 Jan 07 2015



prev sibling  parent  "Joakim" <dlang joakim.fea.st>  writes:


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: that would not happen, as they wouldn't have access to 
them.  Why would Digital Mars pay for anything?  AFAIK, it's just 
one guy who makes almost no money off it.

Perhaps paid patches from independent devs won't work, but you 
haven't been able to articulate a single reason why it won't.


 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 

 one of those more mature languages?


Because D provides features and benefits those languages don't 
provide?  Don from Sociomantic, a company built on D1, has said, 
"Our infrastructure costs are 4X lower than the rest of our 
industry."  Now imagine how much better it'd be if a D compiler 
had the same commercial polish and quality of implementation as 
the best paid C++ compilers.


 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.


I doubt that Sociomantic has released all their proprietary 
additions to D1.  But the key question is related to this: the 
objection to paid patches seems to be that someone somewhere is 
keeping a proprietary feature to themselves.

If so, then what about any person or company that is currently 
adding and using proprietary features with their D compiler?  Why 
isn't that already a deal-breaker for those FOSS purists you're 
talking about and why haven't they left?  Is there something 
magical about when a paid dev sells a bugfix patch to a company, 
but not when the company employs an in-house paid dev to write 
that bugfix patch for them?

The disconnect I see with your stated viewpoint is that there are 
already people using D and adding proprietary additions to it 
themselves.  All I'm proposing is a marketplace in such 
proprietary additions, so they can buy them from outside.  If you 
believe proprietary additions are so bad that "most" would leave, 
even when always given when a core OSS option for free, why 
haven't they left already?



 Jan 08 2015



prev sibling next sibling parent reply "anonymous" <anonymous example.com>  writes:


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.



 Jan 06 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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


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

Of course, it is always possible for some devs to try and game 
the system, just as people sometimes accuse OSS companies using 
his favored support model of making their software overly complex 
so that they ensure more support contracts.

But you could probably go a long way just finishing features or 
fixing existing bugs in the OSS project.


 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.

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.



 Jan 06 2015



  parent reply "anonymous" <anonymous example.com>  writes:


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 
contributors ;) ). Right now, D is communism as usual in OSS. If 
we switch over to capitalism, that doesn't attract the same 
crowd, and may push away the current one.

But if a third party starts selling patches, and merges them into 
D proper after some time, I think that's a whole different story. 
They didn't write the bugs they're fixing. And they can't let 
down a community in which they haven't been active. It could 
still mean that "open D" becomes second class. And that could 
throw existing contributors off. But I see much less friction 
than when current core developers started doing it.



 Jan 06 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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.


Right, but the hybrid model exists elsewhere and is highly 
successful.  His preferred alternative doesn't really exist, at 
least he certainly hasn't listed anybody, and to the extent it 
does, is _significantly_ less successful.


 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 contributors ;) ). Right now, D is communism as usual 
 in OSS. If we switch over to capitalism, that doesn't attract 
 the same crowd, and may push away the current one.


OSS is not communism, it's volunteerism, and to the extent that 
companies like Facebook and Sociomantic are already using it, 
it's already got some capitalism.  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.


 But if a third party starts selling patches, and merges them 
 into D proper after some time, I think that's a whole different 
 story. They didn't write the bugs they're fixing. And they 
 can't let down a community in which they haven't been active. 
 It could still mean that "open D" becomes second class. And 
 that could throw existing contributors off. But I see much less 
 friction than when current core developers started doing it.


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.



 Jan 08 2015



  parent reply "anonymous" <anonymous example.com>  writes:


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



 Jan 09 2015



  parent  "Joakim" <dlang joakim.fea.st>  writes:


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 large commercial deployments, 
just Sociomantic AFAIK, and they're running an old version, D1, 
with significant modifications.  Volunteers are not going to 
produce a compiler with the polish to get into such places.

Now, there's nothing wrong with D staying a hobby language with 
dozens of contributors and tens of thousands of users for the 
next decade.  But Andrei has talked about taking it to the next 
level with commercial support.  This is a way to get there, 
likely the best way.


 [...]

 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.


There aren't right or wrong people to do it, the people who think 
so are just being silly.  They simply feel entitled to the 
regular OSS devs' work because those devs have been generous 
enough to give it away so far, which is a horrible, delusional 
mentality.  If it became less popular with them, who cares.  
There are a lot more people who would use D if it had commercial 
support and was more polished.


 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.


But the two are completely different situations: in the first, 
he's still working on D, just providing an enhanced paid version 
too, while in the second, he's saying it's not as good as some 
other language.

It is understandable why the second situation would hurt D, but 
not at all in the first.



 Jan 10 2015



prev sibling next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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.  Effectively, 
this is taking out insurance against blockers, and as with regular insurance, 
there can be different scales of fee depending on what it is you want
"coverage" 
for (just bugfixes? new features too? or do you just care about getting
priority 
for merges of fixes that your own team will create?), on the anticipated volume 
of requests you are going to make, and on exactly how much you want to be first 
on the list where there are conflicting priorities.  And of course, if you
don't 
make any "claims" for a period of time, this can also bump you up the priority 
list for when you finally do need something.

This is a win-win all round -- the core development team gets a regular supply 
of money; commercial users have a predictable cost for protecting themselves 
against bugs, and are not "locked in" in any way; costs are spread across 
commercial users, so there shouldn't need to be any disincentive to request a 
fix when you do actually need it.  (You can guard against reluctance to put in 
claims by ensuring that if multiple customers all request a fix, it gets higher 
priority, and that it counts less towards their individual volume of claims.) 
Finally, everything remains free software for everyone, both the commercial 
users and the wider developer and user community, which means that there's no 
potential disincentive to community contributions ("Why should I contribute to
a 
project that locks away the latest features from me?").

What about the freeloaders?  Well, the basis of this model is that if someone 
depends on a particular piece of software for their own value-creating 
activities, then it's in their interest to insure against the reliability of 
that tool.  Someone who chooses not to is basically gambling that they will 
never encounter a blocker; I'd say that's their call to make, but I also think 
that if the tool is valuable enough, there will be plenty of people who _do_ 
value being insured.


 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.


There are really only two options here.  If the proprietary, enhanced features 
are part of the language/standard library spec, then there is a paywall around 
the language.  If they are not officially part of the spec, but they are 
supplied by the official language project and the performance of the language
is 
in practice much worse without them, then I'd still count that as a paywall 
around the language, because it's the official project withholding
functionality 
on the basis of payment.  If neither, then you're simply talking about a 
3rd-party library or toolchain, in which case -- well, businesses can be based 
around such things, and if they drive benefits back to the core project that's
nice.


 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.


The second half of your last sentence here summarizes rather well why I don't 
like the idea of generating money by restricting access to features and fixes. 
They have an incentive to restrict as much as possible and release as little as 
they can.


 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.


 Given all your other responses, I suspect this is not the case, ie you don't
 want to see it happen.  But you're right, nobody can stop paid devs from doing
 this.


I believe it could be divisive to the development community, but I'm prepared
to 
be proven wrong by someone actually making it work.


 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.


I've described one payment model to avoid that; there are surely others.  But 
ultimately even without that, there isn't really a "tragedy of the commons" at 
work in the scenario you describe, because in this case, people pay not in
order 
to solve some problem for "the commons", but to solve problems that are
blockers 
to their own value-creating activity.  Yes, you can gamble on someone else 
solving your problem for you, but your ability to do that largely rests on the 
degree to which that solution is actually really vital for you.

BTW, in reference to the "tragedy of the commons", it's worth mentioning that 
the canonical example often cited -- the farmers who have a shared interest in 
common land being available for grazing but no individual motive to maintain it 
-- ignores all the historical mechanisms and institutions that were employed to 
ensure that common land was indeed maintained.  It's not surprising that it
does 
so either, because this "example" originates during the final stages of the 
enclosure movement in the United Kingdom, as intellectual justification for
what 
was in practice simply a mass appropriation of land (and the value created from 
working the land) into a much narrower set of hands.  It's been claimed that 
this had the long-term benefit to everyone of increasing overall productivity, 
but there are good reasons to doubt this; what isn't in doubt is that the 
benefits of that productivity were skewed to such an extent that the enclosure 
movement caused the first mass starvation in England for centuries, _despite 
being in the middle of a food surplus_.

I tell you this little tale not as some sort of metaphor for proprietary 
software, but simply to suggest that it's a good idea to be be cautious around 
this idea of the "tragedy of the commons".  All too often people promote it 
because they have a personal vested interest in preventing the creation of the 
institutional or economic structures that would permit a viable commons to
exist.


 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.


I think I've already responded to this.


 Name me an example of such a vendor that isn't a massive, huge corporate
 behemoth whose ability to sign contracts and make sales is largely dependent
 on business factors entirely separate from their product licensing.


 I'm not sure what point you're trying to make, that only "massive, huge
 corporate behemoths" can sell paid compilers alongside a free base model? 
There
 are many smaller companies selling paid compilers, hell, Borland C++ is still
 around as embarcadero C++ Builder.


My point was that I can't think of any recent example of a highly-successful 
_new_ language whose default toolchain has proprietary components, apart from 
those supplied by corporate behemoths.

I accept that there are commercially successful proprietary implementations of 
already-successful languages, but I think that absent a major corporate driver, 
a proprietary implementation of a not-yet-major language is likely to be a 
turn-off rather than a turn-on for adoption.  There's simply too much 
competition from many excellent free toolchains, both for longstanding and new 
languages.


 I'm really happy that you're trying to think about how to generate money for D
 development, but I think your insistence on the necessity of selling closed
 components is based on a misunderstanding both of how free software flourishes
 and of the business factors at play in the projects you cite as inspiration.


 I'd argue that such a criticism best applies to you.  The most widely used OSS
 projects these days are inevitably hybrid projects, that is incontrovertible.
 You prefer that all the source is available to you, so you make such statements
 that are contrary to the facts or hand-wave away their success with vague
 allusions to other "business factors at play," which you of course do not lay
out.


It is entirely possible that we are disagreeing at least in part based on 
alternative definitions of "success".

For example, if I look at Android as an example, I don't see a free software 
success story.  What I see is a _very_ controlled platform (access to the
actual 
development edge is highly restricted) whose wider community is largely made up 
of hardware manufacturers competing to make proprietary extensions that never 
get sent upstream, and whose code never gets released; and when you receive an 
Android device, in most cases you have no way, as a user, to access the source 
of the code it is actually running.

There's a huge amount of wasted effort, duplication of effort, and so on, which 
is sustained by the fact that, on the one hand, the mobile hardware industry is 
huge and these software development costs are trivial by comparison to the 
investment required to produce, market and distribute a new hardware device;
and 
on the other hand, for Google themselves, the cost of developing the core 
Android platform is small compared to the commercial benefits of the huge 
amounts of extra data it brings in.

Is Android making a lot of money for a lot of people and being put on a lot of 
devices?  Yes.  How much of that distributed software is actually free?  Very 
little, compounded by the fact that as a platform, its "killer apps" are 
proprietary.

In other words, the development of one high-quality piece of open source 
software -- the core Android platform -- has been achieved at the cost of the 
creation of a massive proprietary ecosystem.  That's not a free software
success 
in any meaningful sense.

Of course, you're arguing about making D a success in terms of adoption, levels 
of development activity and so on.  Here I'll happily concede that, for
example, 
if (say) a major commercial OS platform were to adopt D as one of its primary 
development languages, create its own (proprietary or not) D-based development 
libraries and create its own proprietary extension of the compiler that offered 
extra features, it would certainly drive adoption of D, and it would almost 
certainly result in lots of nice code eventually making its way back to the
core 
D project.  This is pretty much analogous to what I see happening with Apple
and 
clang/llvm.

However, that situation of a major OS provider deriving from a free language 
implementation to create its (proprietary) primary development toolchain, is 
very different from the situation of a language provider standing alone trying 
to gain adoption.  Apple are in a position to be able to say to devs, "You use 
this toolchain or you don't get to target our platform."  That's the kind of 
business factor that I'm talking about, which doesn't exist for D: absent that 
kind of driving force, a proprietary implementation would be a blocker both to 
uptake and contributions, for reasons already discussed above.


 Obviously no one factor is determinative in success: it's always theoretically
 possible that the main reason Android succeeded is because it used Java, and
 that the source licensing played little part.  In that case, D can't succeed by
 using a similar hybrid model, because it's not Java. ;)

 But proper rational examination of Android and other hybrid projects' success
 suggests hybrid licensing had a very large role to play.  I suspect you're not
 interested in such a rational analysis, because you have an ideological or
 emotional connection to all source being available, ie pure FOSS.  That's fine,
 just don't expect me to respect your position, that others must always work you
 for free and give you _all_ the source.


I'll thank you not to put words in my mouth.  Where have I said "Others must 
always work for me for free and give me all the source"?

Would I like a world where all software was free-as-in-freedom?  Certainly, and 
I see this as both a moral and a practical good.  Am I enthusiastic about the 
idea of free software also being available without cost for access?  Again,
yes, 
and I think it's important to identify business and development models that
make 
this possible (a position quite different from "Others must...").  Do my 
preferences mean I can't understand or appreciate the social, economic and 
technical dynamics of doing things differently?  Well, a cynic might try and 
dodge the question by suggesting that you yourself seem rather too emotionally 
attached to the cleverness of your hybrid idea to be able to discuss it
entirely 
rationally -- as evidenced by your eagerness to label people as "zealots" or 
"irrational" or "ideological" because they have problems with your proposed way 
of doing things.

However, I'd rather not be such a cynic, and so I'll simply say: I think I've 
engaged, in quite a lot of detail and depth, with almost all of the points 
you've raised.  You're not obliged to agree with either my analysis or my 
principles, but if you do want to dispute them, it might be a good idea to do
so 
on the basis of their content rather than your assumptions or prejudices about 
why I think this way.

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



 Jan 06 2015



  parent  "Joakim" <dlang joakim.fea.st>  writes:


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


I'll pose the same question I did to the anonymous poster above, 
who tried unsuccessfully to explicate your possible reasoning: 
precisely which provider of commercial support is providing 
"fixes or features that have already been created" and paid for 
by one user to other users for free?

The only reason I focused on the fact that fixes have to be paid 
for in both models is because you never said that outside fixes 
are provided for free in the first model, in your original quote 
up above.  We cannot focus on distinctions you have not made. :)

I see no difference in the incentives to purchasers whether they 
pay for a new fix or for already-created fixes.  In either case, 
they're simply paying for what they want and it hardly matters to 
them when it was created.  Perhaps there is a difference in the 
incentives for suppliers, but since you do not bother listing a 
single difference, I can't take such hand-waving seriously.


 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.


Yet the vast majority of purchasers, including Jarrett's 
managers, who he said have no problem with closed-source products 
like VS, have no problem being dependent on such businesses based 
on "artificial scarcity."


 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 envy your ability to read his managers' minds, because I can 
only rely on what Jarrett wrote. ;) Since he says they have no 
problem with using closed-source software like VS, they clearly 
have no problem with "artificial scarcity."  I would bet that if 
you asked them about "artifical scarcity," 100% of them would 
have no idea what that meant. :D


 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.  
 Effectively, this is taking out insurance against blockers, and 
 as with regular insurance, there can be different scales of fee 
 depending on what it is you want "coverage" for (just bugfixes? 
 new features too? or do you just care about getting priority 
 for merges of fixes that your own team will create?), on the 
 anticipated volume of requests you are going to make, and on 
 exactly how much you want to be first on the list where there 
 are conflicting priorities.  And of course, if you don't make 
 any "claims" for a period of time, this can also bump you up 
 the priority list for when you finally do need something.

 This is a win-win all round -- the core development team gets a 
 regular supply of money; commercial users have a predictable 
 cost for protecting themselves against bugs, and are not 
 "locked in" in any way; costs are spread across commercial 
 users, so there shouldn't need to be any disincentive to 
 request a fix when you do actually need it.  (You can guard 
 against reluctance to put in claims by ensuring that if 
 multiple customers all request a fix, it gets higher priority, 
 and that it counts less towards their individual volume of 
 claims.) Finally, everything remains free software for 
 everyone, both the commercial users and the wider developer and 
 user community, which means that there's no potential 
 disincentive to community contributions ("Why should I 
 contribute to a project that locks away the latest features 
 from me?").

 What about the freeloaders?  Well, the basis of this model is 
 that if someone depends on a particular piece of software for 
 their own value-creating activities, then it's in their 
 interest to insure against the reliability of that tool.  
 Someone who chooses not to is basically gambling that they will 
 never encounter a blocker; I'd say that's their call to make, 
 but I also think that if the tool is valuable enough, there 
 will be plenty of people who _do_ value being insured.


Yes, this appears to be your own retainer-oriented variation on 
the familiar consulting/support model used by companies like Red 
Hat.  As I said before, your preferred support model has worked 
for certain types of OSS projects, but is not nearly as 
successful and scalable as hybrid projects like Android or 
clang/llvm.

Building a product business, in D's case with paid patches on the 
OSS core, is orders of magnitude more successful than 
consulting/support businesses, ie product businesses' profits and 
revenues are 10-100 times greater than consulting/support 
businesses, especially OSS ones.

Now you may say, "Who cares?  Red Hat still makes plenty of 
money."  Yes, but for how long?  The fact that hybrid products 
have 100 times the profits available means they can plow a lot 
more money into their products and obsolete the pure FOSS 
consulting/support projects.

We already see this happening, with a billion users of hybrid 
Android on their smartphones, and essentially nobody running FOSS 
Ubuntu or some other linux distro on a mobile device.  How long 
before hybrid Android becomes a desktop distro and kills off the 
tiny FOSS linux distro market too?

I see no reason for D to embrace a clearly inferior business 
model like support/consulting, which has already been shown to 
perform much worse in the market.  That's just setting it up for 
failure against other languages that use a hybrid approach.  Of 
course, since D is permissively licensed, we can always try both 
approaches and see what happens. :)


 There are really only two options here.  If the proprietary, 
 enhanced features are part of the language/standard library 
 spec, then there is a paywall around the language.


No, there is a paywall around some features of the language 
provided by a certain implementation.  There is nothing stopping 
OSS devs from creating a competing OSS implementation of the same 
features.  If they're incapable of doing so, that's their problem.


 If they are not officially part of the spec, but they are 
 supplied by the official language project and the performance 
 of the language is in practice much worse without them, then 
 I'd still count that as a paywall around the language, because 
 it's the official project withholding functionality on the 
 basis of payment.


Nope, still only a paywall around certain features, and since 
they're not part of the spec, it's a stretch to even say they're 
part of the language.  No idea what you mean by "the official 
language project," as D is developed and distributed by a loose 
confederation of OSS devs and companies.  If some of them also 
decide to sell paid patches along with their donations of OSS 
patches, they're not "withholding functionality," they simply 
chose not to donate their work on those features.

It is amazing how just because they have been so generous with 
their time so far, you make demands on what they must do with 
their time in the future.


 If neither, then you're simply talking about a 3rd-party 
 library or toolchain, in which case -- well, businesses can be 
 based around such things, and if they drive benefits back to 
 the core project that's nice.


Since none of the core OSS devs have expressed any interest in 
this paid patches model, that is likely what it would be.  But as 
detailed above, if any of them were to join in to providing paid 
patches, it is ludicrous to suggest they are "withholding" 
anything from you.


 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.


 The second half of your last sentence here summarizes rather 
 well why I don't like the idea of generating money by 
 restricting access to features and fixes. They have an 
 incentive to restrict as much as possible and release as little 
 as they can.


Well, such incentives are there anytime somebody is getting paid, 
doesn't matter if it's the paid patches model you don't like or 
the paid support model you prefer.  The alternative to getting 
paid to work on D is that they can't pay their bills and they go 
do something else, so that no features or fixes get done, or at 
the very least a lot less in their spare time.  Most reasonable 
people prefer paying to getting almost nothing for free.


 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.


 I've described one payment model to avoid that; there are 
 surely others.  But ultimately even without that, there isn't 
 really a "tragedy of the commons" at work in the scenario you 
 describe, because in this case, people pay not in order to 
 solve some problem for "the commons", but to solve problems 
 that are blockers to their own value-creating activity.  Yes, 
 you can gamble on someone else solving your problem for you, 
 but your ability to do that largely rests on the degree to 
 which that solution is actually really vital for you.


Your consulting/support payment model doesn't "avoid that," it 
simply tries to coexist with it, like Red Hat long co-existed 
with CentOS.  But it certainly hurts the consulting/support 
vendors and makes them much less successful.  Nobody said anyone 
is paying "in order to solve some problem for 'the commons,'" but 
that if you release the source into the commons right away, there 
will be others who will free-ride and not pay.

You're right that those free-riding companies may have to pay 
when they consider the solution vital, but they don't have to 
open-source their fix.  So while _you_ may pay a vendor for fixes 
in gcc and let them open-source them, your competitor may pay 
some other vendor for other fixes in gcc and keep those patches 
to themselves.  Since your competitor isn't distributing gcc but 
using it in-house to build their own software, they are not 
forced by the GPL to release their patches.  So they get all the 
fixes you paid for for free and don't release their fixes back to 
you.  And this does happen in practice, a fair amount of 
companies maintain proprietary patchsets on even GPL software 
that they use.

This is why hybrid models do much better, because they mix the 
much greater revenue from closed-source patches in with the 
commons of the OSS core.


 BTW, in reference to the "tragedy of the commons", it's worth 
 mentioning that the canonical example often cited -- the 
 farmers who have a shared interest in common land being 
 available for grazing but no individual motive to maintain it 
 -- ignores all the historical mechanisms and institutions that 
 were employed to ensure that common land was indeed maintained.


I agree that there have sometimes been such mechanisms that are 
neither fully public nor private, just as hybrid source models 
are not fully a commons or private. :)


  It's not surprising that it does so either, because this 
 "example" originates during the final stages of the enclosure 
 movement in the United Kingdom, as intellectual justification 
 for what was in practice simply a mass appropriation of land 
 (and the value created from working the land) into a much 
 narrower set of hands.  It's been claimed that this had the 
 long-term benefit to everyone of increasing overall 
 productivity, but there are good reasons to doubt this; what 
 isn't in doubt is that the benefits of that productivity were 
 skewed to such an extent that the enclosure movement caused the 
 first mass starvation in England for centuries, _despite being 
 in the middle of a food surplus_.


And also led to the British agricultural revolution and 
eventually the Industrial revolution:

http://en.wikipedia.org/wiki/Enclosure

Perhaps it was difficult at first, but I think most countries 
would take that trade, though of course while trying to mitigate 
the initial problems.


 I tell you this little tale not as some sort of metaphor for 
 proprietary software, but simply to suggest that it's a good 
 idea to be be cautious around this idea of the "tragedy of the 
 commons".  All too often people promote it because they have a 
 personal vested interest in preventing the creation of the 
 institutional or economic structures that would permit a viable 
 commons to exist.


While that may be true of some who use that idea, it certainly 
isn't true of those pushing hybrid models of licensing software, 
as one of the main arguments for hybrid models is that they grow 
the commons of the OSS core much better and faster.


 I'm not sure what point you're trying to make, that only 
 "massive, huge
 corporate behemoths" can sell paid compilers alongside a free 
 base model?  There
 are many smaller companies selling paid compilers, hell, 
 Borland C++ is still
 around as embarcadero C++ Builder.


 My point was that I can't think of any recent example of a 
 highly-successful _new_ language whose default toolchain has 
 proprietary components, apart from those supplied by corporate 
 behemoths.


Well, what do you consider to be a "highly-successful _new_ 
language" that wasn't "supplied by corporate behemoths?"  If the 
answer is none, then you're also essentially saying that no new 
non-proprietary language has been "highly successful," since I'd 
say that all the big new languages of the last decade or two, 

when they became successful.  I cannot think of an OSS language 
that reached anywhere near the success of those big proprietary 
languages.


 I accept that there are commercially successful proprietary 
 implementations of already-successful languages, but I think 
 that absent a major corporate driver, a proprietary 
 implementation of a not-yet-major language is likely to be a 
 turn-off rather than a turn-on for adoption.  There's simply 
 too much competition from many excellent free toolchains, both 
 for longstanding and new languages.


Given how successful proprietary implementations have been and 
are to this day, I don't think it'll be much of a problem for D 
to have both options with a hybrid model, and the countervailing 
benefits vastly outweigh the likely negligible potential cost you 
mentioned.

If the "competition from many excellent free toolchains, both for 
longstanding and new languages" were such a big factor, there'd 
be no paid toolchains left.  Yet devs gladly pay a small forest 
of non-OSS compiler vendors to make their lives easier, most of 
whom are not "corporate behemoths."  Of course, there are a lot 
less paid compiler vendors than back when Walter started in the 
compiler business, but there are a lot less OS vendors too, as 
the market matured and consolidated with time.  The free 
toolchains may certainly have killed off the less capable 
proprietary vendors, but the more capable are still thriving.


 It is entirely possible that we are disagreeing at least in 
 part based on alternative definitions of "success".

 For example, if I look at Android as an example, I don't see a 
 free software success story.  What I see is a _very_ controlled 
 platform (access to the actual development edge is highly 
 restricted) whose wider community is largely made up of 
 hardware manufacturers competing to make proprietary extensions 
 that never get sent upstream, and whose code never gets 
 released; and when you receive an Android device, in most cases 
 you have no way, as a user, to access the source of the code it 
 is actually running.

 There's a huge amount of wasted effort, duplication of effort, 
 and so on, which is sustained by the fact that, on the one 
 hand, the mobile hardware industry is huge and these software 
 development costs are trivial by comparison to the investment 
 required to produce, market and distribute a new hardware 
 device; and on the other hand, for Google themselves, the cost 
 of developing the core Android platform is small compared to 
 the commercial benefits of the huge amounts of extra data it 
 brings in.

 Is Android making a lot of money for a lot of people and being 
 put on a lot of devices?  Yes.  How much of that distributed 
 software is actually free?  Very little, compounded by the fact 
 that as a platform, its "killer apps" are proprietary.

 In other words, the development of one high-quality piece of 
 open source software -- the core Android platform -- has been 
 achieved at the cost of the creation of a massive proprietary 
 ecosystem.  That's not a free software success in any 
 meaningful sense.


Yes, our measures of success are different.  You rue that we 
don't live in a world in which all source is available under a 
FOSS license, ie "a free software success," whereas I consider 
the current situation where most Android devices are largely OSS 
as close to the optimum situation, ie the percentage of OSS code 
may move from 65-75% in the future but it will never be 100%.

As for users, they may not have _all_ the source, but the 
flourishing Android ROM scene wouldn't exist without all the 
source they have access to from AOSP today.  That's certainly 
much better than before, ie Windows Mobile dominating the much 
smaller smartphone market before iPhone/Android, where you had 
_no_ option to modify the source of the underlying OS.  And it's 
not just a few small ROMs, some of the largest Android vendors, 
like Xiaomi, Amazon, and Cyanogen, repeatedly fork AOSP and make 
it available to all their users without all the proprietary 
Google apps and services that you dislike. :)


 Of course, you're arguing about making D a success in terms of 
 adoption, levels of development activity and so on.  Here I'll 
 happily concede that, for example, if (say) a major commercial 
 OS platform were to adopt D as one of its primary development 
 languages, create its own (proprietary or not) D-based 
 development libraries and create its own proprietary extension 
 of the compiler that offered extra features, it would certainly 
 drive adoption of D, and it would almost certainly result in 
 lots of nice code eventually making its way back to the core D 
 project.  This is pretty much analogous to what I see happening 
 with Apple and clang/llvm.

 However, that situation of a major OS provider deriving from a 
 free language implementation to create its (proprietary) 
 primary development toolchain, is very different from the 
 situation of a language provider standing alone trying to gain 
 adoption.  Apple are in a position to be able to say to devs, 
 "You use this toolchain or you don't get to target our 
 platform."  That's the kind of business factor that I'm talking 
 about, which doesn't exist for D: absent that kind of driving 
 force, a proprietary implementation would be a blocker both to 
 uptake and contributions, for reasons already discussed above.


Except no reasons for it being a blocker to uptake and 
contributions were actually discussed above, just vague 
intimations that some people may not like it.

What about Java?  Not a primary development toolchain for any 
locked-in platform when it became popular long before Android.  

Windows but there were always other language options on all the 

big factor in Obj-C's success, I don't think it's quite as 
determinative generally as you do.

What if a moderately-sized compiler vendor like Embarcadero were 
to put 20 full-time paid devs on producing and selling an 
enhanced version of ldc that built on the OSS core?  You don't 
think D would be much more successful?  I think there's no doubt 
it would be, ie you don't need to go to the extreme of Apple 
making D the only development language on iOS for paid 
contributions to help D a lot.


 Obviously no one factor is determinative in success: it's 
 always theoretically
 possible that the main reason Android succeeded is because it 
 used Java, and
 that the source licensing played little part.  In that case, D 
 can't succeed by
 using a similar hybrid model, because it's not Java. ;)

 But proper rational examination of Android and other hybrid 
 projects' success
 suggests hybrid licensing had a very large role to play.  I 
 suspect you're not
 interested in such a rational analysis, because you have an 
 ideological or
 emotional connection to all source being available, ie pure 
 FOSS.  That's fine,
 just don't expect me to respect your position, that others 
 must always work you
 for free and give you _all_ the source.


 I'll thank you not to put words in my mouth.  Where have I said 
 "Others must always work for me for free and give me all the 
 source"?


When you say Walter would be "withholding functionality" from you 
and putting "a paywall around the language" if he decides to sell 
some patches he wrote rather than give them away from free, that 
is essentially what you're saying.


 Would I like a world where all software was free-as-in-freedom?
  Certainly, and I see this as both a moral and a practical 
 good.  Am I enthusiastic about the idea of free software also 
 being available without cost for access?  Again, yes, and I 
 think it's important to identify business and development 
 models that make this possible (a position quite different from 
 "Others must...").  Do my preferences mean I can't understand 
 or appreciate the social, economic and technical dynamics of 
 doing things differently?  Well, a cynic might try and dodge 
 the question by suggesting that you yourself seem rather too 
 emotionally attached to the cleverness of your hybrid idea to 
 be able to discuss it entirely rationally -- as evidenced by 
 your eagerness to label people as "zealots" or "irrational" or 
 "ideological" because they have problems with your proposed way 
 of doing things.


I have not intimated that you don't understand what I'm talking 
about, only that you're making extremely weak arguments because 
you're arguing from your FOSS ideology, not from compelling 
evidence and well-established business theory.

I do not label people with those terms because "they have 
problems with [my] proposed way of doing things," but because 
their preferred alternative is a very minority position that 
makes little sense, as I've detailed in this thread.  Their pure 
FOSS approach has almost no usage, as practically all software in 
use today is either hybrid or completely closed-source.

Clinging to such an extreme FOSS position, despite the decades of 
failure of _pure_ FOSS, as even linux almost always runs with 
significant binary blobs, and ignoring all the economic reasons 
I've listed why that is so, suggests to me an animating ideology 
that renders them irrational zealots.  I'm certainly not alone in 
thinking this of Stallman and his adherents.


 However, I'd rather not be such a cynic, and so I'll simply 
 say: I think I've engaged, in quite a lot of detail and depth, 
 with almost all of the points you've raised.  You're not 
 obliged to agree with either my analysis or my principles, but 
 if you do want to dispute them, it might be a good idea to do 
 so on the basis of their content rather than your assumptions 
 or prejudices about why I think this way.


I have always primarily engaged with your content.  I also 
hazarded a guess as to why an otherwise smart guy like you seemed 
to be making such weak arguments in this particular case, a guess 
which you are free to take into consideration or ignore.


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


Any real businessman knows that there are real customers and 
those who will simply make impossible demands and not buy 
anything.  The pure FOSS crowd fall in the latter category.

I noted in my original post that this thread was for those who 
want to pay or get paid.  I don't really care about the pure FOSS 
crowd, but I do like to occasionally take a whack at all their 
dumb arguments. ;)



 Jan 09 2015



prev sibling  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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 R&D.

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-R&D 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.



 Jan 07 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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



 Jan 07 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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.



 Jan 07 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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



 Jan 07 2015



prev sibling next sibling parent reply "Zach the Mystic" <reachzach gggmail.com>  writes:


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.



 Jan 06 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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.



 Jan 08 2015



 next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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.



 Jan 08 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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.



 Jan 08 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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.



 Jan 08 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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


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


 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.


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.

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.  Even the hybrid Android model 
that I've referenced doesn't do this, as the closed patches and 
binary blobs that companies like Qualcomm and Samsung add into 
Android builds are usually never open-sourced.



 Jan 08 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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.



 Jan 09 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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 commenter that as long as you're using a language with a 
common spec and multiple commercial implementations, as most do 
today, it's not a big deal.


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


Ah, finally something approaching a valid criticism, glad to read 
it. :)

Why do companies depend on AOSP or other OSS projects today?  
They're also written by a random conglomerate of individuals and 
companies.  In the case of this paid patches idea, the companies 
_would_ contract with each of the paid devs to provide both the 
patches and support.  You could keep the contracts fairly 
lightweight and standard across devs, certainly initially.  I 
hope you're not arguing that coming up with a workable, reusable 
contract initially would be a giant cost, it isn't.

Any time you contract with a single company that writes the 
compiler, you're contracting with "a conglomerate of 
individuals."  The advantage of not incorporating them all under 
a single company instead is the initial cost of organizing such a 
company, plus the fact that it's not really necessary these days. 
  Allowing devs more independence to work on what they want, 
rather than what the managers direct, has a lot of potential 
benefits for productivity and innovation.

Is this commonly done today?  No, even highly decentralized OSS 
projects like MySQL had many of their devs working for a single 
company to produce the commercial version.  But I believe it's 
where the market is inevitably heading.

It doesn't matter that a lot of users test FOSS, if nobody is 
willing to pay devs to fix the bugs they may find.  D has tens of 
thousands of users, yet only a handful of OSS devs fixing bugs, 
and many bugs that go unfixed for long periods of time.


 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.


Nobody has suggested that they build their own tool.  You 
expressed above a fear that proprietary compiler vendors would 
hold their control of the compiler over the buyer's head and 
force them to "upgrade" at high prices.

Well, if your contract with the compiler vendor provides that all 
patches must be released after a funding/time limit and 70-90% of 
the source for the compiler is always available, as I've detailed 
with the hybrid model in this thread, then your switching costs 
are greatly reduced.  You can always fund other compiler vendors 
who fork that OSS core and clone the proprietary features you 
want.  I suggest you read the Phoronix article I linked in my 
original post.


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


I gave a concrete reply to which of your three categories of 
customers above would use D and pay for this model, then you went 
off on an unrelated tangent about other customized models and 
public pricing.  If you don't tell me in what way you'd like me 
to be more concrete, I can't satisfy your request.

I can only offer concrete scenarios in response to specific 
questions or concepts you'd like me to explain.  Hand-waving 
about how I'm not being concrete enough, but without giving a 
specific reason or concept you'd like me to be concrete about is 
just that, hand-waving.



 Jan 09 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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.



 Jan 09 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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



 Jan 09 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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.



 Jan 09 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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.



 Jan 09 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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…



 Jan 09 2015



prev sibling  parent  "Zach the Mystic" <reachzach gggmail.com>  writes:


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



 Jan 08 2015



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


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.



 Jan 09 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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



 Jan 09 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


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.



 Jan 09 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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 the point of view of 
 commercial relations and motivates faster development by paying 
 exactly for stuff that matters. With your proposed scheme best 
 strategy is to hold off adding new stuff upstream as long as 
 possible to force more people buy it.


Microsoft is an extreme example of product software, most 
software product companies didn't connive their way into a 
similar monopoly position.  Android is the product I keep using 
as an example, no "actual effort" there?

If you're such a believer in open-source support models, I look 
forward to Sociomantic open-sourcing all their code and then 
providing paid hosting and support instead, getting paid only for 
the server baby-sitting you claim is worth paying for.  I don't 
see that happening and we both know why, because your current 
service model from selling access to your mostly closed-source 
product is just much more economically viable.

You are subject to the same incentives with your hybrid-source 
software as you complain about with hybrid models, ie to hold off 
on open-sourcing the few libraries you plan on releasing to make 
more exclusive money off them in the meantime.  As I've said from 
the beginning, the decision on when to open-source in my model is 
not taken by the developer, it is contractually agreed to ahead 
of time based on certain funding and time limits.


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


I see no arguments for why that would happen, simply bald 
statements with no real reasoning and seemingly ignoring the 
funding/time limits involved with my hybrid model.



 Jan 09 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Friday, 9 January 2015 at 15:39:13 UTC, Joakim wrote:

 It poses unacceptable risk of company becoming hostage of 
 ecosystem were "buying" closed patches is only way to use the 
 tool effectively. In software world where even .NET goes 
 open-source there is simply no reason why would one agree on 
 such terms.


 See my response to Joe above, most devs rely on closed 
 toolchains.  Funny how they all avoid becoming "hostages."


It doesn't match my observations at all. Of 5 places I worked, 4 
actively avoided any closed toolchains unless those promised too 
much of a benefit and where considered worth the risk. I'd expect 
this probably to be more common attitude among smaller companies 
as enterprise relies on lawyers to address such risks and does 
not care that much.


 Right now quite some of other developers contribute to D2 
 toolchain and related projects even if it is not directly 
 used. It makes sense exactly because project is fully open - 
 there is a good trust that such work won't get wasted and/or 
 abused and sit there until its actually needed, encouraging 
 other people to contribute in the meanwhile. It won't work 
 that way with hybrid model.


 I don't see how other devs selling paid patches will affect the 
 mentioned aspects of OSS devs working on D.  Simply claiming 
 that "it won't work that way" anymore is not an argument.


It is matter of licensing. Right now it is all open and company 
using D can be absolutely sure that it is possible to fork the 
project at any time while keeping both own contributions and all 
stuff that was paid for. Closed patches would need to restrict 
that to prevent simple sharing of such patches resulting in much 
more complicated situation.

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


 1) Selling services is indeed much different from selling 
 software and much more honest. When you sell a program you 
 don't really sell anything of value - it is just bunch of 
 bytes that costs you nothing to copy. When you sell service 
 you don't just sell "access" to same software running on the 
 server but continuous efforts for maintaining and improving 
 that software, including developer team costs and server h/w 
 costs over time. This is actually something of value and 
 charging for that is more widely accepted as just.


 The only ridiculous statement I see here is your claim that 
 building a desktop/mobile program doesn't also require 
 "continuous efforts for maintaining and improving that 
 software, including developer team costs and server h/w costs 
 over time."  Both server and desktop/mobile software are widely 
 considered worth charging for: it is highly idiosyncratic and 
 self-rationalizing for you to claim that one is significantly 
 different from the other.


Building requires. Selling/maintaining - doesn't. And pure 
sell-the-software model pretty much never includes and guaranteed 
support from the developer. Quite the contrary, those are always 
tempted to abandon support in favor of making new major version 
of same software and selling it again for same money. There is 
also inherent economical issue as such model introduces huge gap 
between successful companies and contenders (either you cover 
development losses and get any income on top "for free" or you 
don't and go bankrupt) favoring creation of monopolies.

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


 2) We don't even sell plain service access - it is more 
 delicate than that, exactly to ensure that our client don't 
 feel like product hostages and get encouraged to try with no 
 big commitment. You can contact our sales department for more 
 details ;)


 You take money and create mostly closed-source software: those 
 are the only details that matter in this discussion.


Nope, this wasn't at all what I was talking about. My objections 
is not as much against the fact patches are closed but the fact 
that you propose to sell _patches_. I despise copyright, not 
closed software.

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


 3) There are indeed plans for open-sourcing at least base 
 libraries we use. It is taking very long because making 
 something public in a way that won't hit you back is damn 
 tricky legally these days and it is blocked in legal 
 department for quite a while. No announcement because no idea 
 how long may it take.


 Sociomantic has always been generous with the D community, I 
 don't mean to imply you haven't.  But unless you open-source 
 all your code, you're employing a hybrid closed-source model, 
 exactly the kind of model you're objecting to here. :) Funny 
 how it's good for Sociomantic but not anybody else.


I hope earlier statements explain the difference.


 Yes, I am much in favor of paying for actual effort and not 
 helping make money from nothing like it has happened with 
 Microsoft. It both more honest from the point of view of 
 commercial relations and motivates faster development by 
 paying exactly for stuff that matters. With your proposed 
 scheme best strategy is to hold off adding new stuff upstream 
 as long as possible to force more people buy it.


 Microsoft is an extreme example of product software, most 
 software product companies didn't connive their way into a 
 similar monopoly position.  Android is the product I keep using 
 as an example, no "actual effort" there?


It is hard to reason about Android business model. It is rather 
complicated and partly so to ensure that vendors won't be afraid 
of unfair competition from Google motivating ongoing trust inside 
the ecosystem. I don't see any similarities with your proposal 
despite the claims.


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


 I see no arguments for why that would happen, simply bald 
 statements with no real reasoning and seemingly ignoring the 
 funding/time limits involved with my hybrid model.


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



 Jan 11 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


On Sunday, 11 January 2015 at 12:39:03 UTC, Dicebot wrote:

 On Friday, 9 January 2015 at 15:39:13 UTC, Joakim wrote:

 It poses unacceptable risk of company becoming hostage of 
 ecosystem were "buying" closed patches is only way to use the 
 tool effectively. In software world where even .NET goes 
 open-source there is simply no reason why would one agree on 
 such terms.


 See my response to Joe above, most devs rely on closed 
 toolchains.  Funny how they all avoid becoming "hostages."


 It doesn't match my observations at all. Of 5 places I worked, 
 4 actively avoided any closed toolchains unless those promised 
 too much of a benefit and where considered worth the risk. I'd 
 expect this probably to be more common attitude among smaller 
 companies as enterprise relies on lawyers to address such risks 
 and does not care that much.


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


 Right now quite some of other developers contribute to D2 
 toolchain and related projects even if it is not directly 
 used. It makes sense exactly because project is fully open - 
 there is a good trust that such work won't get wasted and/or 
 abused and sit there until its actually needed, encouraging 
 other people to contribute in the meanwhile. It won't work 
 that way with hybrid model.


 I don't see how other devs selling paid patches will affect 
 the mentioned aspects of OSS devs working on D.  Simply 
 claiming that "it won't work that way" anymore is not an 
 argument.


 It is matter of licensing. Right now it is all open and company 
 using D can be absolutely sure that it is possible to fork the 
 project at any time while keeping both own contributions and 
 all stuff that was paid for. Closed patches would need to 
 restrict that to prevent simple sharing of such patches 
 resulting in much more complicated situation.


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


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


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


 1) Selling services is indeed much different from selling 
 software and much more honest. When you sell a program you 
 don't really sell anything of value - it is just bunch of 
 bytes that costs you nothing to copy. When you sell service 
 you don't just sell "access" to same software running on the 
 server but continuous efforts for maintaining and improving 
 that software, including developer team costs and server h/w 
 costs over time. This is actually something of value and 
 charging for that is more widely accepted as just.


 The only ridiculous statement I see here is your claim that 
 building a desktop/mobile program doesn't also require 
 "continuous efforts for maintaining and improving that 
 software, including developer team costs and server h/w costs 
 over time."  Both server and desktop/mobile software are 
 widely considered worth charging for: it is highly 
 idiosyncratic and self-rationalizing for you to claim that one 
 is significantly different from the other.


 Building requires. Selling/maintaining - doesn't.


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


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


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

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


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


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


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


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


 2) We don't even sell plain service access - it is more 
 delicate than that, exactly to ensure that our client don't 
 feel like product hostages and get encouraged to try with no 
 big commitment. You can contact our sales department for more 
 details ;)


 You take money and create mostly closed-source software: those 
 are the only details that matter in this discussion.


 Nope, this wasn't at all what I was talking about. My 
 objections is not as much against the fact patches are closed 
 but the fact that you propose to sell _patches_. I despise 
 copyright, not closed software.


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

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


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


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


 3) There are indeed plans for open-sourcing at least base 
 libraries we use. It is taking very long because making 
 something public in a way that won't hit you back is damn 
 tricky legally these days and it is blocked in legal 
 department for quite a while. No announcement because no idea 
 how long may it take.


 Sociomantic has always been generous with the D community, I 
 don't mean to imply you haven't.  But unless you open-source 
 all your code, you're employing a hybrid closed-source model, 
 exactly the kind of model you're objecting to here. :) Funny 
 how it's good for Sociomantic but not anybody else.


 I hope earlier statements explain the difference.


They don't.


 Yes, I am much in favor of paying for actual effort and not 
 helping make money from nothing like it has happened with 
 Microsoft. It both more honest from the point of view of 
 commercial relations and motivates faster development by 
 paying exactly for stuff that matters. With your proposed 
 scheme best strategy is to hold off adding new stuff upstream 
 as long as possible to force more people buy it.


 Microsoft is an extreme example of product software, most 
 software product companies didn't connive their way into a 
 similar monopoly position.  Android is the product I keep 
 using as an example, no "actual effort" there?


 It is hard to reason about Android business model. It is rather 
 complicated and partly so to ensure that vendors won't be 
 afraid of unfair competition from Google motivating ongoing 
 trust inside the ecosystem. I don't see any similarities with 
 your proposal despite the claims.


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

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

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


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


 I see no arguments for why that would happen, simply bald 
 statements with no real reasoning and seemingly ignoring the 
 funding/time limits involved with my hybrid model.


 I see exactly the same from your side.


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


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


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

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



 Jan 11 2015



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


 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.



 Jan 11 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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



 Jan 11 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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



 Jan 11 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


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.



 Jan 11 2015



  parent reply "Zach the Mystic" <reachzach gggmail.com>  writes:


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?



 Jan 11 2015



  parent  sclytrack <sclytrack fake.com>  writes:


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.



 Jan 30 2018



prev sibling  parent  "Zach the Mystic" <reachzach gggmail.com>  writes:


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!



 Jan 11 2015



prev sibling  parent reply Laeeth Isharc <Laeeth kaleidic.io>  writes:


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.



 Jan 30 2018



  parent reply Joakim <dlang joakim.fea.st>  writes:


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.



 Jan 31 2018



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


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



 Feb 01 2018



  parent  Joakim <dlang joakim.fea.st>  writes:


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.



 Feb 01 2018



prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com>  writes:


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.



 Feb 01 2018



  parent reply Joakim <dlang joakim.fea.st>  writes:


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.



 Feb 02 2018



 next sibling parent  Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 2 February 2018 at 09:56, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> 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. :-)



 Feb 02 2018



prev sibling  parent  psychoticRabbit <meagain meagain.com>  writes:


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.



 Feb 02 2018



prev sibling  parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 31 January 2018 at 09:43, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> 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. :-)



 Feb 02 2018



  parent reply Joakim <dlang joakim.fea.st>  writes:


On Friday, 2 February 2018 at 09:26:51 UTC, Iain Buclaw wrote:

 On 31 January 2018 at 09:43, Joakim via Digitalmars-d 
 <digitalmars-d puremagic.com> 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.



 Feb 02 2018



 next sibling parent reply psychotic Rabbit <meagain meagain.com>  writes:


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.



 Feb 02 2018



  parent reply Joakim <dlang joakim.fea.st>  writes:


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.



 Feb 03 2018



  parent reply psychoticRabbit <meagain meagain.com>  writes:


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.



 Feb 03 2018



  parent reply rjframe <dlang ryanjframe.com>  writes:


On Sat, 03 Feb 2018 12:08:21 +0000, 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.



 Feb 03 2018



  parent reply psychoticRabbit <meagain meagain.com>  writes:


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?



 Feb 03 2018



  parent reply Joakim <dlang joakim.fea.st>  writes:


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.



 Feb 04 2018



 next sibling parent  psychoticRabbit <meagain meagain.com>  writes:


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.



 Feb 04 2018



prev sibling  parent  psychoticRabbit <meagain meagain.com>  writes:


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



 Feb 05 2018



prev sibling  parent  Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 2 February 2018 at 11:21, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> 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
 <digitalmars-d puremagic.com> 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. :-)



 Feb 04 2018