Paul Cockings wrote:
My preference would be if the dspam community as a whole could move to a new project, but I'm not sure if anyone will come!
Maybe thats what a dspam fork would be... a new project, or projects. The biggest problem with dspam is that it tries to do too much and fit too many moulds right out of the box. No baysian algorithm specialist is going to be a webapp specialist or postgres specialist. Find a specialist in every dspam area, and you've got someone who can't document the thing etc etc... Johnathan's achievements in this regard (multi discipline expertise) are phenominal but it leaves a vast project that nobody can easily step into.
A new project would need to maintain the bulk of the knowledgeable people found here, a return of Jonathan in some way if he is able, and a structured way that we can all commit back those patches without turning dspam into a black hole of focused smaller projects, that in time will become unmaintained.
dspam would be easier to maintain if it was split into three projects, the daemon, LDA and the web admin. The storage driver support should be reduced down to one, mysql and drop hash databases etc which are only a cop out for people who couldn't be bothered reading how to setup mysql (IMHO) and which are the source of a lot of open bugs. In fact, there's little advantage to dspam being an lda and that portion could be dropped and just ride off the successes that are maildrop procmail etc etc.
With that kind of a split, you can get focused groups to easily maintain their own portion without getting into knots to bend over backwards to suit people, and it leaves the integration possibilities the same and makes the documentation project easier.
I see a need for a fork, but have no experience of a project lead in this way - the setup on sf.net is the easy bit, but will anyone else be interested if I did it?
Project leads are easy to get, what you need are developers who can read and understand code and are willing to patch, test and release.
Brian.
