How the FlightGear project works

See also volunteering.

As FlightGear is becoming increasingly popular each year, we've been seeing a number of controversial discussions regarding the inner workings of the FlightGear project recently. Meanwhile, it is a well-known fact among long-time contributors that the FlightGear development model may seem irritating at first and it is known to cause some confusions or even frustration among new contributors who may already have experience contributing in other flight sim communities or even other OSS software.

This page describes the organizational structure and development workflow of the FlightGear open-source flight simulator project. It is intended for newcomers who want to understand how decisions are made, who does what, and how to get involved.

Overview

FlightGear is an open-source, multi-platform flight simulator developed by a worldwide community of volunteers. The project is not owned by any company; it is managed by a group of core contributors who coordinate development, review contributions, and maintain the infrastructure.

The project consists of several Git repositories hosted on GitLab, with the main ones being:

• flightgear – the main simulator application
• simgear – the simulation libraries for FlightGear
• fgdata – base data package
• manual – introduction for beginners

Governance Model

FlightGear follows a loosely structured, meritocratic governance model:

• Users – provide feedback, bug reports, and feature requests
• Contributors – submit code, aircraft, scenery, documentation, or translations
• Reviewers – experienced contributors who regularly review merge requests
• Core Developers – a group of long-standing contributors with write access to the main repositories and the authority to merge changes

Development Model

FlightGear uses a GitLab-based workflow very similar to the one described in Howto:Start core development.

Branching Strategy

Most active repositories (simgear, flightgear, fgdata) use the following branches:

• next – primary development branch; all new features and non-critical fixes go here
• release/2024.1.6 – stable release branches (e.g., release/2024.1.6) used for backporting critical fixes

The next branch is always open for contributions. It is regularly merged into release branches shortly before a new version is published.

Release Cycle

See release plan for the main article about this subject.

Communication Channels

The project uses several communication platforms:

• Mailing list – flightgear-devel for development discussions
• GitLab Issues – bug tracking and feature requests per repository
• GitLab Merge Requests – code review and contribution integration
• Forum – FlightGear Forum for user support and aircraft/showcase discussions
• Discord – real-time chat

Roles and Responsibilities

Contributors

Anyone can contribute by:

• Submitting merge requests (code, aircraft, scenery, docs)
• Reporting bugs with clear steps to reproduce
• Helping other users on the forum or chat
• Translating the interface or documentation
• Donating hardware, hosting, or financial support (via the official page)

Reviewers

Reviewers are trusted contributors who:

• Triage issues and merge requests
• Request changes or approve contributions
• Ensure code quality, style, and testing standards are met
• Mentor new contributors

Core Team

Core team members have:

• Commit access to one or more main repositories
• Permission to merge approved merge requests
• Responsibility for release management and infrastructure
• The ability to vote (informally) on major project decisions

Getting Involved

If you want to contribute to the official repository:

• See Howto:Start core development