Now that I've had time to think about it some it seems that the move to eglibc isn't as much
about creating a fork of Glibc.. it's just that it is easier to share the burden of managing patch
sets with other people who are experiencing the same problem.
Maybe the term should be 'SPORK' instead of 'FORK'. I've noticed that this is happenned with a
few different peices of software when people are trying to figure out how to deal with difficult
situations created by upstream developers who otherwise are valuable.
There has formed a multitude of MySQL sporks over the time. Stuff like OurDelta: http://ourdelta.org/
As a response to the slow and somewhat negative behavior with Sun Microsystems regarding
In both cases they don't really want to _fork_ their projects. But they have requirements or
desires that are simply not being addressed by the upstream folks in a timely manner. So in
both cases they try to shove code back upstream, but is a community way of maintaining
their own patches.