On 06/01/15 07:14, Joakim via Digitalmars-d wrote:
> I don't think such people matter, ie they're a very small but vocal minority.
> Also, these people are deeply irrational, as every piece of hardware they're
> using comes with many closed binary blobs.  They are either ignorant of this
> fact or just choose to make silly demands anyway.

This is a pretty bad habit you have, to just dismiss people rather than to try and understand the substance and detail of their concerns and requirements.

You seem to see "non-free is a deal-breaker" as some sort of fundamentalist position.  In fact, it's almost invariably contextual and highly dependent on the particular use-case and the particular needs that someone has in a particular piece of software.

For example, I'm not particularly happy about the existence of binary blobs or drivers in my Linux kernel, but it has very little practical effect on my ability to use Linux-based OS's, the sustainability of Linux development, or its reliability as a platform.  It's mostly a PITA for the kernel devs themselves and distro manufacturers who have to debug problems caused by these proprietary components.

But by contrast I would be extremely reluctant to base my software business around a development toolchain with proprietary components, or where I feared that might become part of the toolchain's business model in future.  Why? Because that enables someone else, whose interests may be different to mine, to exert control over my ability to fulfil my commercial and product goals.  The moment you accept a proprietary component into your toolchain, you're at risk of "Pay us more or we stop supporting this thing you are dependent on," and because it's proprietary, you simply don't have the same options to find another supplier.

That's not zealotry or moralism or absolutist, it's basic business sense, and it's not a hard decision to reach when there are so many excellent free development toolchains out there, whose development models are _not_ based on limiting access to new features or fixes.

>> See, if I was in your shoes, I'd be trying to take on board the feedback about
>> why your proposed model would be unattractive to his managers, rather than
>> making sarcastic points that don't actually identify a conflict with their
>> position.
>
> Heh, the whole point of the sarcastic comment was to point out the obvious
> conflict in their position. :)

There isn't any conflict in their position.  If you don't see it, that's probably because you don't perceive some important distinctions that they are concerned with ...

>> Most commercial adopters are going to consider it very important to have a
>> support option that says, "If you have a serious blocker, you can pay us money
>> to guarantee that it gets fixed."
>>
>> They are not going to be at all happy about a support option that says, "If we
>> develop a fix, then you are not going to get it in a timely manner unless you
>> pay."
>>
>> Understanding that distinction is very important.
>
> Haha, you do realize that those two quotes you laid out are the exact same
> option?  In the first option, you pay for a fix.  In the second option, you pay
> for a fix.  What distinction you're hoping to draw has not been made.

... such as the distinction between paying for a new fix to be created, versus being forbidden from accessing already-existing fixes _unless_ you pay.

You seem to think that the only dividing line is whether a fix is paid for or not.  It isn't.  If you're paying for a new fix or feature, then you're paying for the creation of new value.  If you're paying in order to access fixes or features that have already been created, then money is being extracted from you on the basis of artificial scarcity.  The two create very different incentives on the part of both suppliers and purchasers.

Note that the above isn't a moral judgement.  We don't need to assume there is anything ethically suspect about business based around artificial scarcity.  But it is certainly true that, from a purchaser's point of view, it is generally preferable to avoid being dependent on such businesses.

That's fundamentally the decision that Jarrett's managers are making: not between projects that do or don't have paid support, but between projects whose support options are based around creation of new value versus projects whose support model is based around the creation of artificial scarcity.

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

There's a very simple and straightforward model of paid bug fixes.  The core development team charges a retainer that enables the payer to request prioritization of fixes and/or features they require.  You pay on a subscription basis, you put in your priority requests as and when they arise.  Effectively, this is taking out insurance against blockers, and as with regular insurance, there can be different scales of fee depending on what it is you want "coverage" for (just bugfixes? new features too? or do you just care about getting priority for merges of fixes that your own team will create?), on the anticipated volume of requests you are going to make, and on exactly how much you want to be first on the list where there are conflicting priorities.  And of course, if you don't make any "claims" for a period of time, this can also bump you up the priority list for when you finally do need something.

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

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

>>> Having both paid and free versions available is not a "paywall" on a language.
>>
>> Unless those versions are identical, yes it is.
>
> No, it isn't.  Your being able to use the always OSS dmd/gdc for free means the
> language is always available to you.  Just because someone else is using an
> enhanced version of ldc doesn't make the free version any less available to
> you.  To suggest otherwise is to distort the language to make your argument, ie
> flat out lying.

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

> If you have a complementary business model for a D compiler, feel free to
> suggest one and get people to use it.  I don't think complementary business
> models are generally a good idea, because the people making money are usually
> going to focus on the place they're making money.

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

>> Bottom line: if some individual or group of devs want to try and make a
>> business selling proprietary patches to the DMD frontend, or phobos, the
>> licensing allows them to do that. Good luck to them, and if they want to
>> submit those patches to D mainline in future, good luck to them again.
>
> Given all your other responses, I suspect this is not the case, ie you don't
> want to see it happen.  But you're right, nobody can stop paid devs from doing
> this.

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

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

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

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

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

> I suggest you actually read what you're writing:
>
> "people have a very strong interest in paying for commercial support, based
> around the principle 'If we need something fixed, it will be fixed.'"
>
> "If something gets fixed, we have to pay."
>
> In both cases, they're paying for fixes.

I think I've already responded to this.

>> Name me an example of such a vendor that isn't a massive, huge corporate
>> behemoth whose ability to sign contracts and make sales is largely dependent
>> on business factors entirely separate from their product licensing.
>
> I'm not sure what point you're trying to make, that only "massive, huge
> corporate behemoths" can sell paid compilers alongside a free base model?  There
> are many smaller companies selling paid compilers, hell, Borland C++ is still
> around as embarcadero C++ Builder.

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

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

>> I'm really happy that you're trying to think about how to generate money for D
>> development, but I think your insistence on the necessity of selling closed
>> components is based on a misunderstanding both of how free software flourishes
>> and of the business factors at play in the projects you cite as inspiration.
>
> I'd argue that such a criticism best applies to you.  The most widely used OSS
> projects these days are inevitably hybrid projects, that is incontrovertible.
> You prefer that all the source is available to you, so you make such statements
> that are contrary to the facts or hand-wave away their success with vague
> allusions to other "business factors at play," which you of course do not lay out.

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

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

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

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

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

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

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

> Obviously no one factor is determinative in success: it's always theoretically
> possible that the main reason Android succeeded is because it used Java, and
> that the source licensing played little part.  In that case, D can't succeed by
> using a similar hybrid model, because it's not Java. ;)
>
> But proper rational examination of Android and other hybrid projects' success
> suggests hybrid licensing had a very large role to play.  I suspect you're not
> interested in such a rational analysis, because you have an ideological or
> emotional connection to all source being available, ie pure FOSS.  That's fine,
> just don't expect me to respect your position, that others must always work you
> for free and give you _all_ the source.

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

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

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

And really, if you want to sell a business model to people, don't go dismissing people who tell you "this won't work for me".  Those people are your potential customers.  Find out what _will_ work for them, and give it to 'em. ;-)

On 06/01/15 23:32, uri via Digitalmars-d wrote:
>> The dmd backend is not under an OSS license, why haven't they left?  I suspect
>> there are not very many of the type of people you're talking about in the D
>> community.
>
> It's possible that you're right but I don't see it happening. The backend
> doesn't provide any benefit to GDC and LDC and Walter has a very good reason for
> closing the backend sources which is understood by all.

Small point: the DMD backend may not be released under a free software license, but it is not closed -- the source is available, development happens in the open, and in a de facto (rather than de jure) sense there is little to distinguish from an open source project.  The licensing situation is obviously unfortunate, but it makes little practical difference considering that the vast majority of D language development is in the freely-licensed frontend, runtime or standard library, and there are two excellent free backends available.

This is a pretty good example of what I have referred to elsewhere in this thread, about the contextual nature of objections to "non-free".

On 7 January 2015 at 02:08, Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 06/01/15 07:14, Joakim via Digitalmars-d wrote:
>>
>> I don't think such people matter, ie they're a very small but vocal
>> minority.
>> Also, these people are deeply irrational, as every piece of hardware
>> they're
>> using comes with many closed binary blobs.  They are either ignorant of
>> this
>> fact or just choose to make silly demands anyway.
>
>
> This is a pretty bad habit you have, to just dismiss people rather than to try and understand the substance and detail of their concerns and requirements.
>
> You seem to see "non-free is a deal-breaker" as some sort of fundamentalist position.  In fact, it's almost invariably contextual and highly dependent on the particular use-case and the particular needs that someone has in a particular piece of software.
>

Frankly, I gave up reading at - "The alternative is to use the bug-ridden OSS implementation you're using now for free, and not have a paid version for those who want those bugs fixed."

No use talking to someone who is convinced that OSS means bug-ridden.


>
> And really, if you want to sell a business model to people, don't go dismissing people who tell you "this won't work for me".  Those people are your potential customers.  Find out what _will_ work for them, and give it to 'em. ;-)

I can see an opportunity - but not with any existing compilers we have at the moment.

Giving away closed-but-free software occasionally works in certain consumer markets, but you are really going to struggle with this if your consumers are comprised of mostly R&D.

No - you can't reverse a project into a closed source one.  History can tell you that (read up on The Cautionary Tale of XFree86)

If you are going to make this work, the specification of D needs to be rubber stamped either with an ANSI or ISO sticker.  This will allow interested parties to start their own competing compiler - ground up or forked from the existing implementation, it doesn't matter which.

This will have a desired effect that said group/company will not be able to "invent" new features of D.  They are free however to add any __extensions__ or pragmas to the language.

This does not mean that they have no say in the direction of the language (popular extensions could still become standardised), but it gives the current community security that our current procedures for language changes don't get bypassed by some closed-source party.

This then leads up to second point in matter.  If our D spec is set in stone, there would be little compelling differences between the paid and OSS versions of the compiler.  So why in the first place would people bother going down the proprietary route?

Nope, you need something to blow the others out the water that attracts the non-R&D community.  I would proposed that such a killer thing would need to be an integrated IDE to tied in with your closed compiler.  Whilst being a good editor, you need a tool that automates/simplifies complex processes - highlight build errors whilst you type, tell the IDE to go build ARM binaries for my project.

That is where the value-for-money factor comes in.  I cannot see any traction occurring in Joakim's badly thought out idea unless you have some *new* to give.

Iain.

On Wednesday, 7 January 2015 at 11:46:19 UTC, Iain Buclaw via Digitalmars-d wrote:
> That is where the value-for-money factor comes in.  I cannot see any
> traction occurring in Joakim's badly thought out idea unless you have
> some *new* to give.

I somehow feel that there is a commercial closed source opportunity in reducing the feature set somewhat (and fix critical bugs) then redo the memory model so that it performs well in production.

It makes sense for a business that have 5 developers working on a product to pay $10.000/year to get more productive. Of course, this is a shaky business model since the ROI could go out the window if the D community decides that a stable polished version of D is a worthy goal...

On Wednesday, 7 January 2015 at 02:16:47 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 06/01/15 23:32, uri via Digitalmars-d wrote:
>>> The dmd backend is not under an OSS license, why haven't they left?  I suspect
>>> there are not very many of the type of people you're talking about in the D
>>> community.
>>
>> It's possible that you're right but I don't see it happening. The backend
>> doesn't provide any benefit to GDC and LDC and Walter has a very good reason for
>> closing the backend sources which is understood by all.
>
> Small point: the DMD backend may not be released under a free software license, but it is not closed -- the source is available, development happens in the open, and in a de facto (rather than de jure) sense there is little to distinguish from an open source project.  The licensing situation is obviously unfortunate, but it makes little practical difference considering that the vast majority of D language development is in the freely-licensed frontend, runtime or standard library, and there are two excellent free backends available.
>
> This is a pretty good example of what I have referred to elsewhere in this thread, about the contextual nature of objections to "non-free".

Thanks for the correction, and a very important one at that in the context of this thread. I wasn't aware the backend was open source.

Cheers,
uri

On 7 January 2015 at 12:00, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 7 January 2015 at 11:46:19 UTC, Iain Buclaw via Digitalmars-d wrote:
>>
>> That is where the value-for-money factor comes in.  I cannot see any traction occurring in Joakim's badly thought out idea unless you have some *new* to give.
>
>
> I somehow feel that there is a commercial closed source opportunity in reducing the feature set somewhat (and fix critical bugs) then redo the memory model so that it performs well in production.
>

I feel that the same is for the reverse too.  If you remove features, you again enter the realm of being another language.

There may be many implementation details that you can omit or improve, such as how you go about dealing with closures, moduleinfo, thread-local GC - but features listed in the D specification are not optional.

On Wednesday, 7 January 2015 at 12:16:39 UTC, Iain Buclaw via Digitalmars-d wrote:
> I feel that the same is for the reverse too.  If you remove features,
> you again enter the realm of being another language.

Yes, but would a business care? What they care about is productivity and risk assessment. Going with a reduced feature set means they can move to open source D later on. So the risk is low.

You also have source-to-source compilation as an alternative (introduce new features, but provide source-to-source utility to mitigate perceived risk).

> There may be many implementation details that you can omit or improve,
> such as how you go about dealing with closures, moduleinfo,
> thread-local GC - but features listed in the D specification are not optional.

It is optional until you have an installed base. Specifications mean nothing unless it is backed up with a valuable (for the business) corpus that depends on it.

For a game developer the features used by the selected third party physics engine means more than what the C++11 standard says...

On 07/01/15 13:08, uri via Digitalmars-d wrote:
> Thanks for the correction, and a very important one at that in the context of
> this thread. I wasn't aware the backend was open source.

Er, I have to clarify again :-)  The backend license is not an open source one; it is, strictly speaking, proprietary:
https://github.com/D-Programming-Language/dmd/blob/master/src/backendlicense.txt

However, the code is available, development on it is public, and Walter is very liberal in giving permissions to use, distribute and so on.  I think that it's only constraints on Walter himself that mean it is not under an open source licence.

That's what I mean when I say it is de facto open, rather than de jure.  But "in practice, not in law" is an important distinction.

On Tuesday, 6 January 2015 at 20:21:50 UTC, Zach the Mystic wrote:
> On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
>> This is an idea I've been kicking around for a while, and given the need for commercial support for D, would perhaps work well here.
>>
>> The notion is that individual developers could work on patches to fix bugs or add features to ldc/druntime/phobos then sell those closed patches to paying customers.  After enough time has passed, so that sufficient customers have adequately paid for the work or after a set time limit beyond that, the patch is open sourced and merged back upstream.  It would have to be ldc and not dmd, as the dmd backend is not open source and the gdc backend license doesn't allow such closed patches.
>
> A funny scenario based on this proposal: Company A wants feature B, and signs a contract with a developer for a certain amount, receiving the feature as soon as possible, releasing the paid-for software to the public after a year. During that year, company C comes to the same developer wanting the same feature. They say, "It's already paid for, but you can pay company A half the development cost, minus the proportion of time left before it's open to everyone, and you can both have it!" Or something like that.

You're on the right track: I've talked in the past about a more advanced version of such a pricing model, that could be used for any intellectual property, not just for software.  How it would work is that the developer sets a price for all the work to develop the feature, say $3k, and picks a reasonable minimum amount of customers, say 20.  So he then sets the initial price at $150, which may seem high for a single feature.

But assuming he gets to 20 customers, the price drops for each subsequent customer, and the first 20 get a proportionate refund.  So when he gets to 30 customers, each of the last 10 to buy get charged $100, not $150, and each of the first 20 customers get their prices dropped to $100, so that the total for the developer is always $3k.  Right now, this may work better for an up-front payment model, say on a site like kickstarter, or some such marketplace where the customers have ongoing accounts and it's easy to credit money back to them without having to keep issuing refunds to their payment provider, avoiding the accompanying fees.

What are the advantages of such a model?  Well, usually the creator has to set a fixed price, whether $50 or $200, and take the risk that it is the sweet spot and will actually get enough customers to garner $3k, ie he has to guess at the supply/demand curve for his product.  In this variable pricing model, the customer also takes some of that risk, ie you'll pay more if enough other people don't also want the product.  But just like on kickstarter, that's a risk you may want to take, as long as you get the feature.  There are other elaborations on this model to account for some other factors, but the basic idea is here.

This kind of variable pricing model would have been too costly decades ago, with all the paper bookkeeping and chargebacks.  It would be trivial to implement today though and would be a much better model for many products.  Why isn't it done already?  People are stupid, no other reason.

On Thursday, 8 January 2015 at 10:37:57 UTC, Joakim wrote:
> supply/demand curve for his product.  In this variable pricing model, the customer also takes some of that risk, ie you'll pay more if enough other people don't also want the product.

Businesses don't like risk. They need to estimate the total cost before starting the project. I don't think you can advertising "less bugs" as a feature. It has to be a real feature like better performance.

Your assumption is that businesses start on a project and then later discover that they cannot work within the limits of the tools and are willing to pay a premium for it. Sure, that is possible, but your business model is flawed because it is based on your customers having a embarked on a project with a flawed plan in order to become a customer.