CACert.org is basically a self-signed Certificate Authority with aspirations of having its root cert included in as much mainstream software as possible. They're included in some Linux distributions, a couple of BSDs - notably OpenBSD - and aspire on being included in Firefox/Mozilla (which would probably make the certs signed by them at least moderately useful for mainstream usage).
Let me say this first - I rather like the idea of a free CA. Philosophically it's a nice idea. The most important thing though, is not that the CA is free - it's that the CA can be trusted.
I've come to the conclusion CAcert.org can not be trusted. Whether or not you share that sentiment is entirely up to you - I'll outline my own reasons below.
Summarizing them a bit: The source code is available (definite plus), they have a formalized structure of sorts, they are fairly transparent and they audit themselves. This is all good things that I - as a presumptive user - would be expecting.
The thing that gets to me, though, is that they manage to miss out on some of the very fundamental things. If you run a CA, you probably don't want to run it on PHP. If you run it on PHP, you probably want to run a recent version and follow best practices. If you don't follow best practices, you really, really don't want to have register_globals enabled.
And if you insist on blowing all of these fairly sane precautions, bad things can happen:
(Basically means 'which email address would you like to use to verify that you control yahoo.jp so you can get a cert for it'.)
The code base is, in a word, horrid. Bad or no documentation, cases of input being sent to the database without quoting and it seems that some older code - containing what looks like vulnerabilities - got some sanity checking code tacked in front of it without really fixing the main issue.
Case in point - not a whole lot of random peeking allowed me to bypass one pretty damn important security feature (in some instances at least - it's not a generic exploit), and I'm not a vulnerability researcher. If it takes a bit of HTTP knowhow and a few Google queries to get signed certificates for domains I'm in no way associated with, I'm guessing someone who's actually into PHP security could do a whole lot more.
It's good that they have processes, but if it comes to the point where we see schoolbook examples of bad programming, the code really shouldn't be in production in the first place.
And this brings us to what is important in a CA - trust. To trust a CA, you should trust the organization maintaining it. In this case, the board hasn't managed to get a good reality check of the state of the 'product' (or if they have, they're ignoring it / keeping mum), the programmers just plain haven't done a good job and the auditor(s) really, really shouldn't have missed something this obvious.
I don't want to see the root cert of this CA in Mozilla. I don't want to see it in Debian. How it managed to slip by OpenBSD's radar is beyond me. I certainly do hope, though, that there will be a decent free and/or open CA some day - hell, it might even be CAcert - but saying that they're good because they're free and they should be included in as many places as possible because of this is just not sound thinking.
At least to me, running the operation like they do means that they probably shouldn't be trusted without a complete overhaul in code and management. It's that bad.
Finally: I'm perfectly aware that there might be commercial CA's out there with pretty bad bugs of their own - but at least webtrust ensures that they didn't do the classical schoolbook examples of bad security and practices. This peace of mind is well worth $15 a year for a cert.
YMMV, of course.
[Edit: The exploit mentioned above was fixed in a very timely manner once pointed out to the CAcert chaps.]