On Wednesday, 7 January 2015 at 02:08:45 UTC, Joseph Rushton
Wakeling via Digitalmars-d 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.
That's because it _is_ a fundamentalist position, that almost
nobody holds. You yourself point out that you don't hold it,
because you're perfectly willing to use linux with binary blobs.
The only bad habit I see here is your repeated imposition of such
a silly position on D, despite my repeatedly engaging with "the
substance and detail" of the issues you raise and pointing out
all the flaws with such thinking.
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.
For example, I'm not particularly happy about the existence of
binary blobs or drivers in my Linux kernel, but it has very
little practical effect on my ability to use Linux-based OS's,
the sustainability of Linux development, or its reliability as
a platform. It's mostly a PITA for the kernel devs themselves
and distro manufacturers who have to debug problems caused by
these proprietary components.
So your point is that "non-free is _not_ a deal-breaker" when it
comes to the OS or some other tech further down the stack, which
doesn't _directly_ impinge on your "commercial and product goals"
like a compiler does. That's perfectly pragmatic, but it doesn't
sound like non-free is really a deal-breaker for you, maybe just
for certain key tools.
But by contrast I would be extremely reluctant to base my
software business around a development toolchain with
proprietary components, or where I feared that might become
part of the toolchain's business model in future. Why? Because
that enables someone else, whose interests may be different to
mine, to exert control over my ability to fulfil my commercial
and product goals. The moment you accept a proprietary
component into your toolchain, you're at risk of "Pay us more
or we stop supporting this thing you are dependent on," and
because it's proprietary, you simply don't have the same
options to find another supplier.
That's not zealotry or moralism or absolutist, it's basic
business sense, and it's not a hard decision to reach when
there are so many excellent free development toolchains out
there, whose development models are _not_ based on limiting
access to new features or fixes.
That _is_ zealotry: it's so paranoid that it's _not_ "basic
business sense" for the vast majority of developers who employ
proprietary toolchains, like MS Visual Studio or Embarcadero.
The way the bulk of devs avoid the "Pay us more or we stop
support problem" is by using programming languages with a common
spec and with multiple competing commercial implementations, so
they can always switch compilers.
Switching is certainly not costless, but it puts a cap on how
much your original compiler vendor can extort you, because if the
cost of switching is less than their extortion attempt, you'll
switch. Also, the ultimate deterrent to such potential extortion
is all the other customers who'd then switch when you publicized
such behavior, as they know they'd be next to receive such a
shakedown.
In any case, I suggest you reread the linked Phoronix article
from my original post where I wrote about the benefits of such
hybrid models. One of the major benefits of hybrid models is
that if you don't like what a vendor is doing, you can still fork
their OSS code. So if one paid D compiler vendor tried to pull
such a move on you, there would very likely be other vendors you
could easily switch to. :)
Heh, the whole point of the sarcastic comment was to point out
the obvious
conflict in their position. :)
There isn't any conflict in their position. If you don't see
it, that's probably because you don't perceive some important
distinctions that they are concerned with ...
This would mean something if you would lay out why there's no
conflict, rather than hand-waving about "important distinctions"
that you don't know either. Since you can't, I must be right. :)
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.
... such as the distinction between paying for a new fix to be
created, versus being forbidden from accessing already-existing
fixes _unless_ you pay.
You seem to think that the only dividing line is whether a fix
is paid for or not. It isn't. If you're paying for a new fix
or feature, then you're paying for the creation of new value.
If you're paying in order to access fixes or features that have
already been created, then money is being extracted from you on
the basis of artificial scarcity. The two create very
different incentives on the part of both suppliers and
purchasers.
I'll pose the same question I did to the anonymous poster above,
who tried unsuccessfully to explicate your possible reasoning:
precisely which provider of commercial support is providing
"fixes or features that have already been created" and paid for
by one user to other users for free?
The only reason I focused on the fact that fixes have to be paid
for in both models is because you never said that outside fixes
are provided for free in the first model, in your original quote
up above. We cannot focus on distinctions you have not made. :)
I see no difference in the incentives to purchasers whether they
pay for a new fix or for already-created fixes. In either case,
they're simply paying for what they want and it hardly matters to
them when it was created. Perhaps there is a difference in the
incentives for suppliers, but since you do not bother listing a
single difference, I can't take such hand-waving seriously.
Note that the above isn't a moral judgement. We don't need to
assume there is anything ethically suspect about business based
around artificial scarcity. But it is certainly true that,
from a purchaser's point of view, it is generally preferable to
avoid being dependent on such businesses.
Yet the vast majority of purchasers, including Jarrett's
managers, who he said have no problem with closed-source products
like VS, have no problem being dependent on such businesses based
on "artificial scarcity."
That's fundamentally the decision that Jarrett's managers are
making: not between projects that do or don't have paid
support, but between projects whose support options are based
around creation of new value versus projects whose support
model is based around the creation of artificial scarcity.
I envy your ability to read his managers' minds, because I can
only rely on what Jarrett wrote. ;) Since he says they have no
problem with using closed-source software like VS, they clearly
have no problem with "artificial scarcity." I would bet that if
you asked them about "artifical scarcity," 100% of them would
have no idea what that meant. :D
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.
There's a very simple and straightforward model of paid bug
fixes. The core development team charges a retainer that
enables the payer to request prioritization of fixes and/or
features they require. You pay on a subscription basis, you
put in your priority requests as and when they arise.
Effectively, this is taking out insurance against blockers, and
as with regular insurance, there can be different scales of fee
depending on what it is you want "coverage" for (just bugfixes?
new features too? or do you just care about getting priority
for merges of fixes that your own team will create?), on the
anticipated volume of requests you are going to make, and on
exactly how much you want to be first on the list where there
are conflicting priorities. And of course, if you don't make
any "claims" for a period of time, this can also bump you up
the priority list for when you finally do need something.
This is a win-win all round -- the core development team gets a
regular supply of money; commercial users have a predictable
cost for protecting themselves against bugs, and are not
"locked in" in any way; costs are spread across commercial
users, so there shouldn't need to be any disincentive to
request a fix when you do actually need it. (You can guard
against reluctance to put in claims by ensuring that if
multiple customers all request a fix, it gets higher priority,
and that it counts less towards their individual volume of
claims.) Finally, everything remains free software for
everyone, both the commercial users and the wider developer and
user community, which means that there's no potential
disincentive to community contributions ("Why should I
contribute to a project that locks away the latest features
from me?").
What about the freeloaders? Well, the basis of this model is
that if someone depends on a particular piece of software for
their own value-creating activities, then it's in their
interest to insure against the reliability of that tool.
Someone who chooses not to is basically gambling that they will
never encounter a blocker; I'd say that's their call to make,
but I also think that if the tool is valuable enough, there
will be plenty of people who _do_ value being insured.
Yes, this appears to be your own retainer-oriented variation on
the familiar consulting/support model used by companies like Red
Hat. As I said before, your preferred support model has worked
for certain types of OSS projects, but is not nearly as
successful and scalable as hybrid projects like Android or
clang/llvm.
Building a product business, in D's case with paid patches on the
OSS core, is orders of magnitude more successful than
consulting/support businesses, ie product businesses' profits and
revenues are 10-100 times greater than consulting/support
businesses, especially OSS ones.
Now you may say, "Who cares? Red Hat still makes plenty of
money." Yes, but for how long? The fact that hybrid products
have 100 times the profits available means they can plow a lot
more money into their products and obsolete the pure FOSS
consulting/support projects.
We already see this happening, with a billion users of hybrid
Android on their smartphones, and essentially nobody running FOSS
Ubuntu or some other linux distro on a mobile device. How long
before hybrid Android becomes a desktop distro and kills off the
tiny FOSS linux distro market too?
I see no reason for D to embrace a clearly inferior business
model like support/consulting, which has already been shown to
perform much worse in the market. That's just setting it up for
failure against other languages that use a hybrid approach. Of
course, since D is permissively licensed, we can always try both
approaches and see what happens. :)
There are really only two options here. If the proprietary,
enhanced features are part of the language/standard library
spec, then there is a paywall around the language.
No, there is a paywall around some features of the language
provided by a certain implementation. There is nothing stopping
OSS devs from creating a competing OSS implementation of the same
features. If they're incapable of doing so, that's their problem.
If they are not officially part of the spec, but they are
supplied by the official language project and the performance
of the language is in practice much worse without them, then
I'd still count that as a paywall around the language, because
it's the official project withholding functionality on the
basis of payment.
Nope, still only a paywall around certain features, and since
they're not part of the spec, it's a stretch to even say they're
part of the language. No idea what you mean by "the official
language project," as D is developed and distributed by a loose
confederation of OSS devs and companies. If some of them also
decide to sell paid patches along with their donations of OSS
patches, they're not "withholding functionality," they simply
chose not to donate their work on those features.
It is amazing how just because they have been so generous with
their time so far, you make demands on what they must do with
their time in the future.
If neither, then you're simply talking about a 3rd-party
library or toolchain, in which case -- well, businesses can be
based around such things, and if they drive benefits back to
the core project that's nice.
Since none of the core OSS devs have expressed any interest in
this paid patches model, that is likely what it would be. But as
detailed above, if any of them were to join in to providing paid
patches, it is ludicrous to suggest they are "withholding"
anything from you.
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.
The second half of your last sentence here summarizes rather
well why I don't like the idea of generating money by
restricting access to features and fixes. They have an
incentive to restrict as much as possible and release as little
as they can.
Well, such incentives are there anytime somebody is getting paid,
doesn't matter if it's the paid patches model you don't like or
the paid support model you prefer. The alternative to getting
paid to work on D is that they can't pay their bills and they go
do something else, so that no features or fixes get done, or at
the very least a lot less in their spare time. Most reasonable
people prefer paying to getting almost nothing for free.
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.
I've described one payment model to avoid that; there are
surely others. But ultimately even without that, there isn't
really a "tragedy of the commons" at work in the scenario you
describe, because in this case, people pay not in order to
solve some problem for "the commons", but to solve problems
that are blockers to their own value-creating activity. Yes,
you can gamble on someone else solving your problem for you,
but your ability to do that largely rests on the degree to
which that solution is actually really vital for you.
Your consulting/support payment model doesn't "avoid that," it
simply tries to coexist with it, like Red Hat long co-existed
with CentOS. But it certainly hurts the consulting/support
vendors and makes them much less successful. Nobody said anyone
is paying "in order to solve some problem for 'the commons,'" but
that if you release the source into the commons right away, there
will be others who will free-ride and not pay.
You're right that those free-riding companies may have to pay
when they consider the solution vital, but they don't have to
open-source their fix. So while _you_ may pay a vendor for fixes
in gcc and let them open-source them, your competitor may pay
some other vendor for other fixes in gcc and keep those patches
to themselves. Since your competitor isn't distributing gcc but
using it in-house to build their own software, they are not
forced by the GPL to release their patches. So they get all the
fixes you paid for for free and don't release their fixes back to
you. And this does happen in practice, a fair amount of
companies maintain proprietary patchsets on even GPL software
that they use.
This is why hybrid models do much better, because they mix the
much greater revenue from closed-source patches in with the
commons of the OSS core.
BTW, in reference to the "tragedy of the commons", it's worth
mentioning that the canonical example often cited -- the
farmers who have a shared interest in common land being
available for grazing but no individual motive to maintain it
-- ignores all the historical mechanisms and institutions that
were employed to ensure that common land was indeed maintained.
I agree that there have sometimes been such mechanisms that are
neither fully public nor private, just as hybrid source models
are not fully a commons or private. :)
It's not surprising that it does so either, because this
"example" originates during the final stages of the enclosure
movement in the United Kingdom, as intellectual justification
for what was in practice simply a mass appropriation of land
(and the value created from working the land) into a much
narrower set of hands. It's been claimed that this had the
long-term benefit to everyone of increasing overall
productivity, but there are good reasons to doubt this; what
isn't in doubt is that the benefits of that productivity were
skewed to such an extent that the enclosure movement caused the
first mass starvation in England for centuries, _despite being
in the middle of a food surplus_.
And also led to the British agricultural revolution and
eventually the Industrial revolution:
http://en.wikipedia.org/wiki/Enclosure
Perhaps it was difficult at first, but I think most countries
would take that trade, though of course while trying to mitigate
the initial problems.
I tell you this little tale not as some sort of metaphor for
proprietary software, but simply to suggest that it's a good
idea to be be cautious around this idea of the "tragedy of the
commons". All too often people promote it because they have a
personal vested interest in preventing the creation of the
institutional or economic structures that would permit a viable
commons to exist.
While that may be true of some who use that idea, it certainly
isn't true of those pushing hybrid models of licensing software,
as one of the main arguments for hybrid models is that they grow
the commons of the OSS core much better and faster.
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.
My point was that I can't think of any recent example of a
highly-successful _new_ language whose default toolchain has
proprietary components, apart from those supplied by corporate
behemoths.
Well, what do you consider to be a "highly-successful _new_
language" that wasn't "supplied by corporate behemoths?" If the
answer is none, then you're also essentially saying that no new
non-proprietary language has been "highly successful," since I'd
say that all the big new languages of the last decade or two,
Java, Obj-C, C++, C#, were mostly proprietary implementations
when they became successful. I cannot think of an OSS language
that reached anywhere near the success of those big proprietary
languages.
I accept that there are commercially successful proprietary
implementations of already-successful languages, but I think
that absent a major corporate driver, a proprietary
implementation of a not-yet-major language is likely to be a
turn-off rather than a turn-on for adoption. There's simply
too much competition from many excellent free toolchains, both
for longstanding and new languages.
Given how successful proprietary implementations have been and
are to this day, I don't think it'll be much of a problem for D
to have both options with a hybrid model, and the countervailing
benefits vastly outweigh the likely negligible potential cost you
mentioned.
If the "competition from many excellent free toolchains, both for
longstanding and new languages" were such a big factor, there'd
be no paid toolchains left. Yet devs gladly pay a small forest
of non-OSS compiler vendors to make their lives easier, most of
whom are not "corporate behemoths." Of course, there are a lot
less paid compiler vendors than back when Walter started in the
compiler business, but there are a lot less OS vendors too, as
the market matured and consolidated with time. The free
toolchains may certainly have killed off the less capable
proprietary vendors, but the more capable are still thriving.
It is entirely possible that we are disagreeing at least in
part based on alternative definitions of "success".
For example, if I look at Android as an example, I don't see a
free software success story. What I see is a _very_ controlled
platform (access to the actual development edge is highly
restricted) whose wider community is largely made up of
hardware manufacturers competing to make proprietary extensions
that never get sent upstream, and whose code never gets
released; and when you receive an Android device, in most cases
you have no way, as a user, to access the source of the code it
is actually running.
There's a huge amount of wasted effort, duplication of effort,
and so on, which is sustained by the fact that, on the one
hand, the mobile hardware industry is huge and these software
development costs are trivial by comparison to the investment
required to produce, market and distribute a new hardware
device; and on the other hand, for Google themselves, the cost
of developing the core Android platform is small compared to
the commercial benefits of the huge amounts of extra data it
brings in.
Is Android making a lot of money for a lot of people and being
put on a lot of devices? Yes. How much of that distributed
software is actually free? Very little, compounded by the fact
that as a platform, its "killer apps" are proprietary.
In other words, the development of one high-quality piece of
open source software -- the core Android platform -- has been
achieved at the cost of the creation of a massive proprietary
ecosystem. That's not a free software success in any
meaningful sense.
Yes, our measures of success are different. You rue that we
don't live in a world in which all source is available under a
FOSS license, ie "a free software success," whereas I consider
the current situation where most Android devices are largely OSS
as close to the optimum situation, ie the percentage of OSS code
may move from 65-75% in the future but it will never be 100%.
As for users, they may not have _all_ the source, but the
flourishing Android ROM scene wouldn't exist without all the
source they have access to from AOSP today. That's certainly
much better than before, ie Windows Mobile dominating the much
smaller smartphone market before iPhone/Android, where you had
_no_ option to modify the source of the underlying OS. And it's
not just a few small ROMs, some of the largest Android vendors,
like Xiaomi, Amazon, and Cyanogen, repeatedly fork AOSP and make
it available to all their users without all the proprietary
Google apps and services that you dislike. :)
Of course, you're arguing about making D a success in terms of
adoption, levels of development activity and so on. Here I'll
happily concede that, for example, if (say) a major commercial
OS platform were to adopt D as one of its primary development
languages, create its own (proprietary or not) D-based
development libraries and create its own proprietary extension
of the compiler that offered extra features, it would certainly
drive adoption of D, and it would almost certainly result in
lots of nice code eventually making its way back to the core D
project. This is pretty much analogous to what I see happening
with Apple and clang/llvm.
However, that situation of a major OS provider deriving from a
free language implementation to create its (proprietary)
primary development toolchain, is very different from the
situation of a language provider standing alone trying to gain
adoption. Apple are in a position to be able to say to devs,
"You use this toolchain or you don't get to target our
platform." That's the kind of business factor that I'm talking
about, which doesn't exist for D: absent that kind of driving
force, a proprietary implementation would be a blocker both to
uptake and contributions, for reasons already discussed above.
Except no reasons for it being a blocker to uptake and
contributions were actually discussed above, just vague
intimations that some people may not like it.
What about Java? Not a primary development toolchain for any
locked-in platform when it became popular long before Android.
Same for C# to a large extent, Microsoft may have pushed it on
Windows but there were always other language options on all the
C# platforms. While I agree that such corporate imposition was a
big factor in Obj-C's success, I don't think it's quite as
determinative generally as you do.
What if a moderately-sized compiler vendor like Embarcadero were
to put 20 full-time paid devs on producing and selling an
enhanced version of ldc that built on the OSS core? You don't
think D would be much more successful? I think there's no doubt
it would be, ie you don't need to go to the extreme of Apple
making D the only development language on iOS for paid
contributions to help D a lot.
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.
I'll thank you not to put words in my mouth. Where have I said
"Others must always work for me for free and give me all the
source"?
When you say Walter would be "withholding functionality" from you
and putting "a paywall around the language" if he decides to sell
some patches he wrote rather than give them away from free, that
is essentially what you're saying.
Would I like a world where all software was free-as-in-freedom?
Certainly, and I see this as both a moral and a practical
good. Am I enthusiastic about the idea of free software also
being available without cost for access? Again, yes, and I
think it's important to identify business and development
models that make this possible (a position quite different from
"Others must..."). Do my preferences mean I can't understand
or appreciate the social, economic and technical dynamics of
doing things differently? Well, a cynic might try and dodge
the question by suggesting that you yourself seem rather too
emotionally attached to the cleverness of your hybrid idea to
be able to discuss it entirely rationally -- as evidenced by
your eagerness to label people as "zealots" or "irrational" or
"ideological" because they have problems with your proposed way
of doing things.
I have not intimated that you don't understand what I'm talking
about, only that you're making extremely weak arguments because
you're arguing from your FOSS ideology, not from compelling
evidence and well-established business theory.
I do not label people with those terms because "they have
problems with [my] proposed way of doing things," but because
their preferred alternative is a very minority position that
makes little sense, as I've detailed in this thread. Their pure
FOSS approach has almost no usage, as practically all software in
use today is either hybrid or completely closed-source.
Clinging to such an extreme FOSS position, despite the decades of
failure of _pure_ FOSS, as even linux almost always runs with
significant binary blobs, and ignoring all the economic reasons
I've listed why that is so, suggests to me an animating ideology
that renders them irrational zealots. I'm certainly not alone in
thinking this of Stallman and his adherents.
However, I'd rather not be such a cynic, and so I'll simply
say: I think I've engaged, in quite a lot of detail and depth,
with almost all of the points you've raised. You're not
obliged to agree with either my analysis or my principles, but
if you do want to dispute them, it might be a good idea to do
so on the basis of their content rather than your assumptions
or prejudices about why I think this way.
I have always primarily engaged with your content. I also
hazarded a guess as to why an otherwise smart guy like you seemed
to be making such weak arguments in this particular case, a guess
which you are free to take into consideration or ignore.
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. ;-)
Any real businessman knows that there are real customers and
those who will simply make impossible demands and not buy
anything. The pure FOSS crowd fall in the latter category.
I noted in my original post that this thread was for those who
want to pay or get paid. I don't really care about the pure FOSS
crowd, but I do like to occasionally take a whack at all their
dumb arguments. ;)
