Implementing new features for FlightGear: Difference between revisions

* You mention it in the forum: <br/> A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there.

* You make a formal feature request on the issue tracker: <br/> The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen.

* You make it your own project to get feature XY implemented: <br/> This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on.

# Flightgear relies on having a contributor base, but not on a user base: <br/> Unlike a commercial project which needs customers to survive, FG does not. As a result, FG development is not focused on the end user. Developers tend to work on features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting.

# Developers are free to do what they want: <br/> This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily.

# Flightgear development tends to be inclusive: <br/> There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers).

* ... point out how your idea will make FG a better simulation.

* ... make a point out of what you would be willing to do if only XY were available.

* ... be as concrete as possible, point out what precisely you would like to see changed.

* ... demonstrate that you have looked at the relevant information and know what you're talking about

* ... demand anything from anyone.

* ... be rude or angry if people are critical - it's part of the process.

* ... point out how bad FG is going to be or how it will fail if your idea is not implemented.  

* ... say you can't do anything, because you don't understand C++ - the human mind can learn