Here are some of the Frequently Asked Questions (a website is nothing without a FAQ! :P).
Yes. The two main mailing lists are:
You can subscribe to the development list here and to the ideas list here.
Those are multi-users dungeon exploration games. Crossfire has a very long history (it exists since 1992!), but it is nowadays somewhat stalling, partly due to the weight of its long history - the code is cluttered by patches over an ancient design.
Daimonin evolved from Crossfire. At first, it was a cleanup of the original code coupled with isometric graphics (Crossfire uses a top-down view). Nowadays, it attempts to add new features and slowly drifts away from its mother project.
Both projects are sometimes referred to, because several JXFire contributors have some experience with those games, and they are a good common ground to compare features.
Well, no :). First, because we plan to try mechanisms not found in other online RPGs, or not in the same form. I have a simple principle I call the Speaking Sword Principle: point me to a game in which I can create an intelligent sword I can chat with and give simple orders, and I'll seriously consider joining it (and at least I'll test it!). None of the games I've tried so far really allow that, hence it is fair to say that nobody is trying what we are trying to achieve here.
As for contributing to other similar projects, well, we already do - or did. I've myself contributed to Crossfire for several years. The problem is that they obviously aren't working towards implementing things we would like to see in RPGs. Now, there is no exclusive - one can contribute to JXFire and to other RPG projects as well if he/she wants to; we don't expect to jail anybody for such a sin in the near future ;).
Precisely to avoid reinventing the wheel wherever we can. SGS is a framework allowing write massively multiplayer games in Java; we *are* writing a (possibly massively) multiplayer game in Java. See the connection? :)
Now, of course, there are many other frameworks out there for sure, yes. But in the end, a choice had to be done. SGS seemed to fullfill the job, I liked it, thus it got chosen. And before you ask: no, that choice isn't going to change any time soon.
Welcome in the XXIth century. For most tasks, including gaming ones, Java is nowadays optimized enough. There are several benchmarks on the net discussing that.
Now, granted, a language like C is likely going to provide a faster resulting application than its Java counterpart for various reasons (mostly because C allows a closer proximity with the underlying platform). No question about that. But C also means a more complex code in most cases (again, mostly because of its closer relationship with the low-level layers of the platform). When the JXFire project was launched, it was decided that the performances edge of C over Java wasn't worth the increased coding complexity, and thus it was rejected.
The question of "why not C#" would be much more balanced. However, C# isn't as portable as Java, regardless of what the Mono guys may like to say. Moreover, when the very first iteration of JXFire was launched, C# didn't even exist. Once the coding was started with Java, it made little sense to switch to C# in the middle, as no decisive technical advantage was expected in its favor.
The best ways are:
irc.freenode.net, channel #jxfire