You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

10 KiB

Governing Body


This document will outline the high level concepts and guidance principles of the governing body of The Grid that will be used for the articles of constitution.

This document will NOT go into details of how day-to-day management will happen, which will be left to the discretion of the Governing Body.

The Governing Body will be a non-profit organisation, funded in Luxembourg, as an Association sans but lucratif by Max Dor (author of this document), Daily Manager of Kamax Sarl, and two other people (TBC, people that are known personally, but not necessarily technical), as legally required.

Non-profit status will ensure that all activities and incomes must be legally targeted to fulfil the missions of the non-profit without being subdued by making a profit for its shareholders, as opposed to a for-profit which its sole purpose is to make profit and distribute it to its shareholders.

Non-profit gives a better framework for donations or voluntary work, without the need for extensive accounting or legal requirements overall, giving much more freedom in the day-to-day running of the organisation and helps keeping management costs to a minimum, which would otherwise add up to several thousands Euro per year.

The legal entity will be used to centralize ownership of various protocol IP materials, like Internet domains, trademarks, logos. The source code of any tools built by or on request of the legal entity will remain the IP of their respective owners.


The Governing Body will have the following missions:

Regular protocol specification releases

A protocol is only defined by its specification, and its delivery in a clear, comprehensive, validated and usable format by the widest technical audience is the most important mission.

The Governing Body exists in fine for the sole purpose of this deliverable and should be judged on it.

Provide adequate environment, tools and hosting

The Governing Body will provide:

  • A documented vision for the protocol
  • What is reasonably necessary for its boards to fulfill their responsibilities
  • What is reasonably expected from the community about such entity with a similar mission
  • End-users software, tools and services to showcase the protocol usage and goals
  • Development software, tools, documentation and services to ensure independent implementations are possible and straightforward, following BCP 9.
  • Means and services to discuss, exchange, and learn about the protocol
  • Guidelines and processes for protocol changes and community contributions, ensuring these are always welcoming, as easy as possible, and as rewarding as possible.

Community management


  • A Community Manager which will always be available and reachable
  • The community is proactively kept up to date of changes and achievements
  • Officially-managed places are properly and timely moderated
  • Feedback from The Community, however bad or good, is always taken into consideration

Protocol fostering

Proactively engage into activities to:

  • Make the protocol known by as many people as possible (website, social medias, conferences, etc.)
  • Convince end-users to use the protocol (demos, webcast, etc.)
  • Convince developers to build on the protocol
  • Grow the community at large


The Governing Body should only be founded on donations from the community. This will be a critical dynamic for this project, as it will ensure the community has a clear and straightforward way to show its support and general agreement with how well the Governing Body is doing.

All donations will be listed and made public. Donors that have made a donation with significant amount (> X€ over X months) must be publicly disclosed as they can use it as leverage to achieve their own goals. Donations MUST NOT be conditional to any delivery, service or related item. Donations MUST be without any string attached.

While sponsoring is occasionally acceptable, full disclosure about the transaction, including the contract, MUST be publicly disclosed. Contracts that conflict with this full public disclosure clause MUST be refused. Signatures, emails, contact numbers will be removed before public disclosure.

Sales of goods and services are acceptable, as long as:

  • They are legally acceptable for the non-profit
  • The majority of income is not tied to a minority of customers
  • Do not interfere or take priority in any way with the missions and responsibility of the Governing Body outlined in this document

The Governing Body will give full disclosure about incomes on a regular basis (TBD, quarterly?), so it can be audited by the community at large.


The Governing Body will be allowed to use its funds to:

  • Pay a regular salary to management board members
  • Give financial compensation to technical board members, after approval from management board and technical lead, to ensure they can afford dedicated time and give an incentive to remain a member
  • Pay for the various fundamental technical services (Domains, web hosting, etc.)
  • Finance trips and related expense to social events which are relevant for the boards missions (e.g. FOSDEM stand)
  • Finance individual missions with independent contractors/orgs that may have dedicated knowledge into one area, to further progress the protocol (e.g. a security/crypto consultant for end-to-end encryption, or security audit)

The Governing Body WILL NOT be allowed to provide funds to any entity listed as an employer or of significant involvement with any of the boards members. This will ensure no board member will have an incentive to redirect the Governing Body money for its own profit.

The Governing Body will give full disclosure about spending on a regular basis (TBD, quarterly?), so it can be audited by the community at large.


The leadership of the non-profit will be divided into two boards:

  • Management board
  • Technical board

Membership of those boards are not mutually exclusive, and one person can be a member of both. Each board will have specific, non-overlapping responsibilities.

We recognize and even value that no one can be 100% neutral and therefore might try to push their own agenda, even if unconsciously. We see this as a driving force as members would have a reason and a motivation to be there and is not a negative thing on its own.

As a user, developer, sysadmin, member or donator, it is very important to be able to make an informed decision about whether one should continue contributing in its own way to the project. This starts by knowing who the people in charge are, what allegiance they might have and the laws they are bound to.

Therefore, every member of each board must disclose the following on public record:

  • Name (not necessarily full legal name, but not an obscure nickname either, like “l33t1337”)
  • Employment status with position and employer if applicable
  • Significant (paid and/or with decision making level) involvements in other organisations of any kind
  • Country of legal residence

Members will be listed on the main website of the protocol project page, along with the latest up to date information.

Management board

This board will be made from members of the legal entity and will take on the following responsibilities:

  • Management of the non-profit legal entity
  • Accounting
  • Finances
  • Promotion of The Grid
  • Ensure the governing bodys missions are fulfilled
  • Functional (high-level, non-technical) steering of the protocol
  • Community management


  • Legal member of the non-profit

Membership starts:

  • By vote of all current board members

Membership ends if either of the following occurs:

  • Of their own will, at any time
  • By vote of all other board members

Technical Board

This board will be made of people who have written implementations of the protocol and thus can have an informed, knowledgeable and authoritative view about the technical choices to be made and decisions to be taken.

This boards members will be made of:

  • One lead member, called “The Lead”
  • An number of other members, called “The Members”

The board will decide on a tie-breaking mechanism for decisions.

The lead will take on a “back-seat” role, only giving his final opinion/choice/vote after everyone else has. The Lead will have a special role as a spokesperson of the technical board, both towards the management board and the community.

The lead can only be voted in by the management board which MUST seek a written list candidates from the technical board.
The lead can only be voted out by the technical board and MUST, prior to voting, seek a written opinion about it from the management board.
This will ensure that both boards agree on The Lead being a good fit for the role and that potential abuse is kept under control.
The board CANNOT contain more than one member that have financial ties with a specific entity. This will ensure the board cannot be taken over in the long term by a single employer/corporation/organisation.


  • Production of the protocol Specification
  • Production and maintenance of an implementation validation tool to certify those implementations as protocol compliant
  • Technical steering of the protocol, to fulfil the functional goals
  • Review of community proposals
  • Proactively ensure enough implementations exist to keep the protocol validated


  • Be the main author of at least one maintained (compliant with the current or previous version of the protocol) component implementation
  • Submitted at least one protocol change that has been accepted in the official documentation in the last X months
  • Commitment to be available X business days per week, except when on justified leave

Membership starts:

  • By vote of all current technical board members

Membership ends if either of the following occurs:

  • Of their own will, at any time
  • By vote of all current technical board members
  • By failure to disclose any potential conflict of interest, enforced by the management board if necessary
  • By failure to be available as required, enforced by the management board if necessary
  • By failure to keep their implementation maintained, enforced by the management board if necessary