x-4000 (Chris Park)...Next up, when it comes to the source code, I'm not too enthusiastic of just making that a free-for-all. If we did, then that probably wouldn't impact sales particularly negatively (most people who buy it wouldn't be aware of the source code), so that isn't my worry. But how do you get the source code changes BACK into the game itself? People start forking it and presumably the "best" experience then migrates off of what is in Steam, and then people start complaining about it not being up to date with the latest fork, etc, etc.

Then there's a whole new set of problems, basically, which also costs time and money on my end, and probably frustrates Steam customers as well as potentially opening them up to malicious code. Probably that last bit is not really a worry, but it always does run through my mind when I think about unreviewed code going out to customers. If something happens, where is the liability on that, etc.

...With that in mind, what I'd prefer to do is probably just open up our svn repository to interested parties that approach us. That does mean that someone can just grab the code and run away with it, but I'm not really worried about that impacting sales, as I noted before. It would mainly be something that's easier for me to keep an eye on, and do pulls and pushes from, is my thought. I'm not a big fan of git, and our existing repo history isn't something we could easily export somewhere else to my knowledge....My thought is that the process could basically be:

- People who are interested in working on the source code contact me at chrispark7 at gmail and I'll give them access. You're on your own figuring out what stuff does, for the most part, though.

- They can then compile this and just share around the one code dll with others for testing purposes as much as they wish.

- Once things are to a point where they are stable enough for me to review, and probably not more than once per month, I'll take a look at the unified diff in svn, make sure everything is kosher, and then push the update out through Steam so everyone benefits.

Still there is no exact solution on what form it may happen.

It may me entresting expriment for Arcen Games. But it is worth it? I just intrested game in community opinion.

Restricting how many people are open to developing on it isn't really a top concern of mine, to be honest. For someone to be interested enough to do something of value, they mostly have to already want to get the proper dev tools and figure out what the game is doing. I figure that writing to me for a login to svn is the least of the worries if that's something they're up for.

I suppose one potential option, which I'd have to talk to Keith about, would be a public git version that people can mess about with, and then periodically someone helps out by merging those into svn and then I do a push to steam.

Logged

Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

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).