Here's another thing - I know my biggest issue is interface. The first question I ask anyone who comes onto the Excel::Template mailing list with a suggestion is "How do you want to use that feature?". They describe their desired usage, someone else brings up their desired usage, and I add in my knowledge of the rest of the features. Eventually, we come to a consensus. Once that consensus is there, it's cake to write the feature. At least 50% of the time spent in writing F/OSS is figuring out what to write. The actual writing/testing/documenting is a lot easier once you have that figured out.

Personally, I don't think there will/should ever be a gnuTax, because with TurboTax/TaxCut, someone is liable if the return is wrong, and their returns are guaranteed accurate. I'm not saying that someone couldn't develop a GNU version of the same software that would be as correct as TT/TC, but where does the liability fall if something goes wrong? Can the user sue the developer for writing software that say, 1/100000 times made an incorrect calculation that caused the party to be audited?

The user didn't pay for the software, they just downloaded it and used it... so there was no sale or any kind of contract entered into by the developer and the user. I know that there could be some kind of EULA, which I believe has been proved upholdable in court (not sure), but it could just be a sticky situation for a dev who wanted nothing more than to simply give us an alternative to Windows tax software.

As much as I love the idea in theory, in practice.. I don't think it works.

Hi
I agree; I love the idea in theory, and your points are all good ones -- and that's probably part of the reason OSS Tax software doesn't exist. And the fact that it doesn't exist is a bonus for Quicken/QuickTax and probably convinces some people not to look at GnuCash.
however, if someone wrote it, I'd probably give it a whirl, and promise not to sue if there were an error :).
- j

The idea, then, is to have the OSS engine ... and find someone with big pockets to write the forms. I'm kinda thinking of a generic tax package (hopefully, generic enough to fit any country), but with "localisation" packages that describe fields, and the relationships between fields, etc. The challenge (well, the biggest challenge) would be getting someone to write the localisation package every year for each country. Ideally, that would be the government of that country (or at least the tax agency of the country).

The engine would then produce an XML file as output, and the localisation package would include an XSLT transform that would create the country-specific format (whether that's an HTML file to print out, or it's a specific on-line submission version, such as what Canada does).

This would be a challenge in that many less-socialist countries would not want to compete with the private sector for something like this. The engine would be fun to write ... but getting someone to sign on for the country-specific parts would be quite difficult.