WARNING LEVEL High. FGMEMBERS under official Attack!

[IAHM-COL]

Ok, so today the attack changed under drafting the "statement" here I reproduce the content of the devel list

[IAHM-COL]

Hi All,

As promised, below please find a draft statement on FGMEMBERS. The
aim is to post this on the FlightGear website, and use it as a
reference when questions come up about FGMEMBERS from users, and also
as a refutation of some of the claims from FGMEMBERS proponents.

I'd appreciate any and all comments. In particular, I suspect there
are other FAQ entries I haven't thought of - particularly questions
from confused users.

-Stuart

=Preface=

There has been a lot of confusion and FUD caused by the FGMEMBERS
repository. The core FlightGear team feel that it is important to
make clear statement of their position on the matter, and also provide
an FAQ.

=Background=

FGMEMBERS resulted from a fundamental disagreement of a couple of
individuals with the consensus of the core FlightGear team over an
infrastructure change and split of the FGData repository. That
consensus had built up over a number of years of discussion on the
mailing list.

As a results FGMEMBERS forked the FGAddon repository. FGAddon is the
official aircraft repository for the FlightGear project, and the
source of the aircaft that are available on the FlightGear website.

Subsequently, FGMEMBERS proponents have continually made very emotive
statements and accusations regarding the core development team and the
way the project is run. The core FlightGear team consider those
baseless and has refuted them.

=Official FlightGear Position=

The core FlightGear team considers the FGMEMBERS fork to be bad for
the project for a number of reasons and encourages users and aircraft
developers to use the official FGAddon respository instead.

1) Historically, forks of Open Source projects are unsustainable as
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.

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 15 years and has a long track record of ensure the
long-term health of the aircraft.

4) We are concerned that FGMEMBERS does not have robust enough
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 the accusations that they have made
against the core team. We consider this unacceptable.

=FAQ=

Q: Why is this important?
A: FlightGear exists due to the time and effort of developers.
FGMEMBERS has wasted a huge amount of developer effort in refuting
allegations and dealing with questions from users. This is effort
that would otherwise be used to develop the next version of
FlightGear. This is having a visible detrimental affect on the
project as enhancements for the next release are having to be put on
hold. This needs to stop, and this document will hopefully help.

Q: FGMEMBERS intends to sync all changes from FGAdoon. Why can't
FGAddon simply merge all the changes from FGMEMBERS so the
repositories remain identical?
A: 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 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 are not prepared to risk the GPL "health" of FGAddon.

Q: Why can you not work with the FGMEMBERS team to create a single repository?
A: FGAddon represents the consensus of the core flightgear developer
community, and was a decision made over the course of a number of
years with much discussion. We are not prepared to re-open that
discussion, nor change a decision simply because a a very small vocal
minority do not agree with that consensus.

[IAHM-COL]

Hi Stuart,

Thanks for taking the time to organize and assemble this statement. After a first read it looks like a fair, accurate, and measured summary of the situation.

Best regards,

Curt.

[IAHM-COL]

Hi,

On Tuesday 15 September 2015 11:33:22 Curtis Olson wrote:

> Thanks for taking the time to organize and assemble this statement. After
> a first read it looks like a fair, accurate, and measured summary of the
> situation.

I disagree. It is a summary of FG' core team's position, but surely neither
fair nor exactly accurate. The relations seem to have deteriorated since then,
but FGMEMBERS did _not_ start as a hostile fork. It started as a suggestion
for a git based repository followed by a proof of concept.

Sorry, that I have to say this, but shoving the blame for the current mess
into FGMEMBERS' direction is everything but fair. From the very first email
suggestion, FG' core team's reaction has been a "we don't even want to listen
to any arguments, our decision is set in stone". I can't remember a single
statement that I would categorize as cooperative. The only fault of the git
based suggestion was that it came just months too late, when the switch to svn
already happened and everyone was understandably tired of the discussion.

I love the work you have done all these years and I'll be eternally grateful
for it, but in this matter you have not shown your best side. If all the time
that has been wasted by refuting FGMEMBERS and putting it down had been
invested into vetting commits and merging them into FGAddon, there would be no
concern about repositories drifting apart. Cooperation would have been a
wonderful tool to exert influence and help avoiding license violations. The
"summary" reads like those are a new trait brought by FGMEMBERS, but come on.
We had our fair share of license issues in the official repositories, too over
the years.

As a constructive suggestion on how to improve the summary, I humbly suggest
to stick to technical arguments and real facts. It should be enough to state
that the repositories are drifting apart with different improvements to
aircrafts being made and that the official repository benefits from the
maintenance of core developers. No need to point fingers and assign blame.

Putting the statement online as it is can only enlarge the tensions. Please,
let's avoid that.

Stefan

[IAHM-COL]

On 09/15/2015 02:00 PM, Stefan Seifert wrote:
> I disagree. It is a summary of FG' core team's position, but surely
> neither fair nor exactly accurate. The relations seem to have
> deteriorated since then, but FGMEMBERS did _not_ start as a hostile
> fork. It started as a suggestion for a git based repository followed
> by a proof of concept.

Hi,

To add some data to the discussion, Israel is actively messing with
private hangars to meet his "own agenda" (sic, his words) We had a nasty
episode in the c172p-detailed project when Israel proposed some changes
only in the benefit of FGMEMBERS. His changes were initially dismissed,
but he insisted more than I judge necessary. The public discussion is
here https://github.com/Juanvvc/c172p-detailed/pull/218 along with many
private emails.

I think the proposed statement is adequate and necessary.

For the sake of fairness, this episode only lasted a couple of days and
has not influenced the c172p-detailed project. Israel has also
contributed later with useful enhancements to the project.

Juanvi (ludomotico)

[IAHM-COL]

On 15 September 2015 at 14:00, Stefan Seifert <nine <at> detonation.org> wrote:
> Hi,
>
> On Tuesday 15 September 2015 11:33:22 Curtis Olson wrote:
>
>> Thanks for taking the time to organize and assemble this statement. After
>> a first read it looks like a fair, accurate, and measured summary of the
>> situation.
>
> I disagree. It is a summary of FG' core team's position, but surely neither
> fair nor exactly accurate. The relations seem to have deteriorated since then,
> but FGMEMBERS did _not_ start as a hostile fork. It started as a suggestion
> for a git based repository followed by a proof of concept.
>
> Sorry, that I have to say this, but shoving the blame for the current mess
> into FGMEMBERS' direction is everything but fair. From the very first email
> suggestion, FG' core team's reaction has been a "we don't even want to listen
> to any arguments, our decision is set in stone". I can't remember a single
> statement that I would categorize as cooperative. The only fault of the git
> based suggestion was that it came just months too late, when the switch to svn
> already happened and everyone was understandably tired of the discussion.

Hi Stefan,

I would rather say that FGMEMBERS came out not months but rather 5
years too late, and importantly 4 years after exactly the same
solution had already been tried and tested by the FlightGear project,
but failed and was abandoned. To explain this and for reference, I
would like to copy and paste from my forum post from
https://forum.flightgear.org/viewtopic. ... 10#p256448
. I think a number of people here on this list might remember Cedric,
Gijs, and Jorg's attempt in Oct. 2011 to split up the old fgdata into
fdata new and the flightgear-aircraft git+submodule idea with one
repository per aircraft (and possibly correct or add to some of the
details). The text, with some minor corrections, for archival
reference is:

=======

I think that a little walk down history lane will give a bit of
context and help understand the perspective of the long-standing
FlightGear code and content developers. Firstly, here is the birth of
FGMEMBERS:

"[Forum] Re: USA TOUR Event | SAT FEB 21ST 17:00 - 24:00 UTC" (
https://forum.flightgear.org/viewtopic. ... 30#p231107
) (note the date of 2nd Feb, 2015).
"[Forum] Cloning fgdata with GIT submodules" (
https://forum.flightgear.org/viewtopic.php?f=85&t=25314 ) (5th Feb,
2015).

Reading the first thread clearly shows a knee-jerk reaction to not
knowing about the split, after the FGData/FGAddon split was finalised.
Now, the idea of the FGData split into fgdata-new and
flightgear-aircraft (a.k.a. FGAddon) is old, very old. An important
history lesson can be learnt from this abortive 1st attempt:

"[Flightgear-devel] FGData Split Completed - a.k.a. Life after the
Split" ( http://thread.gmane.org/gmane.games.fli ... evel/66846 )
(note the date of 18th Oct, 2011).
"[Flightgear-devel] fgdata: Important note" (
http://thread.gmane.org/gmane.games.fli ... evel/66913 ) (19th
Oct, 2011).

The splitting discussions significantly pre-date this, and then
followed it until the final agreed upon solution of FGAddon was
created. Also see the wiki article:

"[Wiki] FlightGear Git: splitting fgdata" (
http://wiki.flightgear.org/FlightGear_G ... ing_fgdata )

Going back in time in this wiki article to "Revision as of 19:14, 16
November 2011 by Durk" (
http://wiki.flightgear.org/index.php?ti ... ldid=37140
):

"""
To Split or not to Split, that's the question
After much discussion on the mailing list, it was decided to put the
existing attempt to split FGdata on hold until further notice. The
main reason for postponing the split was that, while it was considered
a well intended initiative, the end result of the splitting process
itself left the FlightGear fgdata project in a less than desirable
state. For this reason, before another splitting attempt is to be
undertaken, the pro's and con's of each step should be carefully
evaluated. This article discusses some of our options and will
formulate a plan of approach that can be presented to -and discussed
in further depth- on the developers mailing list. Several reasons have
been put forth to split fgdata:
"""

To say that the FGAddon concept is not well thought out, to also fight
the FG developers ("I invite you all to join the resistance" (
https://forum.flightgear.org/viewtopic. ... 14#p231385 ),
"And maybe everyonce certain time it may be possible to update the
modular repo with changes that stubbornly end up in the wrong place
(a.k.a SVN fgaddon)" (
https://forum.flightgear.org/viewtopic. ... 15#p231856
), etc.), and, from first hand accounts that I've heard, the intense
personal and private attacks on almost all of the core FG developers
once it was realised that FGMEMBERS could not replace FGAddon - this
is disrespectful to the FlightGear developers, past and present, who
have spent almost half a decade debating and refining the current
FGData/FGAddon design.

Note the almost identical set up between the Gitorious
flightgear-aircraft design and the GitHub FGMEMBERS design - the
splitting up individual aircraft into individual repositories, loss of
central control, the git submodule idea (as first proposed by James
Turner), etc. The original wiki page by Gijs is interesting:

"[Wiki] FlightGear Git: splitting fgdata (Revision as of 08:07, 16
October 2011 by Gijs)" (
http://wiki.flightgear.org/index.php?ti ... ldid=36018
).

Note that Cedric was not a FG developer, in that he has no commits in
the core repositories, but was helped by Gijs and Jorg. Also relevant
to FGMEMBERS design of handing the keys to all interested developers
would be this from Gijs (
http://thread.gmane.org/gmane.games.fli ... ocus=66855
):

"""
On 18.10.2011 19:46:58 GMT, Gijs de Rooy wrote:
My "plan" is still to keep the aircraft under the FlightGear Aircraft
project, as written down on the
wiki page http://wiki.flightgear.org/FlightGear_G ... ing_fgdata I did
not add 387 repositories
to Gitorious (by hand!) to see them dissolve

After a simple test I found out that granting admin rights to aircraft
authors will also mean that they
can revoke the flightgear-aircraft team's rights. And if that is done,
we'd have no control over the
repo whatsoever. We even would be unable to delete it (only way is to
delete the entire project, but
as you can imagine that isn't "a way").

I've added this to the "Questions" section at the wiki. Please see if
you can answer/ask any other
questions/concerns: http://wiki.flightgear.org/FlightGear_G ... #Questions

Therefore I think we shouldn't give aircraft authors full admin rights
over their aircraft's repos. I did
add all fgdata-developers and flightgear-developers to the
flightgear-aircraft team, so anyone that
was able to push to fgdata/flightgear should be able to push to all
aircraft repos. Please let me know
when you're missing.
"""

If you read the whole archived thread "[Flightgear-devel] FGData Split
Completed - a.k.a. Life after the Split" (
http://thread.gmane.org/gmane.games.fli ... evel/66846 ) and the
following "[Flightgear-devel] fgdata: Important note" (
http://thread.gmane.org/gmane.games.fli ... evel/66913 ), which
will take time, you'll see a mirror image of the current discussions!
Even Thorsten's arguments are the same. Simply replace Gitorious with
GitHub, flightgear-aircraft with FGMEMBERS, and Cedric with Israel and
these 2011 mailing list threads could very well be these 2015 forum
threads. The development concept behind Gitorious flightgear-aircraft
and GitHub FGMEMBERS are both based on the principle of anarchy to
facilitate development, removing barriers of entry, and the arguments
for this design are identical. I'm starting to wonder if Cedric and
Israel are not one and the same person

I would like to quote an old FG developer who is no longer around -
Thorsten. Not Thorsten Renk, but rather Thorsten Brehm. The
arguments he presents about "[disolving] our central community
aircraft repository" (
http://thread.gmane.org/gmane.games.fli ... ocus=66854
) fit quiet well to the argument against the FGMEMBERS anarchic model
with no central control, and its "stated and undisputed goal of
replacing FGAddon" (
https://forum.flightgear.org/viewtopic. ... 75#p241316
):

"""
On 18.10.2011 19:03:47 GMT, ThorstenB wrote:
A community repo has a lot of advantages. When people leave, work isn't
lost - maintenance kind of automatically "transfers" to the community.
When really necessary, we can also apply patches - i.e. when something
about the flight sim itself has to be changed and aircraft really need
to be adapted (which we usually try to avoid, of course).
A central repo also allowed us to use the bug tracker for aircraft
issues. No one is going to work the bug tracker for issues which affect
aircraft living in some dodgy private hangar, probably in 8 different
versions maintained by 3 different authors - and we're going to see
loads of aircraft forks, without an "official" repo.

We'd also be seeing fewer GPLed aircraft. So far, we had the strict
rule: only GPLed stuff was accepted - which was very good for the
project. Without such a central hangar, there is one reason less for
GPL. And when the majority of aircraft wasn't GPLed any longer,
FlightGear will be much less attractive. And why should someone work on
_GPLed_ FG core sources - if the rest isn't?

The aircraft in our main repository are worth a lot. It's been there for
many, many years and it took many, many hours to create. The aircraft
probably account for far more than 50% of the time spent on creating
FlightGear. It'd be extremely unfortunate to drop all this from the FG
community project. And only being slightly provocative: if splitting
FGDATA now turns toward a path of "breaking up" our FG aircraft - I'll
rather propose to keep the existing FGDATA.

So, before any such major decision affecting the community is made here,
I would really like everyone's opinion. Especially Curt's...
"""

So let me just repeat something I've mentioned a number of times,
mainly in private messages. Those who do not learn from history are
doomed to repeat it! And repetition this sure is!

=======

Regards,

Edward

[IAHM-COL]

Hi Edward,

I just wanted to say thanks for spending so much time to researching and summarizing all these relevant threads. That is a huge amount of work and it's worth taking notice of Edwards message and reading through some of these links for anyone wanting to understand this situation better.

One of the difficulties is the huge incredible volume of postings by fgmembers in response to any attempt at discussion of this issue. So much that it's impossible to respond to (or even read) it all. A point not countered is a point lost ... right??? So one way to win an argument is to produce more volume than anyone can directly respond to. That also has the advantage of obfuscating the situation so that casual readers have no idea what's really going on.

Perhaps people will notice that I am intentionally keeping my responses short and focused.

Curt.

[IAHM-COL]

It looks rather long to me.

Alan

[IAHM-COL]

> Stuart Buchanan wrote:
>> =Preface=
>>
>> There has been a lot of confusion and FUD caused by the FGMEMBERS
>> repository. The core FlightGear team feel that it is important
>> to make clear statement of their position on the matter, and also
>> provide an FAQ.
>>
>> =Background=

I'd like the Background section to be written in a strictly
chronological order (i.e. not start with the disagreement). Also,
seeing that IHAM-COL in [1] feigned to think that FGAddon was not
part of FlightGear, I think it is important to make that clear.

[1]
http://forum.flightgear.org/viewtopic.p ... 15#p257249

Here is a proposal for this first part:

Up until 2014, all official aircraft in FlightGear were maintained
in the "fgdata" repository that also contained other elements such
as AI and scenery models and sounds.

After many months of discussion, the core developers, by consensus,
decided to split the aircraft from fgdata into their own repository
and elected to host the official aircraft on SourceForge in a
Subversion repository called FGAddon. This split became effective
in September 2014 and all official aircraft have been maintained in
FGAddon ever since. FGAddon is the source of all aircraft that
appear on www.flightgear.org/download.

In May 2015, a couple of individuals who were not core developers
expressed dissent with the decision on two grounds: (1) the use of
Subversion over their preferred choice of git, and (2) the existence
of "gatekeepers", developers who have commit privileges on FGAddon
and act as a filter for contributions to the official aircraft.
Consequently these individuals forked FGAddon into a new collection
of git repositories which they called FGMEMBERS. This fork was
hostile from the onset, as it was the result of an irreconcilable
disagreement with the core developers.

After forking, the proponents of FGMEMBERS began to advertize their
unofficial fork on the official forum (forum.flightgear.org), trying
to divert potential contributors from FGAddon and to attract them to
FGMEMBERS instead. These proponents stated, repeatedly, their desire
to "kill" FGAddon or at least make it obsolete.

Their attitude has sparked numerous reactions and counter-reactions
on the forum, to the point where useful and helpful messages could
be drowned in lengthy threads of increased hostility between the
proponents of FGMEMBERS and those of FGAddon. After some of these
threads descended into personal accusations, forum moderators had to
intervene; the discussions have created, and continue to create, a
large amount of work for the moderators, in addition to the split of
the FlightGear community.

>> =Official FlightGear Position=

>> The core FlightGear team considers the FGMEMBERS fork to be bad for
>> the project for a number of reasons and encourages users and
>> aircraft developers to use the official FGAddon respository instead.
>>
>> 1) Historically, forks of Open Source projects are unsustainable as
>> 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.
>>
>> 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 15 years and has a long track record of ensure the
>> long-term health of the aircraft.
>>
>> 4) We are concerned that FGMEMBERS does not have robust enough
>> 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 the accusations that they have
>> made against the core team. We consider this unacceptable.
>>
>> =FAQ=
>>
>> Q: Why is this important?
>> A: FlightGear exists due to the time and effort of developers.
>> FGMEMBERS has wasted a huge amount of developer effort in refuting
>> allegations and dealing with questions from users. This is effort
>> that would otherwise be used to develop the next version of
>> FlightGear. This is having a visible detrimental affect on the
>> project as enhancements for the next release are having to be put
>> on hold. This needs to stop, and this document will hopefully help.
>>
>> Q: FGMEMBERS intends to sync all changes from FGAdoon. Why can't
>> FGAddon simply merge all the changes from FGMEMBERS so the
>> repositories remain identical?
>> A: 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 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 are not prepared to risk the
>> GPL "health" of FGAddon.
>>
>> Q: Why can you not work with the FGMEMBERS team to create a single
>> repository?
>> A: FGAddon represents the consensus of the core flightgear
>> developer community, and was a decision made over the course of a
>> number of years with much discussion. We are not prepared to re-
>> open that discussion, nor change a decision simply because a very
>> small vocal minority do not agree with that consensus.

Q: Why do you use Subversion instead of my preferred version control
system?
A: See previous question.

Q: Why does FGAddon have "gatekeepers"?
A: Because FGAddon is the official repository of FlightGear and, as
such, has obligations and liabilities. The role of the gatekeepers is
primarily to review all changes to ensure that all contributions are
Free Software (GPL or compatible license) and remain compatible with
the core of FlightGear even if FlightGear changes. Their role is
*not* to stifle development of aircraft.

Q: How can I send improvements to FGAddon for inclusion into the
official repository of aircraft?
A: Send an email to flightgear-devel <at> lists.sourceforge.net or post
a message on the forum, stating your intentions.

Q: Does that mean I have to go through a "gatekeeper" to have my
changes applied in FGAddon?
A: Yes, and this is a Good Thing; the gatekeepers will ensure at least
a certain minimal level of quality.

Q: Why would I want to contribute to FGAddon when I could "just" hack
away and publish my changes in a forked repository?
A: You can do both: publish your changes in your own private hangar
*and* have them merged into FGAddon; the only drawback is the
additional work this requires. The merge into FGAddon guarantees the
continued availability of your improvements for years to come,
compliance with Free Software licensing (GPL or compatible), and makes
your improvements available on the official download page,
www.flightgear.org/download.

Q: Can I become a "gatekeeper" too?
A: Yes, and you are encouraged to apply for commit privileges after
you have demonstrated good judgement in the role and responsibilities
of a gatekeeper and good understanding of Free Software licensing
issues. To apply, send an email to
flightgear-devel <at> lists.sourceforge.net.

Q: What about private hangars other than FGMEMBERS?
A: Most private hangars have good reason for existence; perhaps the
best
reason for the existence of a private hangar is the use of licenses
that
are not compatible with the GPL (FGAddon requires compatibility with
the
GPL version 2 or later). The core developers of FlightGear have
nothing
against private hangars in general as long as they are not hostile
forks
and do not try to divert developer time away from FGAddon.

--
Ludovic Brenta.

[IAHM-COL]

Maybe it's a good idea to point out that FGAddon could be synchronized
with a private git repository to get best of both worlds.

Erik