Governance

How decisions get made. Who gets to make them. How the project survives the people who started it.

The governing documents themselves live in flighthelp/governance (licensed CC0 so any public-interest project can fork them). This document explains the structure and reasoning.

Legal structure

flighthelp is incorporated as a non-profit foundation in the European Union, with a US 501(c)(3) sister entity established once the project crosses funding thresholds that justify the legal cost (typically year 3).

The EU foundation is the primary legal entity. It holds the intellectual property assignments (schemas, engine, data, code), the trademarks, the contracts with employees and contractors, and the bank accounts. The US entity exists for US donor tax deductibility and US-specific grant eligibility; it has a parallel board and a fiscal-sponsorship arrangement that keeps operations unified.

The non-profit structure is irreversible by design. The bylaws prevent:

  • Conversion to a for-profit entity
  • Sale or transfer of the IP to any commercial entity
  • Distribution of assets to individuals (other than as employment compensation)
  • Amendment of the asset-disposition clause (which requires dissolution to transfer assets to another aligned non-profit)

These restrictions are the structural enforcement of Principles 5 and 6.

The board

The board (also called the core team) consists of 5–9 elected members serving staggered 3-year terms.

Composition

The bylaws require the board to include:

  • At least 1 member with deep aviation industry experience (former airline employee, regulator, or industry analyst)
  • At least 1 member with legal expertise in passenger rights or consumer protection
  • At least 1 member representing the contributor community (elected by trusted contributors)
  • At least 1 member with technical infrastructure expertise
  • At most 2 founders or early team members (to ensure renewal)
  • No more than 1 board member affiliated with the same external organization
  • Geographic distribution across at least 3 continents at all times

These composition requirements protect against capture: by a single industry, by founders' inertia, by a single funder, by any one country's interests.

Powers

The board:

  • Approves the annual budget and reviews quarterly financials
  • Hires and reviews the executive director
  • Approves major partnerships and grant acceptances
  • Approves changes to the bylaws (with required member ratification)
  • Resolves appeals of major moderation decisions
  • Approves new major versions of the schemas and the rules engine
  • Approves new jurisdictions for the rules engine

The board does not:

  • Set individual data values (the moderation system does)
  • Override individual moderation decisions without an appeal
  • Direct engineering implementation details (the engineering lead does)
  • Approve individual financial transactions (the executive director does within budget)

Meetings

The board meets quarterly, plus emergency sessions as needed. Meetings are minuted, the minutes are public (with redactions for personnel and legal matters), and decisions taken in emergency sessions are ratified at the next regular meeting.

Quorum is 5 members. Decisions require a simple majority of present members for routine matters, and a 2/3 majority for bylaw changes, IP licensing exceptions, and major commercial partnerships.

Compensation

Board members are not compensated for board service, except for expense reimbursement. The executive director, who sits on the board ex officio, is compensated as an employee.

This non-compensation rule prevents the board seat from becoming a sinecure and ensures that members serve out of mission alignment, not financial interest.

Elections

Founder seats

For the first 5 years, up to 2 board seats are reserved for founders. After year 5, all seats are elected.

Community seat

At least 1 seat is reserved for a representative elected by trusted contributors (tier Trusted or higher). Voting is one-trusted-contributor-one-vote, conducted online with a 14-day voting window. The community seat is held by a contributor in good standing who is not also a paid employee of the project.

Other seats

Other seats are elected by the existing board from a public candidate pool. Candidates self-nominate or are nominated by others. The election process is:

  1. Open nomination period (30 days)
  2. Public candidate Q&A (14 days, on the project's mailing list and forum)
  3. Board vote (in-camera, simple majority)
  4. Community review period (14 days, during which a 1/3 petition of trusted contributors can force a community ratification vote)
  5. Member ratification only if triggered

Removal

A board member can be removed:

  • By their own resignation
  • By a 2/3 vote of the remaining board with cause
  • By a community petition of 1/3 of trusted contributors triggering a removal vote, requiring 2/3 community majority

Causes for removal include: breach of code of conduct, conflict of interest unaddressed, repeated non-attendance, and gross misconduct.

Decision categories

Different decisions get made by different parts of the project.

Schema changes

See SCHEMAS.md for the full process. Summary: proposed by anyone, 14-day comment period, simple board majority for minor versions, 2/3 board majority for major versions, with trusted-contributor advisory input on majors.

Rules engine changes

Proposed by anyone, reviewed by the rules-engine maintainers. Bug fixes and clarifications: maintainer approval. New regimes: maintainer plus board approval. Interpretation changes that overturn prior decisions: maintainer plus board plus aviation-lawyer advisory.

Data policy

What's in scope, what's out of scope, what fields exist, what categorical buckets are used. Set by the board with community comment. Changes require a 30-day public comment period.

Operational policy

Day-to-day operations: scraper cadence, queue prioritization, support response targets. Set by the executive director with engineering lead input. Major changes (e.g., adding paid headcount, changing on-call structure) require board approval.

Financial decisions

Annual budget: board-approved. Within-budget transactions: executive director with bookkeeper oversight. Single transactions above 5% of annual budget: board pre-approval. Above 10%: board pre-approval and explicit budget amendment.

Partnerships and integrations

Commercial API tier customers: handled by operations, no board involvement unless contract size exceeds 10% of annual revenue. Strategic partnerships (e.g., with foundations, regulators, or AI labs): board approval. Anything that could be construed as a conflict of interest: board approval plus public disclosure.

Moderation

Individual moderation decisions: moderators. Appeals: senior moderators or board. Policy changes: board. Removal of moderators or core team for misconduct: board.

Conflicts of interest

Every board member, employee, and senior moderator discloses:

  • Current and recent employment
  • Equity holdings in aviation-related companies (airlines, OTAs, claims companies, comparison sites, travel insurance, ground services, AI labs)
  • Consulting relationships
  • Significant donations made
  • Familial relationships with anyone in aviation industry

Disclosures are public for board members and senior staff (with the option to redact specific employers if disclosure would create personal risk; in such cases, the executive director maintains the full record privately).

When a conflict exists, the conflicted person:

  • Recuses from any vote on the matter
  • Does not participate in discussion
  • Does not access non-public materials related to the matter

The conflict-of-interest policy is in flighthelp/governance/CONFLICTS-OF-INTEREST.md.

Succession

The project is designed to outlive its founders. Several structures protect against single-person dependencies.

Bus-factor mitigation

No single person controls:

  • Production infrastructure (multiple people have credentials, rotated)
  • The trademark (held by the foundation, not any individual)
  • The domain names (held by the foundation, with multi-person renewal alerts)
  • The bank accounts (require multiple-signature for transactions above thresholds)
  • The IP assignments (all signed to the foundation, not to individuals)
  • The GitHub org (multiple owners, no single account can transfer ownership)

The "what if the founder gets hit by a bus" document is in flighthelp/governance/CONTINUITY.md. It specifies, for every critical resource: who has access, who is the backup, how access transfers in an emergency.

Founder departure

Founders are expected to rotate off the board within 5–10 years and out of operational roles within 3–5. The project respects continued involvement (advisory roles, contributor work) but the operational dependency on founders ends by year 7 at the latest.

Dissolution

If the project must dissolve, the bylaws specify:

  • All assets transfer to another aligned non-profit (chosen by the board at dissolution; the bylaws list pre-approved candidates: Wikimedia Foundation, Software Freedom Conservancy, Open Knowledge Foundation, Linux Foundation Europe)
  • The dataset and code remain open
  • The trademark transfers with the assets, with a 5-year grandfather period during which any successor must clearly communicate the transition

Dissolution requires a 4/5 board vote and a 60-day public notice period.

Amendment process

The bylaws are amendable through:

  1. Proposal by board member or by petition from 10% of trusted contributors
  2. 30-day public comment period
  3. 2/3 board vote
  4. Trusted-contributor ratification (if the amendment affects community rights or governance structure): simple majority of trusted-contributor votes cast in a 14-day window with quorum of 100 voters

Some clauses are not amendable through this process:

  • The non-distribution clause
  • The IP-stays-open clause
  • The dissolution provisions
  • The amendment process itself (without supermajority plus member ratification)

These clauses can only be changed through the high-bar process of dissolution-and-reincorporation, making them effectively permanent.

Why this structure

The governance is more elaborate than most early-stage projects need. The elaboration is intentional.

Public-infrastructure projects fail in predictable ways: founder capture, funder capture, industry capture, mission drift, succession failure, internal conflict, drift toward commercial-friendly compromises. Each governance structure exists to prevent one of these failures.

The composition requirements prevent industry and geographic capture. The conflict-of-interest policy prevents commercial influence on editorial decisions. The community seat and the trusted-contributor ratification rights prevent disconnection from the volunteer base. The non-distribution and dissolution clauses prevent commercial conversion. The amendment thresholds prevent rapid drift. The succession requirements prevent founder dependency.

None of this guarantees success. It just removes the most common failure modes for projects in this space. The remaining failure modes — being irrelevant, being out-competed, being legally crushed, being underfunded — require ongoing work to mitigate. The governance can't help with those. What it can do is make sure the project doesn't lose itself along the way.