If you want to contribute, please post on the forums (preferred) or send a forum private message to Geoff the Medio.
A list of programming tasks to be completed can be found on the GitHub issues tracker.
For information on procedures, code standards, etc:
To submit code changes, create a pull request for the master branch on the FreeOrion github repository. Be sure to note that you release your changes under the GPL 2.0 (or later) license.
You should expect your submissions to be reviewed and to receive feedback requesting changes before they are accepted and merged into master. Following the Code Standards for FreeOrion will likely reduce the number of changes needed.
High-Level Structure of FreeOrion Code
There are three FreeOrion modules: the human client, the server and the AI client. The server creates the game, and sends it out to the clients. Clients issue orders, which the server executes before updating the gamestate each turn and sending the new gamestate to the clients.
The gamestate comprises a Universe and a set of Empires. The Universe contains various UniverseObject subclasses: Buildings, Planets, Systems, Ships. Empire keeps track of individual empires: research and production status, homeworld, explored systems.
Various bits of game content are stored in manager classes, like TechManager. Techs, Buildings, Specials, etc. are defined in text files, which are parsed when the game starts up. The manager classes provide access to this info from anywhere that needs it.
Each screen in the UI has its own class, in which all the windows and widgets are objects. Most UI screens are objects contained within the MapWnd object. Generally UI classes communicate with classes they contain by calling public methods, and classes that contain them by emitting signals which the containing object has connected to various functions.