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


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

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

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

On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 05/01/15 21:57, Joakim via Digitalmars-d wrote:
>> If you're not paying, you're not a customer.  The alternative is to use the
>> bug-ridden OSS implementation you're using now for free, and not have a paid
>> version for those who want those bugs fixed.  I don't doubt that some irrational
>> people interpret the existence of a paid version in the way you laid out, and in
>> extreme cases that _can_ happen (just as there are OSS vendors who write bad OSS
>> code just so they can make more money off your favored support model), but
>> that's more an issue with their sloppy thinking than anything else.
>
> See, this is where I find _your_ point of view irrational, because you fail to see how straightforwardly damaging closed source can be to adoption.  The fact of the matter is that for a great many users, and particularly for a great many corporate adopters of development toolchains, today it matters hugely that the toolchain is free-as-in-freedom.  Not free 6 months down the line -- free, now, in its entirety.
>
> Non-free code (even temporarily), secret development, etc., are simply deal-breakers for a great many people.  A smart business model will engage with this fact and find a way to drive money to development without closing things up.

I don't think such people matter, ie they're a very small but vocal minority.  Also, these people are deeply irrational, as every piece of hardware they're using comes with many closed binary blobs.  They are either ignorant of this fact or just choose to make silly demands anyway.

>> There are also "fully open source" languages which are "fully commercially
>> supported."  How do your managers wrap their minds around such a paradox? ;)
>
> See, if I was in your shoes, I'd be trying to take on board the feedback about why your proposed model would be unattractive to his managers, rather than making sarcastic points that don't actually identify a conflict with their position.

Heh, the whole point of the sarcastic comment was to point out the obvious conflict in their position. :)

> Most commercial adopters are going to consider it very important to have a support option that says, "If you have a serious blocker, you can pay us money to guarantee that it gets fixed."
>
> They are not going to be at all happy about a support option that says, "If we develop a fix, then you are not going to get it in a timely manner unless you pay."
>
> Understanding that distinction is very important.

Haha, you do realize that those two quotes you laid out are the exact same option?  In the first option, you pay for a fix.  In the second option, you pay for a fix.  What distinction you're hoping to draw has not been made.

>> My point is that such artificial distinctions are silly, whether because of the
>> amount of support or source available.  The alternative to paid bug fixes is not
>> that all the bugs you want fixed get done for free: it's _no_ bug fixes, as we
>> see today. For example, selective imports at module scope has been broken for
>> more than eight years now, as those symbols are leaked into any module that
>> imports the module with the selective import. There are many more bugs like
>> that, that could actually be fixed much faster if there were more paid devs
>> working on D.
>
> You're talking about "the alternative to paid bug fixes" as if the only way of having paid bug fixes is to follow your model of locking them away from the wider community.  That's simply not true.

I wait with bated breath for your model of paid bug fixes that doesn't involve closing the code for the bug fixes at all.  You must have discovered some billion-dollar scheme, because every software company in the world is waiting to copy your brilliant method.

>> Having both paid and free versions available is not a "paywall" on a language.
>
> Unless those versions are identical, yes it is.

No, it isn't.  Your being able to use the always OSS dmd/gdc for free means the language is always available to you.  Just because someone else is using an enhanced version of ldc doesn't make the free version any less available to you.  To suggest otherwise is to distort the language to make your argument, ie flat out lying.

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

If you have a complementary business model for a D compiler, feel free to suggest one and get people to use it.  I don't think complementary business models are generally a good idea, because the people making money are usually going to focus on the place they're making money.  This is why google doesn't care that much if AOSP and Nexus devices are fairly buggy (I bought a Nexus device, will never buy one again for this reason), because they don't really make money off Android but off the complementary mobile ads.

> Bottom line: if some individual or group of devs want to try and make a business selling proprietary patches to the DMD frontend, or phobos, the licensing allows them to do that.  Good luck to them, and if they want to submit those patches to D mainline in future, good luck to them again.

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

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

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

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

Of course there's a change in value.  If another user or competitor also needs that fix and pays for it and upstreams it before you do, that's a cost you don't have to pay at all.  Hence the whole "tragedy of the commons" I laid out in my first post.

>> D is not an OS like linux, so the consulting/support model doesn't apply.  While
>> such free corporate investment is theoretically possible for D, it is very
>> unlikely and as I mentioned in my linked article, such support models are not as
>> successful.
>
> On the contrary, D is a programming language, and as such is used by people to make commercial projects, and so those people have a very strong interest in paying for commercial support, based around the principle "If we need something fixed, it will be fixed."
>
> But they don't have an interest in a situation where, "If something gets fixed, we have to pay."
>
> The first of those options delivers value.  The second is exploitation.

I suggest you actually read what you're writing:

"people have a very strong interest in paying for commercial support, based around the principle 'If we need something fixed, it will be fixed.'"

"If something gets fixed, we have to pay."

In both cases, they're paying for fixes.  If your point is that in the first model they're paying up front through a support subscription, whereas in the second model they're paying after they identify the fix- a distinction I'm stretching to find as you haven't really made it- both are still paying for a fix.  Certainly some companies would prefer the financial certainty of up-front recurring subscriptions to paying on a case-by-case basis, just as some would prefer the potential savings of the latter model, but the former certainly wouldn't save them any money.

>> Turning D into a paid product by using the hybrid model I laid out would make
>> its development go much faster.  There would always be an OSS core for OSS devs
>> to work on and for users to download for free, while those who want to pay for
>> quality and features would do so.  It's similar to how other compiler vendors
>> put out a free but less capable compiler and sell a more capable one.
>
> Name me an example of such a vendor that isn't a massive, huge corporate behemoth whose ability to sign contracts and make sales is largely dependent on business factors entirely separate from their product licensing.

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

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

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

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

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

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

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

Hi,

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

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

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

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

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

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

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


Cheers,
uri

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

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

> Secondly, no one makes money by locking out others when they themselves can be locked out in the same manner. This is basically what your model seems to boil down to.
>
> Party 'A' provides patches X,Y,Z in the compiler and others have to pay for them. Party 'B' provides patches M,N,O and similarly, others pay for them.  Now party A does not benefit from M,N,O unless they pay for it and party B does not benefit from X,Y,Z unless they pay for it. So no one wins.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Tuesday, 6 January 2015 at 06:14:37 UTC, Joakim wrote:
> On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
[...]
>> Most commercial adopters are going to consider it very important to have a support option that says, "If you have a serious blocker, you can pay us money to guarantee that it gets fixed."
>>
>> They are not going to be at all happy about a support option that says, "If we develop a fix, then you are not going to get it in a timely manner unless you pay."
>>
>> Understanding that distinction is very important.
>
> Haha, you do realize that those two quotes you laid out are the exact same option?  In the first option, you pay for a fix.  In the second option, you pay for a fix.  What distinction you're hoping to draw has not been made.

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

[...]
>> I also think you assume far too much value on the part of privileged/early access to bugfixes.  A bug in a programming language toolchain is either a commercial problem for you or it isn't.  If it's a commercial problem, you need it fixed, and that fix in itself has a value to you.  There is not really any comparable change in value if that fix also gets delivered to other users (who may or may not be competitors of yours), because that isn't what differentiates your product.
>
> Of course there's a change in value.  If another user or competitor also needs that fix and pays for it and upstreams it before you do, that's a cost you don't have to pay at all.  Hence the whole "tragedy of the commons" I laid out in my first post.

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

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

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

[...]
>> On the contrary, D is a programming language, and as such is used by people to make commercial projects, and so those people have a very strong interest in paying for commercial support, based around the principle "If we need something fixed, it will be fixed."
>>
>> But they don't have an interest in a situation where, "If something gets fixed, we have to pay."
>>
>> The first of those options delivers value.  The second is exploitation.
>
> I suggest you actually read what you're writing:
>
> "people have a very strong interest in paying for commercial support, based around the principle 'If we need something fixed, it will be fixed.'"
>
> "If something gets fixed, we have to pay."
>
> In both cases, they're paying for fixes.  If your point is that in the first model they're paying up front through a support subscription, whereas in the second model they're paying after they identify the fix- a distinction I'm stretching to find as you haven't really made it- both are still paying for a fix.

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

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

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

On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:
> On Tuesday, 6 January 2015 at 06:14:37 UTC, Joakim wrote:
>> On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> [...]
>>> Most commercial adopters are going to consider it very important to have a support option that says, "If you have a serious blocker, you can pay us money to guarantee that it gets fixed."
>>>
>>> They are not going to be at all happy about a support option that says, "If we develop a fix, then you are not going to get it in a timely manner unless you pay."
>>>
>>> Understanding that distinction is very important.
>>
>> Haha, you do realize that those two quotes you laid out are the exact same option?  In the first option, you pay for a fix.  In the second option, you pay for a fix.  What distinction you're hoping to draw has not been made.
>
> In the first option, you pay for a fix now, or you get it for free when it's done independently of you, e.g. because someone else paid.

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

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

You pay for both types of fixes in both models.

> [...]
>>> I also think you assume far too much value on the part of privileged/early access to bugfixes.  A bug in a programming language toolchain is either a commercial problem for you or it isn't.  If it's a commercial problem, you need it fixed, and that fix in itself has a value to you.  There is not really any comparable change in value if that fix also gets delivered to other users (who may or may not be competitors of yours), because that isn't what differentiates your product.
>>
>> Of course there's a change in value.  If another user or competitor also needs that fix and pays for it and upstreams it before you do, that's a cost you don't have to pay at all.  Hence the whole "tragedy of the commons" I laid out in my first post.
>
> If I get him right, Joseph's point is that the patch's value (not its cost) for the customer doesn't change whether others have access to it or not. So there's no advantage for the customer in the early-access model. But there's a disadvantage: have to pay for every patch. And so, an early-access model may not be attractive to paying customers.

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

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

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

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

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

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

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

> [...]
>>> On the contrary, D is a programming language, and as such is used by people to make commercial projects, and so those people have a very strong interest in paying for commercial support, based around the principle "If we need something fixed, it will be fixed."
>>>
>>> But they don't have an interest in a situation where, "If something gets fixed, we have to pay."
>>>
>>> The first of those options delivers value.  The second is exploitation.
>>
>> I suggest you actually read what you're writing:
>>
>> "people have a very strong interest in paying for commercial support, based around the principle 'If we need something fixed, it will be fixed.'"
>>
>> "If something gets fixed, we have to pay."
>>
>> In both cases, they're paying for fixes.  If your point is that in the first model they're paying up front through a support subscription, whereas in the second model they're paying after they identify the fix- a distinction I'm stretching to find as you haven't really made it- both are still paying for a fix.
>
> In the first model, they pay for specific fixes and get any others for free.
> In the second model, they pay for all fixes.
>
> I think calling it "exploitation" may have been a bit inciting, but I can understand the concern. Charging for bug fixes is a bit shady, when we introduced the bugs ourselves.

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

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

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

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

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

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

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

On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
> This is an idea I've been kicking around for a while, and given the need for commercial support for D, would perhaps work well here.
>
> The notion is that individual developers could work on patches to fix bugs or add features to ldc/druntime/phobos then sell those closed patches to paying customers.  After enough time has passed, so that sufficient customers have adequately paid for the work or after a set time limit beyond that, the patch is open sourced and merged back upstream.  It would have to be ldc and not dmd, as the dmd backend is not open source and the gdc backend license doesn't allow such closed patches.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

We'll see :)

Cheers,
uri

On Tuesday, 6 January 2015 at 19:46:51 UTC, Joakim wrote:
> On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote:
[...]
> I don't know of any commercial support model where you only pay for the fixes you need at any given moment and the fixes that others paid for are provided to you for free.

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

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

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

No, I didn't have that in mind.

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

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

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

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

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

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

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

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

[...]
>> I think calling it "exploitation" may have been a bit inciting, but I can understand the concern. Charging for bug fixes is a bit shady, when we introduced the bugs ourselves.
>
> Who is the "we?"  Paid devs fixing bugs in the existing OSS project that were introduced by OSS devs is not a "we."

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

>> And the whole thing could put off existing users, maybe even contributors. Especially when core developers would work on the early-access patches, the larger community could feel left out in the rain.
>
> Who cares.  First off, D's core OSS devs have given no indication they'd be interested in working on such paid patches, so the paid devs would likely be a completely separate group.

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

> Even if some of the existing OSS devs wrote some paid patches, the D OSS project exists because of the generosity of Walter, Andrei, Kenji, and a couple dozen other volunteer contributors who give away their work for free under an OSS license.  To suggest that they are therefore bound to always provide future patches for free is frankly ridiculous.  They could all just stop working on D tomorrow, they have no responsibility to keep providing all this free work.
>
> Similarly, they have no responsibility to not sell some patches to paying customers, simply because some spoiled handful will throw a hissy fit because they're not getting _everything_ for free anymore.  If they really want those patches, they can pay for them or write them themselves.

It's not so much about responsibilites, definitely not legal ones. It's more about keeping good relations with the community. I'm also thinking more about minor/occasional contributors, like myself, not so much about pure consumers (or potential contributors ;) ). Right now, D is communism as usual in OSS. If we switch over to capitalism, that doesn't attract the same crowd, and may push away the current one.

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