Git ships with a tool to export a Subversion repository, with all history intact, into Git format. I've used it on several repositories over several years and been generally pleased with the results, including on some repositories that had relatively unclean histories. I say this not to argue that you ought to use Git instead (though personally, I always prefer Git over Subversion, even for non-public projects), but to warn that keeping the code in the Subversion repository doesn't present a meaningful barrier to anyone who decides they would prefer to fork the code and put it in Git. If such a person did not care about the history, it would be even easier for them to create a Git fork:
svn export from Arcen,
git init,
git add .,
git commit, and go.
If history is preserved via the Git-svn bridge, it's possible to cross-commit back into the Subversion repository, although it'd generally be easier just to freeze the Subversion repository entirely and track everything through Git.
You indicated a relative lack of concern about adverse impact on sales. One way to slightly mitigate that impact would be to publish only game code, but no supporting assets (sounds, images, etc.). A determined user could still get at least parts of the game free by grabbing assets from the demo and/or patch files, but it'd be a slight hurdle over having a fully functional ready-to-go free game in a publicly accessible repository. This may not be that effective for games where you give away a demo that can be converted to the full game simply by input of a license key. However, since the games are not DRM encumbered, you already have the arguably greater risk that someone will buy the game as-is, post it full for free, and people will download it from there instead of buying from you.
As for your concern about inferior forks, you could release the code under a license that requires (1) Complete Corresponding Source for any binary releases and (2) Modified releases must be clearly marked. Item (1) ensures that you can always see what was changed. Depending on its wording, it could also ensure that you always have the right to incorporate community changes that you like, while not obligating you to take community changes you dislike. Item (2) ensures you are not unfairly blamed for defects introduced in inferior forks. You could further guard against misrepresentation if Arcen signs its official releases with an Authenticode certificate (Windows) / GPG key (any platform) for which the private key is not published, so anything bearing an Arcen signature is by definition approved by an Arcen representative. Such representative would need to take care not to merge "bad" changes from the community nor sign builds derived from untrusted sources, but that's a much easier problem than proving provenance of arbitrary builds with arbitrary modifications.
Licensing is probably the biggest thing to plan before proceeding. I assume that the existing copyright to the code is held by Arcen Games as a corporation, not by the individual employees/contractors who created the assets. If so, you currently have tremendous flexibility in picking a license. Once you release the code, if you want to start pulling in community changes, you need those changes under a license that you can accept. The two most popular ways of handling this are a Contributor License Agreement (often containing a copyright assignment provision) that prospective contributors must complete before their work is merged or to insist that contributors explicitly license their changes under a license that is permissive enough that it will never trouble your expected uses of the combined work. Personally, I refuse to contribute to any projects that insist on a Contributor License Agreement.
Whether it's worth it is hard to say. Some games from the late 90s had their source released after the publisher lost interest in sales, and are still in active maintenance by fan communities. See
Commercial video games with freely available source code for a full list of games so released, although obviously some of those are not as well maintained as others. Some of those games saw a resurgence in sales because new players needed to buy the original game to get the assets (sounds, graphics, levels) to go with the now-free engine.
I'd be more interested in the source for AI War than for Bionic Dues, since there are a few annoying minor things I'd like to change (transport off-by-one bug, some team control enhancements, more detailed info cards, improved galaxy map filters).
Poll