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