It is often the case that windowing libraries tend to result in large, bulky programs because a large measure of ``dynamically dead'' code is linked into the programs because it can not be determined at link time that the program will never require (that is, execute) the code. A consideration (not a primary one though) in GLUT's API design is make the API modular enough that programs using a limited subset of GLUT's API can minimize the portion of the GLUT library implementation required. This does assume the implementation of GLUT is structured to take advantage of the API's modularity.
A good implementation can be structured so significant chunks of code for color index colormap management, non-standard device support (Spaceball, dial & button box, and tablet), overlay management, pop-up menus, miscellaneous window management routines (pop, push, show, hide, full-screen, iconify), geometric shape rendering, and font rendering only need to be pulled into GLUT programs when the interface to this functionality is explicitly used by the GLUT program.