The message http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01268.html by Eric Raymond has pointed out some of the main fallacies of the development process of Emacs:

1. use of an outdated version control system, that is cvs.
2. lack of a modern (or fashionable) interface between core developers and users/non-core developers
3. long time between releases.

A long thread started from there, involving most of the well-known Emacs core developers. I have found that message (and the whole thread) really interesting, especially since ESR wrote the “curse of the gifted” message that sparked the discussion on using a version control system for the Linux kernel.
I want to point out my point of view on the matter, as I am quite far from a typical (or good) Emacs contributor, while using Emacs a lot and occasionally lurking on emacs-devel. I believe that Emacs contributors can be divided in a few categories:

1. core developers (a few dozens) who know the intricacies of the C part and the most important Lisp parts.
2. important developers: they are more specialized to some Lisp parts of the project, but their work is completely integrated in Emacs (ESR is now a good example of the category with his recent work on VC),
3. external developers: like category (2), but the parts they are working on is not integrated within Emacs, therefore their release schedule does not follows Emacs’s. Some of those parts might be integrated into Emacs sometime in the future, and the developer might be actively working in that direction. (Stefan Reichör is an example of such category, with his work on PSVN and DVC).
4. contributors: they are not really in charge of any code, but they can fill bug reports, update documentations, occasionally send a patch.
5. users: they might send a bug report.

Clearly those categories are not that disjoint: for example David Kastrup is in category (1), but his work on AucTeX would be in (3) – at least until AucTeX is integrated into Emacs.
I summarize some of the peculiarities of Emacs’s development process:

1. all code is review in the emacs-devel mailing list.
2. the bugs reports are collected in the bug-gnu-emacs mailing list
3. the guideline states that, in order to send a bug report to bug-gnu-emacs, only a vanilla version of Emacs (that is compiled from original sources and invoked without any .emacs file) can be used. This rules out any version of Emacs found in a major Linux distribution.
4. One of the goal of Emacs development is the advance of free software. RMS has used that argument for rejecting some feature requests. This is not abad idea per se, but it clearly slows down development.
5. All copyrights regarding the code must be assigned to the FSF.
6. A considerable number of the core developers have stated that batch processing of Emacs-related issues is a necessity. RMS has stated that only emails fulfill his needs for bugs handling and code review.

Why have I decided to write this post?

Because Emacs is one of the very few programs that really improve my productivity. The only other software I could not give up using is the LaTeX suite. I could probably adapt to use any major OS (but I am sold on Ubuntu for the foreseeable future), any major browser and ail reader (ditto for Firefox and Thunderbird). I don’t use anything else hat much.

In which category do I fall?

Right now only (5). What is relevant to this post is hat I will likely, within the right environment, escalate to (4). It is much less likely, though not impossible, to go up to rank (3).

My main points are:
1. Emacs would benefit from a good integrated package manager (ELPA is an adequate starting point).
2. A modern, web-based, bug tracker is indispensable for increasing the number of people in categories (3) and (4).
3. The bug tracker must include also bugs from vendor-packaged versions of Emacs as well as different Emacs-related external packages.
4. Using a distributed version control system would help in increasing development speed, especially for external packages.

I now elaborate my main points and give some proposals.
1. Emacs would benefit from a good integrated package manager.

I don’t think this is controversial. The emergence of ELPA and XEmacs history is already a proof that this is a good idea. The only real reason for not already having such a system integrated into Emacs, is that RMS has opposed to the idea as it would enable (or ease) the possibility of using non-free extensions of Emacs.

In my opinion such concern is only partially correct; while I agree that a package manager would lower the technical efforts for using a non-free extension, I do not see any widespread non-free extensions, so there would not be many (if any at all) users switching to some non-free programs.

If any user/developer would be that determined to use some non-free extensions, it should not be too difficult to modify ELPA to include a different repository including non-free extensions; this makes even less meaningful the idea of rejecting a package manager altogether.

My proposal is to integrate ELPA (or a similar program) into Emacs, hardcoding two package repositories: one from savannah.gnu.org and the other from savannah.nongnu.org. Both repositories must contain only GPL packages, so that
no harm is done to the FSF cause. Almost all the people in category (3) – the one involved in a package system – aim at a possible integration into Emacs and/or a spot in the daylight: I believe that the possibility of becoming at least a de facto standard component of Emacs (even if not officially integrated into it) would be strong motivation for external developers.

2. A modern, web-based, bug tracker is indispensable.

Indispensable is strong word, but it is what I believe and it is true for me. I have sometimes contributed some bug reports, mainly through the Debian bugs tracking system. I would surely do the same for Emacs, assuming that I am able
to find a bug in Emacs. Actually I have a nagging problem in Emacs, regarding scrolling pressing the cursor-down key, but I have never reported it for a couple of reasons: the gnu.emacs.bugs mailing list is populated by Emacs ubergeeks and this fact can be quite intimidating, it is too easy to send a bogus bug report and receive an embarassing response; the second reason is that I would have to test if the bug is still there in a vanilla emacs.

If a bogus report could be simply dismissed by a developer closing the bug report, then the bar would be lowered.

Notice that web-based doesn’t mean web-based-only. Integration with email is possible and welcome. At the same time web-based bug tracking can be ugly; I still cannot stand bugzilla and I have some problems with launchpad, for
example. I think that the Debian bug tracking is a much better starting point: already integrated with email (bugs can be
closed by email), a clean interface which is suitable to text-based browsers, good defaults for severity, good integration with changelogs (bugs can be closed by uploading a revision with the appropriate changelog).

The real advantage of a public web-based bugs tracking system is priorityzing and classifying bugs; it is clear to everybody which are the important bugs and which are the bugs that can be solved by a wanna-be Emacs developer. Documentation issues can be clearly marked as such and could be a good starting point for a newbie.

My proposal: customize the Debian BTS, including a bidirectional gateway to/from the BTS to each major distribution BTS for dealing also with distribution-specific issues.

3. The bug tracker must include also bugs from vendor-packaged versions of Emacs as well as different Emacs-related external packages.

I have already advocated the idea of including bugs from different GNU/Linux distributions. The main reason for including also the external packages is that of giving more importance their developers: keep in mind that they contribute greatly to making Emacs a wonderful editor for a number of people (I would not use Emacs without AucTeX).

4. Using a distributed version control system would help in increasing development speed, especially for external packages.

The advantages of disconnected operations are becoming evident to most developers: commuting or long-distance flights are quite common among programmers. Any distributed version control system stores locally the entire project history, allowing all operations even without net access. Notice that in the same conditions even a simple cvs/svn log is impossible.