On Monday, 5 January 2015 at 18:28:39 UTC, Jarrett Tierney wrote:
As a user of D in a corporate environment and personal at home environment, I have to say this model won't work for me. In fact if this model were implemented, I would more than likely have to move my project to a different language because of it. Let me explain the issues I see here.

You've proposed a hybrid open and closed source model. Where certain segments of code (latest patches) are behind a per patch paywall. As a customer I don't want to have to pay for each bug fix in the compiler. If there is a bug in the language/compiler then I want it fixed. I shouldn't be charged to have the language I'm using work properly. It basically says to customers, here you can use this language for free, unless you want it to work properly, in which case you need to pay for each fix you need or wait till developers don't care about making money off a fix anymore.

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.

This will also diminish the growth rate of D. I can tell you, it would be significantly harder for me to use D at my workplace if this model were in place. Managers are okay in letting me use D because its an open source project (minus the backend of DMD) and it doesn't cost them a cent. If all of the sudden I have to ask them to pay for fixes in order for my project to work, that makes it a different situation entirely. My company would also frown on the free option of waiting for fixes to pass out of the pay wall. Companies like actively supported projects. As such, companies (at least the one I work for) prefer either fully commercially supported languages (C# through VS) or fully open source.

There are also "fully open source" languages which are "fully commercially supported." How do your managers wrap their minds around such a paradox? ;)

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.

Remember, that there are ways to provide commercial support without putting a paywall on using the language itself. What is really needed here is buy-in from corporations on the language. Having engineers from a company working on D would provide one form of commercial support. But this model is very difficult to find and the closest to it I've seen is Facebook's involvement with D. I agree having developers who are paid to work on D would be a great thing, but reaching that point is a very difficult road.

Having both paid and free versions available is not a "paywall" on a language. 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.

While I understand, that D needs some form of commercial support for some parties, there is also a stigma that the current model doesn't provide support. I've found to the contrary actually. I find the full open source model employed here, has a better support system than a lot of other commercial support models. The reason is the community, there is always someone around to answer a question. I find with most commercially supported models the development team can't be reached and you have to depend on your coworkers or friends who may know of a workaround (Microsoft model). Most of the time I see bugs get fixed fairly promptly for a compiler project despite the fragmented development that is inherent to open source projects.

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.

I think commercial support for D really comes down to one of two situations in the future:

* A company decides to make a commercial D compiler that is closed source but compatible with phobos, etc. They fully support the compiler. (Doesn't necessarily mean they charge for the compiler itself, they could but they can also charge for support plans and/or a IDE tool).

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.

* A company decides to invest engineers in working on the open source D compiler. Thus providing commercially supported developers to the project. (This would be a hybrid too, where the open source developers can still contribute and work but now there are a group of paid engineers working to advance the language as well).

As I said above, this is unlikely. Just because it has happened before with some OSS projects, many OSS users/devs fantasize that it will happen for their favored project.

IBM and Red Hat didn't contribute to linux because they believe in FOSS or wanted to "give back" to the community, but because they saw real economic advantages to leveraging an existing OS code base in their consulting/support businesses. The GPL and the fact that their businesses distribute software to their customers made them give back their patches. Meanwhile, google runs a patched linux kernel on a gazillion search servers and doesn't distribute their patches, because the license doesn't say they have to and they see no economic advantage to doing so.

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.

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.

Reply via email to