On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 4 Jan 2015 08:35, "Joakim via Digitalmars-d"
<digitalmars-d@puremagic.com>
wrote:
This is an idea I've been kicking around for a while, and
given the need
for commercial support for D, would perhaps work well here.
The notion is that individual developers could work on patches
to fix
bugs or add features to ldc/druntime/phobos then sell those
closed patches
to paying customers. After enough time has passed, so that
sufficient
customers have adequately paid for the work or after a set time
limit
beyond that, the patch is open sourced and merged back
upstream. It would
have to be ldc and not dmd, as the dmd backend is not open
source and the
gdc backend license doesn't allow such closed patches.
Do what you want, but I don't think you could or should call it
D from the
moment you deviate.
I'm not doing anything, I'm putting an idea out here for
consideration. I'm uninterested in doing this on my own and
seeding such paid patches entirely by myself, so if there aren't
enough people interested in both paid development and paying for
patches, it won't get done.
As for what to call it, ldc and gdc both differ from dmd in
non-trivial ways and still call themselves D compilers. I don't
think the name really matters, but for what it's worth, I agree
with you that if such a commercial model goes in a completely
different direction with the language, a name change is probably
best.
http://www.phoronix.com/scan.php?page=article&item=sprewell_licensing
There's no such thing as a hybrid. You're either a cathedral
or a bazaar,
and a hybrid approach is looking pretty cathedral to me.
Tell that to the most widely used open-source projects these
days, ie hybrid projects like Android, iOS/OS X, llvm/clang,
Chrome, etc. There are advantages to both the cathedral and the
bazaar model, which is why it's best to mate the two, as has been
done by the listed highly successful software.
From a technical standpoint, how do you propose to deal with
splitbrain
situations? If your proposed closed solution is
source-incompatible with
the open then you have failed as a model.
Not sure if you're referring to users' D source that can't be
compiled by both compilers or patches from the closed D frontend
that might be difficult to merge back upstream into the dmd
frontend. Obviously both can be handled with some effort. Since
the idea is not to completely fork the frontend but to provide
patches on it that are eventually upstreamed, I doubt either will
be a problem.
From a pragmatic (though maybe philosophical) standpoint,
having been in
active development in or around the core for 4 years, my
observation (which
I believe Walter shared as well) is that back when DMD was
partially
closed, there just wasn't much traction in development or
adoption. Right
now things are moving pretty fast, and I don't think DMD *can*
get any more
open than what it already is. Given the compelling correlation
between
both popularity and contribution with the openness of
development at the
core (ie: moving to github), history tells us that closing will
only serve
to stifle and stop.
Was Walter selling a paid compiler with the then-closed dmd
backend? If not, the comparison is not valid. The idea here is
for paying customers to fund closed patches for a limited time,
and speed up D bug-fixing and development much more. If Walter
was not getting paid for his closed backend but only keeping it
closed because of licensing issues, the situations are completely
different.
Also, this is a _hybrid_ approach, not a closed one. There will
always be an OSS core that potential devs can look at. They just
may not have access to all the closed-source patches that others
are selling.
Recent history of the explosively successful hybrid projects I
listed suggests that a hybrid approach is the most scalable one.
