Unlike most commercial software offerings, Open Source software is seldom backed by a corporate entity, paid support staff, and the like. Instead, it is developed and maintained by volunteers, in an open, cooperative manner.
This system works very well, on its own terms, but it can be confusing or even frustrating to new users, corporate lawyers, etc. So, we have prepared the following troubleshooting guide:
If you are running an outdated version, nobody will be very interested in hearing about the problem. On the other hand, if the bug is present in a current version, you can expect the package's developers and/or maintainers to be interested.
Many packages have well-developed databases of known bugs. If your bug is listed here, you need not report it, unless you have additional details to give. If your bug is not listed, submit a detailed bug report. Describe how the bug may be reproduced, what specific symptoms you observed, what hardware and software environment was being used, and how you may be contacted for further information.
Most substantial Open Source packages have their own web sites, mailing lists, and/or USENET (Netnews) groups. These facilities are commonly used for bug reporting, informal technical assistance, etc.
Unlike proprietary software offerings, Open Source software is open to your inspection and modification. Thus, if the package doesn't do what you think it should, you are free to find the relevent piece of code and fix it.
If you think the fix might be of general interest, you should submit it to the package's user community. Aside from being a noble and virtuous act, this will bring you a (small) measure of fame and (perhaps) save you from fixing future versions.
This is not, however, a guarantee of Y2K compliance. Leaving aside the question of whether it is possible to prove that a program is Y2K compliant (we don't think so :-), most Open Source packages do not have any corporate backer who would be willing to make such an assertion.
More to the point, Open ReSource is not interested in answering questions about whether a given package is compliant. We do not have the resources that would be needed to examine packages for Y2K compliance and we aren't interested in setting them up.
If you are required to obtain a guarantee of Y2K compliance, we suggest that you engage a suitable consulting firm. A detailed code walkthrough may find at least some problems and may also provide some legal accountability, in case a Y2K bug emerges and causes problems.