I use the email client Mutt. It is a tricky-to-learn-but-incredibly-powerful email client. In the past, I have contributed minor patches to the project. Recently, there has been very little new development: the code base has stayed pretty static for the last couple of years. Given that there are a large number of people using the program, this indicates that it has reached a state of Pretty Much As Good As It Gets.
However, some of the non-core Mutt developers have become disillusioned with their contributed patches not being accepted into the main code base and have raised the idea of forking the code off into a separate project (perfectly legitimate, legally and technically – however, it’s rarely the best option if a way can be found for all developers to continue working on the same code base). This has resulted in a lot of heated discussion on the mutt-dev mailing list, as the core developers try to placate others by being more open to new patches to the code.
It will be interesting to see how it develops, as some of the larger patches to be contributed add large amounts of new functionality.
Hmm, I think the quote in the comment that “open source is about feature competition” is dead wrong. Don’t get me wrong, I’m sure mutt could benefit from some new features (like tighter GnuPG integration, given the problems we’ve identified with it), but for me, I’m more interested in the UNIX philosophy of something which does small jobs well and can be easily tied into other software to do complicated tasks.
Perhaps mutt should follow the same path as irssi – the basic client is fairly lean and does its task well, then there are all sorts of third-party modules that can dynamically extend the client to do other things.
PermalinkYeah, that’s generally my feeling. Perhaps the future development of Mutt should be geared towards an API/whatever for plugins. Certainly the main complaint from those who have written patches is that they have to keep re-writing them for each new release of Mutt: if a consistent framework for the plugins is kept, then that shouldn’t be necessary.
BTW What GPG-related issues are you referring to?
Permalinkegroupware is a spin off of phpgroupware when people got fed up with lack of fixes/progress on phpgroupware. Seen other O/S projects do this as well.
I see no reason why you can’t spin off a fork if you want to. Problem of course if then committing the time to the project which may mean you end up in the same situation as the main project 😉
Permalink