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.

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

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.

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.

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?

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.

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.

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

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.

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.