git log -500 --format="%ae" | grep -vP "@\S*(redhat|arm|suse|google|gnu|adacore|alibaba|intel|ibm|apple|linaro|huaw ei|c odesourcery|golang|sony|amd|chromium|nvidia|loongson|accesssoftek|ubisoft|mi cros oft|fb|energize|comstyle|nextsilicon|quicinc|azul|gentoo|graphcore|gdcprojec t|si 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 projectsright 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 youcould 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 orPerforce, or whatever, is a barrier to contribution. 12 years ago Github wasfounded, and then also the open-source clone Gitlab appeared. These two prettymuch set the standard development model nowadays (for a reason too). There stillare 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 itwill 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 andmaintainers. Whereas in Clang a large chunk of it stems from contributors. Letme repeat, paid people come and go, so do maintainers (they may burn out, orjust move on). These contributors are the ones who will become new maintainersand 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?
Yuan |