Forking
By maintaining its own Apache development as an open development project, IBM avoided creating a fork. Forking occurs whenever a software project splits. While the two versions may remain entirely or partially compatible for some period of time, inevitably the unique (and now distinct) histories of each one's development will push them apart.
Forks can happen for many different reasons and may have entirely healthy consequences. A very simple piece of code may be developed by a group of programmers to do, for example, packet-switching. One half of the group may decide to follow a development tree leading toward making the simple packet-switching program into a complex database, and the other half may want to make the same program into a video-on-demand server for use in cable television systems. Such forks can occur without rancor and without any real concern for duplicative or unnecessary programming; the two future developments are so starkly different that mutual compatibility is of no concern.
Forks in more mature projects, however, are much more capable of producing undesirable results. For example, in 1993, the GNU Emacs project forked. Jamie Zawinski led a group of other developers on a line separate from that of Emacs' creator Richard Stallman and the GNU project. In part, this fork was driven by real differences as to the best course of future development for Emacs, but it also may have been the result of personality conflicts and concerns with the progress of Emacs ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access