How does the gcc compiler get written? Who works on it and why? It seems to puzzle some people.

There are vast numbers of free software projects these days, far more than I try to keep track of. Among these, gcc is unusual in several respects.

gcc is more than 20 years old as an active free software project.

gcc has a large number of active contributors.

gcc is not associated with any single company or organization.

gcc has a relatively informal organizational structure.

gcc has no single central maintainer.

there is significant commercial interest in gcc.

gcc has survived a significant shift in organizational approach: the egcs fork back in 1997, which eventually took over as the mainline of gcc development.

What people seem to find most confusing is that gcc has no central governing body. It is a collection of people who cooperate following loosely specified rules. Many of those people are volunteers who are interested in compilers. Many, perhaps a majority, work for companies which have a commercial interest in gcc.

No single party decides what to implement in gcc. Instead, different people work on projects for reasons of their own. As these projects near completion, they are loosely coordinated by the release managers (until recently, there was only one release manager) who decides in which order they should come into mainline. The release manager does not reject projects.

gcc has a steering committee, but the committee does not make technical decisions, and does not decide what code will be written. The main effect of the steering committee is to appoint maintainers for different parts of gcc. This is considerable power, but in practice the steering committee has not chosen to wield it. There have been essentially no controversies about choices of maintainers–the closest to a controversy has been discussions about which contri buting organizations may have too many maintainers.

How does the gcc community decide to work on something? Somebody puts forward a proposal and works on it. If it needs more than one person, he or she gathers interest and tries to convince people to help. There is no central directive to work on anything, although there is a list of suggested projects.

How does the gcc community reject a contribution? There are certain required guidelines: a copyright assignment for the code, various formatting and documentation requirements. The code obviously has to work, and it has to not make the compiler significantly slower or otherwise worse. Given those, pretty much the only way a contribution gets rejected is for somebody else to develop an alternative which makes the first contribution unnecessary.

How does the gcc community fix bugs? One way is that releases are not made until the number of open bugs is reduced to a certain level. This encourages anybody interested in the release to work on bugs. The other way is that some companies have a commercial interest in high quality releases; they direct their employees to fix bugs.

How did this haphazard project produce a widely used compiler, probably second only to Microsoft Visual C++? The compiler is not tied to any single organization, which means that it keeps going even when organizations fail. Because the compiler is widely used, many people benefit from improving it. Because it is free, many people are able to improve it.

gcc is a clear success story in the free software world. Of course it has problems, but I don’t think it has any structural problems which will prevent it from continuing on for many years in the future.