EDIT: Looks like App beat me to posting some details but i'll leave my post unchanged.
Looks like I'm going to spend part of today reading the articles at
http://www.hardcoded.net/articles/ -- looks like great reading

Welcome to the site hsoft!
It sounds like your approach is working, and shares a lot in common with the approach we've followed here. You can read the 2006 article I wrote about our approach
here.
Some similarities I see:
- Assessing the problem: We both agree that users not donating has little to do with not being willing to pay, and more to do with not wanting to go through the hassle of paying; i think laziness is only half the equation -- the other is that they view paying as too high a financial risk compared to the benefits.
- Dealing with people who actively want to circumvent the system: Solution = Don't worry about it, it's not important.
- License Key: We both use a license key for contributors to bypass a nag reminder to donate.
Some differences that are very interestingNag screen and non-contributors:In our programs (that use license key system), we offer a free license key even to people who do not contribute. They can either download a 60 day key anonymously, or a 6 month key by signing up at the forum. This has been the source of quite a bit of confusion and hand wringing. But it's also a way that we maintain that our software is genuinely free for all, and avoid having a nag screen shown on each use.
In your case, you always show a nag screen to non-contributors (as long as their are unpaid hours). This is quite interesting actually. Based on my informal experience, i suspect this is a huge part of getting donations.
I think if we did that we would greatly increase the number of donations. Perhaps by several orders of magnitude. The reality is that a nag screen on every startup of program is a much stronger incentive to contribute than any please we might make.
However, in our case, with closed source -- the closed source freeware community would very likely decide that this turns the software from freeware into shareware. I think i would take issue with that and would probably argue that "nagware" shareware is designed to really nag and annoy the user while they use their software (making it largely a requirement to contribute to peacefully use the software) -- it's a hard argument to make.
And i suspect that most of our freeware site friends would disown us. Your case is somewhat different because at that same time that you are "inflicting" non-contributor users with a nag on startup, you are providing the source code that would theoretically allow them to modify the code and remove it; and because you fall into the open source camp and not the freeware camp, you don't have the same kind of complaints and culture that objects so strenuously to the idea of a nag screen. Which leads to the open source difference..
Open Source DifferenceThe most obvious difference is of course the fact that your programs are Open Source while our license-key applications (mostly mine) are closed source. This is the part that I am very interested in because it's an issue I've struggled with. I have some open source projects on DonationCoder but they don't really get donations and I don't really push for them on those tools, largely because I've not though it practical or worth the effort.
It's heartening for me to see independent open source projects like yours succeed in getting funding. I have written before that i lay much of the blame at how hard this is on the open source *culture* which i view as tragically not putting any energy into cultivating a culture of users financially supporting open source projects. To me it seems that open source funding is another example of a scenario where only a couple giant projects get all the funding, and where
3rd parties are figuring out how to scoop up all the potential available funding for a project, usually by providing pay-for-support of someone else's code.
To me the best future world we could move towards is one where digital content (music, software, art) is all free and generously supported by optional user-chosen donations. But to do that it requires (in addition to easier and safer donation making) a shift in culture that emphasizes the importance of supporting such creators. I find it tragic that the open source community didn't/doesn't embrace this as one of the core tenants of open source.
But back to the details that I think are interesting about your experience.. First, you talk about my concern with doing open source donationware-type software, the prospect of someone forking your software and starting a new project without the nag screens or where they put their own nag screen redirecting donations to them. Basically you have said that it could happen but doesn't -- or hasn't so far -- perhaps primarily because it's too much effort for someone to do. I think for the most part your analysis is probably correct -- that it's more of a theoretical problem than a practical one. However, I do wonder whether the likelyhood of such a thing happening starts to go up dramatically as the popularity of a program increases, and as you have more developers. So i really do still wonder about this fundamental forking problem when thinking about open source software as donationware.
Dealing with software projects where there are many developers:
I find myself drawn to your basic approach -- which is to say that author contributors keep track of their hours and payments get split among the unpaid hours of the developers. However this is another case where i worry about your approach scaling up when you start to have many developers and perhaps some that disagree about direction. I do note that on your page listing developers that for all intents and purposes it's just you. It may be a case where i'm worrying more about theoretical problems rather than technical ones, but on the other hand I am interested in finding a theoretically solution that would scale up and be something that could be advocated for large projects and which one could feel safe about it not becoming unmanageable.
More thoughts later..