[neomutt-devel] What is NeoMutt (long)

[Richard Russon]

Hi Fabian,

# Is NeoMutt a Mutt fork these days?

No, but the answer's less clear than ever.

For Mutt-1.6, I maintained all the features as separate branches.
Back then it was very clear that NeoMutt = Mutt + Patches
It would have been easy to supply upstream Mutt with a patch.
Note: this was a hell of a lot of hard work to maintain.

Then NeoMutt started becoming popular.
The new developers couldn't understand my branching model.
They also couldn't understand why I was wasting my time maintaining it.
They convinced me to drop the branches and the patches.

For Mutt-1.7, we have a single [neomutt] branch.
This has reduced my workload and my stress levels.
However, now we can't easily offer patches to upstream Mutt.

# But are we a fork?

Still no.  Even with ~25 patches, the code is still compatible with
Mutt.  I can still easily merge their fixes into our code.  We'd be
stupid to turn our backs on their fixes.

# Can we fork?

No (my opinion).  We just don't have the manpower to do it.
We'd need more developers with more free time to succeed.
We've achieved enough to get recognition, now we need a big publicity
campaign to expand our community.

We're starting to get lots of users, so we're starting to get plenty of
bug-reports.  Fortunately, we're in a useful position.  Any bugs that
weren't caused by NeoMutt, we can offload to Mutt.

# Do we want to fork?

Yes, of course.  Every developer thinks they could do a better job than
those before them.  Unfortunately, I'm experienced enough to realise
that this is an illusion.  We developers don't understand NeoMutt's code
that well and we don't know the RFCs concerning mail handling/delivery.

To fork, we'd have to poach developers from Mutt.

# What happens when we fork?

If we fork, then there's a brief happy period of intense activity as we
tidy and refactor code.  After that things become ordinary.  Bugs start
piling up and people lose enthusiasm.  Now *we* have to fix everything
that's wrong.

A project would need to be very well managed to maintain the momentum
that the fork generated.  It would need:
 - a good roadmap
 - to place a high value on bug-fixing
 - to be welcoming to newcomers

Also, we'd need to consider the distros.  At the moment, NeoMutt is an
extension of Mutt and many distros are using it as a drop-in
replacement.  If something goes wrong with it one community (NeoMutt or
Mutt) will fix it.

If we fork, and our code diverges, then suddenly there's a lot more
pressure on us.  Plus, the distros might be less happy to use a large
app with a very small development community behind it.

# What's the alternative?

I want a good mail client with modern features.
NeoMutt might get me there.

The alternative possibility is that Mutt starts accepting patches.
This is still an outcome I'd be happy with.

To get here, Mutt would have to change its development model significantly.
 - Start accepting patches
 - Be welcoming to new people
 - Start several parallel branches of development
 - Delegate work to trusted lieutenants

# Why is NeoMutt still gaining ground?

I've been lucky and had some good managers at work, so when I started
NeoMutt I had some good managerial habits.

 - Talk to the downstream distros
   - Find out what they want
   - Find out how I can help them
   - Actually help them

 - Documentation
   - Document all features
   - Create template docs
   - Keep docs up-to-date

 - Be welcoming to newcomers
   - Invite everyone in
   - Invest time in helping them
   - Thank people for their contributions

Of course we accept code, too, which makes us very popular :-)

We still need a clear development roadmap (and more developers),
but we're getting there.

Rich / FlatCap
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.neomutt.org/mailman/private/neomutt-devel-neomutt.org/attachments/20160918/668029d3/attachment.sig>