Flight sim community survey: open till November 23

For the first time, FlightGear is taking part in Navigraph’s annual flight sim survey, the largest of its kind (with 17,800 participants in 2019)! By participating, you can help establish a broad overview of the needs and wishes of flight sim users. While the survey is traditionally focused on the big commercial players, we got to help shape some of the questions this year. By participating, you get to show that our open-source flight simulator is a serious alternative (and maybe you learn a bit more about the width of the flight sim world too).

Follow this link to go to the survey: https://www.surveymonkey.com/r/flightsi … flightgear

The survey closes on November 23 and results will be published on the 10th of December. We receive an extract from the (anonymous) answers of our own FlightGear community, so we can see how our community differs from the general flight sim public and hopefully learn some more about our own users.

Thank you for taking part!

FlightGear 2020.3 Released

After two years of work, the new stable release of the free open-source flight simulator FlightGear is finally here: 2020.3! It replaces 2018.3 as our supported, stable version. There’s many updated aircraft, visual enhancements and a new default airport/region: Keflavík (BIKF) in Iceland.

The Alouette III getting close to a volcanic plume.

As always there’s also internal improvements to the flight models and other simulation systems, bug-fixes, and performance improvements.

We’re going to take a proper tour around Iceland in another post, and detail some of the improved feature and aircraft over the next few months. The full change-log is available here. But we’d like to quickly share some highlights below.

To get started straight away, visit our download page.

Welcome to Iceland

Iceland is the world’s newest country, if you’re speaking geographically: a land of ice and fire. FlightGear models several volcanoes with multiple levels of activity: Eyjafjallajökull which disrupted aviation in 2010, Surtsey, and the brooding, powerful, Katla.

Iceland seen from space (using EarthView imagery)

Keflavík International Airport (BIKF) is the featured airport for the release: due to its remote location in the north Atlantic, the long runways have been used by all kinds of aircraft over the years; especially as stop-over for early transatlantic services, but also patrolling military aircraft and transports.

Aircraft

  • The A320 has been overhauled, with accurate simulation and display of the flight management systems.
  • The C182 gained an excellent integration of the FG1000 glass-cockpit, as did the J3 Cub and the Diamond DA40. More aircraft installations are in development.
  • The SEPCAT Jaguar GR.1, Bombardier Q400 and twenty more aircraft were added.

Feature highlights

There’s been many changes since the last release, but here’s a few particular interesting ones:

  • FlightGear now simulates tides covering and uncovering shallow areas (littoral areas), like tidal flats (mudflats). You can see tides as the day progresses – there are two highs and two lows per day.
Morecambe bay at low tide
  • Textures can be cached & compressed for faster loading and reduced memory use, giving better performance.
  • Connection to the VATSIM network via SWIFT is officially supported.
  • Better translation support, and handling of non-ASCII file names.
  • Many view improvements, including a new Tower-AGL view.

FlightGear 2020.1.2 Released

FlightGear 2020.1.2 contains bug-fixes and improvements to the 2020.1 release. For users experimenting with the Compositor renderer, there’s now clearer information on startup, and a simple interface to select the display settings (performance or higher quality)

Bugs affecting macOS users when updating from an older version were fixed, as well as other bugs in GPX flightplan loading.

As usual, grab the updated files here

FlightGear 2020.1 released

The FlightGear development team is delighted to announce the 2020.1 release of FlightGear, the free, open-source flight simulator. This version is a preview of our next stable release, containing many new features and improvements.

Enhancements since 2019.1 include a developer preview of the upcoming Compositor graphical rendering framework as a separate pre-built binary, better aircraft carrier support, improvements to both the JSBSim and YASim flight dynamics models, better view options, more efficient and improved OpenStreetMap buildings and translation of the UI into Polish and Slovak. Here’s the complete list of changes.

Many aircraft have been updated, including major updates to the Boeing 777, Airbus A320, Antonov AN-24, F-16, Piper J3Cub, Saab JA37 Viggen, Piper PA28 Cherokee, Bombardier Q-400, Space Shuttle.

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

New stable release: 2018.3.5

There’s a new stable (long-term supported) release just available on SourceForge : 2018.3.5. This contains some smaller bug-fixes but most importantly, the build now works correctly on macOS 10.15 Catalina. This required updating many internal aspects of how we build the software, which took considerable effort from a whole team of people.

Get the new release while it’s hot: from SourceForge.

A preview of the 2018.3 release

A change to the release philosophy

After introducing the scripted releases four times a year, the FG development team decided to have a discussion to compare this experience with what we had before, and the result of this is that we want

* less changes of the default airport
* make one of the four yearly releases especially stable

This stable release is planned to be the fall release – so you can expect this to be especially well tested.

What else will there be?

The new C-172p

Flightgear’s default aircraft, the C-172p, is now better than ever.

The cockpit has received a lot of improvements, including new recess casings and glass reflection effect to all instruments, previously missing panel parts have now been included, such as alternate static source knob, low voltage LED, lighter hole, a working glove pocket (which holds the GPS device when not in use), sun visors, and PPT cables connected to the yokes. Other improvements include 3D model and textures changes to all levers, toggles, seats, magneto keys, EGT gauge, attitude indicator and ammeter gauge. An ambient occlusion map has been applied to all interior textures, making the cabin look much more realistic.

The plane now makes use of lightmaps, making night flights much more immersive than before. These include post lights, which are installed on individual gauges, a red flood light which can be used during night flights too, and a white dome flight and wing courtesy lights to be used while in the ground during the pre-flight checks. The lightmap illumination responds to the environment light and dims during daylight.

The exterior model has also received some improvements. It now has a much improved vertical stabilizer model, including a retopologized beacon model, and all of the aircraft antennas have been redesigned as to match the gauges in the model P.

The aircraft has also received new sounds: clicking on the checklist in the pocket by the pilot seat, toggling the control lock, mounting and dismounting the GPS from the panel, opening and closing glove pocket, moving the window latches, and toggling the water rudder cable. The flaps lever and flap motor have also received sound improvements.

Other than that, the tutorials and checklists have received much attention, including two new tutorials: take off and landing for float variants. This release also fixes many bugs, among them an adjusted P-factor effect, making the flight model more realistic.

New cloud lighting

In the Atmospheric Light Scattering renderer, an experimental new option for more detailed cloud lighting is now available. This includes diffraction and rainbow effects on high Cirrus clouds as well as more dramatic darkening and silver-lining for lower clouds seen against the sun.

For clouds seen with the sun, Mie scattering is simulated which darkens the fringes of clouds.

(Note that this is an experimental option and may not yet always work as intended.)

Display visuals

Aircraft developers can now use a new effect for displays, which simulates both the eye response to too bright or too dark display settings for the ambient light level and the visuals of dust on the screen surfaces for glancing light angles.

(Note: This needs to be implemented per aircraft and is not available for all.)

Scenery to explore

An exciting new spot to explore is the Arctic island of Jan Mayen, situated north east of Iceland. It received a makeover with corrected elevation data and coastlines, and is now available via TerraSync. The volcano, Beerenberg (2277m) is also now one of the active volcanoes simulated in FlightGear, making for an impressive sight as the snow covered peak belches out smoke and ash.

The island’s airstrip, Jan Mayensfield (ENJA), has a 1600m dirt runway, perfectly suited for the DHC-6 or c172p’s skis.”

Other improved aircraft

Besides the C-172p, several other craft also have received improvements, including

F-14
– Improved low speed handling, flaps aero rework using OpenVSP, spoiler aero added for yaw, adjusted effectivity at higher alpha based on pilot reports and OpenVSP analysis
– APC now holds alpha rather than airspeed.
– Wingsweep (oversweep) now modelled correctly, wing bending (G load, damage), JSBSim systems rather than Nasal.
– alpha indicated has been aligned based on the touchdown geometry of the hook; optimised for 15degrees indicated.
– carrier and tanker now included in replay

F-15
– Exterior model improvements and revised liveries
– added conformal fuel tanks (IAF, AF86-0023),
– MK-84 air to ground support,
– performance improvements (canvas, cockpit model merged with texture atlas), should work better on lower spec. systems.
– more accurately modelled autopilot
– FDM improvements (mass properties for stores corrected, stores drag, correct aero axes)
– FG Fuel&Payload works correctly with aircraft specific stores dialog

Space Shuttle

– Improvements to the visuals, including furry velcro strips
– Improvements to launch guidance and orbital plane targeting
– More realistic OMS burn procedures
– Expanded systems including circuit breaker simulation
– Expanded failure modeling including tank leakage

Other improvements

Lots of other, less visible things are happening behind the scenes:

– improved joystick configuration dialog
– additions to the launcher
– better support for starting aircraft in a certain state
– bugfixes
– and much more…

The Grand View

Earth from space

The view from a spacecraft – dark blue oceans, the multi-colored landmasses, the blue ribbon of the atmosphere and brilliant white cloudbands during the day, long shadows and hues of orange and pink in the dawn zones and finally the gleaming lights of the planet’s cities and the faint strands of aurora in the sky.

Few of us will ever have the chance to go to ISS and view the ‘pale blue marble’ from low Earth orbit – for real that is.

Visualization

Matters are quite different in a simulation of course. Over the last years, Flightgear’s rendering engine for views from orbit called ‘Earthview’ has undergone a lot of improvements and additions, making it one of the best visualization tools available.

Lots of work has gone into the visuals at night. For example, a fairly sophisticated model of Aurora Borealis and Australis colors the sky around the poles. See a diffuse green glow of high Oxygen excitation for low solar activity, or a full auroral arc with slow red Oxygen lines high above, sharp green glow of Oxygen following the field line structure further down, culminating in the purple fringe of Nitrogen excitation.

The night lights of the cities are taken from the NASA visible Earth project – but they are post-processed by a shader to give them the appearance of being composed of millions of small lights.

As a special treat, there are even some thunderstorms with lightning momentarily illuminating the storm cell in a number of places – beware, they are not easy to find!

Earthview also comes with its own runtime-adjustible model for scattering in the atmosphere – dry scatterers give the scene a blue hue, wet scatterers make it appear foggy. The amount of scattering follows the path through the atmosphere – there’s less atmosphere effect on mountains and high plateaus than at sea level. Even a semblance of weather changes can be simulated by either moving the cloudsphere or dialing the density of clouds.

The relief mapping on the terrain give it a 3d appearance, and post-processing adds the appearance of details up to a few dozen meters in size scale. Like the terrain, the cloud map is also post-processed to show shadows and 3d appearance using parallax mapping, and clouds cast shadows onto the terrain – all of which combines to make the scene come alive.

Simulation

Ready to take the trip?

Flightgear has a handful of vehicles which can reach into space, but only two which allow to insert into a stable orbit – the Space Shuttle, and the Vostok-1 carrier. While learning to operate the Shuttle takes some time, Vostok is now equipped with automatic launch guidance, making it a good choice for your first trip into space – like Gagarin, you can just sit back and ride it out.

If your memory and graphics card permits it (8+ GB are a good idea), now would be the time to install a few GB of hires textures linked on the Earthview Wiki page. These textures are not part of a normal FG installation since they are substantially larger than the whole FG data package.

At every step, you can follow the Vostok stage separation in outside view and see the discarded rocket stages disappearing behind you as the next stage ignites.

Once in orbit, you can even try to maneuver around the TDU and get back to the discarded 3rd stage.

There’s not much in terms of maneuvering the Vostok capsule can really do, so you might as well enjoy the view for a few orbits, and eventually turn it around for a de-orbit burn that brings you back onto the ground.

The simulation can’t give you the real feeling of weightlessness, but it tries to bring you close – in the Space Shuttle, you can put a flight data file folder in free-float mode into the cabin – you can watch Earth through the windows while the manual slowly floats through your visual field.

So, get out on the pad, launch into space and enjoy the grand view!

Further reading

The Earthview project page
The Earthview wiki page
The Vostok-1 wiki page
The Shuttle project page

A preview of new features in the Honolulu release

Discover Hawaii

The first FG release in 2018 will move to the tropical island of Oahu, using Honolulu as the default airport. In preparation, the islands of the Hawaii chain have received a makeover – textures for the typical shrub vegetation has been added, the terrain texturing has been improved and the airport layouts have been re-generated.

There’s now a lot of new things to discover – fly to the ‘garden island’ of Kauai and look for waterfalls, search for the new highly detailed aircraft carrier ‘Harry S. Truman’ cruising close to Oahu, watch a sunrise from the summit of mighty Haleakala on Maui or discover an active lava fountain on the ‘big island’.

Active volcanoes

Have you ever seen a volcano eruption in a flightsim? This is your chance – in the upcoming release, you won’t only be able to see lava pools and volcanic smoke of Puu’Oo on Hawaii, but also see lava fountains of the Italian volcano Stromboli and even the mighty ash plumes blown high into the air by an eruption of Etna on Sicily. The activity of all these volcanoes can be adjusted from the Environment GUI.

The current implementation is still limited, but in the future, volcanic ash might actually interfere with the weather and aircraft operations – just like in reality.

Unprecedented vegetation detail

Using geometry shaders, the Atmospheric Light Scattering rendering framework now offers the option to see dense volumetric grass layers on the airport greenspaces, as well as rendering additional 3d layers of vegetation underneath the regular random trees and shrubs in regions where this is configured. This offers the eye a pleasantly high level of detail even at close range and adds much to the visuals. While this technique might be heavy for older graphics cards, the performance on a modern high-performance graphics card is excellent.

A helpful co-pilot

Have you ever wanted to fly a helicopter, but didn’t manage to get it off the ground? The Alouette-III now comes with a helper (or flight instructor) for you – Amelia.

Amelia (named after aviation pioneer Amelia Earhart) is an animated co-pilot capable of taking off, landing and hovering the helicoper for you, according to your instructions. You can simply ask her to get the craft off the ground for you, then fly it a bit forward and then take over from her. Or, if you’re interested in operating the winch and doing rescue operations, she can hover over a spot and move slowly to the right spot according to your directions.

New and updated aircraft

A lot of development has happened for various aircraft – for instance the Robinson R44 helicopter has received a stunning new 3d model and many systems are now simulated in detail.

Another great addition, both in terms of visuals and systems, is the new Cessna C-182. If you like single prop aircraft and want to see something more modern than the default C-172p, try it out – it makes for a great plane to do sightseeing in Hawaii!

The carrier handling of the F-14b is now much more realistic, with arrestor wire effectivity dependent on speed at touchdown, more realistic low speed aerodynamics during the approach and correct ‘kneeling’ of aircraft when on the catapult – take the F-14 to the ‘Harry S. Truman’, and you won’t be disappointed!

Lots of details have also been added to the Citation-II business jet and bugfixes, gear damage, a correct autopilot and an improved radar to the F-15.

…and much more

Much more work going on behind the scenes:

* improved usability and integration of the Flightgear launcher
* fixes for AMD graphics cards rendering issues
* many other small bugfixes
* improvements to the YaSim flight dynamics engine for better realism

Stay tuned as we launch the next release!

FGMEMBERS Statement

FlightGear FGMEMBERS Statement (v2.2):

Preface

What you see today as FlightGear is the result of 20 years of collaborative development effort by hundreds of talented people all working together to provide a freely available GPL flight simulator that anyone can contribute to.  The core FlightGear team feel that it is important to make a clear statement of their position concerning the FGMEMBERS organization, explaining why it is important to continue working in a way that will ensure that FlightGear continues to prosper for the next 20 years as well as to clear up any confusion and FUD that has been disseminated by members of the FGMEMBERS organization.

The FGMEMBERS infrastructure offers little benefit to contributors.  From experience, the core team knows that the lack of appropriate controls on contributions may, after a long period of time, lead to a divergence that may result in contributions being lost.  This includes the divergence of models as well as scenery enhancements that are not contributed to the scene models database.

TOC

Background

During five years of in-depth discussions on the development mailing list (where decisions are made[1]) a consensus of opinion was reached which defined the future direction for the core assets of the FlightGear project.  This required the removal of the aircraft models from the old fgdata repository[2], leaving the core assets and the default aircraft.  Unfortunately this necessary change resulted in a fundamental disagreement with a couple of FlightGear users who demanded that the decision making process be restarted[3].  Clearly with five years of discussions already undertaken it was not a viable path forwards to restart discussing the splitting of the assets and which revision control systems were most suited for the FlightGear project.

One of the objectives of the project is longevity and ensuring that the path taken is, with the best available knowledge, as future proof as possible, allowing authors to make their contributions with the minimum amount of disruption whilst maintaining quality and licencing standards.

As a result of the disagreement, one contributor started what is generally considered to be a hostile fork of the core asset repositories into what is known as FGMEMBERS.  This was expanded to include all the other models and assets from all non-official repositories from all corners of the internet, to form a single source for all contributed assets (core assets, aircraft, scenery, 3rd party hangars, etc.).  At a first glance this appears to be a good idea, as there is a single place where everything can be found.  However the disparate nature of contributions means that FGMEMBERS is a divergence of most of the original content.  Whilst certain repositories may be up to date within FGMEMBERS, it is not necessarily true that this will remain the case.  Taken together, this negates the key benefit of a single location for all content.  The other key point is that any changes contributed to the FGMEMBERS infrastructure may never make it into the original repositories.  This affects the availability and quality of models for the wider community of the FlightGear project, such as the aircraft that are available for download on the FlightGear website and launcher[4].  Any contributor spending considerable time making changes to aircraft or scenery may be unaware that their changes may be lost in the future, especially in the case of scenery as the FGMEMBERS scenery workflow is to modify what is considered to be an automatically generated set of temporary files from base data sources.

Since its inception, the FGMEMBERS organization has continually made very emotive statements and accusations regarding the core development team and the way the FlightGear project is run.  The core FlightGear team consider those baseless and has refuted them.

Official FlightGear Position

The core FlightGear team considers the FGMEMBERS data asset forks to be hostile and the infrastructure bad for the FlightGear project for a number of reasons:

  1. Historically, forks of Open Source projects are unsustainable because developers choose one or the other.  Over time, the vast majority of forks die.  In a small minority of cases they become prevalent and the original dies.  In either case, a huge amount of effort is wasted on the fork that eventually loses.  We feel that effort is better spent on improving the simulator.
  2. It is inevitable that the fork will diverge, as changes are made to one repository but not the other.  Attempting to keep the repositories in sync requires huge amounts of effort and is likely to fail due to incompatible changes being made to the same file by multiple developers.
  3. The FGAddon repository is actively supported by the core development team, with processes in place to ensure the long term health of the repository, and compatibility with any changes to the FlightGear core.  The core FlightGear team have been working on this project for 20 years and has a long track record of ensure the long-term health of the aircraft.
  4. We are concerned that FGMEMBERS deliberately does not have controls over commit access to the repository and as a result license violations have occurred.
  5. Different versions of the same aircraft existing in both FGAddon and FGMEMBERS causes confusion and adds to the burden of support from volunteers who may not have the same version.  This makes tracking down bugs much more difficult.
  6. We object most strongly to the way that FGMEMBERS proponents have evangelized against FGAddon and TerraSync and the accusations that they have made against the core team.  We consider this unacceptable.
  7. The constant and active recruitment of potential developers away from the core infrastructure has caused and is causing a lot of long term harm to the FlightGear project.

The FlightGear development team encourages users and developers to use the official repositories and infrastructure (FGData, FGAddon, TerraSync) and continues to support 3rd party hangars.

FAQ

Why is this important?

Question: What is the point of this document?

Answer:
It is important that we all work together to ensure the continued growth and development of FlightGear.  The core team does not want to see valuable contributions being lost because these contributions were made to something outside of the FlightGear project.  What you see today exists due to the time and effort of developers.  Unfortunately in recent years FGMEMBERS has proved to be a considerable waste of developer time that could have better been spent on improving things rather than dealing with and refuting allegations, answering questions from confused users and declining attempts to reopen discussions that have no relevance for the already decided future path of the project.

Why is FGMEMBERS considered as a legal liability?

Question: Why is the core design of the FGMEMBERS system considered as a legal liability?

Answer:
The official FlightGear infrastructure operates on a basis of trust and experience, in which a committer must be prepared to accept the trust of everyone else and show an understanding of copyright issues.  This is in stark contrast with the FGMEMBERS principle that everyone and anyone can obtain commit access for improving the system.  The FlightGear way has been proven to work over many years as it results in collaborators who can be trusted not to cause damage to the FlightGear project or to cause legal jeopardy by a lack of understanding.  Without this there is an elevated risk that an inexperienced content developer may deliberately or inadvertently obtain material (3D artwork, photographs, sound bites, etc.) found somewhere on the web and include it within their own GPLv2+ licensed content without due consideration of the licencing implications.  The official FlightGear infrastructure has the *-commitlogs mailing lists[5], allowing individual commits to be reviewed; whereas FGMEMBERS has no such system and as such can be considered as a more anarchic system where illegal content will inevitably be added under the radar.  This is unacceptable in a large open source project such as FlightGear as it puts the contributor and the project at legal risk.

Why use the “hostile fork” terminology?

Question: Why is the FGMEMBERS infrastructure referred to as a “hostile fork”?

Answer:
This is standard software development terminology for the FGMEMBERS situation.  Here is one definition:

  • “A HostileFork happens when someone isn’t happy about the way a collaborative effort is being run, so they start their own competing project.  They take the work of the group in a different direction…rather than working on achieving a consensus.  Often they lobby for developers to assist their effort, rather than the original project from which they are derived.”[6]

And another:

  • “A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project.  It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split.Compare to forking to solve a very specific or specialized problem that doesn’t make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case.  In such a case, it’s common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don’t diverge too much.”[7]

The core group consider the current situation to be an exact match to the “hostile fork” definition.

Why not consider the FGMEMBERS proposal?

Question: Why is the design and operation of the FGMEMBERS system considered as unsuitable for use as the official FlightGear infrastructure?

Answer:
Firstly, the proposal was made years after a consensus had been made and a decision reached.[8].

Secondly, the design is considered to be incompatible with how the FlightGear community operates.  The FlightGear community is bound together by mutual respect and basic courtesy; there may be disagreements but it is expected that disagreements be handled in a respectful way without personal attacks.  The wishes of all contributors wherever possible are respected.  There are some models in FGMEMBERS in which the original authors have directly stated a wish to not have their aircraft be distributed as part of this system.  Instead of respecting that wish, these aircraft remain bundled as part of the FGMEMBERS.

Another concern, and in many ways for the community a large concern, is the encouragement to make contributions outside of the official or original author’s distribution channels.  This is a key aspect of the FGMEMBERS system used to advertise to new users that the FGMEMBERS system is superior to the original upstream sources.  Hence the FGMEMBERS system strongly competes against those wishing to be independent of the system, using an “improved” version of their own work.  To avoid this, a number of content creators have used specific licensing to legally block FGMEMBERS redistribution.  But in the process these authors have lost part of their freedom that the GPL licence offers — the same freedom that has allowed FlightGear to become what it is today.  This is causing long-term damage to the FlightGear project and the GPL ecosystem built around it.

We consider that redistribution for solely aggregation and deliberate divergence of GPL-licensed content is permissible legally but morally questionable.  Particularly when it is against the wishes of the original author, and implicitly competing against that author for the aim of selling the FGMEMBERS system.  This is considered unacceptable as a model of operation for the FlightGear project.

Why not peacefully coexist?

Question: Why is FGMEMBERS different from all of the other 3rd party infrastructure and peaceful coexistance not possible?

Answer:
The aim of the FGMEMBERS organization is to attract as many FlightGear users and content developers as possible to become the de-facto FlightGear content infrastructure.  To achieve this, FGMEMBERS deliberately aims to minimise or completely cut off contributions upstream to the core FlightGear infrastructure for the sole purpose of rendering it irrelevant.  However as the same design is used for both the core infrastructure and the 3rd party infrastructure, this affects the whole of the FlightGear community equally.  FGMEMBERS hoards absolute all of the content from all content creators, but then applies fixes and improvements that are not submitted back upstream to the original authors, using the excuse that upstream should find and backport the fixes themselves.  This is specifically to use as a selling point against the official and 3rd party FlightGear content infrastructure.  Because of this positioning, the FGMEMBERS organization is unlike any other 3rd party infrastructure — it is not complementary to the FlightGear ecosystem but is rather competitive to it.

Why is syncing not possible?

Question: FGMEMBERS intends to sync all changes from FGAddon, why can’t FGAddon simply merge all the changes from FGMEMBERS so the repositories remain identical?

Answer:
There are three reasons for this.  Firstly, over time the repositories will diverge in a way that is impossible to reconcile (e.g. two different developers with different end goals modify the same aircraft model at the same time).  Secondly, such a merge would require a large, continuous amount of effort just to maintain a position that would exist without FGMEMBERS.  Thirdly, we have concerns over the attitude of FGMEMBERS to licensing and accepting almost all content, and are not prepared to legally risk the GPL “health” of FGAddon.

For many years it has always been that FGAddon and its predecessor infrastructure is the definitive place for the FlightGear models.  As part the FlightGear contribution workflow, the responsibility is on the content author to contribute to FGAddon when their work is ready for release.  Once the work is present in FGAddon, the author is then expected to maintain the aircraft in FGAddon.  This is how development has always been performed and it works well and everyone understands it.
To change this now so that it becomes the responsibility of someone else, other than the contributor making the changes is clearly an unworkable solution.  However the published procedure for adding or modifying FGAddon does not preclude contributions from anyone who is prepared to follow the submission rules and content guidelines.  So FGMEMBERS could, if they so wished, follow these procedures to ensure that FGAddon remains the core asset that is definitive and up-to-date.

Why not switch the core infrastructure to FGMEMBERS?

Question: Why can you not work with the FGMEMBERS team to create a single repository?

Answer:
Primarily this is not possible as it would require reopening a discussion that was ongoing for 5 years — and this approach is merely a different way of doing things that does not provide any real benefits to the long term goals of the project.

Why Subversion?

Question: Why do you use Subversion instead of my preferred version control system?

Answer:
Subversion was agreed upon during the discussions on the development mailing list as it provided most of the required facilities in a way that worked for the wider community.

Why have gatekeepers?

Question: Why does FGAddon have gatekeepers?

Answer:
The official policy[9] is designed to allow for easy access to FGAddon for contributors whilst maintaining quality and legal standards.  As the official FlightGear repository has obligations and legal liabilities, the gatekeepers are there to ensure these quality guidelines are met.  The gatekeepers are friendly and helpful — their role is to promote the development of aircraft while respecting the community rules and to guide new contributors; who themselves may gain, or already have, the experience to be a gatekeeper.

How do I contribute?

Question: How can I send improvements to FGAddon for inclusion into the official repository of aircraft?

Answer:
As detailed on the FGAddon wiki article, there are a number of steps.  Firstly the original aircraft authors should be contacted.  If this is not possible, then send an email stating your intentions to the FlightGear development mailing list or post a message on the forum.

Why should I contribute upstream?

Question: Why would I want to contribute to FGAddon when I could just hack away and publish my changes in a forked repository?

Answer:
Contribution to FGAddon guarantees the widest distribution of your work by including your work into the FlightGear project (your improvements will be available on the official download page and inside the launcher).  You are also contributing back and collaborating with the FlightGear project.  This is a proven method to ensure continued and long term availability of your improvements for years to come.  If an original aircraft developer is still active it is normally considered respectful to work with that author as it will often benefit everyone involved, rather than taking their work and competing against them.  Otherwise this will result in two versions that have different improvements, when the goal should be to all work together to provide the best models that collaboration can build.

Can I obtain commit access?

Question: Is it possible for me to obtain commit access to the FGAddon repository?

Answer:
You are encouraged to apply for commit privileges as soon as you feel that you meet the criteria and are ready to take on the responsibility[10].  If in doubt, send an email to the FlightGear development mailing list.

Is FGMEMBERS a 3rd party hangar?

Question: Are the FGMEMBERS aircraft repositories considered as a 3rd party hangar?

Answer: No.
As FGMEMBERS has aggregated all of the FlightGear assets, including FGData, FGAddon, TerraScenery, 3rd party hangars, and all other sources, the aircraft component of this system is not considered as a 3rd party hangar.  As it is a hostile fork, unlike the 3rd party hangars, it competes directly against the official FlightGear data assets and infrastructure as well as the 3rd party hangars.  It also competes for developer resources against the FlightGear project and 3rd party hangars.

Conclusion

We believe that the best path forwards for FlightGear is for the community to work together.  We recognise the importance of contributors and collaboration and positively encourage everyone to work together with the common goal of improving FlightGear in a positive way, and to be respectful, honest, trustworthy and fair.  Let’s get the word out and make sure that FGMEMBERS has to communicate with a well informed audience.