Most of today's successful large and complex centralised organisations and ecosystems have an 'organisation chart' or at least a website to show what is done by whom and where and how ownership and control work. It's usually expressed as a hierarchy of business units. Often it is hard to see how things get done in these high and mighty hierarchies and pyramids. For example - How do I (as a customer) get that custom product or service I want? Hierarchy builders usually respond by defining processes that 'cut across' the hierarchy in some sort of intelligible event - process - outcome chain and then presenting a view - on a website or in a physical store - that hides underlying / backroom complexity from the stakeholder.
The business unit hierarchies (sales, engineering) are usually in tension with the 'cross-cutting' process owners (marketing to sale, order to cash, build to ship, hire to retire, accounting to reporting.... and so on). The tensions often escalate painfully up the hierarchy only to be resolved at a lofty and remote executive or board level in decisions made out-of-touch from reality and without good data/evidence. Some sort of business model and a business architecture function may be charged with resolving such issues on behalf of the board, but such 'ivory tower' units sometimes fail to keep up with a rapidly changing environment.
It is harder and harder these days for a hierarchy to organise in response to external 'chaos', so some of the more successful ones have chosen instead to design and organise as 'ecosystems' or 'multi-sided platforms': Facebook, AirBnB, Amazon, Alibaba and so on. These are still essentially centralised or at best, federated organisations, with a platform owner / designer at the heart, governing a proprietary strategy and control over the value chain. See https://www.valuewalk.com/2017/11/trebor-scholz-uber-worked-underpaid-talks-google/
Co-operative, collaborative 'flat' organisations and networks shift from a hierarchical system of ownership to a collectively owned enterprise or purposeful project. Work is done and value added in a self-organising, peer-to-peer network, and fairly rewarded. A wide range of patterns or tools is used to organise and decide. An excellent presentation on the advantages and challenges of collective organisation is provided here, by Rich and Nati of thehum.org: https://www.youtube.com/watch?v=7P2ryGEP5W8&t=2s Presentation deck: https://docs.google.com/presentation/d/1qo44fPTMVijBS42McIhoYtJWvPp1kUsA_WblsRFwCxg/edit?usp=sharing
It is not the purpose of this project to create further material on the advantages of collaborative, co-operative, peer-to-peer working. It is instead aimed at mitigating some of the disadvantages (see slide 5):
- slow, inefficient decision-making
- unfocused, unclear roles and responsibilities with low accountability
- frequent re-inventing the wheel
- poor facilitation / implementation, and
- overall dissatisfaction with the 'tyranny of structurelessness' (https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness)
A minumum necessary level of co-ordination is necessary in a decentralised peer-to-peer organisation to address these challenges. In a small organisation the co-ordination may be implicit and unstructured, relying on norms, values and behaviours, but large, complex organisations need more explicit structure, roles and accountabilities, however those are decided. A single 'registry' of the units, relationships and behaviours is useful for all in a collaborative enterprise.
Provide co-operative governance users with a view and navigation of an overall baseline 'governance map' Allow the browsing and viewing of governance objects within the map (roles, events, processes, governing body charters, processes, inputs / outputs, measures, resources and so on) An ability to comment on governance
Provide those accountable for governance design ('governance content editors') with tools to: Create and edit the governance map(s) Create and edit governance objects and attach to the map(s) Resolve comments raised by governance users (mark as resolved and communicate)
Provide links / API's for publication, version control and security of governance view content
This is a proof of concept exercise in support of the proposed RChain Co-op Governance Committee (see draft charter here https://docs.google.com/document/d/17-vJZXDZ_7w823pD9pnvoKiPa9ifj8C3ayKopLJzBhQ/edit#heading=h.3u2n8wqjynqz)
The Rchain Co-op routinely uses Discord as an everyday communications tool, and contains a #governance chat channel. (In future, other tools may be used... e.g. Mattermost.) Github is used as a repository for key documents and for the Rchain dev lifecycle. The website is a focal point for information for users, investors, developers and partners in the ecosystem. The PoC will simulate rather than implement full integration with these tools and services.
The PoC excludes particular decision-making processes, organisational or behavioural norms. Its focus is structure, not the detail of behaviour or process. Decision making and 'digital democracy' tools are being considered by the 'Expression of Wish' working group at Rchain co-op.
The PoC assumes maximisation of decentralised, autonomous organisation and diversity - and only a minumum necessary level of co-ordination - within the effective and efficient delivery of the Co-op goals. The centralised vulnerability of implicit structure and rules understood by the few is reduced by making the implicit explicit, and open sharing with all. We will experiment and trial to strike the right balance.
The PoC will use the Electron framework. Opportunities to meaningfully use Rholang / Smart contracts or otherwise persist data in an Rchain structure will be considered at a later stage.