Fixing up the README. Still struggling with the ending.

[?]

May 25, 2015, 11:58 PM

45QJYWN343MSN5LLXNIXZKWT7QVRVO23XQJUTU5QM24DP7GPSAZAC

Dependencies

[2] A6HKMINB Attempting to improve JSON handling.
[3] LAROLAYU WIP
[4] EZQG2APB Update task list.
[*] AXKKXBWN Initial attempt at writing down my ideas for a company based on trust.

Change contents

replacement in README.md at line 1

[3.1]→[3.2:20](∅→∅)

The 3-minute Tour

[3.1]

[3.20]

What is an Aftok?
edit in README.md at line 3

[3.38]

[3.38]

Let's talk about an idealized model of commerce: Make something that you think
other people will value. The difference between the cost of making that thing
and the price you sell it for is the amount of value that your effort has
created in the world. Divide this value by the number of hours it took you to
produce the thing, and you arrive at a good estimate for the value of your
time.

This idea of how the exchange of value should take place in an economy is
appealingly simple, and almost completely unrelated to how most of us
experience our economic participation. For the vast majority of us, the
relationship between the value that we produce and the amount we earn is almost
entirely opaque. The effect of this is that we instead use the relative demand
for our skills as a proxy for this value, but this proxy is subject to a great
deal of distortion. In the standard model, it is in the interest of every
corporation to pay less (on average) for its employees' work than the
value that they generate, so that the remaining profits may accrue to the
corporate body itself.
replacement in README.md at line 22

[3.39]→[3.39:455](∅→∅)

A quixotic company is a group of independent actors who distribute revenue
among themselves according to the amount of time they've each spent
contributing to a project. As soon as any revenue is received, it is
immediately paid out to the contributors in proportion to their contributions.
In a sense, the hours contributed to the project form the "shares" of the
company, with a caveat as will be described below.

[3.39]

[3.455]

An aftok is a new, experimental company structure that proposes a different approach.

The Essentials
--------------

An aftok is a group of individuals, working collaboratively to create a good or
service for which they wish to be paid, who distribute revenue among themselves
according to the relative amount of time each person has spent contributing to
the project. As soon as any revenue is received, it is instantaneously paid out
to the contributors in proportion to their contributions.

You'll note that nowhere in this description is there any entity equivalent to
a corporation; there is no fictional entity that owns resources or employs the
contributors. [http://aftok.com](http://aftok.com) is a service that allows
customers to compensate the creators of a product or service directly without
the need for a corporate middleman. As such, it is *revenue*, not profit, is
divided among the collaborators. That distribution is performed by a simple
algorithm which ensures that all contributors are treated fairly.

As was mentioned above, the baseline metric used to determine what share of
revenue is distributed to each contributor is based upon the amount of time
spent on the project, so we provide a simple time tracking service that can be
used by contributors to log the time that they spend working on the project.
Any hour (really, any second, but hours are a bit easier to think about) logged
is equivalent to any other hour logged by any contributor that ends at the same
moment; at a first approximation, this implies that the every individual's life
is considered to be of equal value.
replacement in README.md at line 50

[3.456]→[3.456:1030](∅→∅)

Any hour logged is equivalent to any other hour logged that ends at the same
moment; this produces a situation where the value of each individual's life is
considered to be equal, at the outset. However, it is acceptable for one
contributor to explicitly "work for" another, by either donating some of their
share of revenue to their collaborators, or by allocating time that they have
worked to another's account. In this way, a market for talent can evolve within
a company; however, all such actions are public, and at the sole discretion of
the individuals making them.

[3.456]

[3.1030]

In order to allow for differences in skill to be compensated at different
rates, we provide a mechanism that allows any contributor to compensate their
peers for their work, by either "tithing" some of their share of revenue to
their collaborators, or by allocating time that they are working to another's
account. Revenue tithes can be one-time-only occurrences, or can be scheduled
to recur whenever revenue is received. Tithes of time, however, are permanent;
once worked time has been logged to a contributor's address, it is treated as
though that contributor had been working for that period and cannot be changed.
In a traditional corporation, these sorts of tithes are made implicitly,
usually to management and stockholders, and making them is a precondition of
accepting employment. By contrast, in an aftok a market for talent
can evolve within a group, and all such tithes are explicit, public, and at
the sole discretion of the individuals making them. If someone wants to claim
that their time is worth a premium, all that they have to do is convince their
collaborators.
replacement in README.md at line 66

[3.1031]→[3.1031:1677](∅→∅)

The caveat: for numerous philosophical and practical reasons, the value of an
hour contributed is not constant. Instead, the value of an hour decays
according to a tunable function of time elapsed since the hour was logged. For
example, after 6 months from the time of the original contribution, an hour
contributed begins to decay at a rate of 2 minutes per month, such that after 5
years, the value of the hour has been completely exhausted, and when revenue is
distributed, that hour will no longer be compensated. Of course, hour-shares of
the company are also subject to constant inflation as more contributions are
continuously being made.

[3.1031]

[3.1677]

One problem that arises from the algorithm as stated up to this point is that,
over time, it would become economically impossible for new collaborators to
join a company, because the accrued time of earlier contributors would vastly
outweigh any new time contributed, and thus the new collaborator could never
reach parity with the rest of the company when revenue is distributed. For this
reason, the value of an hour contributed is not constant. Instead, the value of
an hour decays according to a tunable function of time elapsed since the hour
was logged. For example, after 6 months from the time of the original
contribution, an hour contributed may begin to depreciate at a rate of 2
minutes per month, such that after 5 years the value of the hour has been
completely exhausted and when revenue is distributed that hour will no longer
be compensated. Of course, each contributor's time-share of the company's
revenue is also subject to constant dilution as more contributions are
continuously being made.

In addition to the practical reasons for time depreciation, there is an
additional, more philosophical point to be made, which is that contributions
made in the distant past do not justify compensation in perpetuity. Companies,
and the services they provide, must change over time in order to stay relevant
and competitive. On a long enough timescale we're all manufacturers of buggy
whips and steam engineers; while people in these professions created value long
ago, in the present day their contributions have been rendered irrelevant by
progress.

At this point it's important to point out that, even though a collaborator may
cease contributing to a project (or may have forked the project, or been exiled
from the project by the other collaborators, a process that will be described
later), the compensation for their contribution up to that point does not
immediately go to zero, as it would be the case when someone stops getting paid
when they leave a traditional corporation; instead, their logged time is paid
out according to the ordinary schedule, with the combined forces of dilution
and depreciation eating away at the share of revenue they receive. The reason for
this is that, while they may no longer be permitted to contribute new work, the
value that they produced in the past must still be recognized and compensated.
For more information on this situation, see the 'Irreconcilable Differences'
section.

Making Decisions
----------------

Just as the depreciated amount of time that one has devoted to the company
(relative to that devoted by the rest of the collaborators) determines what
proportion of the revenue of the company they are awarded, it also determines
the amount of influence that person has in making decisions that affect the
company as a whole. The [http://aftok.com](http://aftok.com) platform provides a voting service
that can be used by collaborators to make collective decisions.

The voting system provided uses a range-voting model where the ratings chosen
by an individual for the options provided are weighted by their revenue
distribution percentage at the ending moment of the voting period. Only those
contributors who are currently permitted to record time to the company's logs
are allowed to vote; while 'exiled' contributors are entitled to compensation
to the value that they created, they do not have the right to influence the
company's future.

Shared Resources
----------------

As was alluded to earlier, in an aftok, there is no central entity that can be
responsible for owning property, so one of the first problems that arises is
how to obtain shared resources that are needed by the company to do its
business. Ownership of things is a privilege that should be reserved for real
flesh-and-blood people, so any resource that is needed should be either
individually owned, or, if used by all, then rented.

In order to provide an equitable means for raising money to pay for a rented
resource from among the collaborators of a company, the approach offered by
this service is that units of time (the primary unit of account within a company)
are *auctioned* to raise the money. The fundamental idea is that if someone is
contributing money to purchase a shared resource, obviously some effort of
theirs was required in the past for them to obtain the money that they are
contributing, and so in some sense the contribution of money is equivalent to a
contribution of some amount of their time. The purpose of the auction is to
determine what amount of time their monetary contribution is worth.

The process goes like this:

First, a vote must be held to determine the amount of money to be raised in a
shared resource auction; an auction involves the allocation of new logged units
of time and consequently dilutionary pressure that will be felt by all the
collaborators in the company, so it is important to obtain the consent of the
members before proceeding. In addition, a vote may be held to determine a
designee who will be responsible for renting or otherwise handling the
acquisition of the shared resource once the auction is complete.

If the vote passes (if a nonzero amount is selected by the weighted range vote)
then a Dutch auction opens. Each collaborator may then place bids, where a bid
consists of both a monetary amount and the amount of time that they expect to
receive in exchange if they win.
replacement in README.md at line 156

[3.1678]→[3.1678:2020](∅→∅)

If the company needs to rent a shared resource, the money needed to pay for
that resource may be raised from the contributors, or from others, by
auctioning hours of time that are then logged to the accounts of the
purchasers. It is not recommended that the company, as an entity, own anything;
ownership is a privilege reserved individuals.

[3.1678]

[3.2020]

When the auction closes, bids are sorted in descending order by the ratio of
currency to time expressed by each bid. Then, the top bids are accepted until
the amount of money that the auction seeks to raise has been reached. Each
winning bidder will be awarded the amount of time specified in their bid upon
payment of the monetary amount of the bid to the auction's designee. The result
of this auction process is that the dilution collectively suffered by members
of the company is minimized.
replacement in README.md at line 166

[3.2179]→[3.2179:2293](∅→∅)

the company; however, the particulars of such agreements are outside the scope
of the quixotic company structure.

[3.2179]

[3.2293]

the company; however, the particulars of such agreements are at present outside
the scope of what is addressed by the [http://aftok.com](http://aftok.com)
platform.

Irreconcilable Differences
--------------------------

In any group of people, there may come a point where someone, or some subset of
the group, decides that they simply cannot continue to work with the remainder.
In a traditional corporation, people can be fired. In an aftok, it's not quite
so simple. Fortunately, the past couple of decades of experience of the
open-source software world have provided us with an excellent model for how to
deal with such a situation when there's no fixed hierarchy of control: the
"fork."

In software, forking a project involves taking the current state of the source
code, and creating a competing project using that source as a base. The aftok
structure permits an analogous process.

When a schism arises, and there is no possible reconciliation the entire
company may split into two or more subsets of the original collaborators. In
the case of such a fork, the parent company must essentially dissolve, but this
process is facilitated by the fact that the company owns no property, and any
leases of shared resources may be termintated and reestablished by the child
companies. At the point of a fork, the log that tracks the time of each
contributor is duplicated, and two or more new companies are formed such that
each new child company may begin extending their logs independently. As each
child company begins taking in revenue, it is distributed according to the
same rules as before the split; it is even possible, for example, for an
individual to contribute their time to more than one child company that arises
from the fork. Over time, the new contributions on either side of the fork
will dilute the claims of those who are no longer contributing, and the
depreciation process will finally reduce their interest in received revenue
to nothing.
replacement in README.md at line 201

[3.2294]→[3.2294:2350](∅→∅)

What Is a Quixotic Company?
===========================

[3.2294]

[3.2350]

A group may, of course, choose to fork away from a single contributor; this is
analogous to firing someone from a traditional corporation. An individual who
has been forked away from in this fashion is said to have been exiled; they do,
however, always have the option to form a full fork on their own and become
a competing company.
replacement in README.md at line 207

[3.2351]→[3.2351:2698](∅→∅)

The idea of the quixotic company arose out of my experience in the open-source
community. Something we have learned from the past couple of decades of
experimentation with open-source projects is that a group of motivated
individuals, working in their own individual interest in a framework of
collaboration and trust, can achieve amazing things.

[3.2351]

[3.2698]

Aftok Philosophy
================
edit in README.md at line 210

[3.2699]

[3.2699]

The idea of the aftok arose out of my experience in the open-source community.
Something we have learned from the past couple of decades of experimentation
with open-source projects is that a group of motivated individuals, working in
their own individual interest in a framework of collaboration and trust, can
achieve amazing things.
replacement in README.md at line 223

[3.3234]→[3.3234:3531](∅→∅)

dissatisfaction that people feel when confronted with inequality; the simple
fact is that hierarchical structures are relatively stable. However, as the
open-source software development world has shown us, this sort of hierarchy
is not the only kind of organization that can create great things.

[3.3234]

[3.3531]

dissatisfaction that people feel when confronted with inequality; a simpler
explanation of their popularity is that hierarchical structures are
relatively stable. However, as the open-source software development world has
shown us, hierarchies are not the only kind of organizational structures that
can lead to the creation of great things.
replacement in README.md at line 230

[3.3608]→[3.3608:3688](∅→∅)

that a great deal of open-source work is paid for by conventional corporations,

[3.3608]

[3.3688]

that a great deal of open-source work is paid for by traditional corporations,
replacement in README.md at line 232

[3.3759]→[3.3759:3966](∅→∅)

contributor to an open-source project. The quixotic company is intended to
provide the minimal structure that is needed for a group of individuals to
collaborate on a project for which they hope to be paid.

[3.3759]

[3.3966]

contributor to an open-source project. The aftok is designed as minimal
structure that is needed for a group of individuals to collaborate on a project
for which they hope to be paid.

More importantly, however, the Quixotic company structure is designed to
maximize individual freedom within the context of performing paid,
collaborative work.
replacement in README.md at line 241

[3.3985]→[3.3985:4003](∅→∅)

=================

[3.3985]

[3.4003]

-----------------
replacement in README.md at line 247

[3.4316]→[3.4316:4577](∅→∅)

an hour to be worth enough to maintain a certain lifestyle and yet not be so much
that nobody will be willing to pay it. Yet, the question has always remained with
me: what is the actual value, in terms of revenue, of the effort of the hours that
I've put in?

[3.4316]

[3.4577]

an hour to be worth enough to maintain a certain lifestyle and yet not be so
much that nobody will be willing to pay it. Yet, the question has always
remained with me: what is the actual value, in terms of revenue, of the effort
of the hours that I've put in?
replacement in README.md at line 257

[3.4895]→[3.4895:4986](∅→∅)

The only answer that I can come up with is this. We should begin with an idea of equality.

[3.4895]

[3.4986]

The only answer that I can come up with is this. We should begin with an idea
of equality. However, it's undeniable that the value one person can create
within a given period of time will differ from the value created by another, and
a mechanism must be provided to allow this difference to be recognized and
compensated. Since there is no central authority to make compensation decisions,
it is up to the individual contributors to honestly assess and compensate their
peers. This brings us to the next, and perhaps most important, point.
replacement in README.md at line 265

[3.4987]→[3.4987:5007](∅→∅)

Resources
=========

[3.4987]

[3.5007]

The Value of Trust
------------------
edit in README.md at line 268

[3.5008]

[3.5008]

The aftok concept grew out of a simple question: what would be the best way to
structure a for-profit organization in which all of the members of that
organization trusted one another?
replacement in README.md at line 272

[3.5009]→[3.5009:5023](∅→∅)

Tithes
======

[3.5009]

[3.5023]

I believe that in general, the ways in which corporations strive to limit the
potential impact of malicious actors also act to inhibit individual creativity
and productivity. Hierarchies of control can ensure that outcomes desired by
those at the top are achieved, even when those goals are poor or shortsighted.
The aftok ideal seeks another way.
replacement in README.md at line 278

[3.5024]→[3.5024:5046](∅→∅)

Investment
==========

[3.5024]

[3.5046]

In my experience, a group of motivated and skilled individuals working toward a
common goal in an environment of shared trust requires no, and indeed is
inhibited by, a hierarchy of control. If you feel that you can trust your
collaborators, you should be able to trust their judgment as to what they
should be working on, and that their perspective, while perhaps distinct from
yours, is as valid as your own. If you don't trust someone to this degree, you
simply should not work with them; if you choose to work with someone whom you
feel that you may need to control, you're setting yourself up for failure
anyway. The most important of the fictional (but true) [Celine's
Laws](http://en.wikipedia.org/wiki/Celine%27s_laws) is "Communication is only
possible between equals." Wherever communication is inhibited in business,
whether by secrecy (of salary information, for example) hierarchy of control
(with the thread of firing or punishment available as a goad) or even lack of
access (can you really interrupt your CEO whenever you want?) it encourages
people to behave in cynical, rather than enlightened, self-interest. This
cynicism is the sort that causes people to reserve their best work for projects
where they have the freedom of self-determination.

Any question related to how you should behave with respect to others in your
company comes down to a simple question: do you trust them or not? If you trust
them, then trust their judgment and in their good intentions; there is no need
to attempt to control them, only perhaps to convince them or find common ground
when you disagree.
edit in README.md at line 302

[3.5047]

It's possible, of course, that you'll be wrong. That you've misplaced your
trust, and that you'll have to change your mind and fork away from them. This
risk is not unique to an aftok. Sometimes, there can even be people
whom you trust and even admire greatly, but just don't want to work with, and
this is okay. A virtue of the aftok structure is that the damage that can be
done by an incompetent or even malicious actor is limited by the very fact that
there is no centralized entity that can own assets, or even control revenue in
any but the most temporary fashion. Fraud is possible on a limited scale
(someone could overstate the hours that they've worked), but this situation is
equally likely to occur in a traditional corporation, and the scale upon which
fraud of other sorts can be perpetrated is greatly reduced.

How Things Should Work
----------------------

Given all of this, we can construct a pretty good picture of what working in
an aftok should look like, at least ideally.

... to be continued.
replacement in TASKS.md at line 32

[2.112]→[2.112:226](∅→∅)

# * Timeline
# * Amend Event
# * Amend operations targeting events older than <commit_delay hours> fail.

[2.112]

[2.226]

* Timeline
* Amend Event
* Amend operations targeting events older than <commit_delay hours> fail.
file addition: features.md (----------)

[6.2]

Implemented
===========

* Time-interest (with depreciation) based revenue sharing.
* Time-interest (with depreciation) based voting.

Planned
=======

* Blockchain-verified update of payout addresses.
* Resource funding auctions.
* Support for forking of companies.
* Software license designed to enforce payout schedule
across forks.
* Alternative voting mechanisms.
* Scriptable/alternate depreciation functions.

Prospective
===========

* Scriptable resource
* Loans to new contributors secured by time accrued
* For OSS projects, logs attached to pull requests; if the request is merged,
the time becomes valid.
file addition: notes.md (----------)

[6.2]

Aftok
=====

> *"I have to figure out how to balance the work I can make a living on with the
> work I can’t, because the work I can’t make a living on is more important."*
> -- [Meredith L. Patterson](https://medium.com/message/how-i-explained-heartbleed-to-my-therapist-4c1dbcbe1099)

It's impossible to make a living writing open-source software. Certainly, there
are exceptions; a few companies eke out a relatively spare existence selling
"enterprise support" licenses for free software, and lots of people employed by
private companies contribute to open-source products on time paid for by their
employer. Nonetheless, a great deal of the open-source software that developed
is a labor of love. OSS developers are artists, but they're fortunate that
their art is in a medium that also, at present, makes it easy enough to find
paid work that few of us have to starve while making our art.

Unlike many other arts (excepting music) open-source software development is
frequently a deeply collaborative endeavor.

* Trust cannot be imposed, it can only be grown.
* Last section needs to be more positive, deemphasize risk.