On Monday, 5 January 2015 at 22:51:25 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 05/01/15 21:57, Joakim via Digitalmars-d wrote:
If you're not paying, you're not a customer. 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. I don't doubt
that some irrational
people interpret the existence of a paid version in the way
you laid out, and in
extreme cases that _can_ happen (just as there are OSS vendors
who write bad OSS
code just so they can make more money off your favored support
model), but
that's more an issue with their sloppy thinking than anything
else.
See, this is where I find _your_ point of view irrational,
because you fail to see how straightforwardly damaging closed
source can be to adoption. The fact of the matter is that for
a great many users, and particularly for a great many corporate
adopters of development toolchains, today it matters hugely
that the toolchain is free-as-in-freedom. Not free 6 months
down the line -- free, now, in its entirety.
Non-free code (even temporarily), secret development, etc., are
simply deal-breakers for a great many people. A smart business
model will engage with this fact and find a way to drive money
to development without closing things up.
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.
There are also "fully open source" languages which are "fully
commercially
supported." How do your managers wrap their minds around such
a paradox? ;)
See, if I was in your shoes, I'd be trying to take on board the
feedback about why your proposed model would be unattractive to
his managers, rather than making sarcastic points that don't
actually identify a conflict with their position.
Heh, the whole point of the sarcastic comment was to point out
the obvious conflict in their position. :)
Most commercial adopters are going to consider it very
important to have a support option that says, "If you have a
serious blocker, you can pay us money to guarantee that it gets
fixed."
They are not going to be at all happy about a support option
that says, "If we develop a fix, then you are not going to get
it in a timely manner unless you pay."
Understanding that distinction is very important.
Haha, you do realize that those two quotes you laid out are the
exact same option? In the first option, you pay for a fix. In
the second option, you pay for a fix. What distinction you're
hoping to draw has not been made.
My point is that such artificial distinctions are silly,
whether because of the
amount of support or source available. The alternative to
paid bug fixes is not
that all the bugs you want fixed get done for free: it's _no_
bug fixes, as we
see today. For example, selective imports at module scope has
been broken for
more than eight years now, as those symbols are leaked into
any module that
imports the module with the selective import. There are many
more bugs like
that, that could actually be fixed much faster if there were
more paid devs
working on D.
You're talking about "the alternative to paid bug fixes" as if
the only way of having paid bug fixes is to follow your model
of locking them away from the wider community. That's simply
not true.
I wait with bated breath for your model of paid bug fixes that
doesn't involve closing the code for the bug fixes at all. You
must have discovered some billion-dollar scheme, because every
software company in the world is waiting to copy your brilliant
method.
Having both paid and free versions available is not a
"paywall" on a language.
Unless those versions are identical, yes it is.
No, it isn't. Your being able to use the always OSS dmd/gdc for
free means the language is always available to you. Just because
someone else is using an enhanced version of ldc doesn't make the
free version any less available to you. To suggest otherwise is
to distort the language to make your argument, ie flat out lying.
A company is not going to just write a bunch of patches and
open source all of
them unless they have some complementary business model to go
with it, whether
google making more mobile revenue off Android or Apple
providing clang as the
system compiler on OS X and making money off the bundled Mac.
So why not focus on creating those complementary business
models?
If you have a complementary business model for a D compiler, feel
free to suggest one and get people to use it. I don't think
complementary business models are generally a good idea, because
the people making money are usually going to focus on the place
they're making money. This is why google doesn't care that much
if AOSP and Nexus devices are fairly buggy (I bought a Nexus
device, will never buy one again for this reason), because they
don't really make money off Android but off the complementary
mobile ads.
Bottom line: if some individual or group of devs want to try
and make a business selling proprietary patches to the DMD
frontend, or phobos, the licensing allows them to do that.
Good luck to them, and if they want to submit those patches to
D mainline in future, good luck to them again.
Given all your other responses, I suspect this is not the case,
ie you don't want to see it happen. But you're right, nobody can
stop paid devs from doing this.
However, I don't see it making any sense for a company to
invest in proprietary patches to a toolchain, because 99% of
the time, when you need a patch written, it's a bugfix. And
when you want a bugfix, you don't want a patch that applies
only to your version of the toolchain and which you (or your
friendly proprietary-patch-writing consultant) have to keep
rebasing on top of upstream for the next 6 months -- you want
upstream fixed. Otherwise you'll wind up paying far more
merely for maintenance of your proprietary extensions, than you
would have just to get someone to write a patch and get it
straight into the open-source upstream.
These merging and rebasing issues you raise are fairly trivial.
I've had PRs sit unmerged on github for many months and
occasionally they'll go out of date with git HEAD. Updating them
to work again takes a negligible amount of time. If paid devs
only focus on point releases initially, as mentioned above, the
problem doesn't really exist.
I also think you assume far too much value on the part of
privileged/early access to bugfixes. A bug in a programming
language toolchain is either a commercial problem for you or it
isn't. If it's a commercial problem, you need it fixed, and
that fix in itself has a value to you. There is not really any
comparable change in value if that fix also gets delivered to
other users (who may or may not be competitors of yours),
because that isn't what differentiates your product.
Of course there's a change in value. If another user or
competitor also needs that fix and pays for it and upstreams it
before you do, that's a cost you don't have to pay at all. Hence
the whole "tragedy of the commons" I laid out in my first post.
D is not an OS like linux, so the consulting/support model
doesn't apply. While
such free corporate investment is theoretically possible for
D, it is very
unlikely and as I mentioned in my linked article, such support
models are not as
successful.
On the contrary, D is a programming language, and as such is
used by people to make commercial projects, and so those people
have a very strong interest in paying for commercial support,
based around the principle "If we need something fixed, it will
be fixed."
But they don't have an interest in a situation where, "If
something gets fixed, we have to pay."
The first of those options delivers value. The second is
exploitation.
I suggest you actually read what you're writing:
"people have a very strong interest in paying for commercial
support, based around the principle 'If we need something fixed,
it will be fixed.'"
"If something gets fixed, we have to pay."
In both cases, they're paying for fixes. If your point is that
in the first model they're paying up front through a support
subscription, whereas in the second model they're paying after
they identify the fix- a distinction I'm stretching to find as
you haven't really made it- both are still paying for a fix.
Certainly some companies would prefer the financial certainty of
up-front recurring subscriptions to paying on a case-by-case
basis, just as some would prefer the potential savings of the
latter model, but the former certainly wouldn't save them any
money.
Turning D into a paid product by using the hybrid model I laid
out would make
its development go much faster. There would always be an OSS
core for OSS devs
to work on and for users to download for free, while those who
want to pay for
quality and features would do so. It's similar to how other
compiler vendors
put out a free but less capable compiler and sell a more
capable one.
Name me an example of such a vendor that isn't a massive, huge
corporate behemoth whose ability to sign contracts and make
sales is largely dependent on business factors entirely
separate from their product licensing.
I'm not sure what point you're trying to make, that only
"massive, huge corporate behemoths" can sell paid compilers
alongside a free base model? There are many smaller companies
selling paid compilers, hell, Borland C++ is still around as
embarcadero C++ Builder.
Guess what? Embarcadero provides a starter edition, for those
who aren't making much money to try out, and a full paid version,
for once you go over $1k/year in revenue. Embarcadero is a
good-sized software company at 500 employees and $100 million in
yearly revenue, but I certainly wouldn't call them a "massive,
huge corporate behemoth."
The dual free and paid model I've laid out is commonplace in the
compiler world.
I'm really happy that you're trying to think about how to
generate money for D development, but I think your insistence
on the necessity of selling closed components is based on a
misunderstanding both of how free software flourishes and of
the business factors at play in the projects you cite as
inspiration.
I'd argue that such a criticism best applies to you. The most
widely used OSS projects these days are inevitably hybrid
projects, that is incontrovertible. You prefer that all the
source is available to you, so you make such statements that are
contrary to the facts or hand-wave away their success with vague
allusions to other "business factors at play," which you of
course do not lay out.
Obviously no one factor is determinative in success: it's always
theoretically possible that the main reason Android succeeded is
because it used Java, and that the source licensing played little
part. In that case, D can't succeed by using a similar hybrid
model, because it's not Java. ;)
But proper rational examination of Android and other hybrid
projects' success suggests hybrid licensing had a very large role
to play. I suspect you're not interested in such a rational
analysis, because you have an ideological or emotional connection
to all source being available, ie pure FOSS. That's fine, just
don't expect me to respect your position, that others must always
work you for free and give you _all_ the source.
