Firstly I'd like to thank SN for the replies last week, we now know your
alive and listening. If no reply had been made a fork would be in
progress, but you now get a perfect chance to show us how a SN+Community
effort can exist.
I would truly love SN to be more active on this lists and show that a
community fork is not needed. You can see that community supports a
fork, not because we don't want to work with SN, but your not helping us
to help yourselves.
A community fork will happen (project espam) by the end of the year if
the following points cannot be moved forward:
- Central Repository - with community access
- Central Bug Tracker - with community access
- Fold in exist SN patches, Gentoo patches and any other patches
- Release a Beta with the patches and options in so we can start testing
- Feature Suggestion - with community access, and place to discuss wacky
ideas (I have some)
- Wiki (maybe Frank will donate the start of this?) - Example setups,
docs etc - with community access
- Reliable DNS Servers (the dspam website appears offline most of time)
- Invite Jonathan back into the party (if he can), the project misses him
- Give us some ideas of what SN is doing with dspam
- Better mailing list storage/search function
- Establish contacts with distribution specific maintainers
With comments and direction on the following:
Move towards better distribution standardisation (you have at least
Gentoo, CentOS and FreeBSD actively here)
Structure/Roles for those willing to help out. Seems like the project
can be sub divided (particularly split away webgui) and lots of Doc +
testers
Release/Test schedule
Roadmap/Discussion of future ideas/features
Discuss the illegality's of copyright for those that contribute to
SN+Community project
Assurance of SN commitment to open source and that the community will
not be froze out
Take ownership and show us the way.....
If SN doesn't have the time/resource to commit to the dspam project
right now, then i'm not adverse to the Compiz/Beryl/Compiz idea. The
community is waiting to help make dspam a better product, that's all we
care about.
While I'm in a writing mood, I'd also like to thank everyone on the
dpsam lists for keeping the project alive this long. My particular
thanks goes to Steve for all the work with the Gentoo patches and those
with name suggestions for the forked project. 'espam' takes the votes,
even though I personally smile at PigeonHole each time i say it :-)
Maybe a pigeon can feature in the logo...
I await a positive Sensory Networks reply,
Paul
Mark Rogers wrote:
Steve wrote:
The last weeks here almost every one was talking about forking DSPAM.
Well... Sensory Networks replied and now every thing is quite again.
I was thinking the same thing. I was optimistic that the message from
SN indicated that there might be some involvement from them (and not
on an "early next year" timescale) but it's gone quiet again.
My opinion is that a fork would be worthwhile, if only to merge back
into the official source if/when SN wish to do so (or not if they
decide not).
Okay. Why this long mail? Well... I would love to see other people on
the list implement stuff. I am sure that others are developers or can
develop. What is holding you back to do things? I miss the time when
DSPAM was getting better and better with each release and where you
did not had to wait almost 1 year to get a new DSPAM release.
I think I found dspam just too late to have witnessed this, but it's
obvious from the passion people have about dspam that it was once there.
As a coder I might be able to offer something, but my days of C coding
are some time ago. I would very much like to look at the web interface
though (although I'm happier in PHP than Perl). Maybe I could do some
documentation too.
So please all you out there using DSPAM and able to code: fire up
your dev environment and start coding on DSPAM. Add new features. Fix
old known bugs (if you don't know them, then ask here and I am sure
you will get responses). Enhance DSPAM. Make it faster. Make it use
less memory. Add new storage engines. Etc...
What I'm missing here is a clear idea of where to put the resulting
code. Do we fork? Can we at least have a single repository of patches
and other enhancements?
Would SN be hostile to a fork? It seems to me that they might benefit
from it (they can merge the code back after all, and they don't seem
to have the resource to push dspam forward at the moment). If they are
hostile to a fork then these mailing lists may disappear...
If you look at how Compiz forked to create Beryl, which later merged
back into Compiz once it was stable, then there might be a model we
can follow here.
