Hackers & Designers Coop, 2018 Retrospective by James Bryan Graves

The Problem

By 2018, despite my best efforts to push an agenda of de-professionalization in 2017, Hackers & Designers had formalized into a stichting (non-profit entity), and the number of individuals involved began to increase. This introduced a need for a formalized infrastructure, which included transparency and clarity regarding what labor was being performed by who, and for what reason, in order to justify the appropriate dispensing of funds.

The Basis, the original formal definition of the coop model as written by James Bryan Graves, January 7th, 2018:

The Hackers & Designers Coop is a proposed model for a collaborative organization based on fiscal democracy.

Funds will be divided equally between all members of the cooperative.
Projects will be proposed to the cooperative by one or more members of the cooperative. Projects broadly consist of a description, budget, and participants, but can include any relevant information for funding cooperative members.
Projects can contain participants outside of the cooperative, but participants outside the cooperative cannot participate in cooperative funding.
Funding members (cooperative members outside a project's participant list) consider the project proposal, and then return with either a promise to fund the project (a promise), a refusal to fund the project (a rejection), or suggestions as to how the project could be modified so to be evaluated for funding again (a modification).
Projects cannot be funded by the participating members of the cooperative, except when all the members of the cooperative are participating in the project.
Projects that receive enough promises, even when they also receive modifications, can be executed without fulfilling modification requests.
If a project does not receive enough promises, but does fulfill modification requests, it must be re-evaluated by all the non-participating members of the cooperative to be considered for funding again.
Everything the cooperative does should be included in or described as a project, including administration and organizational activities such as: bookkeeping, communication, external funding applications, etc.
It is possible to participate in the cooperative and never propose or participate in a project. Such members, however, will not receive funds.
It is possible to continue with a self-initiated project which was rejected by all members and still use the ‘Hackers & Designers’ non-financial assets (name, communication, web, wiki, whatever). Such assets are perks of being part of the cooperative. Self-initiated projects can also happen completely outside the Hackers & Designers umbrella. It is completely up to the person executing the project.
Projects that receive the required amount of promises and are executed must include Hackers & Designers in their project communications, etc.
Individual project management need not concern the cooperative once it has been funded and the project has begun. Any funding received by an individual project is to be handled by those in charge of the project. They can then decide to return the funding partially or in its entirety back to the cooperative, but that is not mandatory. Any funding returned to the cooperative is then split evenly between cooperative members.

Practically, the budget proposed to Stimularingsfonds for 2018 pre-dated this coop proposal, and it therefore will need to be evaluated and combined with a project description. The definition of a project is loose by design, but it should not be too large or too small, for instance HDSA2018 should be divided into smaller projects.

The Technology

The set of rules for the coop takes the form of a codified list, and therefore the algorithmic translation of it was relatively trivial. Furthermore, as the context of coop proposal was during the height of the blockchain hype, the software stack for the coop algorithmics, or ‘platform’ implementation, included a private Ethereum blockchain with a DApp (distributed web based application) interface. The intention was to critically explore the technology by ‘eating our own dog food’. The coop software platform implementation was the first proposed and approved coop project.

The Retrospective

The budget for the coop platform project was purposely small, and a ‘release early, release often’ strategy for development was borrowed from the lean world of startups. Unfortunately, these combined approaches proved tragically ineffective, as the members of the coop, who were also the users of the platform, grew increasingly frustrated by user experience (UX) manifest in the overly simple web interface, bugs, and lack of clarity in manipulating the blockchain.

This software has been abandoned by H&D, however, the coop structure persists. The software was adopted by Peerparty in the Peerpolls code base, and many of the original issues with the blockchain manipulation have been addressed.

I personally believe most of the internal questions and desires for operational clarity were ultimately answered by the adoption of the coop protocol. Although, there does seem to be a reluctance by newer members to propose projects, or to suggest what projects should look like, but these problems are easily addressed via communication within the coop.

NOTE: I left the organization halfway through 2018.

Published in Fake it! Fake them! Fake you! Fake us! Publication in 2019