An idea for commercial support for D

[Joakim via Digitalmars-d]

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. ;)