Has Mailman lost its way?
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:
Freeze 2.1 now. No new features. The only exception would be security bug-fixes. Nothing else.
Freeze "new idea" development now. Concentrate solely on bugfixing the already implemented ideas.
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.
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.
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!)
Best wishes.
--
: 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. :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi David,
Thanks for the post. As I hope you will soon see, I believe the
Mailman projects is very much alive and kicking, and it is moving
forward with a fairly clear plan. Ultimately of course, that roadmap
is subject to the constraints that many open source projects are also
subject to, grand designs implemented between diaper changes, trading
today's new feature or fix for falling ever farther behind in email,
and convincing yourself that sleep is a Corportist plot.
On Mar 20, 2008, at 6:41 AM, David Lee wrote:
Could I suggest that serious consideration be given to:
- Freeze 2.1 now. No new features. The only exception would be
security bug-fixes. Nothing else.
This is happening. When Mark releases 2.1.10, there will be no 2.1
releases except for security or other serious bug fixes.
- Freeze "new idea" development now. Concentrate solely on
bugfixing the already implemented ideas.
Hmm. Probably not realistic. There's a huge backlog of good ideas
waiting to get in. Now is actually exactly the time to evaluate those
and decide whether and where to implement them.
- 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.
I don't think this is going to happen. Almost all new code for
Mailman is today written by either Mark or myself. This is not to
dismiss all the fantastic contributions of other sorts by other
people, nor to dismiss the huge number of patches available out on the
'net. But some of the things I've pushed for recently is specifically
geared to getting more involvement from the community. That's why I
chose Bazaar as our dvcs. I don't want patches, I want live branches
that I can merge and review.
Both 2.2 and 3.0 are the future, but for different audiences. I
recognize that this means our limited resources are stretched even
thinner, but I think it's justified. Mailman 2.2 will be for those
users who are happy (enough) with the 2.1 data model, and just want a
few new features, a spruced up web u/i, and other modest but important
improvements. I consider Mailman 2.2 a critical project, and I am
delighted that Mark will lead this effort.
While I will be involved in 2.2, and plan to be engaged in its design,
I personally am spending my limited hacking time on 3.0. Mailman 3 is
the long promised solution to several architectural limitations in the
MM2 series, and improving those aspects requires a bump to version 3.
Mailman 3 also has a different focus. It's trying to be at its core a
mailing list delivery library, usable and easily integrated with a
wide variety of applications and web frameworks. Ultimately, Mailman
3 will be usable just like 2 is, as a standalone turn-key system, but
I think it's real power will be in its use as a component for more
interesting systems.
Will 2.2 or 3.0 be released first? I have no idea.
- 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.
Well, there is nothing stopping you from participating today. I just
released Mailman 3.0 alpha 1. You can pull the code down, or branch
from the Bazaar repository, start fixing bugs, implementing ideas and
helping out. You can push branches, request reviews, strive toward
adoption in the core. Soon, I expect we'll see some Mailman 2.2
branches and alphas, and then you can do the same there.
This is a volunteer effort, on my and your part. I've put my stake in
the ground. Where are you interesting in contributing?
- 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.
It doesn't quite work that way. Once you reach beta, features are
frozen, and I think we're too early for that. But we can have a
vibrant alpha ecosystem right now, and if you're willing to
participate, you can make a difference. If that means you can't make
a business case to your manager right now, then hack on it in your
spare time. Help us get to a point this year where we /can/ feature
freeze and start releasing betas. I would like nothing more than
that, so that both you and I can begin to convince our managers to let
us spend Real Work Time polishing and releasing.
Otherwise, are we not in danger of following Majordomo into oblivion?
It's always possible, but I think unlikely. You have it in your power
to help avoid that fate.
(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!)
Proper virtual domains exist today, in Mailman 3.0a1. Try it. If
there is anything stopping folks from participating, please let me
know. I'm very keen on helping remove barriers to participation. But
remember that Mark and I have jobs and families, other hobbies and
lives. Occasionally we like to eat and sleep too, so we develop the
software when we can. But I think we'd both welcome anybody who's
interested getting more involved, in whatever way they want (it does
not /have/ to be as a coder, as great contributions from Terri, Clytie
and many others has proven).
I guess I need to sleep now. Damn those Corportists!
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkf8L78ACgkQ2YZpQepbvXF8QwCfT7KXPXPUoK+5XEJDCYpFdwqb FdMAmgM/6JxIZZxerpUurZzrOdbz89/h =1Jlg -----END PGP SIGNATURE-----
participants (2)
-
Barry Warsaw -
David Lee