[neomutt-devel] mutt vs neomutt
dgc at bikeshed.us
Mon Feb 13 01:28:54 CET 2017
Again, Guyzmo, thanks for your long and thoughtful response.
* On 10 Feb 2017, Guyzmo wrote:
> I think the issue at hand is how can we create a synergy between mutt
> "established community" and neomutt's bazaar, so we can get the most out
> of it.
I think there's a possibility here. But, I'm sorry to say -- sorry to
lay this at your door -- neomutt needs to be more open with mutt for
this to happen. You're currently making a lot of decisions about the
code that need to involve at least Kevin if not more of the mutt-dev
group in order for there to be any synergy. Without that there's no
_syn_ to it.
I want to mention politics too. You said that you just want to code and
not deal with politics, but forking is the most political thing an open
source project can do. So you really stepped into it there. :/
I hate the politics myself. I grimace every time certain topics come
up, or... sorry to say it, certain people. I wish we could just make
mutt win. Ironically, we've tolerated this in mutt-dev perhaps more
than we would like to avoid losing developers. Looks like you lose
either way once your community gets to a certain age.
> > To paraphrase: Neomutt is a fork. There's no way to think otherwise,
> > as I read more of your material and look at events. I think there's
> > acknowledgement of that from within, even embracing. The activity
> > within the group is characteristic of a project that fully intends to
> > supplant its predecessor. I just ask that you own it. The only way
> > Neomutt is "not a fork" is if you have or anticipate a proposal for
> > merge-back. I'd be curious what it is.
> My position is that if mutt and neomutt have different goals, they
> should follow on the vim vs neovim path, and actually _own_ those
I don't know the vim/neovim story, so can't respond to that.
What bothers me is how your group diverged. It's hard to see it as
anything other than a hijacking of the mutt development leadership by
someone with no previous relationship to our "line of succession",
when we weren't even closed to the contributions. That's why I said
previously that it seems arbitrary -- there was never even an argument
to prompt the split. If everyone had come over and discussed plans,
I think we'd have had a great conversation and a lot of trust in the
community. But that didn't happen, and I don't know how to trust
Yes, this is all easy to say now, but here's my belief: nobody can point
to a disagreement that directly caused a fork. It's the result of a lot
of hearsay and vague concern and sense of hopelessness.
Does that feel unfair? I'm being totally candid about this. I hope
you can imagine what it would feel like if someone did that to the OSS
project closest to your heart.
That said, I want to admit that I'm also envious. I've wanted this
boost in productivity for a long time. Years ago I had lots of time for
mutt. Now I don't, but I still have big ideas and enthusiasm for it.
I feel like that's been taken, because the momentum you have now will
probably do a lot of harm to upstream. I think some of you believe that
too, but don't mind as much as I do, of course.
> My understanding is that mutt is likely to stay the good old MUA many
> loved and some still loves. Very portable, that can run even on AIX4 or
> some other forgotten Unix, but without all the shiny features we can
> find in all the many patches gathered all across the intertubes.
> Then, how I'd see neomutt being a fork? Try to modernise the codebase,
> not being afraid of breaking stuff that has been there for ages:
> - consider using external dependencies (like libuv for file and network I/O),
> - break compatibility with systems we cannot test on (I'm sorry AIX),
> - add unit/regression testing and CI,
> - add scripting for enabling second class features,
> - reformat, refactor and document the code,
> - add features like notmuch integration, nntp and other stuff alike.
> Would that mean that neomutt would supplant mutt? I don't think so. Many
> user will prefer using mutt because they don't need more features, but
> want a software that can still run on that 1997 sparc machine.
All those things you list sound very exciting. Mutt would love to have
them. I feel a little punched in the gut that you say our relevance
or desire is to be the mailer of choice for Solaris 2.5. That's not
true at all. I would be happy, personally, to cut off older operating
systems at some appointed version. It's a great principle for 2.0.
But to be fair we need to manage that process, not just start applying
breaking patches willy-nilly. We need to be answerable to our user
community, not to our developers' sense of glee at doing cool new
> As we're defining a vision of what we, users and contributors of
> neomutt, want neomutt to be, it's naturally a great idea to confront
> that with what the vision of mutt's "established development community"
> is. Depending on how much we agree on, and how much we diverge, we
> should be able to define whether neomutt is a fork of mutt, or merely an
> extended patchset above mutt.
When code can't backport, it's a fork. When developers aren't talking
to each other, it's a fork. With the changes you have in flight, your
"patchset" will be more than half the code unless we do things to
preserve compatibility that we weren't involved in deciding.
I have more that I'd like to say on this, but I need to talk with
others. The most important thing to me is that the mutt community not
be divided. That's what hurts more than anything else, that some people
think that's a worthwhile sacrifice to make for not having to deal with
I want to keep this discussion going. We'll talk more.
David Champion • dgc at bikeshed.us
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the neomutt-devel