[Mailman-Developers] Has Mailman lost its way?
t.d.lee at durham.ac.uk
Thu Mar 20 11:41:12 CET 2008
First there was Majordomo...
Once upon a time, Majordomo version one was the leader in its field. So
good was it, that ambitious plans were laid for a succeeding generation:
version two. And at that point it went off the rails and ended up in a
ditch. 'Domo V1 got stuck, because the development went into 'Domo V2.
But V2 got stuck because it never got released and never got used. And so
the once glorious Majordomo sadly faded into the night-time of obscurity.
Move forward a few years...
In another place, at a later time, Mailman v2.1 became the leader in its
field. So good was it, that ambitious plans were laid, not just for one,
but for two, succeeding generations: v2.2 and v3. And at that point...
... well what has happened?
Nearly two years ago, the July 5 2006 "What I did on my summer vacation"
email and wiki entry (http://wiki.list.org/x/vg) outlined a massive amount
of potential progress. But, in reality, what actually have we (the subset
of real-world end-users who could assist development) been able to do?
Has Mailman lost its way? Could it be drifting to the same obscurity and
oblivion as the entire majordomo project?
Could I suggest that serious consideration be given to:
1. Freeze 2.1 now. No new features. The only exception would be security
bug-fixes. Nothing else.
2. Freeze "new idea" development now. Concentrate solely on bugfixing the
already implemented ideas.
3. Decide whether 2.2 or 3.0 is the way of the near future. The reality
is that neither of these has delivered anything to the real-world end-user
during two or more years. Choose only one. Freeze the other for the time
being, until the "chosen one" has been properly post-beta released.
4. Whichever of the above is chosen, aim to start delivering betas fast.
Get something out there that you (the main developers) and we (some
real-world end-users who can help bug-hunt) can get to work on, knowing
that our work will be productive in a foreseeable timescale. Set the
goal. Drive towards it, ignoring distractions.
5. For a few months, change the mindset away from development (yes, I know
we coders love it) and towards a firm, decisively-directed "release
management" (to use ITIL-speak).
Mailman used to be a leading product. But it is slipping behind.
We, the end-users, need some of that new code that's being lying dormant,
and (to an end-user) unuseable, during the last two years or so.
Many of us, the enthusiastic real-world end-users, cannot realistically
commit to developing something for which there is no clear strategy.
Give us a strategy, a roadmap with real, near-future dates on it, then we
can at least make local business cases to our local managements for our
taking part in beta trials.
Let's get some new code out now as beta. There may be a sizeable "TODO";
there may be a sizeable "Known Problems". But let's start releasing betas
soon, and concentrate all our limited efforts on that one common task.
Otherwise, are we not in danger of following Majordomo into oblivion?
(Oh, and #1 on my own list is proper "virtual domains": the Jul/2005 paper
mentioned that the code substantially existed. But sadly it's never come
anywhere near a release schedule. If we have a realistic beta-release
schedule, then I can locally justify actively investing in bug-hunting.)
Sorry if that sounds harsh. It is meant to be constructive. (Honest!)
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
More information about the Mailman-Developers