An idea for commercial support for D

[Iain Buclaw via Digitalmars-d]

On 7 January 2015 at 02:08, Joseph Rushton Wakeling via Digitalmars-d
<digitalmars-d at 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.