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
This may not work, because they've just chaned the mail config _again_...
Bryce Harrington wrote:
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.)
I will try and get this book.
Based on our discussions so far, it looks like the invariants might be:
- Full SVG compliance
Yep.
- Core coded in C/C++
Yep
- Gtk-compliant user interface
Can we go further and say Gnome (including HIGs)?
- Extensible using various scripting languages
Aiming for first-class external language access
- Open, community-oriented development processes
A Biggy
- Baseline is the Sodipodi 0.32 codebase
Yep
- Strives to use commonly available libraries
Yep, how about when ever we share some functionality with another program, share a library. That's the GnuCash fill-o-sophy, and I think the results speak volumes!
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. ;-)
Indeed, and porting to another language is O(n) anyway. In this vein, I propose we prototype things in high level scripting language of choice and use that to nut out ideas for things like options dialogs. Especially when talking on jabber.
njh
On Wed, 29 Oct 2003, Nathan Hurst wrote:
- Gtk-compliant user interface
Can we go further and say Gnome (including HIGs)?
We can; I was deliberately being vague to give us some wiggle room. E.g., I didn't want to specificy Gtkmm directly; it's a logical choice once you say Gtk-compliant, but not the only choice.
- Extensible using various scripting languages
Aiming for first-class external language access
- Open, community-oriented development processes
A Biggy
- Baseline is the Sodipodi 0.32 codebase
Yep
- Strives to use commonly available libraries
Yep, how about when ever we share some functionality with another program, share a library. That's the GnuCash fill-o-sophy, and I think the results speak volumes!
It's good idea. Creating a piece of code as a reusable library requires significantly more work than just using it as an internal module in an application, but in the long run it can be well worth it.
Also, I know that often a third party library doesn't *quite* give the functionality needed. It's common for this to frustrate the developer into rewriting the library themselves, but experience shows this to be much easier started than finished.
It would probably be wise, when we run into these situations, to adopt the practice of creating and submitting patches to the owners of those libs and in parallel develop 'work arounds' and/or compile options that are used if the user doesn't have the latest version of the lib. I know this is a pain from a development perspective but it avoids a huge amount of maintenance hassle in the long term.
Thoughts? More? Less?
Oh, another common invariant I forgot to put in there is what OS's to target. Sodipodi seems to have done well by seeking to be portable to all systems for which a suitable Gtk port exists, so it'd be sensible to adopt a similar approach.
Bryce
On Wed, 2003-10-29 at 02:50, Bryce Harrington wrote:
Based on our discussions so far, it looks like the invariants might be:
- Full SVG compliance
And CSS2 and XML, too, of course.
- Core coded in C/C++
Yes.
- Gtk-compliant user interface
GNOME HIG-compliant, really, as Nathan pointed out.
- Extensible using various scripting languages
The scripts should be able to act as first-class citizens of the core.
I think more generally, it should be a major design goal to make "plug-ins" first-class citizens.
( It should be understood that at the beginning, this means plugin breakage will be frequent until the core really APIs stabilize. Not much worse than the situation with Linux kernel modules, IMO. )
Being able to say "no" to a feature in the core is easier if development outside the core and runtime installation is easy and carries few disadvantages. This is one of the primary drivers behind Firebird's success, IMO.
So, basically I would want to aim (long-term) for a Firebird-like approach to functionality and extensions/scripts.
- Open, community-oriented development processes
Absolutely.
- Baseline is the Sodipodi 0.32 codebase
Well, Hydra. There's an appreciable delta between 0.32 and HEAD/Hydra in places, as I recall.
- Strives to use commonly available libraries
Mmm, again with Nathan on this one. I don't think it should be a goal.
I think using libraries on the "edges" (i.e. I/O related stuff, like Gtk and libxml/libcroco parsers, and Cairo) carries a lot of advantages.
However, most applications I've seen that use external libraries in their core (i.e. their data model) suffer as a result. Often the extra shims needed to make a library do exactly what's needed harm maintainability and runtime efficiency.
I think we should keep our "core" stuff completely in-house -- in practice I think that means the XML tree, object tree, the canvas widget, and the application framework used by extensions.
In general we need to evaluate libraries very carefully based on maturity and how well they directly meet our needs.
If we need to use a new library for something, we also need to ask whether it's worth doing at all in the main codebase -- maybe it would be better as an extension.
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. ;-)
Yep.
-mental
participants (3)
-
Bryce Harrington -
MenTaLguY -
Nathan Hurst