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 
supported languages (C# through VS) or fully open source.

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

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

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

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

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

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

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

 Two big benefits come out of this approach.  Obviously, this 
 would provide commercial support for paying customers, but the 
 other big benefit is that it doesn't depend on some company 
 providing that support.  A decentralized group of 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 
 for) prefer either fully commercially supported languages (C# 
 through VS) or fully open source.
There are also "fully open source" languages which are "fully commercially supported." How do your managers wrap their minds around such a paradox? ;) My point is that such artificial distinctions are silly, whether because of the amount of support or source available. The alternative to paid bug fixes is not that all the bugs you want fixed get done for free: it's _no_ bug fixes, as we see today. For example, selective imports at module scope has been broken for more than eight years now, as those symbols are leaked into any module that imports the module with the selective import. There are many more bugs like that, that could actually be fixed much faster if there were more paid devs working on D.
 Remember, that there are ways to provide commercial support 
 without putting a paywall on using the language itself. What is 
 really needed here is buy-in from corporations on the language. 
 Having engineers from a company working on D would provide one 
 form of commercial support. But this model is very difficult to 
 find and the closest to it I've seen is Facebook's involvement 
 with D. I agree having developers who are paid to work on D 
 would be a great thing, but reaching that point is a very 
 difficult road.
Having both paid and free versions available is not a "paywall" on a language. A company is not going to just write a bunch of patches and open source all of them unless they have some complementary business model to go with it, whether google making more mobile revenue off Android or Apple providing clang as the system compiler on OS X and making money off the bundled Mac.
 While I understand, that D needs some form of commercial 
 support for some parties, there is also a stigma that the 
 current model doesn't provide support. I've found to the 
 contrary actually. I find the full open source model employed 
 here, has a better support system than a lot of other 
 commercial support models. The reason is the community, there 
 is always someone around to answer a question. I find with most 
 commercially supported models the development team can't be 
 reached and you have to depend on your coworkers or friends who 
 may know of a workaround (Microsoft model). Most of the time I 
 see bugs get fixed fairly promptly for a compiler project 
 despite the fragmented development that is inherent to open 
 source projects.
That community involvement would still be there for the OSS core with D, but you would get support for a closed patch from the developer who wrote it.
 I think commercial support for D really comes down to one of 
 two situations in the future:

 * A company decides to make a commercial D compiler that is 
 closed source but compatible with phobos, etc. They fully 
 support the compiler. (Doesn't 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 don't because we have C++, Java, C# already. Why not just use one of those more mature languages?
 As for people leaving because somebody else has developed a 
 proprietary feature for D and not given it to them for free, 
 companies like Sociomantic have already developed such features 
 and they haven't been integrated upstream, why haven't "most" 
 left already?
The features from Sociomantic features are all D1 and also there are devs from Sociomantic are trying to get features released upstream. Sociomantic isn't the blocker it's integrating the features into D2.
 The dmd backend is not under an OSS license, why haven't they 
 left?  I suspect there are not very many of the type of people 
 you're talking about in the D community.
It's possible that you're right but I don't see it happening. The backend doesn't provide any benefit to GDC and LDC and Walter has a very good reason for closing the backend sources which is understood by all.
 Maybe a handful of FOSS zealots would leave, but the resulting 
 commercially supported D would be so much better, they'd be 
 swamped by the new people coming on board. :)
We'll see :) Cheers, uri
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 don't because we have C++, Java, C# already. Why not just use 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, Java, Obj-C, C++, C#, were mostly proprietary implementations 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. Same for C# to a large extent, Microsoft may have pushed it on Windows but there were always other language options on all the C# platforms. While I agree that such corporate imposition was a 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 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 "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
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