Trust scales to a point - once you need to scale beyond it, it's time to split and specialize.
An aftok is always founded on the basis of mutual trust between a group of individuals. But what happens if that trust is breached? Or, more commonly, what happens when you need to grow beyond the size where everyone can really know one another well enough to sustain trust relationships? In these cases, it may be time for a fork.
A fork is the condition under which an aftok splits to form two or more new projects. At the point of a fork, the log that tracks the time of each contributor to the original "parent" project is duplicated, and new aftoks are formed such that each new child aftok may begin extending their copies of the logs independently with new work. As each child aftok begins taking in revenue, it is distributed according to the same rules as before the split, so contributors on the "other side" of the fork will still continue to receive a share of revenue for the time that they've previously contributed. It is possible for an individual to contribute their time to more than one child aftok that arises from the fork, though of course not to both at the same time. Over time, the new contributions on each branch will dilute the claims of those who are no longer contributing to that branch, and the depreciation process will finally reduce their share of received revenue to nothing.
Members of an aftok may, of course, collectively choose to fork away from a single contributor; this is analogous to firing someone from a traditional corporation. Such a person however, always has the option to form a full fork on their own and become a competing aftok, and they will still continue to receive revenue. until the point at which their shares are fully depreciated.
Forks don't have to occur just for contentious reasons; they can be of mutual benefit for all the parties involved. Forking allows groups of contributors to specialize on different parts of a business as cohesive teams. Having teams with different specialties is common in traditional corporations, and hierarchy is used to enforce relationships between different teams. In an aftok, this isn't usually a great option because of the bottom-up nature of the system. Instead, it's better to have small cohesive groups interacting economically rather than face the communication and collective-decision-making challenges that come with a larger non-hierarchical organization.
Due to the nature of the work log, and the effects of dilution and depreciation on distribution of revenue shares, the economic effects of the fork are only experienced gradually by the members; in the immediate aftermath of a fork revenue distribution remains essentially unchanged until enough time has passed for the varying dilution on each branch to be observed in member revenue shares.
Just as aftoks can split using the forking mechanism, they can also merge! The merge process is just the forking process in reverse; when a merge occurs, both parent's work logs are taken into account when distributing the revenue of the unified child organization. Special rules may apply in the case that the parent organizations chose different share depreciation functions.
And, that's it! You've reached the end of the guide! If what you've read appeals to you, go here to sign up and found your own aftok!
See how to put these principles into action