On 05/01/15 21:57, Joakim via Digitalmars-d wrote:
If you're not paying, you're not a customer. The alternative is to use the bug-ridden OSS implementation you're using now for free, and not have a paid version for those who want those bugs fixed. I don't doubt that some irrational people interpret the existence of a paid version in the way you laid out, and in extreme cases that _can_ happen (just as there are OSS vendors who write bad OSS code just so they can make more money off your favored support model), but that's more an issue with their sloppy thinking than anything else.
See, this is where I find _your_ point of view irrational, because you fail to see how straightforwardly damaging closed source can be to adoption. The fact of the matter is that for a great many users, and particularly for a great many corporate adopters of development toolchains, today it matters hugely that the toolchain is free-as-in-freedom. Not free 6 months down the line -- free, now, in its entirety.
Non-free code (even temporarily), secret development, etc., are simply deal-breakers for a great many people. A smart business model will engage with this fact and find a way to drive money to development without closing things up.
There are also "fully open source" languages which are "fully commercially supported." How do your managers wrap their minds around such a paradox? ;)
See, if I was in your shoes, I'd be trying to take on board the feedback about why your proposed model would be unattractive to his managers, rather than making sarcastic points that don't actually identify a conflict with their position.
Most commercial adopters are going to consider it very important to have a support option that says, "If you have a serious blocker, you can pay us money to guarantee that it gets fixed."
They are not going to be at all happy about a support option that says, "If we develop a fix, then you are not going to get it in a timely manner unless you pay."
Understanding that distinction is very important.
My point is that such artificial distinctions are silly, whether because of the amount of support or source available. The alternative to paid bug fixes is not that all the bugs you want fixed get done for free: it's _no_ bug fixes, as we see today. For example, selective imports at module scope has been broken for more than eight years now, as those symbols are leaked into any module that imports the module with the selective import. There are many more bugs like that, that could actually be fixed much faster if there were more paid devs working on D.
You're talking about "the alternative to paid bug fixes" as if the only way of having paid bug fixes is to follow your model of locking them away from the wider community. That's simply not true.
Having both paid and free versions available is not a "paywall" on a language.
Unless those versions are identical, yes it is.
A company is not going to just write a bunch of patches and open source all of them unless they have some complementary business model to go with it, whether google making more mobile revenue off Android or Apple providing clang as the system compiler on OS X and making money off the bundled Mac.
So why not focus on creating those complementary business models?
That community involvement would still be there for the OSS core with D, but you would get support for a closed patch from the developer who wrote it. ... There is essentially nothing different from this situation and the hybrid model I've described, in terms of the product you'd be using. The only difference is that it wouldn't be a company, but some selection of independent devs.
Bottom line: if some individual or group of devs want to try and make a business selling proprietary patches to the DMD frontend, or phobos, the licensing allows them to do that. Good luck to them, and if they want to submit those patches to D mainline in future, good luck to them again.
However, I don't see it making any sense for a company to invest in proprietary patches to a toolchain, because 99% of the time, when you need a patch written, it's a bugfix. And when you want a bugfix, you don't want a patch that applies only to your version of the toolchain and which you (or your friendly proprietary-patch-writing consultant) have to keep rebasing on top of upstream for the next 6 months -- you want upstream fixed. Otherwise you'll wind up paying far more merely for maintenance of your proprietary extensions, than you would have just to get someone to write a patch and get it straight into the open-source upstream.
I also think you assume far too much value on the part of privileged/early access to bugfixes. A bug in a programming language toolchain is either a commercial problem for you or it isn't. If it's a commercial problem, you need it fixed, and that fix in itself has a value to you. There is not really any comparable change in value if that fix also gets delivered to other users (who may or may not be competitors of yours), because that isn't what differentiates your product.
D is not an OS like linux, so the consulting/support model doesn't apply. While such free corporate investment is theoretically possible for D, it is very unlikely and as I mentioned in my linked article, such support models are not as successful.
On the contrary, D is a programming language, and as such is used by people to make commercial projects, and so those people have a very strong interest in paying for commercial support, based around the principle "If we need something fixed, it will be fixed."
But they don't have an interest in a situation where, "If something gets fixed, we have to pay."
The first of those options delivers value. The second is exploitation.
Turning D into a paid product by using the hybrid model I laid out would make its development go much faster. There would always be an OSS core for OSS devs to work on and for users to download for free, while those who want to pay for quality and features would do so. It's similar to how other compiler vendors put out a free but less capable compiler and sell a more capable one.
Name me an example of such a vendor that isn't a massive, huge corporate behemoth whose ability to sign contracts and make sales is largely dependent on business factors entirely separate from their product licensing.
I'm really happy that you're trying to think about how to generate money for D development, but I think your insistence on the necessity of selling closed components is based on a misunderstanding both of how free software flourishes and of the business factors at play in the projects you cite as inspiration.
