nmushegian/gist:8fdb4eff9d9f998f71f610d694734f81

## gistfile1.txt
- monospace protocols company principles
	- We are an R&D firm.
	- We only work on systems we believe are credibly neutral, and aim to make this definition rigorous.
	- Any software written for a client must be licensed permissively.
	- We do not operate validators (we run full nodes but do not produce blocks). People can run whatever they want as individuals or side ventures.
	- We only accept investments from entities that leave us complete control over when and how to allocate funds and to pay returns. We are making long term plays and there is no reason to invest in us if you don't think we know what we are doing.

- Software Writers
	- Software writers spend 60% time on personal projects and 40% on company projects.
	- Software writers own their IP, but must license it permissively (more specifics later).
	- Software writers must keep a learning journal
	- Software writers perform anonymous peer review to keep a high standard for talent; churn from the bottom not from the top


- Software Project Leader
	- Software Project Leader is a role that is defined with respect to a particular repository or project.
	- Almost all software projects have one person that is a primary architecture designer who mediates feedback and keeps **all** relevant tradeoffs in mind.
	- This person has absolute final say over the contents of the repository. Because of that, they should make sure to architect things in a way where their control cannot be abused (by them, or by someone else in the future).
	- The SPL gets to choose their collaborators. Working for an SPL is a mutually agreed upon working relationship where the collaborators choose to defer to the SPL on design decisions. If they disagree about something strongly enough, that is an opportunity to become the SPL for an alternative approach.
	- Any software project leader can fire any executive
		- they have to make a public writeup about why, but it will not be questioned, the executive will be fired

- Executive
	- No executive has any control over any kind of infrastructure.
	- Every executive must understand the purpose of every repository. Executives must spend 40% time participating in code reviews as students and learning to write small practical scripts.
	- Executives represent the company to create an interface for person-to-person interaction with the company. When an executive leaves the company or is fired, they naturally lose the ability to represent the company. This is their only role.
	- Executives are given goals by Software Project Leaders. The BDFL mediates this and controls the scope of tasks given from SPLs.
	- Any software project leader can fire any executive
		- they have to make a public writeup about why, but it will not be questioned, the executive will be fired

- Benevolent Dictator For Life of Monospace Protocols and Dumb Money
	- Write software
	- Tell investors to go fuck themselves
	- Say things on behalf of software writers who don't want to say it themselves
	- Hire slow fire fast
	- Understand projects and connect people to projects but not in a manager-like way where they don't know anything but instead, in a way where it helps to create working software
	- No meaningful control over any part of any system, only informal feedback to Software Project Leaders. Monospace should be resilient to attacks or corruption and all projects should continue independently as if nothing happened if the corporate structure is compromised.
	- monospace protocols company principles
	- We are an R&D firm.
	- We only work on systems we believe are credibly neutral, and aim to make this definition rigorous.
	- Any software written for a client must be licensed permissively.
	- We do not operate validators (we run full nodes but do not produce blocks). People can run whatever they want as individuals or side ventures.
	- We only accept investments from entities that leave us complete control over when and how to allocate funds and to pay returns. We are making long term plays and there is no reason to invest in us if you don't think we know what we are doing.

	- Software Writers
	- Software writers spend 60% time on personal projects and 40% on company projects.
	- Software writers own their IP, but must license it permissively (more specifics later).
	- Software writers must keep a learning journal
	- Software writers perform anonymous peer review to keep a high standard for talent; churn from the bottom not from the top


	- Software Project Leader
	- Software Project Leader is a role that is defined with respect to a particular repository or project.
	- Almost all software projects have one person that is a primary architecture designer who mediates feedback and keeps all relevant tradeoffs in mind.
	- This person has absolute final say over the contents of the repository. Because of that, they should make sure to architect things in a way where their control cannot be abused (by them, or by someone else in the future).
	- The SPL gets to choose their collaborators. Working for an SPL is a mutually agreed upon working relationship where the collaborators choose to defer to the SPL on design decisions. If they disagree about something strongly enough, that is an opportunity to become the SPL for an alternative approach.
	- Any software project leader can fire any executive
	- they have to make a public writeup about why, but it will not be questioned, the executive will be fired

	- Executive
	- No executive has any control over any kind of infrastructure.
	- Every executive must understand the purpose of every repository. Executives must spend 40% time participating in code reviews as students and learning to write small practical scripts.
	- Executives represent the company to create an interface for person-to-person interaction with the company. When an executive leaves the company or is fired, they naturally lose the ability to represent the company. This is their only role.
	- Executives are given goals by Software Project Leaders. The BDFL mediates this and controls the scope of tasks given from SPLs.
	- Any software project leader can fire any executive
	- they have to make a public writeup about why, but it will not be questioned, the executive will be fired

	- Benevolent Dictator For Life of Monospace Protocols and Dumb Money
	- Write software
	- Tell investors to go fuck themselves
	- Say things on behalf of software writers who don't want to say it themselves
	- Hire slow fire fast
	- Understand projects and connect people to projects but not in a manager-like way where they don't know anything but instead, in a way where it helps to create working software
	- No meaningful control over any part of any system, only informal feedback to Software Project Leaders. Monospace should be resilient to attacks or corruption and all projects should continue independently as if nothing happened if the corporate structure is compromised.