|
1
|
<title>Checklist For Successful Open-Source Projects</title> |
|
2
|
<nowiki> |
|
3
|
|
|
4
|
This checklist is loosely derived from Tom "Spot" Callaway's Fail Score |
|
5
|
blog post <a href="http://spot.livejournal.com/308370.html"> |
|
6
|
http://spot.livejournal.com/308370.html</a> (see also |
|
7
|
<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>). |
|
8
|
Tom's original post assigned point scores to the various elements and |
|
9
|
by adding together the individual points, the reader is supposed to be able |
|
10
|
to judge the likelihood that the project will fail. |
|
11
|
The point scores, and the items on the list, clearly reflect Tom's |
|
12
|
biases and are not necessarily those of the larger open-source community. |
|
13
|
Nevertheless, the policy of the Fossil shall be to strive for a perfect |
|
14
|
score. |
|
15
|
|
|
16
|
This checklist is an inversion of Tom's original post in that it strives to |
|
17
|
say what the project should do in order to succeed rather than what it |
|
18
|
should not do to avoid failure. The point values are omitted. |
|
19
|
|
|
20
|
See also: |
|
21
|
<ul> |
|
22
|
<li><a href="http://offog.org/articles/packaging/"> |
|
23
|
http://offog.org/articles/packaging/</a> |
|
24
|
<li> |
|
25
|
<a href="http://www.gnu.org/prep/standards/standards.html#Managing-Releases"> |
|
26
|
http://www.gnu.org/prep/standards/standards.html#Managing-Releases</a> |
|
27
|
</ul> |
|
28
|
|
|
29
|
<hr> |
|
30
|
|
|
31
|
<ol> |
|
32
|
<li>The source code size is less than 100 MB, uncompressed. |
|
33
|
|
|
34
|
<li>The project uses a Version Control System (VCS). |
|
35
|
<ol type="a"> |
|
36
|
<li>The VCS has a working web interface. |
|
37
|
<li>There is documentation on how to use the VCS. |
|
38
|
<li>The VCS is general-purpose, not something hacked together for this |
|
39
|
one project. |
|
40
|
</ol> |
|
41
|
|
|
42
|
<li>The project comes with documentation on how to build from source |
|
43
|
and that documentation is lucid, correct, and up-to-date. |
|
44
|
|
|
45
|
<li>The project is configurable using an autoconf-generated configure |
|
46
|
script, or the equivalent, and does not require: |
|
47
|
<ol type="a"> |
|
48
|
<li>Manually editing flat files |
|
49
|
<li>Editing code header files |
|
50
|
</ol> |
|
51
|
|
|
52
|
<li>The project should be buildable using commonly available and |
|
53
|
standard tools like "make". |
|
54
|
|
|
55
|
<li>The project does not depend on 3rd-party proprietary build tools. |
|
56
|
|
|
57
|
<li>The project is able to dynamically link against standard libraries |
|
58
|
such as zlib and libjpeg. |
|
59
|
<ol type="a"> |
|
60
|
<li>The project does not ship with the sources to standard libraries. |
|
61
|
<i>(On the Fossil project, we will allow the SQLite library sources |
|
62
|
to be included in the source tree as long as a system-installed |
|
63
|
SQLite library can be used in its stead.)</i> |
|
64
|
<li>The project does not use slightly modified versions of standard |
|
65
|
libraries. Any required bug fixes in standard libraries are pushed |
|
66
|
back upstream. |
|
67
|
</ol> |
|
68
|
|
|
69
|
|
|
70
|
<li>"make install" works and can be configured to target any |
|
71
|
directory of the installer's choosing. |
|
72
|
<ol type="a"> |
|
73
|
<li>The project contains no unconfigurable hard-coded pathnames like |
|
74
|
"/opt" or "/usr/local". |
|
75
|
<li>After installation, the source tree can be moved or deleted and |
|
76
|
the application will continue working. |
|
77
|
</ol> |
|
78
|
|
|
79
|
|
|
80
|
<li>The source code uses only \n for line endings, not \r\n. |
|
81
|
|
|
82
|
<li>The code does not depend on any special compiler features or bugs. |
|
83
|
|
|
84
|
<li>The project has a mailing list and announces releases on |
|
85
|
the mailing list. |
|
86
|
|
|
87
|
<li>The project has a bug tracker. |
|
88
|
|
|
89
|
<li>The project has a website. |
|
90
|
|
|
91
|
<li>Release version numbers are in the traditional X.Y or X.Y.Z format. |
|
92
|
|
|
93
|
<li>Releases can be downloaded as tarball using |
|
94
|
gzip or bzip2 compression. |
|
95
|
|
|
96
|
<li>Releases unpack into a versioned top-level directory. |
|
97
|
(ex: "projectname-1.2.3/"). |
|
98
|
|
|
99
|
<li>A statement of license appears at the top of every source code file |
|
100
|
and the complete text of the license is included in the source code |
|
101
|
tarball. |
|
102
|
|
|
103
|
<li>There are no incompatible licenses in the code. |
|
104
|
|
|
105
|
<li>The project has not been blithely proclaimed "public domain" without |
|
106
|
having gone through the tedious and exacting legal steps to actually put it |
|
107
|
in the public domain. |
|
108
|
|
|
109
|
<li>There is an accurate change log in the code and on the website. |
|
110
|
|
|
111
|
<li>There is documentation in the code and on the website. |
|
112
|
</ol> |
|
113
|
|