by Hooray » Fri Oct 21, 2016 7:49 pm
Git is distributed by nature, so anything going into fgmembers will automatically be also made available to people tracking that repository (regularly).
Apart from that, legally, it would make sense to no just contribute to fgmembers but also other repositories/hangars.
Thus, even when it comes to FlightGear, my recommendation would be to create backups and try to "commit early & often", and to multiple repositories - using git, you can easily contribute (push) your work to more than one repository - and there is tons of free git hosting available these days.
Besides, you can also make your work available via p2p file sharing, i.e. in the form of a corresponding tarball/zip archive.
In general, your contributions are on the safe side if you always assume that flightgear.org and fgmembers could go down tomorrow, and contribute your work using more than just a single channel.
Finally, as a matter of fact with this assumption in mind, the non-distributed svn/subversion approach taken by fgaddon is technically inferior in comparison to a git-based, distributed, approach. However, on legal grounds, fgmembers is much more likely to be affected in a major way - whereas there definitely is a technical hurdle when it comes to recreating fgaddon - however, the flightgear project has a long-standing history of solving such challenges in a swift fashion once they do become real (think CVS/git migration, seedwiki/mediawiki, avsim/forum, gitorious/sourceforge etc)
As long as you understand how git works, and as long as you can safely assume that there are at least a handful of people using, and thus mirroring, fgmembers - it is unlikely that a shutdown scenario will necessarily impact fgmembers massively - with the obvious exception that there is a certain challenge when it comes to setting up a new remote from scratch, as most people will not be too familiar with the specifics - we've seen that even being the case here whenever a repository URL changed.
However, as long as your work is regularly committed to a public git repository that is also regularly pulled from by many users, dataloss is unlikely to occur - which is one of the strengths of the distributed approach, which is also why this kind of setup is used for other FlightGear resources, including the SimGear/FlightGear source code - mainly due to a lesson learnt from the "infamous cvs/coffee incident".