There used to be some kind of mission statement, e.g. see:
http://www.flightgear.org/proposal-3.0.1 (from 1998).
And then there's a more recent wiki article trying to cover the same thing based on community activity:
http://wiki.flightgear.org/Long_Term_GoalsThe most representative long-term list of goals is probably any core developer page listing their own goals:
http://wiki.flightgear.org/Category:Developer_PlansThese days, many core development efforts have a lifetime of at least 5 years given the low number of active core developers, as well as the degree of required architectural large-scale changes - for instance, to name just a few ongoing efforts:
- increasingly adopting OSG (since early 2006, still in progress)
- support reset/re-init, for switching aircraft at run-time, without requiring existing/restarting fgfs (equally, people want to be able to save/load flights to continue a flight at a later time)
- increasing focus on proficiency/flight instruction scenarios (e.g. by being able to replay/continue an approach reliably)
- allowing aircraft/scenery to be downloaded/installed and managed from inside the simulator
- better use of multi-core systems
- supporting distributed setups with multiple windows/viewers and multiple graphics cards
- adopting HLA/RTI, especially for distributed setups, but also for better leveraging multi-core systems and an improved multiplayer experience
- making more and more subsystems configurable and entirely optional, e.g. for better troubleshooting/regression testing
- For the past few years, the Canvas subsystems has been used to re-implement MFD functionality without requiring core development
- modernizing the GUI
- procedurally populated scenery ("autogen") is becoming increasingly relevant, i.e. we're seeing a lot of activity in anything involving OSM and procedural scenery creation
- equally, people want to keep on improving the scenery engine and the TerraGear compilation suite to support more and more visibility, while also providing good performance
These are just some of the things that some of the more consistent core developers have been working towards over the last couple of years, many of these efforts dating back at least 5+ years.
There are also a handful of external efforts, including a few "internal" ones that simply got stalled at some point (think Rembrandt/deferred rendering).
Overall, FlightGear is very much evolving - not unlike HTML browsers have evolved over the last 10-15 years - however, FlightGear's evolution is taking place much more slowly, but the trend is very similar (e.g. better use of multi-core platforms, more and data-space coding etc)
In addition, FlightGear is using quite a few external dependencies/libraries that have their own roadmaps/goals (e.g. OSG or JSBSim).
In summary, it is hard to maintain an up to date list of priorities/roadmaps - simply because goals are mainly determined by those people who are involved, as well as their degree of involvement. For instance, some of the goals listed above could be considered controversial - so may not get as much support from certain contributors, but they're very actively being worked towards by some of the most active core developers. Equally, this situation may change quickly once some key people are having to take a hiatus from FlightGear core development.
In the last couple of years, Zakalawe and TheTom were the most active core developers when it came to SG/FG commits - so their statements and actions were pretty representative about the direction of the project. These days, some things have changed a little and some other core developers showed up again, i.e. veto'ing certain changes/trends or pulling into completely different directions. Equally, there are long-term contributors who are no longer as active anymore, but whose stated goals are not aligning too well with things that more active developers are working towards.
Basically, the degree of your own involvement (and influence) gets to determine how FlightGear will evolve - once you're taking a step back, you may very well have to defend your contributions/ideas and roadmaps, or they may quickly become obsolete - this can be seen in a number of areas that are no longer as well maintained (think Nasal engine, or the basic weathe system).
In other words, you should take everything said in this context with a grain of salt and look who's supporting certain changes, and if that someone is even (currently) involved or not.
The efforts I've listed above are not comprehensive, but fairly representative - however, only as long as those people around actually around, and only as long as there are no more senior contributors showing up to veto a certain change.
I do agree that it would be a good idea to ask more contributors to state their goals, and try to come up with a more recent "mission statement" - maybe just by using a subset of "meta goals" that most people can agree on. But given how FlightGear works, this may turn out to be too difficult - but it would definitely be a good thing for the sake of the project, especially given the total lack of project management.
In general, FlightGear is moving away from just being a flight simulator towards being a very flexible and generic platform for simulation needs - which seems like a logical step, but it is happening slowly.