ForkingOfOnlineCommunities

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Is it a good idea to base a wiki on the same principles as OpenSource and to make its content "free" and give everybody the RightToFork?

Contributors: AlexSchroeder ("yes"), HelmutLeitner ("no"), SunirShah ("random"), StephenGilbert ("it depends…")

Starting point

If you use a wiki to accompany OpenSource development, you will want it to follow the same rules. If you want to content to remain "free", you must implement some sort of CopyLeft. This means that you must give your users the RightToFork. We have to all agree on this.

Why might the RightToFork not be appropriate for all wikis, however? We should recommend a good license on SeedPosting.

The rest of this page takes a look at the RightToFork in the wiki context.

While reading, be aware of the two concepts used, here: We talk about the content, and we talk about the community producing this content. A fork may or may not involve both. Keep also in mind that the proponents on this page may argue for social, technical, and juridical ConflictResolution. The wiki is primarily a social system, and often we prefer the social solutions (as in SoftSecurity vs. HardSecurity).

Also note that there are different types of forks: a "full fork" where the new community uses a complete copy of the content, a "partial fork" where only a part of the content is reused and a "split", where a part of the content is removed from the old community and used as the starting point of the new community. In relation to OpenSource a "full fork" of the documentation is the obvious situation. In relation to a wiki community, a "split" of a topic may be typical.

Forking Protects the Content

Forking protects the content against hijacking by CopyrightTraps, AbsentLeaders, evil GodKings, etc. If your host suddenly turns bad, anybody can take the content and StartAgain. Without the RightToFork, the new project would have to start from scratch.

Forking protects the content against dilution from new interest groups. If a large subset of the users want to change the topic of the community, then a fork will prevent a lot of bad blood.

: In fact forking (or the right to fork) doesn't protect the content, it protects the interests of the members of the community. -- HelmutLeitner

Example: WhyClublet

WhyClublet forked the religious topics from WardsWiki at the behest of Ward himself. Some people were opposed, some were in favour, but it was forked. Not many pages were forked either, mind you, but of those that were forked, they were never permanently deleted. They are merely hanging around in the EditCopy limbo waiting for their final destruction. (In fact, I "archived" them on sunir.org during the Wiki:WikiAtTwentyThousand spring cleaning in order to encourage their deletion.) Also, the eastern philosophy pages exist in tension between the two sites — mostly because of me, of course. That story is detailed on Wiki:WhyClublet, especially the child page Wiki:EasternThoughtNecessaryToUnderstandPatterns.

The point is that a new topic emerged on one site that many people wanted to move to another site. This required the same kinds of copyright gymnastics required in a full fledged fork.

Be Nice Instead of Forking

Why don't you ask them, whether you may use content from their pages? If you are on good terms with them, they will agree, perhaps asking for a "this page was created from a authorized copy of wiki:page". Of course, taking without asking is simpler, but it seems like bad manners. Look for a social instead of a legal solution.

The problem with that is it will not work if are either no longer on good terms with the other authors, or if you can no longer determine the other authors. In those cases, the content can no longer be used in other works.

You Cannot Fork a Community

To talk about "forking" a community is wrong, because you can't fork a community. It is wrong to assume that forks are like branches in a version control system. What you can do is to fork the content and to split the community, but this does not have the same effect as the forking of software. See JargonFile:fork: "This should not be confused with a development branch, which may later be folded back into the original source code base."

There are enough examples of major forks that did in fact split the developer communities. This is a very high price to pay for a fork. Examples: Emacs vs. XEmacs, Free BSD vs. Open BSD vs. Net BSD vs. Mac OS X. But consider the alternative: strife and bad blood within the community. A fork is one of the most radical ConflictResolution strategies.

Obviously, a community has other options than only forking to accommodate different opinions and structures (see BuildInTolerance). But forbidding a fork is not the cure. You loose the other benefits of forking mentioned above without solving the problem.

Forking is Unaffordable

As explained on JargonFile:fork, forking seldom happens, exactly because of the high price on the community.

This is why the threat of forking WikiPedia is very low: No one could afford it. They can barely afford it as it stands.

Therefore, forks that happened without acknowledged justifications will just die of disinterest. Real forks only happen under dire circumstances. Forbidding them does not solve the problem.

Attracting Authors, Author Expectations

Authors give something of value to the public. Very often, they sell their thoughts, their work as books or other publications. Now, growing a wiki community, you want them to come and contribute the content to build an interesting place. Why should they do this? There are a number of answers: The wiki is an easy place to publish, they can get feedback, they can have interesting discussions. But basically, it's a TitForTat: the authors give something and they get something, and the total effect must be positive or they will retreat.

If your license forces them to to give up their copyright (RightToFork has this effect) then they have to put more value into the wiki, and the statistical chance to attract authors or contributions will be reduced. This may make the difference between a wiki living or dying.

: I do not understand this point. Can you elaborate? Certainly nobody has to "give up their copyright" — perhaps you need to describe better what you mean. -- AlexSchroeder

On the other hand, many people now expect a viral copyright for all "public" intellectual property thanks to RichardStallman's efforts and the general DotOrg boom. Consequently, you may find the reverse situation where people refuse to join your community unless it supports something like the FreeDocumentationLicense. A very vivid example of this situation is WikiPedia. Moreover, this exact same argument was used against OpenSource software projects earlier in the day and they seem to be doing fine. As always, a good campaign can change what people want.

To Keep or To Give Away

A community is … "a group of people seeking for common advantages by the means of synergy (collaboration)".

One of the easiest ways within a wiki is to build content (a form of common property). You may not be able to sell it for money, but it is still your work, your creation and you may identify with it or be proud of it (think of a pioneer village building a church). If you decide at the beginning not to accumulate this property, but to just give it away to anyone who wants to take it, this is in my opinion an absurd decision and you will reduce the chances that a community will form.

It seems as if contributing to a wiki is already a form of "giving away". That may be so, but there are different degrees of "giving", if you want to look at it this way. You can either "give" it to one wiki only (no CopyLeft). Then you incur the negative chance of somebody hijacking your contribution. Or you can "give" it to a wiki that allows forking (with CopyLeft). This makes your gift usable, no matter how the original wiki develops. Therefore, the CopyLeft increases the value of the gift.

Having copies of the gift around also has negative consequences: Redundancy (see below).

Redundancy

Any copy will increase the redundancy of the information. This makes facts harder to maintain, as there are now several places where they are recorded. We want LessRedundancy

Any copy will split the readers and decrease the chance of feedback.

Copying can also add value, however, because it is possible that content would be useful in multiple contexts.

For example, math books. There are a lot of math textbooks around, and often you will hear "this textbook has a good treatment of this but a bad treatment of that", or perhaps "we're using this one because it's more complete, but its real confusing and if you have a hard time go to the library and read that one." Now, of course, these projects are textbooks protected by "vanilla" copyrights, but assume that they were all Wikis, online, under a non-forkable license. The same situation would happen. What you would like to be able to do in this situation is to create a composite textbook, copying and pasting from two or even more different previous textbooks, selecting the clearest explanations available for each concept.

So in this situation a non-forkable license prevents these projects from being merged into a "composite" project, frustrating what would be the goal of each project; to produce a superior textbook.

There is another way out, too, to form a corporation: If the Wiki members don't retain their own copyright but give it to "the Wiki", and a few people are actually in charge of the Wiki, then those few people could authorize a merge. But see the section "Be Nice…" above.

Often the content to be copied is rather trivial. See the example about AIWiki on FreeDocumentationLicense.

At the same time, a merger might not always be in the best interest of both parties, because of different interests. See "Forking Protects…" above.

Example: WikiPedia and AIWiki

Certainly one could create a bunch of pages on AIWiki with a link to the relevant WikiPedia article, but that would serve as a very effective springboard (people would have ideas for how the content could be changed or extended, realize that their ideas are too technical for WikiPedia, and then just not post anything).

The solution to this is not to ask WikiPedia to BuildInTolerance to such an extent so as to allow groups of researchers from every conceivable field of human endeavor to have their own SubWikis within WikiPedia.

The WikiPedia could be considered a bad example for this, because WikiPediaIsNotTypical.

Comments

I think forking of communities is necessary, it's the genetic algorithm the greeks observed with the original idea of thesis and antithesis. I write corrections, comments, questions, ideas, and more into the margins of my books. Other people wouldn't write the same things into their books, but they might like to take a copy I've written into and add their own thoughts and ideas. I believe that forking is necessary to keep things from being stagnant. -- ShaeErisson

: Obviously this wiki offers an improved situation compared to your book example. You can comment and others can read and comment on your comments. Forking this wiki would in my opinion decrease the quality of this process by the redundancy of multiple copies. -- HelmutLeitner

This is not true for FreeSoftware, why should it be true for Free Books? -- AlexSchroeder.

Spaces don't have to be mutually exclusive, since that is more of a waste of time than cooperating. That is, why work at cross-purposes when you can work together? EnlargeSpace is about changing the structure of the SemanticSpace, not about changing the structure of people, even if it is necessarily motivated by people, and it will in fact change the structure of people implicitly. The trick is to use these personalized spaces to create more value as a whole; cf. LambdaMOO, wikis.

Forking is by itself value neutral. For instance, forks may be friendly, but they may also be hostile. The differences are well known. Friendly forks allow different groups to explore the code base in new directions, and then the newly discovered best practices can move between the different groups freely, and the entire group of projects continuously improve. Hostile forks on the other hand duplicate effort and socially prevent code from moving back and forth, even in some instances inciting fights when code is copied by political rivals (even if legally legitimately). This is mutual death because no one wants to join a project that is more heat than light. Sometimes a third group just forks the two projects again to start anew. e.g. FreeBSD, OpenBSD, and NetBSD? [ed: assuming I remember my BSD case history correct], and that is just more confusing. It is possible this has contributed significantly to why Linux is more popular than BSD.

Therefore, hostile forks lower overall attention, whereas amicable forks increase overall attention. The goal for all open source projects is to eliminate cases where hostile forks are felt as necessary, but without forcibly creating a monolithic project (i.e. allowing further exploration by multiple groups). Both horns waste everyone's time. (cf. RightToFork) -- SunirShah

: Yes there is a common goal of project unification, but is it healthy? Are mass projects/wikis any more desirable than smaller, less complex, and more varied ones? -- Anon

CategoryCopyright CategoryCase