[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why are so many great packages not trying to get included in GNU Ema

From: Yuan Fu
Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers
Date: Sat, 20 Jun 2020 21:37:02 -0400

   git log -500 --format="%ae" | grep -vP
five)\.(org|com|de|cz|cn)" | sort -u | wc -l

Results are:
* GCC as of commit 445d8da5fbd: 15
* Clang as of commit 7b201bfcac2: 49

This is some pretty big difference! If I expand the commits range, the
difference increases further.

GCC is alive for 33 years, so I think your theory eats dust.  Many of
the GCC and GDB developers get paid for their work, but that doesn't
mean the project is less viable, and the long history of both GCC and
GDB is the proof.

Okay, let me say beforehand that both GCC and Clang are very active projects
right now. Just in case, so there's no misunderstanding.

So, times are changing. In older times there were no standard to development,
Git was not as popular, development practices are varied too. So, as long you
could get your patch to a project, any odd contribution requirements were fine,
they hardly would set a barrier.

But these days Git got over all other VCSes (and for a reason), so using SVN or
Perforce, or whatever, is a barrier to contribution. 12 years ago Github was
founded, and then also the open-source clone Gitlab appeared. These two pretty
much set the standard development model nowadays (for a reason too). There still
are projects that use other models, but this is a barrier to contributors.

What I'm getting at is that your reasoning that since GCC is 33 years old it
will live on does not work. For a project to "live on" it needs to be active.
Sure GCC is active! But its activity mainly stems from paid people and
maintainers. Whereas in Clang a large chunk of it stems from contributors. Let
me repeat, paid people come and go, so do maintainers (they may burn out, or
just move on). These contributors are the ones who will become new maintainers
and the ones who advertise the project in their environment.

I hope it makes clear the future of what project looks brighter.

I think the point is not “this works for a long time and it must be better than new stuff” but rather the current method _can_ live long (proven by gcc & gdb, etc). If in the future people moves to other shiny new SVN’s and github’s, does the git method still work? 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]