If you are an open-source developer, you could write in license or documentation, `This software does whatever its source code states it does'. Joe the Average

If you are an open-source developer, you could write in license or documentation, `This software does whatever its source code states it does'. Joe the Average User don't need to to read through code himself; there are enough geeks on his friendlist to have this covered. In spite of reeking of RTFM-ness, this approach actually is about the only honest; all other ways of documenting are simplifications, approximation and literally shuffling dirt under the rag by assuming nonexistence of bugs. However, due to to exceptionally high complexity, and hard to predict interactions between various software and hardware components of system, you need to put strong disclaimers in place: `Unless there are faults in compiler, libraries, the underlying OS your hardware' makes any responsibility very diluted and hard to prove at best. And let's not forget about the -- very uncommon, but occurring nonetheless -- random flips of bits in memory, which may bring the system down or silently corrupt code or data in unreproducible ways, regardless of software and hardware quality. Only actual cure for software reliability is to use simpler systems, made up of loosely coupled components, where failure of one doesn't affect others, and it's easy to re-start from previous step. It's the big, opaque, monolithic, all-encompassing application or systems that bomb and trash your data that are the most problematic. Outlaw those.