Entitlement

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/contributors 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 how much a contributor has previously contributed, and often even how difficult/complex that work was/is.

FG works the way it does for a reason - exactly because people like you (or I) don't roll up their sleeves to change it for the better, but instead prefer to just voice their criticism. So what you can learn by reading such articles is how the project works despite all of us being "lazy volunteers", who do not like to be told what to work on, and instead work on their own little pet projects, and just resort to making comments whenever we do not agree with something that we're not interested in getting involved with. — Hooray (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.

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. People following the developers mailing list will notice that even many core developers will often just express support for certain ideas, without really offering to work on implementing them-this is why it is ultimately up to the corresponding contributor to decide how to proceed, as long as there is someone who is able to commit.

people won't change a single thing just by debating - even if they should be completely right. And being ignorant about how the project works behind the scenes, will not help much either. This is not to say that we all "like" the way the project works, but the way things are working is not by conscious decision, but due to the exact same behavior that many people have been exhibiting here for the last few years: due to people caring about their own stuff, with little to zero interest for getting involved in other projects, that they consider "side kicks". Simple as that. It is the few cases where people manage to work around such issues and actually collaborate that FlightGear is shaped in major ways, and consistency improved. Nasal, Canvas, NavDisplay and MapStructure are testimony to this working extremely well - but it's tedious and not exactly "fun" to work like this - just ask TheTom, Gijs, Philosopher or myself: It is much more fun to focus on our own little projects than keeping the big picture in mind and coordinating things behind the scenes. — Hooray (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.

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.

For example, some of the more recent advances in FlightGear, such as Canvas, were suggested and discussed several years prior to the current implementation by some of the most senior core developers-yet, it was never implemented by any core developer, but by a new contributor who became a core developer that way. This goes to show that people may even agree on technical terms, but may still lack the interest/skills to actually implement an idea-which is why good ideas may often have a certain shelf life.

'Useless' development

A related theme sometimes raised comes in the form of the question 'Why do people develop a useless feature like X when the important problem Y is not fixed?'

Since developers are volunteers, they pick the issues they think need to be improved with highest priority within the limits of their expertise. That means first, that while everyone may agree that there is e.g. a problem in 3d rendering which needs to be addressed, it still makes no sense for a flight dynamics coder who has no knowledge of 3d rendering to address it and vice versa. The Flightgear development team is not a homogeneous pool of people who understand every aspect of the simulation and could potentially be reassigned to any task, rather most people have their area of expertise within which they maintain systems and address problems and it makes no sense for them to address issues outside their expertise. Much of the FlightGear code base consists of legacy code, which isn't actively owned, or even just maintained, by a developer. This also leads to situations where active core developers feel no longer qualified to maintain certain unmaintained components, such as for example the YaSim FDM or Nasal scripting engine.

But within an area of expertise, developers work according to their own perception what is important and what is not. Anyone who decided to work on X rather than Y is obviously of the opinion that X is more important than Y. A user demand that a developer should not use his own judgement on what has highest priority but rather accede to the user's idea on what is important is hence just another form of the above - a wish to exercise control over the priorities of the project without investing any effort. To people familiar with the project and its code/infrastructure, such attempts get very obvious pretty soon, and they start becoming boring quickly. If you'd like to have some attention from other contributors, make sure that you're offering something in return, as per: Implementing new features for FlightGear

The FSX threat

Sometimes users threaten to leave Flightgear for another simulation software like FSX or X-Plane 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.

any type of company/collaboration needs to be self-sustaining, a commercial entity/company will usually be self-sustaining by charging money for its products/services and listening to those who are willing to pay for them. An open source project, which doesn't have any access to regular/stable funding, needs to be self-sustaining, too - and here it's obviously contributors that are spending their time so that the project can be improved - indeed, some may even spend money on infrastructure (hosting, shipping, advertising, bandwidth etc). — Hooray (Wed Jun 11). Re: Eye Candy & Performance Issues (was: Slope line patterns.

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. This also holds true with regard to making our multiplayer environment more popular, which is another common notion expressed on the forums:

These things are not obvious to bystanders, but our "multilplayer network" isn't very much different from having a handful of litter boxes with people trying to use them for certain purposes (for which they were never designed!), despite not quite realizing that they can only "handle" so much, in terms of capacity/load and use. Which is exactly the reason why we don't mind being reminded that there's not hundreds or thousands of people using the system: the existing system is too lame to even think about such a thing. We would have a huge problem if we all of a sudden had hundreds of players. And some of the features discussed here would definitely make things more popular (ATC, combat, airliners, virtual airlines). Currently it's just imaginary features that are implemented by people using very few feature and lots of imagination. We would be in the same situation if we suddenly had thousands of former FSX/XP users here - we couldn't handle the sheer volume, and we couldn't get anything done. — Hooray (Thu May 01). Re: Trouble at EDDF-Triangle.

Also consider that the added traffic will explode the bandwidth required by the multiplayer servers, possibly breaking bandwidth limitations — Johan G (Mon Oct 08). Re: Populate AI Traffic with real traffic.

The current MP system probably isn't able to deal with this amount of "traffic" at the client-side - thus, it might make more sense to develop this as a server-side module, that can be run as part of the fgms process. — Hooray (Mon Oct 08). Re: Populate AI Traffic with real traffic.

think we are lucky that obviously not everybody is making use of the FlightGear multiplayer support: the current multiplayer system is simply not designed for that many players, it is not even particularly efficient at what it is doing-so, I wouldn't even want to imagine how hundreds or even thousands of clients are joining the current network of servers. In fact, even apart from the multiplayer server design, multiplayer support isn't yet as enjoyable as just running the simulator without it: I rarely use mp myself, I just don't like the spikes in lag its causing on the simulator. I wouldn't dare to suggest making mp more accessible by enabling it a default in fgrun, it would just reflect badly upon fgfs as a whole. — Hooray (Sun Mar 08). Re: Just out of Interest.

it's kinda pointless currently to debate the merits of such a system, because our existing architecture is fairly inadequate to pull something like this off. Yeah, having a restricted 5-10 player shared MP environment may be possible to come up with by using some creative workarounds - but overall, our existing MP system is not really a good foundation for something like that. In very simple non-technical terms, our fgms server acts like a "mirror" in the conventional sense, it isn't very much state-aware and cannot be easily ab/used to share/propagate/replicate other state, beyond what is currently hard-coded - that is why people had to come up with "generic properties" and the mp_broadcast system. We hit some of those limitations back when we were working on extending fgms to use RL traffic to populate our world — Hooray (Tue May 13). Re: Online .

We've also been seeing similar debates about introducing VATSIM/IVAO-like feature (virtual ATC) or people debating how adding more VA related features (virtual airlines) would help make the project more popular.

Nobody designed any "ATC code". For the time being, there's basically zero FG contributors who are working on ATC related stuff as part of FG, so we have more people willing to use/provide ATC than people willing to implement and maintain it. Thus, there really is no ATC environment at all. What you describe as "ATC code" is a huge workaround, much more so than any other scripted system is, including flug's bombable addon or Thorsten's weather system (those are actually designed). In the case of ATC support built into FG, it doesn't exist. Simple as that. What you may perceive as some form of "ATC system" is nothing more than creative use of a handful of features, namely scripting, XML, a few GUI dialogs and the conventional FlightGear chat system, built into MP. So, it's not that people are "pooing into the ATC sand box" - rather, ATC is taking place in a huge cat loo The only reason it's still kinda immersive for some, is that people are actually talking and behaving like ATC, and others are willing to comply with their request. But otherwise the whole feature is a fake - we have no ATC system in FlightGear, neither the fgms/MP network, nor the FG binary has any explicit support for MP-enabled ATC. — Hooray (Thu May 01). Re: Trouble at EDDF-Triangle.

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

Also see FlightGear and old 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 Project Rembrandt, many shaders/effects, but also osgEarth or osgOcean support - more often than not, these features 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, that comes with certain hardware requirements.

People really need to understand that FlightGear is the product of putting many ingredients together, these ingredients are so called "dependencies" (usually, libraries) - and it is only normal for such libraries to have their own hardware requirements. And once you integrate, enable and use such optional features, you cannot expect that hardware requirements will remain the same. It is for a reason that these features are usually optional: they will not work for people without certain hardware specs. But for FlightGear to make progress, we must evolve and add new features, features that also scale with the horsepower available.

not even manufacturing a Ferrari or Porsche qualifies as discrimination just because I cannot afford buying a Ferrari in cash, but that would be great (see the [./images/smilies/icon_biggrin.gif linked image]) - and FlightGear is far from being a high-end product. FlightGear is very much like shopping: you get what you can afford, but you aren't discriminated against just because there's certain products like salmon or caviar that you cannot afford to have every day, you simply don't use/buy them. Just because your cable TV offers payTV doesn't imply that you have to use it, or that you are "locked out" by it. The whole discussion kinda seems like people complaining about the prize for "first class" tickets, even though they're not forced to even use certain features (flying). Some of you seem to be thinking just because FG is free, that all its latest features also must be freely available to everyone - then, we would need to add $3k worth of hardware t...e that you've got access to. And while it is true that some things need changing to better support older hardware, the majority of features that people are referring to here (Rembrandt, ALS, advanced weather, osgEarth) simply cannot be run on 90s-era hardware. And as a community of volunteers contributing to the project, we typically only have access to 1-2 "devices" (computers) to test-run our code, so we depend on others to provide feedback. You guys are basically asking for hardware with "forward compatibility", because that's the main problem here: old hardware not being able to support certain features, i.e. pre-GLSL hardware not supporting shaders isn't exactly surprising — Hooray (Tue May 06). Re: Available to everyone...or is it?. (powered by Instant-Cquotes)