I can't be bothered to read all points the both of you have
mentioned thus far, but I do hope to add a voice of reason to
calm you down. ;)
On Wednesday, 26 June 2013 at 17:42:23 UTC, Joakim wrote:
On Wednesday, 26 June 2013 at 12:02:38 UTC, Joseph Rushton
Wakeling wrote:
Now, in trying to drive more funding and professional effort
towards D development, do you _really_ think that the right
thing to do is to turn around to all those people and say:
"Hey guys, after all the work you put in to make D so great,
now we're going to build on that, but you'll have to wait 6
months for the extra goodies unless you pay"?
Yes, I think it is the right thing to do. I am only talking
about closing off the optimization patches, all bugfixes and
feature patches would likely be applied to both the free and
paid compilers, certainly bugfixes. So not _all_ the "extra
goodies" have to be paid for, and even the optimization patches
are eventually open-sourced.
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.
How do you think that will affect the motivation of all those
volunteers -- the code contributors, the bug reporters, the
forum participants? What could you say to the maintainers of
GDC or LDC, after all they've done to enable people to use the
language, that could justify denying their compilers
up-to-date access to the latest features? How would it affect
the atmosphere of discussion about language development --
compared to the current friendly, collegial approach?
I don't know how it will affect their motivation, as they
probably differ in the reasons they contribute.
If D becomes much more popular because the quality of
implementation goes up and their D skills and contributions
become much more prized, I suspect they will be very happy. :)
If they are religious zealots about having only a single,
completely open-source implementation- damn the superior
results from hybrid models- perhaps they will be unhappy. I
suspect the former far outnumber the latter, since D doesn't
employ the purely-GPL approach the zealots usually insist on.
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.
... and -- how do you think it would affect uptake, if it was
announced that access to the best features would come at a
price?
Please stop distorting my argument. There are many different
types of patches added to the dmd frontend every day: bugfixes,
features, optimizations, etc. I have only proposed closing the
optimization patches.
However, I do think some features can also be closed this way.
For example, Walter has added features like SIMD modifications
only for Remedy. He could make this type of feature closed
initially, available only in the paid compiler. As the feature
matures and is paid for, it would eventually be merged into the
free compiler. This is usually not a problem as those who want
that kind of performance usually make a lot of money off of it
and are happy to pay for that performance: that is all I'm
proposing with my optimization patches idea also.
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.
In another email you mentioned Microsoft's revenues from
Visual Studio but -- leaving aside for a moment all the moral
and strategic concerns of closing things up -- Visual Studio
enjoys that success because it's a virtually essential tool
for professional development on Microsoft Windows, which still
has an effective monopoly on modern desktop computing.
Microsoft has the market presence to be able to dictate terms
like that -- no one else does. Certainly no upcoming
programming language could operate like that!
Yes, Microsoft has unusual leverage. But Visual Studio's
compiler is not the only paid C++ compiler in the market, hell,
Walter still sells C and C++ compilers.
I'm not proposing D operate just like Microsoft. I'm
suggesting a subtle compromise, a mix of that familiar closed
model and the open source model you prefer, a hybrid model that
you are no doubt familiar with, since you correctly pegged the
licensing lingo earlier, when you mentioned "open core."
These hybrid models are immensely popular these days: the two
most popular software projects of the last decade, iOS and
Android, are hybrid models. Of course, that is partly because
mobile is such a hot field, but the explosion of mobile
software didn't mean success for the closed models of RIM,
Nokia, or Microsoft. Android's hybrid model is a big reason
why it succeeded.
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.
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.
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.
My thoughts in summary:
- 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.
- 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.
- 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.
tl/dr;
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.
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.
</ End argument on feasibility of a hybrid development model >
Regards
Iain "That GDC Developer" Bucław
