Entitlement: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 20: Line 20:
Thus, approaching Flightgear with the attitude of a paying customer who is crucial for the project leads nowhere - Flightgear users are not paying customers, and users leaving for FSX will not have any impact on the project.
Thus, approaching Flightgear with the attitude of a paying customer who is crucial for the project leads nowhere - Flightgear users are not paying customers, and users leaving for FSX will not have any impact on the project.


What will have an impact is contributors leaving the project - but contributors have rendered services to the project already, and are hence justly entitled to some attention in return.  
What will have an impact is contributors leaving the project - but contributors have rendered services to the project already, and so they may receive some attention from other contributors in return.


== The silent majority ==
== The silent majority ==

Revision as of 12:55, 10 June 2014

Entitlement is the errorneous perception by a subgroup of users that the Flightgear development team 'owes' them certain things for no other reason than that they are using Flightgear. This basic misunderstanding makes communication between developers and users prone to fail.

The reality is that Flightgear is developed by a team of volunteers who work for the project in their spare time and that users get the finished product for free (that 'free' includes costs for infrastructure like download bandwidth and file hosting), so it is difficult to see in what sense developers would owe users in addition to the service already rendered. If anything, it would be the other way round.

In practice, entitlement comes in various forms, often in statements like 'users should get more of a say where the project goes', requests to make binding votes and polls or unrealistic expectations in problem reporting situations.

Votes and polls

With some regularity, users express their ideas on where they think the project should be going and feel that the project should be more democratic and take their vote into account and are disappointed that this leads nowhere. However, Flightgear is in essence a meritocracy in which the influence on where the project goes roughly scales with the merits a developer already has.

There are at least two basic reasons why the project does not let vote users into which direction future development should be going. First, making such decision requires insight into what the issues and alternatives are, and what they would imply. Some seemingly small changes may in fact require large changes in the basic architecture of the software. Inofficial opinion polls backed up with arguments are sometimes held on the developer's mailing list, but the aim is more to distill the arguments than the individual opinions. Basically, project decisions should be made by the people who have the skills and experience to make them. This has real-life analogies - in case of an emergency, an airliner crew does not give the passengers a vote what should be done, the cockpit crew decides that, as they have the skill and experience necessary, the passengers do not.

The second reason is tied to the volunteer nature of the project. Volunteers can not be compelled to work on something they do not like. Even if a user vote would make sense conceptually, if the people who have the ability to code a certain feature that has been voted in do not want to do it, it all stops there. It is completely unreasonable to ask people who devote their free time to coding for Flightgear to regularly do things someone else tells them to - especially if that someone else has not done any service for the project.

The FSX threat

Sometimes users threaten to leave Flightgear for another simulation software if their idea is not taken into account. From a developer's perspective, this is an empty threat, as the number of people who just use the software is irrelevant for the continuation of the project. This is very different from commercial projects where the number of users largely is the number of customers who finance the project, but in the Flightgear case, things actually work the other way round in that a larger userbase creates a larger drain on the infrastructure, making it more difficult to offer it for free.

Thus, approaching Flightgear with the attitude of a paying customer who is crucial for the project leads nowhere - Flightgear users are not paying customers, and users leaving for FSX will not have any impact on the project.

What will have an impact is contributors leaving the project - but contributors have rendered services to the project already, and so they may receive some attention from other contributors in return.

The silent majority

Several users have in the past questioned whether the feedback provided via the forum and other channels is really representative and argued that they represent the position of the (much larger) silent majority of users who do not provide feedback anywhere.

It is certainly true that the sample of users reporting back is skewed - but the skew goes the opposite direction, since a main driving force for users appearing in the forum is that they experience problems - in all likelihood, the silent majority is therefore silent because these users don't see problems.

However, as argued above, the (non)-existence of a large number of users having one opinion or the other who do not want to get in contact with the project is irrelevant for the way the project works. Unlike paying customers, the sheer number makes no difference anywhere. So even if the silent majority could be demonstrated to be of a certain opinion, the argument would not be stronger.

Bug reporting

The Flightgear project does not have the resources to pay for a user support department, so again all bug reports are handled by volunteers. Most bug reports are answered with requests for more information. The reason is that it is almost impossible to find the cause of a bug if it can't be reproduced. Some users react rather violently to this, apparently out of a notion that they have done their part by reporting the bug, so now it's the developers' duty to fix it, not to ask more questions.

Needless to say, this is an unproductive attitude. Nobody likes to trace bugs, people volunteer nevertheless because they realize there is need. However, to expect that a volunteer will put up with rudeness and go out of his way to investigate many possible causes of a problem he can't see because a user doesn't provide enough information is unrealistic. Users are not paying customers, and the people trying to help with problems are not a paid support department.

Support for outdated hardware

On occasion, users have accused to project of discriminating against them, as they can't run the recent versions of the program on their hardware. Note first that the premise is likely not true - Flightgear is known to run fine on very old hardware using a minimum startup profile and legacy support is strong driving force for decisions made in the devel community.

However, leaving that aside and assuming that there are systems on which a recent Flightgear version no longer runs - in what way would that be discrimination? Especially since older versions are still available? Why would the project have an obligation to support every bit of hardware in existence? With the same logic that 'free' equals 'everyone must be able to use it' - should the project provide computers for everyone who wants to use the simulator but does not own a computer at all?

Users who invest in high end graphics cards have at least just as much reason to expect that new version make use of their computers' performance. Many novel features are implemented optionally can can be switched off, the project tries hard to be backward compatible (and is probably much more so than any commercial software) but fundamentally there is no right of a user that his hardware is supported, and accusations of discrimination against users with low end hardware are just baseless.

Finally, there are features that cannot be realistically run on very outdated hardware, this includes deferred rendering schemes like Rembrandt, many shaders/effects, but also osgEarth support - more often than not, these feature actually require fairly recent hardware. And in the case of osgEarth, or many other OSG-based features, the hardware requirements (such as e.g. shader/multi-threading support and lots of RAM/VRAM) are actually beyond the control of the FlightGear project - FlightGear merely uses existing software.