This checklist is loosely derived from Tom "Spot" Callaway's Fail Score blog post http://spot.livejournal.com/308370.html (see also [1] and [2]). Tom's original post assigned point scores to the various elements and by adding together the individual points, the reader is suppose 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.

See also:

• http://offog.org/articles/packaging/
• http://www.gnu.org/prep/standards/standards.html#Managing-Releases

1. The source code size is less than 100 MB, uncompressed.

2. The project uses a Version Control System (VCS).

   1. The VCS has a working web interface.
   2. There is documentation on how to use the VCS.
   3. The VCS is general-purpose, not something hacked together for this one project.

3. The project comes with documentation on how to build from source and that documentation is lucid, correct, and up-to-date.

4. The project is configurable using an autoconf-generated configure script, or the equivalent, and does not require:

   1. Manually editing flat files
   2. Editing code header files

5. The project should be buildable using commonly available and standard tools like "make".

6. The project does not depend on 3rd-party proprietary build tools.

7. The project is able to dynamically link against standard libraries such as zlib and libjpeg.

   1. The project does not ship with the sources to standard libraries. (On the Fossil project, we will allow the SQLite library sources to be included in the source tree as long as a system-installed SQLite library can be used in its stead.)
   2. The project does not use slightly modified versions of standard libraries. Any required bug fixes in standard libraries are pushed back upstream.

8. "make install" works and can be configured to target any directory of the installer's choosing.

   1. The project contains no unconfigurable hard-coded pathnames like "/opt" or "/usr/local".
   2. After installation, the source tree can be moved or deleted and the application will continue working.

9. The source code uses only \n for line endings, not \r\n.

10. The code does not depend on any special compiler features or bugs.

11. The project has a mailing list and announces releases on the mailing list.

12. The project has a bug tracker.

13. The project has a website.

14. Release version numbers are in the traditional X.Y or X.Y.Z format.

15. Releases can be downloaded as tarball using gzip or bzip2 compression.

16. Releases unpack into a versioned top-level directory. (ex: "projectname-1.2.3/").

17. 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.

18. There are no incompatible licenses in the code.

19. 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.

20. There is an accurate change log in the code and on the website.

21. There is documentation in the code and on the website.