initial commitHEADmaster

1 files changed, 112 insertions, 0 deletions

diff --git a/www/foss-cklist.wiki b/www/foss-cklist.wiki
new file mode 100644
index 0000000..cdf90f3
--- /dev/null
+++ b/www/foss-cklist.wiki
@@ -0,0 +1,112 @@
+<title>Checklist For Successful Open-Source Projects</title>
+<nowiki>
+
+This checklist is loosely derived from Tom "Spot" Callaway's Fail Score
+blog post <a href="http://spot.livejournal.com/308370.html">
+http://spot.livejournal.com/308370.html</a> (see also
+<a href="http://www.theopensourceway.org/book/The_Open_Source_Way-How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL.html">[1]</a>).
+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.
+
+See also:
+<ul>
+<li><a href="http://offog.org/articles/packaging/">
+http://offog.org/articles/packaging/</a>
+<li>
+<a href="http://www.gnu.org/prep/standards/standards.html#Managing-Releases">
+http://www.gnu.org/prep/standards/standards.html#Managing-Releases</a>
+</ul>
+
+<hr>
+
+<ol>
+<li>The source code size is less than 100 MB, uncompressed.
+
+<li>The project uses a Version Control System (VCS).
+<ol type="a">
+<li>The VCS has a working web interface.
+<li>There is documentation on how to use the VCS.
+<li>The VCS is general-purpose, not something hacked together for this
+    one project.
+</ol>
+
+<li>The project comes with documentation on how to build from source
+and that documentation is lucid, correct, and up-to-date.
+
+<li>The project is configurable using an autoconf-generated configure
+script, or the equivalent, and does not require:
+<ol type="a">
+<li>Manually editing flat files
+<li>Editing code header files
+</ol>
+
+<li>The project should be buildable using commonly available and
+       standard tools like "make".
+
+<li>The project does not depend on 3rd-party proprietary build tools.
+
+<li>The project is able to dynamically link against standard libraries
+      such as zlib and libjpeg.
+<ol type="a">
+<li>The project does not ship with the sources to standard libraries.
+    <i>(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.)</i>
+<li>The project does not use slightly modified versions of standard
+    libraries.  Any required bug fixes in standard libraries are pushed
+    back upstream.
+</ol>
+
+
+<li>"make install" works and can be configured to target any
+       directory of the installer's choosing.
+<ol type="a">
+<li>The project contains no unconfigurable hard-coded pathnames like
+    "/opt" or "/usr/local".
+<li>After installation, the source tree can be moved or deleted and
+    the application will continue working.
+</ol>
+
+
+<li>The source code uses only \n for line endings, not \r\n.
+
+<li>The code does not depend on any special compiler features or bugs.
+
+<li>The project has a mailing list and announces releases on
+       the mailing list.
+
+<li>The project has a bug tracker.
+
+<li>The project has a website.
+
+<li>Release version numbers are in the traditional X.Y or X.Y.Z format.
+
+<li>Releases can be downloaded as tarball using
+       gzip or bzip2 compression.
+
+<li>Releases unpack into a versioned top-level directory.
+       (ex:  "projectname-1.2.3/").
+
+<li>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.
+
+<li>There are no incompatible licenses in the code.
+
+<li>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.
+
+<li>There is an accurate change log in the code and on the website.
+
+<li>There is documentation in the code and on the website.
+</ol>