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.

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

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

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.

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.

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…

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.

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.

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

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.