[CD-HIT] Let's focus on making CD-HIT an exemplar Open Source Project in bioinformatics!

[Dan Bolser]

I have been reading:
  http://producingoss.com/


It has lots of great information about running open source projects.
For example:

* The importance of version controlled code repositories:
  http://producingoss.com/en/vc.html

  Versoin controll helps with virtually every aspect of running a
project: inter-developer communications, release management, bug
management, code stability and experimental development efforts, and
attribution and authorization of changes by particular developers.


* The importance of mailing lists:
  http://producingoss.com/en/mailing-lists.html
  http://producingoss.com/en/setting-tone.html#avoid-private-discussions

  As slow as public discussions can be, they're almost always
preferable to private email in the long run. Volunteers don't like the
feeling that big decisions are being made in private. Additionally,
there are several other advantages: project discussion will help train
and educate new developers, the discussion and its conclusions will be
available in public archives (enabling future discussions to avoid
retracing the same steps), someone on the list may make a real
contribution to the conversation by coming up with an idea you never
anticipated.


* The importance of bug trackers:
  http://producingoss.com/en/bug-tracker.html
  http://producingoss.com/en/getting-started.html#vc-and-bug-tracker-access

  The importance of a bug tracking system lies not only in its
usefulness to developers, but in what it signifies for project
observers. An accessible bug database is one of the strongest signs
that a project should be taken seriously. The higher the number of
bugs in the database, the better the project looks. This might seem
counterintuitive, but the number of bugs recorded really depends on
three things: the absolute number of bugs present in the software, the
number of users using the software, and the convenience with which
those users can register new bugs. Of these three factors, the latter
two are more significant than the first. Any software of sufficient
size and complexity has an essentially arbitrary number of bugs
waiting to be discovered. The real question is, how well will the
project do at recording and prioritizing those bugs? A project with a
large and well-maintained bug database (meaning bugs are responded to
promptly, duplicate bugs are unified, etc.) therefore makes a better
impression than a project with no bug database, or a nearly empty
database.


Dan.