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
- Official FlightGear Position
- FAQ
- Why is this important?
- Why is FGMEMBERS considered as a legal liability?
- Why use the “hostile fork” terminology?
- Why not consider the FGMEMBERS proposal?
- Why not peacefully coexist?
- Why is syncing not possible?
- Why not switch the core infrastructure to FGMEMBERS?
- Why Subversion?
- Why have gatekeepers?
- How do I contribute?
- Why should I contribute upstream?
- Can I obtain commit access?
- Is FGMEMBERS a 3rd party hangar?
- Conclusion
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:
- 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.
- 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.
- 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.
- We are concerned that FGMEMBERS deliberately does not have controls over commit access to the repository and as a result license violations have occurred.
- 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.
- 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.
- 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.
