Aim
The goal of the FlightGear project is to create a sophisticated and open flight simulator framework for research, education, industry, and home use.
Policies
The FlightGear project operates as a meritocracy on the principles of politeness, respect, trust and humility.
All decisions affecting the core of the project (e.g. simgear/flightgear source code, fgdata, releases, infrastructure, future direction) are made on the flightgear-devel@lists.sourceforge.net mailing list, and those interested in the development of the project are strongly encouraged to subscribe. Participants on the mailing lists are expected to post using their real names and follow the principles above. Personal attacks, flame-wars, or other negative, non-constructive behavior will not be accepted.
Contributions from new developers are encouraged. Merge requests should be made using the tools available from the respective repositories. Patches sent to the mailing list are also welcome. Small, stable, incremental changes are preferable to larger monolithic changes to ease review. To maximize the spread of knowledge, contributions are encouraged in all areas of the project.
All contributions to the flightgear repository must be released under the GNU General Public License V2.0 with the “or any later version” option (GPL2+). All contributions to the simgear repository must be released under the GNU Library General Public License V2.0 with the “or any lager version” option (LGPL2+). All source code files should include the standard (L)GPL2+ header and the original author copyright statement. The authorship of subsequent modifications are not recorded within source code files – instead they are recorded in commit messages in the appropriate version control system.
All contributions to the fgdata repository must be compatible with the GPL. Completely original contributions are strongly encouraged to be released under the GNU General Public License V2.0 with the “or any later version” option. A list of compatible license is available from www.gnu.org/licenses/license-list.en.html.
The names of contributors with commit rights to the core repositories are published and kept up to date. Commit rights are granted by consensus of the existing committers, based on showing good judgement and having a good track record with the project.
Aircraft released under the GPL2+ may be hosted on the fgaddon repository, for which their author will receive commit rights. All contributions to fgaddon repository must be compatible with the GPL, and should include an AUTHORS file listing the copyright holders of the aircraft and a COPYING files containing the GNU General Public Licence V2.0 license text (http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt). Such aircraft are considered projects in their own right, but may receive updates from the core committers for bug fixes and compatibility with core changes. Aircraft authors must review all merge requests to their aircraft, provide feedback, and work with other contributors. If an author is no longer available, the aircraft may be maintained, adopted and improved by other contributors. The core committers will adjudicate on any disagreement and reserve the right to revoke commit rights.
Hosting aircraft on FGAddon is encouraged to ensure the availability and longevity of open source aircraft.
Road map
This is the road map for the 2016.X releases. It is not exhaustive but describes the main development aims of the core developers.
Migrate FG from a monolithic executable to a HLA architecture. The primary split will be to separate rendering from the rest of the simulator, but other components such as FDM, weather, scripting may follow. This will result in more consistent frame-rates, better resource use of multi-processor systems, easier integration into industrial and research applications, and allow support for alternative rendering engines.
Complete implementation of a package manager, allowing aircraft to be downloaded and loaded in-sim. This will improve ease of use and deployment primarily for home enthusiasts.
Replace the plib GUI with Qt. This will improve the maintainability of the GUI as well as being visually more appealing. At the same time, allow the GUI to be run in a separate window from the main simulator. This is of particular interest for multi-screen applications.
Integrate OpenStreetMap (OSM) building data into the main scenery workflow. This will allow a mixture of auto-generated buildings and OSM buildings depending on the availability of data.