I haven’t read enough Heinlein to be sure that I like the guy, but he gets major brownie points for TANSTAAFL. jwz gets brownie points for several reasons, not the least of which is for having written, Linux is only free if your time has no value.
I try to avoid the mistake of saying that an inanimate object or non-corporeal hunk of information “needs” something, but I fail sometimes. For example, I said “I just think that ActiveRecord needs to support the low-level and middle-level abstractions better.” This is silly; of course, code doesn’t need anything per se.
You may think I’m being pedantic by saying this, but people commonly mix up whose needs are really being described. What I should have said was, “I would be happy with ActiveRecord if it supported…”, clearly indicating that the need was mine. I have a problem, and this code doesn’t solve it fully. And I understand that I, and maybe some like-minded individuals, bear the burden of actually trying to solve this problem. If I sit and wait and it gets fixed, that’s great, but it’s not fair for me to demand that the universe solve all my problems for me just because it has solved a few of them already without me doing any work.
The reason for this is that although the software is free to acquire, it still is not a free lunch, and doesn’t magically solve all of your problems for you. You still need someone to fill the role of the vendor in proprietary closed-source software, who will solve your problems because they’re being paid to do so. To paraphrase a quote by Warren Buffett about poker and identifying the patsy… if you’re using open source software and you don’t know who the vendor is, it’s you.
That’s not necessarily a bad thing. I use a lot of open source software, and quite often, there’s a big community of people who have a strong financial interest in making each particular project better. If you can manage to find a huge group of people who have no choice but to invest in something that you need, and who give it away for free, you can just freeload. I donate cash to these organizations, since I’m really not interested in hacking on every single app that I use, and because I’d hate to have to pay commercial license fees for this stuff. Or, you can donate hacking effort, or documentation, or some other form of enhancement or promotion. Or you can just mooch. But no matter which path you choose, you can’t reasonably point your finger at someone who is giving you something for free, and tell them that they owe you something else.
It’s terribly frustrating when someone makes a decision you don’t agree with, such as to release something with a known bug, which later bites you. Or, they might make design decisions that you disagree with. Don’t like it? Re-read that “as-is” clause and then ask for a refund of the $0 you paid. It’s only fair: you wanna mooch, you get what someone else gave you, which is not necessarily what you wanted. Feel free to fix it yourself.
Let me be clear here: bug reports are good. Discussing defects is good. Criticism of the “this sucks and could be better by doing this” variety is good. Demanding a free fix to a free program is bad.
This is where some maintainers of open source programs go wrong. Bugs are useful information, assuming that they are written properly. Patches to fix those bugs are even more valuable, and a bug with an attached patch and regression test code is fabulous. But there are still human gatekeepers who have to keep their project from being changed too drastically by overeager contributors. This is a tough job, because these gatekeepers have to try and keep the community happy: accept sane and useful patches, but avoid bloat and major changes in functionality that break regular users’ experience with the code. I’ve encountered management failure in both directions: too reluctant to accept change, or too willing to add random junk.
But the more common problem I’ve seen is rejection of well-written bug reports that nobody feels like fixing. Something like “these bugs are verified but old and nobody feels like fixing them so I’m closing them.” That smells to me like an identity crisis: are you a vendor, or a project steward? If a problem has existed for years and still exists in the current code, and users are complaining, but no one is fixing it, that’s a live bug. If you close it, it will probably never get fixed. But your bug list will look so much prettier! “It’s always been like that” is not a fix. This happens all the time in open source projects. Although you have to draw the line somewhere to keep out random stupid bugs that will inevitably be submitted, the temptation is strong to just WONTFIX anything that you don’t personally care about. Why even have a public bug tracker if you’re going to do this?
This is toxic because it says to the community, “we are not interested in your input if it makes work for us”. But that’s just a sign of steward/vendor confusion. Behavior like that leads to forking, so that someone more receptive to community feedback can be put into a position of stewardship. Maybe that’s the goal of the maintainers: to release something in order to trick other people into fixing bugs for the original authors, and if they can’t use that fix, too bad. Well, in that case forking it is perfectly reasonable.
The flip side of steward/vendor confusion is the confusion that leads users of free open source software to believe that the project stewards are a vendor, or that the code “needs” something because they find it lacking. “I need this defect fixed (in order to do X Y and Z)” becomes “the defect needs to be fixed.”
If you pay a vendor thousands of dollars for a program that they claim will do something and it doesn’t, you have a valid claim, and can take them to court. If you upgrade your operating system and that program you paid for stops working, you are within reason to expect that the vendor will sell you an upgrade that does in a reasonable amount of time, unless they have told you that they won’t do so, or that there’s a migration path to something else. But if you pay nothing, then anything you get is upside, and anything you don’t get was something you didn’t have anyway. Your only reasonable expectations are what they told you to expect, and quite a lot of programs say that they promise no suitability to any purpose whatsoever.
In light of all this, I really like the idea behind GitHub, because it makes forking extremely cheap. The person releasing software as open source need not be a community steward too. In this model, anyone can appoint themselves a steward, without permission from anyone else. Any disagreements can be easily resolved by forking and patching, and in fact that’s the de facto means of patching: just tell the other folks with forks of the same software that you made an improvement that they might care to incorporate into their version, and here’s where your patched repository is. Some folks will just patch one time; others will fix a few things; others will try and maintain the best combination of other folks’ patches.
In a few years, Git is going to be recognized as the tool that made distributed version control popular, and easy forking common, in the open source world. The frustrations inherent in the tug of war between personal needs and community stewardship will be replaced with the challenge of finding the best version of a widely forked program. But we’re much better at trusting the recommendation of a friend or authority than we are at managing a cathedral that “needs” to be a bazaar.