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.

With a DVCS, everybody can be a lone ranger, unless you build a process on top that puts back these features (i.e. a remote repository that everybody pushes to). This is something that many of the introductory documents I’ve seen regarding Git try to downplay — you don’t need a central repository, yippee! Just pass changes around from developer to developer — but while that may thrill the solo coder hacking on his laptop on a long flight, it isn’t music to the ears of a CIO.

In Git’s case, there is no central list of version numbers, and the history can be altered using git-rebase and git-commit --amend. Do you really need to see the precise history of every change ever made to the code? Perhaps you think you do because it gets screwed up so easily in some version control tools, and you need to at least be able to backtrack and manually unsnarl a really big screw-up. In that case, you probably don’t need it, as long as the version control tool can be trusted.

Or maybe you’re guarding against human error, and what you really want is granular remote backups. Just as you can use svnadmin dump and svnadmin load to intentionally truncate the history that the repository knows about, you could use git rebase to squash a bunch of commits together into a single big change, and thereby lose the ability to go back to one of those intermediate steps. So you probably should think about archiving the full-granularity repository before you consolidate the old historical steps for developer convenience reasons. And even if you’re a lone ranger, you should think about using rsync or duplicity to regularly put your local .git repositories someplace safe, or push to a remote git repository that no one else has access to, or both.

One solution to make Git more enterprise-friendly git-svn, which gives you the tool integration and centralness of Subversion, with the local branch/merge and offline commit benefits of Git (which are very very nice). I haven’t used it but I am told that it works very well. It’s also a very low-risk way to try out Git, since you can just check your changes in and go back to using Subversion at any time.

Git is challenging to learn, partly because the command language is not very intuitive, and partly because the folks documenting it so far are obsessed with explaining how radically new and different it is rather than how you probably will want to use it. And for folks reading this documentation, the “look how different your process could be” examples are not necessarily very appealing, since the benefits gained by using a centralized VCS are not addressed.

Still, I think Git has enough hype around it that in a year or two there will be some very slick, usable tools that conceal the complex inner workings that you currently have to understand well in order to be productive. They may also include features that make backups or the setup and shared use of a remote repository easy. So if you’re not convinced that it’s time to migrate Git now, just wait. It will probably come to where you are eventually.

Well, they’re fixing it. I dunno if it’s gonna be perfect, but at least they’re addressing the problem and seem to understand what the needs of the masses are. So I’m optimistic.

And yeah, at some point I’ll probably check out Git. But not until Subversion irritates me more than it does today. :)