On 7 January 2015 at 02:08, Joseph Rushton Wakeling via Digitalmars-d <firstname.lastname@example.org> 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.