Penguin
Recent Changes

  1. A split or divergence in a software project

    Projects fork when one or more groups with different visions from the original project team decide to take a copy of the SourceCode and develop it to their own ends. The SourceCode must be sufficiently Free to begin with for this to happen.

    Being able to do this is both a blessing and a curse. Halving the number of developers working on the source for a project more than halves the productivity of each group due to the NetworkEffect – a powerful deterrent to forking. However, a fork can also serve to dissolve the tension in the direction of the previously united project, letting each of the forks focus on a particular agenda. In many (maybe most) cases, all but one of the forks eventually wither and die, and the surviving fork pushes onward with a more well-defined vision that has greater consensus. Forking may therefore contribute to the health of a project in the long term.

    In rare cases (such as the Beryl/Compiz split or GCC/egcs), the projects eventually reunite.

    Well-known examples of forks include:

    • GCC and egcs
    • Mandrake and RedHat (I think Mandrake was originally RedHat with KDE?)
    • Emacs and XEmacs, both branches of which continue to thrive to this day
    • XFree86 and XOrg, where an unpopular change to the licensing terms of the former caused a wholesale defection of developers, distributors and users to the latter
    • X Consortium and XFree86, same as previous example, but XFree86 on the other side, and years earlier :)
    • More recently, the forking of cdrkit off from cdrtools, because of a licence change to the latter. It remains to be seen how this one will play out
    • RPM and RPM5 (see http://www.linux.com/articles/114339)
    • A new entry: Debian is moving from glibc to eglibc.

    Some interesting analyses of the pros and cons of forking are:

    See also OpenSource.

  2. A system call for creating a new process

    The Unix way of creating new processes: when a process calls fork(2), the Kernel makes a copy of the process at that point. The system call returns separately in both of the processes. In the child process it returns 0, whereas in the parent process it returns the process ID of the child.