On Wednesday, 26 June 2013 at 19:26:37 UTC, Iain Buclaw wrote:
From a licensing perspective, the only part of the source that
can be "closed off" is the DMD backend. Any optimisation fixes
in the DMD backend does not affect GDC/LDC.
This is flat wrong. I suggest you read the Artistic license, it
was chosen for a reason, ie it allows closing of source as long
as you provide the original, unmodified binaries with any
modified binaries. I suspect optimization fixes will be in both
the frontend and backend.
You should try reading The Cathedral and the Bazaar if you
don't understand why an open approach to development has caused
the D programming language to grow by ten fold over the last
year or so.
If you still don't understand, read it again ad infinitum.
Never read it but I have corresponded with the author, and I
found him to be as religious about pure open source as Stallman
is about the GPL. I suggest you try examining why D is still
such a niche language even with "ten fold" growth. If you're not
sure why, I suggest you look at the examples and reasons I've
given, as to why closed source and hybrid models do much better.
Think I might just point out that GDC had SIMD support before
DMD. And that Remedy used GDC to get their D development off
the ground. It was features such as UDAs, along with many
language bug fixes that were only available in DMD development
that caused them to switch over.
In other words, they needed a faster turnaround for bugs at the
time they were adopting D, however the D front-end in GDC stays
pretty much stable on the current release.
Not sure what point you are trying to make, as both gdc and dmd
are open source. I'm suggesting closing such patches, for a
limited time.
I see no reason why another "upcoming" project like D couldn't
do the same. :)
You seem to be confusing D for an Operating System, Smartphone,
or any general consumer product.
You seem to be confusing the dmd compiler to not be a piece of
software, just like the rest, or the many proprietary C++
compilers out there.
Having used closed source languages in the past, I strongly
believe that closed languages do not stimulate growth or
adoption at all. And where adoption does occur, knowledge is
kept within specialised groups.
Perhaps there is some truth to that. But nobody is suggesting a
purely closed-source language either.
I don't think a "purely community-run project" is a worthwhile
goal, particularly if you are aiming for a million users and
professionalism. I think there is always opportunity for
mixing of commercial implementations and community
involvement, as very successful hybrid projects like Android
or Chrome have shown.
Your argument seems lost on me as you seem to be taking a very
strange angle of association with the D language and/or
compiler, and you don't seem to understand how the development
process of D works either.
I am associating D, an open source project, with Android and
Chrome, two of the most successful open source projects at the
moment, which both benefit from hybrid models. I find it strange
that you cannot follow. If I don't understand how the
development process of D works, you could point out an example,
instead of making basic mistakes in not knowing what licenses it
uses and what they allow. :)
- The language implementation is open source. This allows
anyone to take the current front-end code - or even write their
own clean-room implementation from ground-up - and integrate it
to their own backend X.
Sort of. The dmd frontend is open source, but the backend is not
under an open source license. Someone can swap out the backend
and go completely closed, for example, using ldc (ldc used to
have one or two GPL files, those would obviously have to be
removed).
- The compiler itself is not associated with the development of
the language, so those who are owners of the copyright are free
to do what they want with their binary releases.
- The development model of D on github has adopted a "pull,
review and merge" system, where any changes to the language or
compiler do not go in unless it goes through proper coding
review and testing (thank's to the wonderful auto-tester). So
your suggestion of an "open core" model has a slight fallacy
here in that any changes to the closed off compiler would have
to go through the same process to be accepted into the open one
- and it might even be rejected.
I'm not sure why you think "open core" patches that are opened
after a time limit would be any more likely to be rejected from
that review process. The only fallacy I see here is yours.
- Likewise, because of licensing and copyright assignments in
place on the D front-end implementation. Any closed D compiler
using it would have to make its sources of the front-end, with
local modifications, available upon request. So it makes no
sense whatsoever to make language features - such as SIMD -
closed off.
I suggest you read the Artistic license. You have no idea what
you are talking about.
DMD - as in refering to the binary releases - can be closed /
paid / whatever it likes.
The D Programming Language - as in the D front-end
implementation - is under a dual GPL/Artistic license and
cannot be used by any closed source product without said
product releasing their copy of the front-end sources also.
This means that your "hybrid" proposal only works for code that
is not under this license - eg: the DMD backend - which is not
what the vast majority of contributors actually submit patches
for.
Wrong, you have clearly not read the Artistic license.
If you strongly believe that a programming language can't be
big (as in 1M users) without being partly closed source, I
suggest you do your research better.
I have done my research and provided examples: you provide none.
I suggest it is you who needs to research this topic. Start with
reading the Artistic license. :)
</ End argument on feasibility of a hybrid development model >
</ End my demolition of your ignorant arguments >
