20,741
edits
Implementing new features for FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Implementing new features for FlightGear (view source)
Revision as of 18:33, 17 May 2014
, 17 May 2014→Some (unpleasant) truths up front
No edit summary |
|||
| Line 31: | Line 31: | ||
First, to avoid disappointments, it is important to understand how FG as an OpenSource all-volunteer project works - if you start with your project without understanding these essentials, it is bound to fail. | First, to avoid disappointments, it is important to understand how FG as an OpenSource all-volunteer project works - if you start with your project without understanding these essentials, it is bound to fail. | ||
# 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. | # 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. A commercial project is sustained by paying customers, so that the company can pay its workers. In FlightGear, "workers" are generally not paid. And a self-sustaining project depends very much on contributors. As a result, FG development is not focused on the end user. Developers, and other contributors, tend to work on ideas and 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. | # 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). | # 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). | ||