[Home]RightToFork

MeatballWiki | RecentChanges | Random Page | Indices | Categories
In the strictest sense, a fork happens any time development proceeds along two or more different paths. The right to fork is inherent in the [fundamental software freedoms] common to all open source software. A new fork in development does not start from scratch, but continues to build on the resources of the project available up until the time of the fork.

The JargonFile:forked entry is accurate, but not complete, in describing the influence of the right to fork on the social structure of a software project's user and developer communities.

Forking isn't unique to free software projects, but also takes place in non-profit associations and political and religious movements. What happens is that a group of voluntary members walk away to form a new community. They cannot bring physical property with them, but the fork implies this sacrifice. Some startup companies, where physical property is not as important as management culture, are also subject to forks or spin offs. What's unique to free software projects in this perspective is the lack of physical property, so the only sacrifice is the loss of connection with the members left behind. Managing such projects to avoid forks requires more openess and tolerance, since the loss implied by a fork is smaller. However, even in free software projects there are some things that resemble physical property (in the sense that you have to leave it behind when you fork):

Here is another essay: [Fear of Forking, original version (corrected and annotated)]

The right to fork, when invoked privately or on a small scale, carries no controversy. Anyone deploying a piece of open source software may make any patch s/he wants, and may publish either the patches alone or the entire body of patched code for others evaluation and use. The lack of controversy stems from the fact that the parameters of copyleft software development contain built-in provisions for healing or resolving a fork--if the code from a separate branch is public, it can be brought into the main development branch at any time. Since copyleft software licenses require that code be made available for any software which is distributed, the condition of code availability (for license-compliant use) is always met.

Acrimony accompanies invocation of the right to fork only when a large portion of the developer community looks to follow a development branch maintained by anyone other than the currently recognized BenevolentDictator for that project. Such a move signals the rejection of the benevolent dictator's role in the project and perhaps the annointing of a new one.

The right to fork guards the project against single points of failure. For example, the right to fork is a powerful check upon the influence of the benevolent dictator on the project's work, and through the project's work, on the community itself. The presence of this right provides strong assurance for any participant in the community to contribute his/her efforts to the community, and lack of it calls into question the open nature of a BenevolentDictator's leadership of that community.

The right to fork also bears upon the "what if the project leader gets hit by a bus" question. Even if the project leader is competent, engaged, and respected, no one lives forever. Amicable exercise of the right to fork (as in the establishment of a port to a new architecture or another experimental venture) provides a venue in which successors to the benevolent dictator might gain crucial experience. (See also EnlargeSpace) A body of such people with such experience may be able to take on responsibilities that would otherwise fall to the benevolent dictator alone, providing some buffering for the benevolent dictator and working against burn out.

Independently of the project leader's role, the right to fork benefits the project in other ways. It makes the establishment of mirrors and backups trivial. In the case of a software project, this insulates the community from hardware failure, network failure, or unfriendly shifts in local legal climates.

Some say the right to fork is a destructive tool, that it should be put on the same shelf as civil war, and that it's far easier to exercise your RightToLeave.

Others recognize that a fork is mostly acrimonious in cases where there has been at least a perceived failure of leadership. Amicable forks can happen when there is an explicit recognition of sufficiently dissimilar goals--witness the spawning of multiple wiki sites from WardsWiki. Both the RightToLeave and the RightToFork impose costs that can largely be difficult to quantify, as in a DollarAuction, so not everyone will agree as to which is easier, or even that ease (or fun or what-have-you) is a primary criterion for deciding a course of action.

Contrast the RightToInclude.

Forking isn't a simple institutional democratic process where one party may impeach another. It's really democratic; down to the mob. When you fork, you really fork. There are now two paths that any user or contributory developer may choose, and thus the available resources are split. Plus, there is a tax now extracted in the ways of bitterness and resentment. Since many people contribute to FreeSoftware because it is fun, if the project is no longer fun but vile, many will no longer contribute. Indeed, those who haven't exercised their RightToLeave after a bitter fork, are likely hanging around because their emotional attachment is too strong. Without a check from those who don't take the project too seriously, the rift will grow and the fun factor will shrink unabated.

See ForkingOfOnlineCommunities, for more about social aspects.

Example: Sourceforge

More recently, due to the increasing reliance on SourceForge to organize FreeSoftware projects, SourceForge has growing power over what it may or may not allow. Forking from SourceForge remains difficult, as things like the bug tracking database don't extract so easily. If SourceForge just shut down, or locked out non-paying users, many would be left stranded. See Advogato:article/378.html. The RightToFork is technically hindered, as is the lesson by CodeAndOtherLawsOfCyberspace.

This is one of the reasons the Savannah project was started at http://savannah.gnu.org/. With SourceForge moving to proprietary software, it gets increasingly difficult to fork from SourceForge. In order to prevent dependencies on a single company, certain parties such as the FSF Europe have started to spread the word: It may be time to pull your projects from SourceForge and move elsewhere. Savannah is based on SourceForge code and the maintainers are trying to package the Savannah software as a Debian package... Thus, they are trying to build the RightToFork right into the software.

Example: Emacs Wiki

The EmacsWiki licencing terms and the availability of the current page database for download give all users the RightToFork.

Example: Censorware.org

One of the more famous examples where the RightToFork was at first denied, then created, then muddied is The Case of the Censorware Project vs. Michael Sims [1]. If the site was mirrored (and thus forked), Michael would not have had the power over the project he did.

This one of the reasons why the RightToFork or some other rule is important:

Example: MeatballWiki

See MeatballIsNotFree, CompilationCopyright for discussion of (amongst other things) JoeAnderson's (aka NameWithheld?) FermentWiki - a somewhat fork of MeatballWiki.

CategoryCase CategoryCopyright CategoryIdentity CategorySoftSecurity

is this really CategoryIdentity? I always thought of CategoryIdentity being the identity of an individual, not the identity of the community. we have a bunch of categories dealing with communities. if they don't suffice, how about creating a CategoryCommunityIdentity? or something like that? -- BayleShanks

Go ahead, if you'd like, and set that additional category up. In my view, individual identity is strongly intertwined with group identity, especially when one is talking about groups whose participant base is wholly self-selected: Both "who are we" as well as "who am I" or even "who the hell do you think you are" ;-)

Snipped from a comment on CopyLeft...

"Another option, much ignored or downplayed in Sunir's widely expressed fear and loathing of forking,..." --anon. (though not really)

I don't fear or loathe forks in general. I'm not insane. I wrote parts of this page, after all. I know when forking is a good thing, such as an option to EnlargeSpace. I loathe and fear cryptonauts who have no empathy and cannot deal with social problems, so they run away from the people they have problems with by forking. Or, alternatively, they are so obnoxious, they force people to run away and fork. Sometimes divorce is necessary, but I still think it's a last resort, not a natural option to ConflictResolution. It's certainly an extremely expensive solution. It bothers me that it's considered "conservative" to have the state suggest alternative resolutions to marital conflict other than divorce. Often divorce could have been prevented if the root problem was caught and fixed earlier on. Similarly with online communities. e.g. Why fork if you can replace the obnoxious GodKing? Why fork if you can open the stagnant source repository to enthusiastic developers? Maybe I'm just too Confucian.

Of course, I recognize that I am also a stubborn bastard, and that has "forced" (or at least motivated) our not-so-anonymous equally stubborn bastard friend here to "fork" MeatballWiki, though I think things on the Internet move too quickly. It was already in our third year that we had this problem. France was still chopping heads at this point in their Revolution. We can only sort out the tough problems with time and with hope. -- SunirShah

Trying to generalize the concept, is not the RightToFork quite similar to political RightToSecession? ? -- magius

No, because (over the people itself) secession fights over some finite resource that has to be split, whereas forking only fights over the people (and therefore the vision). Some forks try to steal the name of their mother project and then sully it, however, so that can create tension. The name is a finite resource as there is only the one name. -- SunirShah

The right to fork also bears upon the "what if the project leader gets hit by a bus" question. -- VoiceOfMeatball?

In other organizational contexts, leaders train successors. There are known paths where potential leaders gain skills on sub-projects. Component-based delegation would seem like a better way to train leaders than wholesale forking. -- AdinaLevin

Re: "whereas forking only fights over the people" -- People aren't entirely a finite resource. One person (or one group of people) can work on multiple projects at once; some may choose to work on both the fork and the parent at the same time. It's possible. Perhaps a better way to put this would be that forking forces the related projects to compete for man-hours, because essentially time is the only truly finite resource. -- DzCeph?

A right to fork is stupid. The virtue of wikis is their movement towards consensus, so absent in other communication mediums. Right to fork simply sacrifices this virtue in the interests of 'community'. It is much better to achieve consensus through FactionalTruth?, thus solving both the social and the process problems. --anon

Do you have any evidence of the efficacy of this "factional truth" in managing strong disputes to back up your claim that forking is "stupid"? What, indeed, do you mean by it? Is it connected to NeutralPointOfView? -- ChrisPurcell

CategoryManagement CategoryCopyright

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: