This checklist is loosely derived from Tom "Spot" Callaway's Fail Score blog post http://spot.livejournal.com/308370.html (see also  and ). Tom's original post assigned point scores to the various elements and by adding together the individual points, the reader is supposed to be able to judge the likelihood that the project will fail. The point scores, and the items on the list, clearly reflect Tom's biases and are not necessarily those of the larger open-source community. Nevertheless, the policy of the Fossil shall be to strive for a perfect score.
This checklist is an inversion of Tom's original post in that it strives to say what the project should do in order to succeed rather than what it should not do to avoid failure. The point values are omitted.
The source code size is less than 100 MB, uncompressed.
The project uses a Version Control System (VCS).
The project comes with documentation on how to build from source and that documentation is lucid, correct, and up-to-date.
The project is configurable using an autoconf-generated configure script, or the equivalent, and does not require:
The project should be buildable using commonly available and standard tools like "make".
The project does not depend on 3rd-party proprietary build tools.
The project is able to dynamically link against standard libraries such as zlib and libjpeg.
"make install" works and can be configured to target any directory of the installer's choosing.
The source code uses only \n for line endings, not \r\n.
The code does not depend on any special compiler features or bugs.
The project has a mailing list and announces releases on the mailing list.
The project has a bug tracker.
The project has a website.
Release version numbers are in the traditional X.Y or X.Y.Z format.
Releases can be downloaded as tarball using gzip or bzip2 compression.
Releases unpack into a versioned top-level directory. (ex: "projectname-1.2.3/").
A statement of license appears at the top of every source code file and the complete text of the license is included in the source code tarball.
There are no incompatible licenses in the code.
The project has not been blithely proclaimed "public domain" without having gone through the tedious and exacting legal steps to actually put it in the public domain.
There is an accurate change log in the code and on the website.
There is documentation in the code and on the website.