Prepared for: Enbility Steering Committee Originally prepared by: Coretech Innovations LLC Date: 2026-07-29 Document Version: v1.4
Revision History
| Version | Date | Author | Change Description | Approved By |
|---|---|---|---|---|
| 1.0 | 9/11/2025 | Wesam Khattab | Initial Version | Wesam Nashaat |
| 1.1 | 21/1/2026 | Thomas Müller | Draft Amendments | Thomas Müller |
| 1.2 | 22/1/2026 | Simon Thelen | Reformat & Amendments | Simon Thelen |
| 1.3 | 10/7/2026 | Birger Becker | Comments incorporated | |
| 1.4 | 29/7/2026 | Birger Becker | Final version | Andreas Ertel, Thomas Müller, Wesam Nashaat, Kai Takac, Simon Thelen |
1. Enbility Group Governance
This manual defines the policies, procedures, and governance mechanisms that form Enbility’s governance. It ensures that roles and policies are well defined.
1.1 Principles
- Neutrality: Technical decisions are made in the open and based on merit.
- Transparency: Proposals, decisions, and roadmaps are public.
- Continuity: No single-company dependency for releases, security, or CI.
- Accountability: Clear roles, rotation, and measurable SLAs.
Enbility software is intended to be used as a foundation for both open source and commercial products. Member companies may build, distribute, and commercialize proprietary or open products on top of Enbility without obligation to disclose proprietary source code, subject to the repository license.
1.2 Enbility Group
The Enbility Group is fully committed to maintaining and continuously improving the policies that govern the continuity of development and maintaining the enbility source code repositories. This commitment is demonstrated through provision of resources, regular management reviews, policy approval, and promoting a culture of contribution awareness.
1.3 Enbility Group Scope
The Enbility Group covers all activities related to the design, development, testing, and maintenance of the open source EEBUS stack implementation. It includes source code repositories, engineering tools, test platforms, and data storage within the Enbility Group agreed repositories.
1.4 Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Member | Legal entity or individual that joined the Enbility Group; appoints one representative for SC |
| Contributor | Commits engineering effort; participates in roadmap discussions |
| Maintainer | Owns one or more repos/areas; merges PRs; runs releases; ensures quality gates; participates in CRs decisions Approve/merge; release sign‑off; can veto with technical rationale |
| Project Manager | Owns backlog, release trains, and triage rotation; facilitates CRs process; reports metrics — Sets iteration plans; proposes scope to Maintainers/SC; coordinates releases |
| External Contributor | Frequent contributor with new features, bugfixes or any other activities without any obligations or Member steering rights |
Non-code contributions (infrastructure, hosting, CI/CD, documentation, marketing, community management) are considered first-class contributions for fulfilling Member commitments.
2. Enbility Policies
2.1 Release Planning & Feature Development
Purpose & Objective: Project Manager shall review and plan features & bugfixes and shall be responsible for maintaining updated backlog.
Scope & Applicability: This policy applies to all Enbility Members who are listed in the organization member list.
Policy Directives / Rules:
- Create and Maintain release backlog.
- Create a release scope & plan.
- Follow-up on weekly basis development progress.
- Periodic internal audits will verify adherence to this policy.
Implementation & Review Cycle: This policy is implemented through the Enbility Group. The policy shall be reviewed quarterly or sooner if significant organizational or technological changes occur. Changes require approval of SC.
2.2 Steering Committee (SC)
Purpose & Objective: The Enbility Group is handled and managed by the SC which consists of one representative from each Member. The Enbility Group is committed to the development of the organization and maintaining the open source stack.
Scope & Applicability: This policy applies to all Enbility Members who are listed in the organization member list.
Policy Directives / Rules:
- Admission: New Members require SC approval (simple majority) after (a) commitment declaration (see §2.3) and (b) at least one meaningful contribution (code or ops).
- Removal: Member that fails to meet minimum commitments for two consecutive review periods may be placed on inactive status by SC; reinstatement on proof of capacity.
Implementation & Review Cycle: This policy is implemented through the Enbility Group. The policy shall be reviewed quarterly or sooner if significant organizational or technological changes occur. Changes require approval of SC.
2.3 Steering Committee - Formation & Voting
Purpose & Objective: Provide neutral oversight without blocking day‑to‑day development. The SC serves to resolve disputes and ensure the group’s strategic direction aligns with the Enbility’s core values.
Scope & Applicability: This policy applies to all Enbility Members who are listed in the organization member list.
Policy Directives / Rules:
- Conflict Resolution: The SC’s primary function is to resolve disagreements regarding code changes, feature prioritization, or technical decisions where consensus cannot be reached amongst Maintainers.
- Strategic Direction: The SC is responsible for reviewing and approving high-level roadmap items, ensuring alignment with Enbility’s long-term goals.
- Member Actions: The SC maintains the member list and manages Member admission/removal processes, adhering to the guidelines outlined in Section 1.4.
- Review Cycle: The SC will hold quarterly meetings, the meeting minutes and decisions will be made available to all Members.
Implementation & Review Cycle: This policy is implemented through the Enbility Group. The policy shall be reviewed quarterly or sooner if significant organizational or technological changes occur. Changes require approval of SC.
2.4 Member Effort Commitment
Purpose & Objective: Enbility Members are committed with a minimum effort per month. The committed efforts are planned and assigned by the project manager to the needed assigned role in the defined release plan.
Scope & Applicability: This policy applies to all Enbility Members who are listed in the organization member list.
Policy Directives / Rules:
- Each Member shall provide ongoing contributions to the Enbility project. Contributions may include, but are not limited to:
- Software development
- Infrastructure hosting and maintenance
- CI/CD, security, or release operations
- Documentation
- Marketing, ecosystem development, and community support
- Each Member shall commit at least with 32 h/month or equivalent resources.
- Members may fulfill their contribution commitments in whole or in part via sponsored or subcontracted work performed by other Members or Contributors, provided the work is contributed under the project’s license.
- The nature and level of contribution is reported by the Project Manager and reviewed quarterly by the SC.
Implementation & Review Cycle: This policy is implemented through the Enbility Group. The policy shall be reviewed quarterly or sooner if significant organizational or technological changes occur. Changes require approval of SC.
2.5 Repos Maintenance
Purpose & Objective: Enbility is maintained under different (e.g., eebus-go, spine-go, ship-go, tooling, examples., for each repository there are at least 2 assigned repo owners and their responsibility to maintain the repository, accept different Pull Requests.
Scope & Applicability: This policy applies to all Enbility Members who are listed in the organization member list.
Policy Directives / Rules:
- Each Repo has assigned at least two main repo owners
- A repo owner has the right to merge and accept different PR.
- The default branch (e.g. “master” or “main”) shall be a protected branch and owned by the repo owners
- Individual contributors may be promoted to Committer then Maintainer by Maintainer vote (simple majority).
Implementation & Review Cycle: This policy is implemented through the Enbility Group. The policy shall be reviewed quarterly or sooner if significant organizational or technological changes occur. Changes require approval of SC.
3 Decision-Making
3.1 Decision-Making Flow
While Enbility prioritizes lazy-consensus for day-to-day operations, critical decisions and those for which no consensus could be obtained will require formal voting to ensure stability and alignment.
1.Lazy-Consensus (Default): Most decisions shall be made through informal discussion and agreement, with silence considered implicit agreement. 2.Formal Voting (Triggered When Necessary): The following items necessitate a formal vote, utilizing a simple majority vote unless otherwise specified:
| Decision Type | When | Majority Required | Quorum Required | Responsible Group(s) | Notes |
|---|---|---|---|---|---|
| Code Changes, Feature Proposals | Escalation | Super Majority | ⅔ | Maintainers | Decisions regarding code implementation, feature scope, and integration. |
| Code Changes, Feature Proposals | Deadlock | Super Majority | ⅔ | SC | Decisions regarding code implementation, feature scope, and integration. |
| Conflict Resolution (Technical) | Escalation | Simple Majority | ≥½ | Maintainers | Resolving disagreements regarding technical approaches, code reviews, or project priorities. |
| Release Planning & Scope | Escalation | Simple Majority | ≥½ | Maintainers & Project Manager | Defining release schedules, features included in releases, and overall release scope. |
| Strategic Roadmap Items | Escalation | Simple Majority | ≥½ | SC | Approving high-level roadmap items and ensuring alignment with Enbility's overall goals. |
| Member Admission/Removal | Always | Simple Majority | ≥½ | SC | Managing the membership list and resolving issues related to Member participation. |
| Major Policy Changes | Always | Unanimity | 100% | SC | Changes affecting fundamental governance processes, such as this document itself. |
| Project License Changes | Always | Unanimity | 100% | SC | Change the license agreement of the project |
| Domain-Change/-Transfer | Always | Unanimity | 100% | SC | Transfer or sale of the domain (material changes and routine changes are defined in the domain trust agreement) |
Notes:
- Super Majority: Defined as 2/3 (two out of three) of the Members present and voting.
- Simple Majority: Defined as more than 50% of the Members present and voting.
- Unanimity: Defined as unanimous consent (100%) of the responsible group(s).
Process for Calling a Vote:
A Member can initiate a formal vote when consensus cannot be reached. The decision-making process will then follow the thresholds outlined above.
4. Enbility — Initial Files (governance, policies, …)
This proposal is to be published publicly and shall be linked on the Enbility website as well as in every Enbility repository.
Issue & PR Templates:
- .github/ISSUE_TEMPLATE/bug_report.md
- .github/ISSUE_TEMPLATE/feature_request.md
- .github/PULL_REQUEST_TEMPLATE.md
Workflows:
- .github/workflows/ci.yaml
- .github/workflows/release.yaml