FOSSBilling/GOVERNANCE.md

Project Governance

Last updated: 04 October 2025 Version: 1.1

Overview

FOSSBilling is an open source project that builds and maintains a free, self-hostable billing and client management platform. The project is developed collaboratively by a global community of contributors and users. Anyone (individuals, teams, or organizations) with an interest in FOSSBilling is welcome to join the community, contribute in any capacity, and participate in shaping the project's future. Contributions can include code, documentation, design, testing, financial support, or community engagement.

There are no barriers to participation. Whether you're a developer, a user, or simply curious, your involvement is valued. For ways to get involved, see the Contribution Guidelines.

TL;DR: Major project decisions are made by consensus of the Steering Committee, informed by transparent and inclusive community discussion.

Community

The FOSSBilling community includes anyone who uses, contributes to, or supports the project, whether occasionally or regularly. The core FOSSBilling software is licensed under the Apache License Version 2.0 and is free to use, modify, and distribute, now and forever. No fees, registration, or special permissions are required for basic usage.

We encourage, but do not require, creators of third-party modules, themes, or integrations to share their work with the community (e.g., via GitHub, Discord, the Forum) so it can be included in the extension directory. However, all use of the FOSSBilling name, logo, or branding must comply with the FOSSBilling Branding Guidelines. Any use beyond what is explicitly permitted requires prior written permission from the Steering Committee.

To get involved:

• Explore the code and report issues on GitHub
• Join real-time discussions on Discord or engage in discussions on the Forum
• Contribute via GitHub Sponsors or Open Collective

Maintainers

Maintainers are trusted contributors who have demonstrated consistent, high-quality involvement in the project over time. They help review code, triage issues, improve documentation, and guide the project's evolution.

Becoming a Maintainer

• Nominations may be made by existing Maintainers or Steering Committee (SC) members. The SC evaluates nominees based on the quality, consistency, and collaborative nature of their contributions.
• New Maintainers are granted provisional status for one month, during which their engagement is observed.
• After this period, status is made permanent unless concerns are raised.

Contributions may include, but are not limited to:

• Participating in GitHub discussions (issues, pull requests)
• Submitting bug fixes or new features
• Improving documentation or user guides
• Creating educational or promotional content (e.g., blog posts, videos)

There are no formal skill requirements; what matters is sustained, constructive participation.

Stepping Down or Removal

Maintainer status may be removed if a person:

• Resigns voluntarily;
• Is inactive for six consecutive months without prior notice; or
• Engages in behavior that violates the project's Code of Conduct or disrupts the community.

Removal (except for resignation) requires discussion and a majority vote of the SC. A grace period or warning may be offered in cases of inactivity.

Defining Activity

To ensure clarity, "activity" is defined as meaningful participation in the project. This includes, but is not limited to: committing code, reviewing pull requests, triaging issues, contributing to documentation, or actively participating in project discussions on GitHub, Discord, or the Forum.

Steering Committee

The Steering Committee (SC) is responsible for the long-term health, direction, and sustainability of FOSSBilling. Its members are active contributors who hold administrative access to the FOSSBilling GitHub organization to ensure project continuity, even if individual members become unavailable.

Current Members

As of this writing, the SC consists of the following individuals (listed by GitHub username):

• admdly
• BelleNottelling
• yagiz-dev
• HunterNyan
• jaapmarcus

Appointments and Removals

• New SC members may be nominated by existing members or recommended by Maintainers.
• Appointments require discussion and at least a two-thirds majority of current SC members (unanimity preferred).
• A member may resign at any time.
• Removal for inactivity (6+ months, as defined under the Maintainer section) or disruptive conduct follows the same process as Maintainer removal, with the affected member recused from voting.

Decision-Making Process

FOSSBilling operates on principles of transparency, collaboration, and efficiency.

Lazy Consensus

Most decisions are made using lazy consensus:

If a proposal is made and no objections are raised within a reasonable timeframe (typically 5-7 days), it is considered accepted. Silence is interpreted as consent.

This enables progress without requiring explicit approval from every participant.

Formal Decision Pathway

For significant or contentious matters, decisions follow this process:

1. Proposal: Any community member may submit a formal proposal as a GitHub issue.
2. Discussion: The community and Steering Committee discuss the proposal publicly on GitHub (or Discord for early ideation).
3. Vote (if needed): If consensus isn't reached after discussion, the Steering Committee may hold a vote.
4. Final Decision: The SC makes a final determination, informed by both discussion and any vote results. For a formal SC vote, a motion is considered passed if it receives approval from a majority (>50%) of the voting Steering Committee members. In the event of a tie, the proposal is not approved and may be revisited after further discussion.

Note: Polls and votes are advisory, not binding. The Steering Committee retains final responsibility for project direction.

Scope of Public Discussion

All non-sensitive discussions occur in public (GitHub issues, public Discord channels, Forum threads). Exceptions include:

• Security vulnerabilities (handled via private channels)
• Personal or personnel matters (e.g., Code of Conduct violations)

Only proposals filed as GitHub issues are considered formal. Discord is excellent for brainstorming but lacks the permanence and accessibility required for official records.

Amending This Governance Document

This document is a living policy. Any community member may propose changes by submitting a pull request to this file.

1. Proposed changes must include a clear rationale.
2. The Steering Committee will discuss the proposal and seek consensus.
3. If consensus cannot be reached, the change will be put to a community-wide vote.
4. A two-thirds majority of valid votes is required for adoption.

Approved changes will be merged and this document updated accordingly.