Linux kernel developers forked glibc in 1994 because the FSF's development was too slow. When glibc 2.0 launched in 1997 with superior POSIX compliance, every distribution switched back and Linux libc died.
The C library is the most fundamental piece of userspace software on a Unix-like system, providing the interface between applications and the kernel. Every program on the system links against it, making it one of the highest-stakes components to fork. ABI compatibility issues during the migration from Linux libc to glibc caused significant pain for distributions.
In 1994, the Linux kernel developers faced a frustrating situation: the GNU C Library (glibc) was moving too slowly to meet their needs. The FSF's development process was conservative, patch acceptance was slow, and Linux-specific features were not being prioritized. Rather than continue fighting upstream, the kernel developers did what seemed natural — they forked glibc into 'Linux libc' and started maintaining it themselves.
For several years, Linux libc (released as libc versions 5.x) was the standard C library on Linux systems. It included Linux-specific improvements and moved faster than the FSF's glibc. The fork seemed successful, and most Linux distributions shipped with it rather than the official glibc.
But the fork had a critical problem: copyright attribution was not properly maintained, making it legally impossible to merge changes back to glibc. This meant the two codebases diverged irreversibly. Meanwhile, in late 1995, Cygnus Solutions hired Ulrich Drepper to work full-time on glibc. The investment paid off dramatically: glibc 2.0, released in January 1997, was a quantum leap in quality, featuring superior POSIX standards compliance, better threading support, and a cleaner architecture.
The comparison was devastating for Linux libc. Glibc 2.0 was simply better in every way that mattered. Red Hat switched to glibc in December 1997, and by 1998, virtually every Linux distribution had followed suit. Linux libc was abandoned with no ceremony — it simply became irrelevant overnight when the upstream project it had forked from leapfrogged it.
The Linux libc fork is one of the earliest and cleanest examples of a pattern that would repeat many times: a fork born of legitimate frustration that succeeds temporarily but dies when the original project addresses the underlying complaints.
Linux kernel developers fork glibc into Linux libc
Cygnus Solutions hires Ulrich Drepper to work on glibc full-time
glibc 2.0 released with vastly superior POSIX compliance
Red Hat switches from Linux libc back to glibc
Nearly all Linux distributions complete migration back to glibc; Linux libc abandoned
The Linux libc fork's death proved that corporate investment in open source can overcome community frustration. Cygnus Solutions' decision to fund a single developer (Drepper) to improve glibc was more effective than the distributed, unfunded effort of the Linux libc maintainers. The episode also highlighted the dangers of poor copyright attribution in forks.