Overview

This document describes a governance/economic model for mission-oriented distributed organizations offering services in the marketplace.

It values pro-bono, care and market work with complementary metrics and doles out payment accordingly. The purpose is to extract people from the capitalist marketplace so they can use their unique talents to do fulfilling, social and environmentally meaningful work. The document prototypes a governance model fit for digital labor and applies it concretely to an existing organization: the P2P translation collective Guerrilla Translation which is, in turn, embedded into a larger proto-organization called the Commons Media Collective.

It is a substantially developed fork of the Better Means Open Enterprise Governance Model (OEGM). The adaptations have been made to:

bypass the original model’s start-up/for profit oriented lingo
fit the needs and ideals of Open Cooperativism and Open Value Networks,
benefit, commons-oriented market entities self sustain their social vision. while addressing their specific requirements and allow for future modifications.

An OVN Coop is a equipotential, commons-oriented and community-based organization. Not all Open Coops are OVN’s and not OVN’s are Open Coops. What we offer here an opt-in engagement model: this means that anyone who is participating in CMC as a member or contributer will have their work valued, and will be expected to participate in the decision making process. Decisions and control are shared, based on contribution and peer review.

This model outlines the responsibilities of different roles within the organization by allowing its stewardship to be held by those who have demonstrated willingness and invested personal effort participating in its goals. By endowing those who have offered the greatest demonstrated investment with the most decision-making responsibility and influence, the strategic development of the organization is entrusted to those with the greatest stake in the outcome of those decisions. Nothing is ever foolproof, but this modified model serves as our intention to protect and provide for those who have participated in building our strong foundation.

To see how we envision this in practice, we’ll be using Guerrilla Translation as a showcase example, but it’s important to stress that the model is designed to be useful to other organizations, whether they’re part of the Commons Media Collective, or independent from it altogether.

Want to comment? For general comments, use the discussion page. For in-text comments, corrections, etc, use this colaborative document.

The Open Cooperative Model in Guerrilla Translation

TL,DR: In Guerrilla Translation, members undertake both pro-bono and agency translation/editing work. Both types of work are accounted for in internal credits (1 credit = 1 Euro). Once a month, GT’s account is distributed: 75% of holdings goes to fulfil each members agency/livelihood credits queue, 25% goes to fulfil the pro bono/love queue.

The following example is a simplified explanation of how the model works. We’ll get into the nitty-gritty and open questions in later sections.

Guerrilla Translation (GT) begun its life as an activist translation collective. Guerrilla Translators are politicised, conscious translators. Their motivation? To create a plurilingual knowledge Commons, accessed through GT’s websites (English and Spanish so far). But it is also a translation/language agency offering a series of services. The governance model is what ties these two facets together.

What this looks like in practice

So “Jill the Guerrilla Translator” chooses an article to be translated. Maybe she’s proposed it, or maybe she’s picked it up from a common-pool of to-be-translated material. She then contacts the author to let her know GT is going to translate and publish it, ask permission if necessary etc.

The thing to keep in mind is that this will be a pro-bono translation. Jill will work on it with “María” a copyeditor and “Deb”, who’ll take care of the web formatting and social media promotion of the article.

The article is 1000 words long. This wordcount is then processed through GT’s internal credits system. This means that this Pro-bono translation is valued a 0,16 credits per word. Once the translation is finished, 160 Love credits (LCs, for this is what they're called) have been created. This is how they are split:

80 to the translator (Jill)
40 to the editor (María)
10 pre production (Jill, as she contacted the author)
20 formatting (Deb)
10 post production (Deb, as she’s doing social media, etc)

So, let’s imagine that this is the first time that Jill, Maria and Deb have done a pro-bono projectfor GT. Once the project is accounted for, their respective pro-bono piggy banks look like this.

Jill has accrued 90 Love Credits
María has accrued 40 LCs
Deb has accrued 30 LCs

A week has passed an an author or client wants to contract GT to translate an article. This is seen as livelihood work. The material is chosen by the client, the deadline negotiated with the collective. Coincidentally, the text to be translated is also 1000 words long. Amazing! GT’s agency side uses a sliding scale for prices. This client is a sufficiently funded small NGO, so the price quoted in 0,12 € per word and the the team will be Jill (as a translator) and María as editor (bear in mind that, for this example, there is no web formatting to be done). Once the translation is completed the client owes GT 120 €. Now, these will not be paid directly to Jill and María, but are accrued as Livelihood Credits (LHs) going into separate piggy banks:

Jill has accrued 80 Livelihood Credits
María has accrued 40 Livelihood Credits

For the sake of simplicity, we’ll assume that this is the only pro bono and agency work done in the collective’s history. It's getting toward the end of the month and the Guerilla Translators are ready to distribute! There are exactly 120 euros in the bank account. This is how they will be distributed:

74% of the funds will fulfil Livelihood credits.
25% will fulfil pro-bono credits
1% is held in the bank (ice cream fund or, basically,money left in the back to keep the account alive).

These percentages have been chosen to offset time for paid gigs with the vital pro-bono side (AKA: "The Heart of Guerrilla Translation". No pro-bono, no love!). So, given that we have 160 € to dole out, we'll split them like so:

The Livelihood Stream receives 88,80 €
The Love Stream receives 30 €
The Ice cream fund keeps 1,20 €. Take that, bankers!

This is now divided among the member's piggy banks in the following way:

In the Livelihood Stream Jill holds 67% of the "shares" (80 credits of a 120 total), while María has 33% (40 credits of a 120 total). So out of 88,80 € allocated for the Livelihood Stream Jill will receive 59,50 €. María receives 29,30 €.

In the Love Stream Jill holds 56% of the shares (90 credits of 160 total). María has 25% (40 out of 160) and Deb has 19% (30 out of 160). So, out of 30 € allocated for Love Jill will receive 16,80 €, María 7,50 € € and Deb 5,70 €.

All added up, this is the money that gets paid to the three active members:

Jill gets 76,30 €
María gets 36,80 €
Deb gets 5,70 €

This totals 118.80 €, remember that 1.20 remaining is the Ice Cream fund. More on that later.

An exampleamong many

This is one situation. Another month María may have done a lot more editing work (which takes less time). Deb may have done more carework (more on that later) in both the Love and Livelihood streams. New people may have come in, maybe there's been a windfall! The model can account for all those possibilities, and more, while also being dynamic and adaptable to changing circumstances. It's a "Team Human" mode, where the technology is kept flexible and updated to serve the qualitative experiences of the collective, not just the measurable ones.

The secret life of Livelihood, Love and other credits

As you may have noticed, if 1 love credit equals 1 euro, in the example above we've only paid down 30 credits (25%) in Euros. As 160 Love credits were created with the pro-bono translation this still leaves 130 which haven't been paid in money. This last part (money transferred to individual's accounts) is what we call divested credits, ie: they've been paid down. The unpaid Love credits are considered Invested credits: active credits that have yet to be paid. If you think about it on a month by month basis 75% of Love credits will be "invested" rather than paid. In essence, the coop has a debt with its own pro-bono stream which will be paid back in a rolling basis.

Also, maybe the client that owes the 120 € at the end of the month hasn't paid and we can't divest those credits into Euros? In that case they'd be "invested" until there are funds in the account.

These are some of the types of credits handled in Guerrilla Translation. "Why so many? So confusing!" We get it, but complexity allows for dynamism and nuance. We'll get into the various types of credit and their functions in a section below. For now, it's important to make clear that the total amount of credits you have accumulated (both divested, invested... the lot) accrue to give you G-chi. G-chi reflects your investment in the organization, through paying work and sweat equity and directly informs its governance. The more G-chi you have, the more it is understood that you have poured your soul into the collective and will be affected by its health. More G-chi means more influence and decision making power within the collective's governance.

Why have we chosen this model?

Imagine that María is single mother with two kids to take care of. She wants to do socially useful work, but her material realities don't allow her that privilege. By working with Guerrilla Translation she a) Gets agency work for causes that matter and b) is not "losing" income by doing pro-bono work - ie, translations that wouldn't get funded otherwise, but should still be translated. In fact, she could spend all of her time just doing agency/livelihood work, and it would still benefit the pro-bono/love side and vice versa. The model addresses the possibility of internal competition for "paid work" overshadowing the social/activist mission of the collective. In short, contributing to the Commons also makes your livehood more resilient and, in turn, you make the Commons more resilient by creating new commons and facilitating communications.

The Commons-Oriented Open Cooperative Governance Model in detail

After this overview of how the model works, we will now break down its components in more details, as applied to Guerilla Translation. We will be covering:

Roles and responsibilities
Decision making processes
Credits contribution and tracking

Roles and responsibilities (in ascending order of participation)

There are various levels of engagements within the collective. It has, in fact, designed to be porous with the main distinction being "casual" and "committed" relationships, (think of dating). In short, casual" relationships function more like a commons-based peer production project, such as Wikipedia, Firefox or the VLC video player. Contributions are permissionless and validated after the fact. Everybody is welcome to contribute but translations will only be published if there's an editor available and there is no agency work or pro-bono payments doled out to casual members (although pro bono work is accounted, maybe they'll become committed further down the line).

Committed relationship work more like a traditional Commons: clearly established boundaries, governance protocols and accountability. This also makes more akin to a Coop: the members watch out for each other and are dependent on their shared trust. Committed members are worker-owners of the agency side of GT (think of it as their day job) while assuming the responsibility of upkeeping the pro-bono/commons-producing side.

UP TO HERE; TEXT BELOW NEEDS TO BE EDITED

Supporters

We will refer to individuals who have neither been tested for hands-on participation within CMC as “Supporters”. A supporter helps ensure that the collective (CMC) succeeds in accomplishing its mission while remaining true to its values.

Supporter contributions could include (but are not limited to):

Evangelizing about the collective (e.g., posting links to our work on social media,word-of-mouth awareness raising, etc.)
Providing feedback: informing the organization of strengths and weaknesses from a new supporter's perspective, which will help to keep us accountable to our mission and values.
Providing moral support, including simple acknowledgement (a ‘thank you’ goes a long way).
Participating in open discussions: commenting on Work Items, and in the forums
Supporting the collective monetarily: This includes donations, Patreon supporters, funders etc.

Supporters can engage with Guerrilla Translation through it'

Workstream dashboards. They can start (or join) any open Work Item.

In addition to starting and joining Work Items, users can use the dashboard to vote in the following ways:

prioritizing existing Work Items
voting on new ideas (agree/disagree)
estimating the effort for suggested Work Items
accepting completed Work Items (accept/reject)

All these votes are non-binding (see below)

Supporterss who continue to engage with the enterprise and its community will often become more and more involved. Such users may find themselves becoming Contributors. Once a supporter has worked on a Work Item that has been completed and accepted by the community, they are automatically considered a Contributor.

Contributors

Contributors are supporters who have completed work in an enterprise. Any supporter can become a Contributor .

Contributors are eligible to be nominated for Membership.

As Contributors gain experience and familiarity with the enterprise, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for Membership, as described in the next section.

Members

Members are Contributors who have shown that they are committed to the continued development of the enterprise through ongoing engagement with the enterprise and its community.

Any Contributor can become a Member; there are no special requirements, other than to have shown a willingness and ability to participate in the enterprise as a team player. Typically, a potential Member will need to show that they have an understanding of the enterprise, its objectives and its strategy. Most importantly, they need to demonstrate that they are aligned with the enterprise’s core principles and values. They will also have provided valuable contributions to the enterprise over a period of time.

A Contributor can be nominated for Membership by any existing Member. Once they have been nominated, there will be a vote by the Core Team (see below). Once the vote has been held, the aggregated voting results are published on the public forum.

Nominees may decline their appointment as a Member. However, this is unusual, as the enterprise does not expect any specific time or resource commitment from its Members. The intention behind the role of Member is to allow people to contribute to the enterprise more easily, not to tie them in to the enterprise in any formal way.

By the time a Contributor is invited to become a Member, they will have been guided through the use of the enterprise’s various tools as a supporter and then as a Contributor.

In addition to their actions as Contributors, Members will also find themselves doing one or more of the following:

nominating Contributors for Membership
voting on Core Team Membership (see below)

Also Members’ votes are binding.

It is important to recognize that Membership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the Core Team (see next section) in extreme circumstances. However, under normal circumstances Membership exists for as long as the Member wishes to continue engaging with the enterprise.

A Member who shows an above-average level of contribution to the enterprise, particularly with respect to its strategic direction and long-term health, may be nominated to become a Member of the Core Team. This role is described in the next section.

Core Team

The Core Team consists of those individuals identified as ‘enterprise representatives’. The Core Team has additional responsibilities over and above those of a Member. These responsibilities ensure the smooth running of the enterprise. Core Team Members are expected to participate in strategic planning, approve changes to the governance model, and formally represent the enterprise to the outside world. First and foremost, they are the guardians and keepers of the enterprise’s principles and values, and are accountable to all stakeholders.

Core Team Members do not have significant authority over other Members of the community, although it is the Core Team that votes new Members in. In addition to their actions as Members, Core Team Members will also find themselves doing one or more of the following:

voting on nominated Members
voting on changes to the governance model
nominating Members to the Core Team

Membership of the Core Team is by invitation from the existing Core Team Members. A nomination will result in discussion and then a vote by existing Members of the enterprise. Core Team Membership votes are subject to consensus approval (see below) of enterprise Members.

Decision making process

Decisions about the future of the enterprise are made through discussion by the entire community, from the newest supporter to the most experienced Core Team Member. All non-sensitive project management discussion takes place in public Workstream dashboards and forums. Occasionally, sensitive discussion occurs in a private Workstream.

In order to ensure that the enterprise is not bogged down by endless discussion and continual voting, the enterprise operates a policy of lazy majority. This allows the majority of decisions to be made without resorting to a formal vote, and keeps the work agile and red-tape free.

The Process

Decision making typically involves the following steps: 1. Proposal 2. Discussion 3. Vote 4. Decision

Anyone can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should add the idea to the appropriate Workstream dashboard or forum (work-item ideas go in the dashboard, big-picture strategy is discussed in the forums). This will prompt a review and discussion of the idea. The goal of this review and discussion is to gain approval for the contribution.

The Dashboard and the mechanism of Motions allow for work-items and ideas to be voted upon by the community. However different level of voting and approval are needed depending on the situation. In general, as long as nobody explicitly opposes a proposal, it is recognized as having the support of the community. This is called lazy majority – that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal, and those that showed up to vote determine the direction of the work.

Lazy majority

Lazy majority is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with nothing to add to a proposal need not spend time stating their position, and others need not spend time reviewing it. This section describes how a vote is conducted. Section 3.4 discusses when a vote is needed.

For lazy majority to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.

If a formal vote on a proposal is called, all users may express an opinion and vote.

There are 4 types of votes:

‘agree’: agrees that the action should move forward
‘disagree’: disagree but will not oppose the action’s going forward
‘block’: opposes the action’s going forward and must propose an alternative action to address the issue (or a justification for not addressing the issue)
‘neutral’: indicates that attention has been given to the action but abstaining from voting one way or another

Another way to abstain from the vote is for participants to simply not participate. However, it is more helpful to cast a ‘neutral’ vote to abstain, since this allows the team to gauge the general feeling of the community if the proposal should be controversial.

The entire community, from interested supporterto the most active Core Team Member, has a vote. The enterprise encourages everyone to express their opinions in all discussion and all votes. However, only Members of the enterprise (as defined above) and/or Core Team Members have binding votes for the purposes of decision making. It is therefore their responsibility to ensure that the opinions of the entire community are considered. While only Members and Core Team Members have a binding vote, a well-justified ‘block’ from a non-Member must be considered by the community, and if appropriate, supported by a binding ‘block’.

A ‘block’, when cast by a Member or Core Team Member, essentially becomes a ‘veto’.

When a vote receives a ‘block’, it is the responsibility of the community as a whole to address the objection. Such discussion will continue until the objection is either rescinded, overruled (in the case of a non-binding block) or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the Core Team will decide the forward course of action.

In summary:

Those who don’t agree with the proposal and feel it would be detrimental to the enterprise if pursued should vote ‘block’. However, they will be expected to submit and defend a counter-proposal.
Those who don’t agree, don’t find it detrimental, and don’t have a better idea should vote ‘disagree’.
Those who agree should vote ‘agree’.
Those who do not care either way or who find themselves on the fence should vote ‘neutral’.

Type of approval

Different actions require different types of approval, ranging from lazy majority to a majority decision by the Core Team. These are summarized below. The next section describes which type of approval should be used in common situations.

Lazy majority: 72 hours

A lazy majority vote requires more binding ‘agree’ votes than binding ‘disagree’ votes and no vetoes (binding ‘block’ votes). Once 72 hours have passed, the decision moves in the direction of the majority. Naturally if an actual majority of Members vote before the 72 hours are up, the decision moves in that direction immediately.

Sometimes a lazy majority is tied with a vote threshold. This allows for decisions to be made quicker than 72 hours if enough Members vote. If the vote threshold is reached before the 72 hours are up, the decision moves in the direction of the majority.

Unanimous consensus: 120 hours

All of the binding votes that are cast are to be ‘agree’ and there can be no ‘disagree’ votes or vetoes (binding ‘block’ votes)

Credit majority

Some strategic actions are decided by giving each credit-holder 1 vote per credit; Such actions typically affect the foundation of the project (e.g. adopting a new governance model)

When is a vote required?

Every effort is made to allow the majority of decisions to be taken through lazy consensus. That is, simply stating one’s intentions is assumed to be enough to proceed, unless an objection is raised. Activities that require more control are taken through lazy majority, which is still informal enough for team to stay agile.

However, some activities require a more formal approval process in order to ensure the health and cohesiveness of the enterprise.

This section identifies which type of vote should be called when:

Work Item moving to open queue and Work Item acceptance is dependent on the estimated value of that item:

o 0-1 points: Lazy majority of all Members, vote threshold: 1

o 2-4 points: Lazy majority of all Members, vote threshold: 2

o 5-6 points: Lazy majority of all Members, vote threshold: 3

New Workstream: Lazy majority of all Members
New Member: Unanimous consensus of Core Team
Member removal: Unanimous consensus of Core Team
New Core Team Member: Unanimous consensus of Members
Core Team Member removal: Unanimous consensus of Members
Governance model change: Credit majority
Legal structure changes: Credit majority

Anomaly: Estimation is done by lazy averaging: Any Member can estimate a Work Item that is new or open. Estimation is closed once the item is in progress.

Credits: Contribution Tracking

XXX ADD INFO FROM HERE: [1]

Credits offer an exciting new way of tracking contribution that can be utilized as a compensation system or merely a contribution tracking system. The Credits module is an OPTIONAL module of the BetterMeans platform, however we believe it is a central and important module to the Open Enterprise Governance Model. Throughout this section, we will describe this system with the assumption that it is being used as the form of compensation for work, however know that in application is can be used however the team chooses to.

Credits

Credits are the measurement by which contribution is tracked. A Credit typically means $1 in compensation. Therefore if an item is estimated at 100 credits, and a person completes the work and is attributed 100% of the contribution, than that person earns 100 credits and thus is owed $100 for work completed.

Estimation

Each Work Item in an Open Enterprise is estimated independently, in terms of how many credits will be awarded for its completion. Any member is free to give an estimate of how much should be given for any open Work Item, and their estimation will affect the average estimate of that item. And once work starts on a Work Item and it is being executed, its estimation can no longer be changed. Only the estimates of Members and Core Team Members are counted as binding and affect the final average. Contributors and Users’ estimates are shown and are non-binding and should be considered by Members if they believe that the non-binding vote is based on better knowledge or expertise of the value of that work item.

Retrospectives

In order to ensure that all Contributors to a Workstream get adequately compensated for their work, and that compensation be as fair as possible, the compensation system in an Open Enterprise is based on several tenants:

There are no fixed salaries in an Open Enterprise
Participants are compensated based on Work Items completed, not time spent – This is to provide everyone the freedom to contribute as much or as little as they choose, and for the Enterprise to be billed fairly.
Contribution is assessed by one’s peers, seeing as coworkers and co-team members are the most likely to know how valuable someone’s contributions were – This is to provide the most fair assessment of one’s contribution, using the wisdom of the crowd in assessing work done.
Peer assessment is compared with self-assessment – This is to provide an opportunity for each participant to self-reflect and learn about their assessment of their own work, as well as an indicator to all users of each participant’s self-assessment abilities.

This system of compensation is executed using the Retrospective, which occurs once a number of Work Items worth a certain amount of credits are completed and accepted in any given Workstream.

During the Retrospective, each person who has contributed any amount of work to any of the Work Items involved is asked to assess their own percentage contribution to the completion of these items, as well as every other participant’s. Once all participants have stated their opinion, each one receives the average of their team’s assessment of their work. That figure is also compared with their own assessment of themselves, which affects their self-assessment reputation.

The percentage each participant receives is then applied to the total amount of credits associated with the retrospective and these credits are distributed accordingly.

Credits Queue

Once Credits have been awarded, they are tracked in the Credits Queue. This Queue demonstrates all the credits ever awarded, and in addition it demonstrates which Credits are active. When an individual decides to retire their credits, meaning that they have been paid or they are trading in their credits, they are able to do this from the Credits Queue. The Credits Queue is a way for people to see who has completed what and how and when people have been compensated for their contribution.

Volunteer Credits

In addition, any workstream can be declared as a volunteer workstream. In this system, item are still tracked and estimated with retrospectives to distribute credits. However all credits earned are volunteer credits and are merely a recognition of the hard work that a person has donated to a cause they believe in. Volunteer Credits give the owner the recognition and decision-making ability of a credit, but have no monetary value. In addition, the volunteer workstreams are an important signal to participants that their work will be volunteer in this context.

.

Commons-Oriented Open Cooperative Governance Model V 1.0

Contents