I suspect I’m not the only person thinking this, but what is Bjorn on about? From the whole “Eclipse is You” debacle (in which he proclaimed that it’s basically the users’ fault that Eclipse has bugs, because they’re not fixing them), he’s now come out with the (false) assertion that “Eclipse isn’t free”. In any other organisation, the marketing department would be horrified to learn that one of their upper echelons is doing so much damage to the Eclipse brand. Sadly, I doubt that anyone at the Eclipse Foundation is likely to bring it up or for there to be any response on this.
So, to make it clear; despite what Bjorn might be raving about, Eclipse is free, both as in speech as in beer. In other words, you can get the source of Eclipse, do what you want with it (both running and using) — and it doesn’t cost you a penny to do so. One of the great reasons why the vanilla Eclipse environment (and by projection, their commercial counterparts) has done so well is precisely because it’s free in both senses.
As for why Bjorn might have made the mistake of saying Eclipse is non-free; well, I suspect he’s probably not an economist at heart. The up-front cost of Eclipse is indeed zero; you can get hold of a nice shiny new Eclipse 3.3.1½ merely by going to the website and downloading the package. However, his argument is that even if you have the software, you have no support; that buying support will cost you money; and thus the overall effect is that it has cost you real cash to make it happen. The fallacy is here that you don’t have to purchase any such support if you choose not to.
Not only that, but there is a free support model; the newsgroups and developer mailing lists (not to mention sites like EclipseZone) are all free at the point of use. And, as with all free support contracts, the limit of the liability is the same as the up-front cost; which is to say, zero. In other words, you can ask a question; there’s a good chance that your question won’t be answered (and even a slim chance that someone will answer and give you the wrong result). In other words, what costs the money is not the ability to posit questions (or indeed, receive answers); but rather the guarantee of receiving (correct) answers in a given timeframe. You can even file a bug at bugs.eclipse.org if you find an issue with Eclipse – and if you’re feeling generous, you can even apply a patch to help get it fixed – but there’s no guarantee that it will be included in the main distribution.
All open-source models work in this same way. The source is given out; anyone can create a ‘fork’ of the work (whilst staying true to the same license conditions, of course) and make those changes available. And all this can be free both as in beer and as in speech. Bjorn falls to the fallacy of composition when he suggests that “Linux isn’t free” by asserting that since RedHad clearly offers paid support for its Linux distribution that the same must also hold for other Linux distributions.
However, nothing could be farther from the truth; for example, Debian has a very strict set of security volunteers that work to ensure that security patches are applied to the contents of the distribution and make those available as an ongoing service in support of the Debian distribution. In these systems, each ‘package’ is forked from up-stream and only security bugfixes are applied (much like the maintenance releases of 3.3 only contain the most critical of bugs — unless you’re on a Mac, because Windows is more important for Eclipse). Sometimes, these security bugs are back-ported and haven’t been provided by the original up-stream providers.
Forking, and maintaining an ongoing distribution of, an up-stream system is a tireless job. It therefore makes sense for those up-stream distributions to receive any fixes that have been found down-stream, and that’s what happens in the case of some of the fixes that Debian have made. Not all patches are accepted by those up-stream counterparts (and nor are they obliged to take them), although clearly it makes sense overall if this is the exception, rather than the rule.
Anyway, you can’t force an up-stream system to fix bugs, even if you have provided a patch. It’s ironic that Bjorn clearly doesn’t understand the difference between ‘support contract’ and ‘availability of Eclipse’; but then, the majority of Bjorn’s posts have been navel gazing about the process rather than the result of that process. As an example, I raised a bug some time ago about a typo in some documentation for project plod back when I used to care about improving Eclipse. I even volunteered to fix it, and (after working through other problems with buckminster that causes it not to work on the Mac), supplied a patch to fix the issue, where it lied dormant gathering electronic dust. When I tried to close the bug as WONTFIX, Bjorn threatened to disable my bugzilla account, since only committers may dare touch a bug resolution. The process was more important to him than improving the quality of the product. Needless to say, whatever respect we may have had for each other at that point evaporated, and any desire to help out with either of the other Bjorn-involved projects went with it.
The moral of this story is; Eclipse is free, and you get what you pay for. There are free at the point of use support models; and as with any free offering, there’s no guarantees. You can spend your own time teaching yourself and writing articles on how it works; or you can buy a book or pay to go on a training course to have it delivered in a more commercially oriented offering. But claiming that it isn’t free just because you can purchase additional guarantees is a bit like claiming air costs you money to breathe because you can buy SCUBA tanks for diving.
PS, yes, the patch is still gathering electronic dust and there’s no likelihood of it being fixed in my lifetime.