On 18 Feb 2014, at 19:55, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> So you are saying that patch review process is that "red tape" that
> was mentioned earlier?  If so, all the projects I'm involved with
> insist on the "dialog", i.e. that the original contributors improve
> and fix their contributions until they are acceptable. 

To some degree, but (my impression is that) Emacs stops a lot of
changes at the need for support on more platforms than the submitter
can easily develop on.  Note that Im not saying that these are
unreasonable - just that theyre not based on github.

> Which projects don’t?

Most software projects today are much smaller, more nimble, and
piecemeal-clockwork than emacs. Emacs was built in a heavily
monolithic era, and continues with most of that lineage. Far more
software projects today are assembled from many interlocking pieces
of libraries, middleware, and plugin code. Again, there are good
reasons for this, but it has a cost, and much of that cost is
expressed as a high barrier to entry.

Compare this to typical java, python, or ruby projects; they usually
use a variety of smaller, self-contained projects, each of which
is a viable entry point for a new contributor. To the extent that
Emacs uses libraries, its often more hindrance than help, as the
new contributor is faced with X, GTK, ns/OpenStep, and w32 libraries,
or learning the daunting Emacs internal wrappers for each.

Another thing that hits Emacs: people working on changing or extending
Eclipse do it IN java, which is the same language they use Eclipse
FOR. While there are surely Emacs developers using Emacs to develop
Emacs Lisp, theyre doing so mostly just for Emacs, not for anything
else; this internal focus shows in the results. There was a time
when Emacs was a great way to write C code, but its really fallen
behind in some key areas, and Emacs own C code is highly idiosyncratic.

Again, Im aware that there are good reasons for all of these things
to be true, but each of them makes it harder for people to make
significant contributions to Emacs, which is the topic at hand.

I hope that helps,
~Chad