The book "Open Source Development with CVS" is IMHO the best source of
good, solid advice about starting and running open source projects.
(The odd numbered chapters talk about cvs, the even ones about open
source dev.)
For starting a new project one of the key things it recommends is to
choose the "Invariants" for the project. That is to say, certain base
assumptions that define with some specificity what the project will be
(and, on the flip side, what it _won't_ be.) This is important because
it helps potential users and developers in setting their expectations
and determining if the project is worth their effort.
Typical invariants would be file formats, programming languages, and key
underlying libraries. Processes and policies could also be invariants
if they would play a large role in how decisions are made in the
project.
The trick is to select specific enough invariants to make it easy to
pigeon-hole the project, without painting yourself into a corner.
Typical mistakes would be picking a programming language you're not
totally familiar with, or a new library that you haven't discovered its
quirks yet, or selecting hardware performance criteria that make sense
today but turn out to be anemic and silly when you finally hit 1.00.
Based on our discussions so far, it looks like the invariants might be:
* Full SVG compliance
* Core coded in C/C++
* Gtk-compliant user interface
* Extensible using various scripting languages
* Open, community-oriented development processes
* Baseline is the Sodipodi 0.32 codebase
* Strives to use commonly available libraries
Thoughts? More? Less?
I think the first three in particular are important items to establish
firmly, because they are the types of things that can get endlessly
argued back and forth and back again, until months path with zero
results. Establishing them as invariants allows us all to admit and
agree that C and C++ suck, and lets us get down to coding in them
anyway. ;-)
Bryce
