OSE Governance

Organization

edit

Index Guide 2012 Rollout Plan | Mission Needs Funding Structure Strategy Governance | Media Marketing | Development Documentation Archive

GVCS Tools | Tasks Resource Map Network | Meetings | International Places Europe | Start your project!

Open Source Ecology Governance Charter (Minimal)

Source [1]

Purpose

This charter defines the minimum governance required to preserve coherence, accountability, and non-capture while scaling Open Source Ecology (OSE) toward full technosphere open-sourcing.

OSE governance is designed to:

• Enable rapid production and replication
• Preserve open-sector integrity
• Prevent fragmentation during success
• Channel surplus into universal productive capacity
• Remain minimal until civilization-scale governance is required

This charter applies prior to the $50B open technosphere threshold.

---

Governance Principle

OSE governance is custodial, not democratic.

OSE Core exercises authority in trust for the open sector, not for private enrichment, popularity, or internal politics.

Execution is decentralized. Standards are centralized. Forking is allowed. Capture is not.

---

I. OSE Core Custodial Authority (Non-Negotiable)

OSE Core holds exclusive authority over the following domains:

• Canonical product definitions (what constitutes an official OSE product)
• Interface standards (what must connect to what)
• Acceptance criteria (what counts as “done”)
• Benchmark metrics (what is measured, tracked, and published)
• Official documentation canon (source of truth)
• Brand usage and representation
• Contract templates
• Warranty boundary definitions
• GVCS roadmap prioritization

Crews, vendors, and branches do not vote on these standards.

They either:

• Execute against them under contract, or
• Fork and operate independently without OSE brand, contracts, or warranty support

---

II. Hard Non-Negotiables

The following principles are never negotiable inside the OSE system:

1. Canonical designs and interfaces remain open
2. Documentation is mandatory, current, and truthful
3. Performance is benchmarked and published
4. No proprietary lock-in may be embedded in system-critical artifacts
5. Safety margins are preserved regardless of cost or speed
6. Warranty boundaries are respected
7. OSE Core remains system integrator, not labor manager
8. Revenue surplus is funneled into open-sector R&D, not private rent extraction
9. Forking is allowed but brand capture is not
10. No undocumented deviation is permitted in OSE-delivered products

Violation of any non-negotiable triggers review or decertification.

---

III. Artifact-Based Governance

Governance is enforced through artifacts, not meetings.

Canonical rule:

If it is not in the official artifact set, it does not exist.

Artifacts include:

• Designs
• Specifications
• Build procedures
• Interfaces
• Benchmarks
• Acceptance tests
• Documentation
• Metrics

Oral tradition, undocumented improvements, and local exceptions have no standing.

---

IV. Branch Governance Model

OSE branches are execution nodes, not sovereign entities.

Branch Authority

Branches may control:

• Local scheduling
• Hiring and onboarding
• RLF operation
• Site logistics
• Helper training

Branches may not control:

• Product definitions
• Interface standards
• Canonical documentation
• Benchmark definitions
• Brand terms
• Contract structure

OSE Core may audit, pause, or decertify branches without negotiation.

---

V. Branch Decertification Protocol

Branch decertification is a corrective mechanism, not punishment.

Triggers

• Repeated deviation from standards
• Documentation lag behind production
• Quality failures beyond tolerance
• Safety violations
• Warranty Boundary Violations
• Brand misuse
• Attempted enclosure or capture

Process

1. Written notice issued with specific violations
2. Remediation window defined (typically 30–90 days)
3. Audit of corrective actions
4. Either recertification or decertification

Consequences of Decertification

• Loss of OSE brand usage
• Termination of OSE contracts
• Loss of warranty coverage
• Continued right to fork and operate independently

OSE Core retains no obligation beyond contract closure.

---

VI. Fork Protocol (Plain Language)

Forking is explicitly allowed.

A fork is an intentional divergence from the OSE canonical system.

A fork means:

• You take the open OSE designs
• You may modify them independently
• You may add proprietary components or processes
• You operate under your own brand
• You clearly declare divergence from OSE standards
• You assume full responsibility for the resulting system

Forking is valid only if it is honest and explicit.

---

What Forking Requires

A legitimate fork must:

• Use a distinct product name and branding
• Clearly state that it is not OSE-compliant
• Clearly document which components are open and which are proprietary
• Make no claims of OSE compatibility, certification, or warranty
• Assume full responsibility for safety, performance, compliance, and support

---

Forking Consequences

Forking results in:

• No OSE branding
• No OSE contracts
• No OSE warranty backing
• No claim of OSE compliance or compatibility
• No access to official OSE documentation canon updates
• Full responsibility for customers, regulators, and long-term performance

OSE does not interfere with forks. OSE does not police proprietary innovation outside its boundary.

---

What Forking Is Not

Forking is not:

• Enclosure (undeclared divergence while claiming OSE lineage)
• Open-core drift inside the OSE warranty envelope
• Proprietary lock-in embedded in OSE-branded systems
• Withholding system-critical improvements while claiming OSE compliance

Any of the above constitutes misrepresentation and triggers immediate decertification.

---

Closing Clarification

Forking is not rebellion.

Forking is the pressure-release valve that preserves openness, accountability, and non-coercion while allowing experimentation, commercialization, and divergence.

OSE remains open. OSE remains coherent. OSE remains non-capturable.

VII. Economic Governance

OSE surplus is allocated by OSE Core into:

• Open R&D
• Documentation infrastructure
• GVCS machine development
• Branch replication capacity
• Risk buffers

No private party may redirect surplus into proprietary capture of system-critical resources.

---

VIII. Scaling Throttle

Growth is constrained by governance capacity.

OSE does not add:

• Crews
• Branches
• Product variants

Faster than it can:

• Maintain documentation integrity
• Enforce acceptance criteria
• Audit performance
• Preserve system coherence

Slowing growth is preferable to losing standards.

---

IX. Scope of This Charter

This charter governs OSE until the open technosphere reaches civilization scale (~$50B).

Post-$50B governance will involve:

• Embedded accountability in infrastructure
• Self-auditing systems
• Planetary externality management

Those mechanisms are explicitly out of scope for this charter.

---

Closing Statement

OSE exists to open the technosphere, not to accumulate power.

Governance exists to protect that mission during success.

Simplicity is strength. Forkability is freedom. Standards are survival.

(end of 2026 addition by MJ)

Summary - 2022

OSE follows principles of collaborative, transparent, inclusive abundance. This may sound simple, but the previous qualities are far reaching. OSE also proposes these principles as the complete constitution for any country, or for any region of Swarm Governance.

General

OSE is currently run as a Meritocracy under the direction of Marcin Jakubowski. One must make the distinction between the goverance of OSE the corporation (Board of Directors) and the technical leadership of projects. Under all of OSE's work lie OSE Specifications. Since the project is modular - any team leader who follows OSE specifications, inclusing Collaborative Literacy - can assume leadership of effort on any of the GVCS machines, 500 Modules, or any other endeavors. The governance structure revolves around the completion of the GVCS 50 tools by 2028, with the following requirements:

1. OSE Roadmap - involves a prioritized and strategic rollout that is negotiable only by the Board of Directors, with decisions influenced by OSE Advisors. Yearly Critical Paths are drafted.
2. The primary activity of OSE is R&D&E - Open source product Research and Development and Education.
3. Distinctions are made between 4 units of OSE operations:
   1. OSE Inc, the corporate entity that is a container for OSE activity;
   2. the community - OSE global, collaborative, open source appropriate technology R&D;
   3. Facility operations at the OSE Headquarters or other campuses;
   4. and its revenue-generating enterprises (in the nonprofit sector) - XM Workshops, kit production, training, immersion workshops, swag, and other
4. Anyone is welcome to develop and document GVCS or related products on the OSE Wiki, which is openly editable.
5. All contributions to the wiki are open source according to the OSE License.
6. Product and strategy must comply with OSE Spec, and can be evaluated by the OSE Spec Score. Compliance with Product Ecologies further specifies the development path. It should be specified that the greatest governance risk is assuring compliance with OSE Spec and Product Ecologies. The reason for OSE Spec and Product Ecologies is to create a minimum, lowest cost set that still meets or exceeds industry standards - but does so at a theoretically achievable 100-1000 lower cost. The lower cost is achieved by open source (10x cost reduction), lifetime design (10x lower cost), and Modularity/Product Ecologies (10x). Open source, lifetime, modular design is the critical value proposition of OSE.
7. OSE encourages and enables, and produces infrastructure for Distributive Enterprise organization - OSE gives other orgs the tools to compete with OSE
8. OSE community is a meritocracy. OSE the corporation follows the usual org chart of an organization or company. Merit is gained by involvement in the core development process and by certification. OSE Certification can occur as a Development Team member, an OSE Fellow, or a producer using the OSE brand. Specific license agreements for using the OSE brand are crafted on an individual basis.
9. OSE Org Chart defines roles. Current filled roles are the BDFL, CTO, Graphics Lead, Community Manager, and Power Cube Lead. See Team
10. OSE Fellows are the highest status of developer at OSE as a full time role. Fellows do R&D on the Critical Path, and work together with the CTO on product development, as verified by the ability to generate revenue via Extreme Manufacturing Workshops.
11. CTO and Fellows make collaborative decisions on specifics of products, where products comply with the Roadmap, Critical Path, and OSE Spec. Simple majority determines specifics of product instances, with CTO and Fellows having one vote each.
12. Fellows make a quarterly individual product release, with Product Release added to the Critical Path.
13. Fellows may tap OSE Developers and SMEs for assistance in their Product Release Schedule.
14. Product Releases are tracked via the Simple Development Template with 100% marking complete burndown
15. CFO makes funding decisions. Fellows can submit research budgets for approval by CTO. CTO evaluates proposals based on OSE Spec. Fellows get funding based on revenue they generate from workshops such that money comes from "their pot," thus preventing "freeloaders" who take without putting in. Fellows must be in Good Standing
16. OSE Developers are official part time developers. OSE Developers may submit requests to the CTO for resource support in their prototyping tasks if they are in Good Standing.
17. The OSE Immersion Program is designed to train both OSE Fellows who receive a monthly stipend and Independent Collaborators, who collaborate with OSE on a contractual basis.
18. Contributions to the project are voluntary. OSE does not have external funding, but generates revenue through its activities. See OSE_Financial_Transparency for financial reporting.

Notes

1. A road map is publish every year by OSE's executive director.
2. OSE Fellows are being trained for leadership positions to influence this direction.
3. All product design follows OSE specifications. Any changes in requirements have to pass through an evaluation of the OSE specifications score.
4. Anyone is welcome to develop any existing project or start forks of projects. The accepted route to documentation is to use the OSE Development Template for new designs and builds. The wiki is freely editable for anyone to contribute in this fashion.

Forks

There were historically several forks of OSE:

• OSEG - Open Source Ecology Germany[[2]] - active
• OSE_Fr - Open Source Ecologie in France [[3]] basing its governance on Sociocratic principles - active
• OSEE - Open Source Ecology Europe[[4]] - folded
• OTF - Open Tech Forever[[5]] - folded
• OSE Greece, OSE Italy