This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

clang and FSF's strategy

From: esr at thyrsus dot com (Eric S. Raymond)

To: rms at gnu dot org, gcc at gcc dot gnu dot org, emacs-devel at gnu dot org

Date: Tue, 21 Jan 2014 15:19:49 -0500 (EST)

Subject: clang and FSF's strategy

Authentication-results: sourceware.org; auth=none

David Kastrup's recent question on emacs-devel motivates me to bring up a larger related question I've been meaning to open for a while: Are the FSF's goals best served by continuing to technically restrict GCC? This is a question in which I have some positive stake. Yes, I continue to be opposed to the FSF's style of propaganda exactly because I think it hinders an end goal - a software ecosystem that is open-source and user-controlled - that I agree with and have worked hard to achieve. On the other hand, I have always said that the FSF's artifacts are its best artillery, and GCC is certainly one of the biggest guns in that arsenal. I want GCC to do what the FSF wants it to do - promote freedom and openness, erode proprietary control, prevent vendor lock-in of development toolchains. I think it is time to question whether the anti-plugins policy is still the best way to accomplish this. What gives this question point is the very existence of clang. The clang developers aren't shy about saying in public that they regard the FSF's anti-plugin policy as obstructive and that this is a major motivation for their work. And they're making excellent progress; clang is a production-quality tool today, not yet as mature as GCC but with better features in some areas - its error messages, in particular are *far* superior. The clang developers very carefully do *not* say that they aim to make GCC obsolete and relegate it to the dustbin of discarded tech. But I believe that is unmistakably among their goals, and I judge that they are a credible threat to GCCs's dominance in the 3- to 5-year timeframe. It might be that my goals would actually be advanced if clang were to kick GCC off the top of the heap. That is, there is at least a possible world in which a serious hit to FSF's prestige would decrease its ability to hinder progress through PR I have made no secret of considering ham-handed and counterproductive. For the present I choose to ignore this possibility. It seems better to me to promote as vigorous as possible a competitive race between GCC and clang, so that both will improve and the the aggregate position of open-source toolchains will strengthen. Therefore, I point out that FSF can no longer prevent proprietary vendors from plugging into a free compiler to improve their tools. That horse has left the barn; the strategic goal of the anti-plugin policy has been definitively busted. I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more. GCC won its war; the cost and time-to-market advantages of hooking into open-source toolchains are now so widely understood that new processor designs support them as a matter of course. Wouldn't it make sense, then, to entirely drop the factoring restrictions from GCC so it can compete for developer attention more effectively with clang? Before clang existed, back when GCC had a near monopoly in its competitive space, there might have been a functional case for those restrictions. Reasonable people may differ on that; there's no point in arguing it retrospectively. Now, I submit, they have become a pointless gesture that serves only to hinder GCC development abd increase clang's competitive advantage. GCC has a lot of strengths to play from, most notably the maturity of its multiplatform and cross-development support. I urge the FSF to fully free the code - drop the policy restrictions, encourage a flourishing ecosystem of surrounding plugins. Let GCC, clang, and other alternatives compete for attention on pure technical merit. I think the last fifteen years have demonstrated that in this sort of competition, the proprietary vendors will eat dust if they try to outcompete open-source tools on their own ground. Furthermore, they've learned this the hard way, and are quite unlikely to try. There are less risky uses for their NRE. In some sense I don't really care who wins. Either GCC or clang will serve my needs. I do prefer that both tools be as excellent as possible. And it would be nice if the FSF were to demonstrate that it can recognize changed conditions and move with the times. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> There's a tendency today to absolve individuals of moral responsibility and treat them as victims of social circumstance. You buy that, you pay with your soul. -Tom Robbins, Still Life with Woodpecker