How the FlightGear project works: Difference between revisions

A more succinct version of this article can be found at: http://forum.flightgear.org/viewtopic.php?f=42&t=15267 (which serves as a really good introduction, people interested in more details, may still want to look at the text below).

As FlightGear is getting increasingly popular, we get to see new users coming to our forums and the mailing list every week. Many of them quite obviously very much interested in contributing to FlightGear in one way or another and getting involved in our community.

Please don't think that you cannot contribute to the project, because you cannot program or because you cannot design 3D models. Creating a flight simulator is a huge undertaking and there are many tasks which may seem less obvious to outsiders, such as helping maintain the wiki, moderating the forum, reporting spam, triaging the bug tracker, reviewing bug reports, helping fellow users and so on.

However, sometimes we get to see some irritations among new community members and more seasoned members, because people may have certain expectations and assumptions on contributing to FlightGear. This has frequently caused some heated discussions, sometimes even flame wars on both, the devel mailing list and the forums.

It seems, some people are trying to apply their own experiences and assumptions to FlightGear as a software development project, which is sometimes causing grief and anger because FlightGear seems so different from anything they may know already.

Honestly, we are all part of this community because we appreciate some things about this open source flight sim named FlightGear. So we are always sorry whenever our tone becomes inappropriate or even harsh.

We sincerely believe that you can contribute in more meaningful ways than you may currently perceive, without just voicing criticism. Obviously, it really is important to get along with people, regardless of differences in opinions.

To tell the truth: Most of us have been in that situation at some point. To most of us, the way FlightGear works as a project has been somewhat irritating and confusing in the beginning. So, we may actually share your initial confusion, because most of us went through the same process at some point.

At the time of writing (2012), this is largely copied together from various flame wars that have taken place in the last 12 months, so the format still needs some work, and things may seem pretty inconsistent and roundabout in some places.

This is not to say that things are set in stone, but the current development model is the result of a certain evolution, and it's exactly this what has enabled FlightGear to survive and grow for over a decade already, without relying on commercial backing, funding organizations or formal project management.  

It requires patience to work together and to get something useful out. Sometimes you just have to live with a problem, work around it, and talk to people for a long time. It takes time, but I've experienced that you can convince core developers that your particular project is important enough to warrant attention and support. Everyone's time is limited, and it's all volunteer work. For example: If you complain that shadows are absent, it will change nothing. What you need to do is convince people that shadows would make a huge difference - possibly even with a proof of concept code.

Let's be honest: Not every suggestion made in the forum or on the devel list is good. While no one deserves to be belittled, a fair share of suggestions deserve to be ignored (unless you feel you are entitled to 30 minutes time from, say, a 3d rendering specialist who explains to you in detail why your idea really doesn't work in non-technical terms).  

I just lack any sign from the user community that they're willing to accept that a suggestion or feedback can in fact be dismissed, and that a developer's time to explain why a suggestion cannot be followed is also not unlimited. I have no problem with the users providing 50% of an opinion where the project should go - as long as they don't expect that that opinion necessarily translates into a decision.

Lack of feedback - same thing. Go out into the forum, download interesting addons, talk to the people who provide them, let them know what you think. If you want feedback for your own work, start by giving feedback to the work of others. That's how it works. And yes, lack of recognition is sometimes a problem. Basically, you have to do things because you want to, and you have to be enthusiastic enough to pull others along so that they can see and appreciate your vision of how things could be. Again, requires a lot of patience. I wish that many things here would be different. I wish people would collaborate on projects more often, instead of everyone developing his own pet project and half of them dying for lack of interest. But I've come to realize that it's not going to happen because I wish it to happen - things are only happening my way if I slowly work towards it, talk to people an unholy amount of time and try to convince them that I am serious and have a case.  

So, I'd like to see some appreciation for the fact that there is no a priori right to be taken seriously, no matter what you say, but that this is something you need to work on. I also think that if the forum would offer a lot of high-quality development related discussions then you'd see much more active core developers here.

You'd expect in the real world that if I give you something for free, that this earns me your gratitude. But this is the internet - so instead of gratitude, you somehow assume that in addition to giving you something, I am also expected to care about what you want, and it disturbs you that I don't really care for people who take for free and ask for more, but that I care for those who take and are prepared to give in return.

I just have no sympathy for people who take, are not prepared to do any work, but feel entitled to say how others should do their job and issue demands for features, aircraft, documentation, whatever. You may call that elitism, I call that my sense of fairness.

FlightGear is a volunteer effort and no one is paying several thousand dollars a year for software and related support each year. Since legacy support is expensive (IE. time/effort) one of the ways a project like FlightGear deals with this is to limit legacy support. If this were not the case then time/effort would be expended on legacy support that could be used for new features and bug fixes. Like most things there are trade offs involved. Which do you want - more advanced FlightGear and aircraft or better support for older versions? This is a common issue for open source software and most prefer to look forward rather than looking back.

In addition, FlightGear itself has been a moving target with a constant stream of new features and enhancements some of which require changes to at least some aircraft.

{{cleanup}}

One thing to consider when comparing real-world handling qualities versus simulated handling is the control devices. I use a Logitech Gamepad which is not ideal by any means, it serves my purposes and gives me acceptable handling capability. The biggest problem with it is the small throw of the sticks which makes them very touchy. Even if you have a full size control column, you lose a lot of fidelity due to the lack of control feedback as well as lack of "seat of your pants" feedback. Both the control throw and the feedback issues result in a great loss of fidelity which makes it impossible to control an aircraft in simulation anywhere near as well as the real thing.  

First, let me say that there are HUGE fluctuations in the quality of FG flight dynamics models, and that I don't like all of them. This is why I specifically wrote which planes I use and asked which plane you've been flying. Some FDMs are pretty bad, but others (the Seneca-II for instance) are made by people who fly the real thing, yet others (the P-51D, the F-16) are done using a huge pile of available test data and have been tweaked literally for hundreds of hours to agree with the real performance and capabilities. It's these FDMs which I like and which I'm defending here.

Maybe I misunderstand the notion of options to make a plane harder or easier to fly. For me, the point is to simulate the aircraft. If the aircraft had functions or gadgets that facilitated making it harder or easier to fly, then fine, that's part of the simulation goal. But it's not the same as a game, where I can select EASY, NORMAL, HARD, or HURT ME PLENTY. There are many planes where someone like me has no business trying even the simulated version. And no real C172 or MD-80 has difficulty modes or configuration files.

By saying that users can easily tweak the FDM in FlightGear, I am not implying that the the flight models or the FG architecture are inherently defective. There are many FG aircraft with great FDMs, other are not so good. Those that aren't so good are usually because they are not completed as indicated by their production status. As with any software product in beta release, the users are free to provide feedback directly to the developer. As this is an open source project, that feedback is often in the from of contributing code/FDM enhancements directly to the author for incorporation into the model. With commercial flight sims, you are always seeing the polished product because they would not get away with selling an unpolished product. With FG we are not burdened by the need to make a profit or satisfy our customers. We ARE our customers so we only need to make ourselves happy 8) So with FG you get to see a preview in the form of a pre-production or alpha release. This gives the users an opportunity to provide feedback directly to the developers, and often this feedback can be incorporated into an updated version of the aircraft in a few days or less. This is not a remote possibility for a commercial sim. I think this is why those who use FG like it so much. We are not content to use something out of the box, we are far too picky!

FlightGear is developed by a community of volunteers from all over the world, we contribute in whatever way we see fit, if you disagree with the way FlightGear development is going, your best chance to affect it, is by starting contributing yourself. FlightGear could only progress so far without any commercial backing for over a decade, because of FlightGear contributors and their very passion for turning their own ideas into FlightGear features.

So until you roll up your own sleeves, let's just appreciate the variety of aircraft and other features to be found in FlightGear, including the X-wing star fighter from Star Wars, Star Trek space shuttles and lots of other passionately developed 3D models, like the BlueBird for example

FlightGear doesn't necessarily have a real "fictional side" - it's just that we all needed to get started somehow. Contributing a completely new aircraft is obviously difficult. Contributing to existing aircraft is useful, but it doesn't teach you all of the skills required to create an aircraft from scratch. So people who want to do a full aircraft, need to start with something simple and "fun".

So what new contributors often do, is creating "fun" vehicles to learn how FlightGear works.

Obviously, contributing to all these areas in FG takes time, a steep learning curve is an unfortunate but important part of it - rarely, do we see people who immediately start out with complex and well-developed aircraft, it's a process - and we all needed to get started at some point. Just because we contribute "playful" things to FG, doesn't necessarily mean that we are not interested in "realistic aviation" as you can see.

You will notice that many long-term contributors actually have an aviation-related professional background, be it flying (commercial, private, ATPL), software development, maths, physics, GIS or whatever. Among the long-term contributors are people with PhDs, Masters, commercial pilot rating, PPL or retired military pilots, and even one test pilot...

Creating the ogeL was obviously simple and fun, creating aircraft like the Seneca requires tons of skills, experience and expertise that you don't end up having "automatically". And it requires tons of dedication and discipline.

I hope that puts things a little into perspective.

You might have made general statements like 'There should be clear development guidelines', 'the project should not depend on a single person being around' or 'the developers should pay more attention to the users'. In theory, all these are beautiful - and who would object that these are all good things?

Who gets to determine the guidelines and how - and what happens with people who don't want to follow? What happens if a developer doesn't want to code a feature even if 500 users signed a petition? What happens to a developer who belittles a contribution, and who enforces that and how? Once you start thinking these questions through, the moral high ground of the theoretical principles becomes a mud field of messiness and compromises.

Posted by MAKG:

Whether this is open source or not is irrelevant. It's a volunteer effort; there are many of those that don't have to do with software. Think Habitat for Humanity, for instance.

Every once in a while, people complain that they feel elitism is a major problem in the FlightGear project.

All these cases have nothing to do with elitism. In the first case (shareholder), the argument is fairness - if I take 10% of the risk of an enterprise and you take 1%, it is hardly fair that we should have the same voting rights. In the second case (science conference), the argument is efficiency - the amount of potential information is so huge that a careful filtering needs to be done in order to ensure that people spend their time processing relevant information - the scientific filter eliminates time-wasters up front (well, not all of them, as I can state from experience). You couldn't run either a shareholder's meeting or a science conference based on 'everyone is equal' - because while everyone is indeed equal in value as a human being, not everyone is equal in ability, expertise, or is equally involved in risk, work, ...- that's a fact, and to pretend otherwise doesn't help.

You may call that elitism if you like, but my definition of elitism would be that a transfer takes place, i.e. that someone who owns 60% of the shares of a company starts to believe that he should not only get to say how the company is run, but also should get more influence in other areas outside his field of expertise, in other words, he starts to feel that his value as a human being is enhanced.

In general, that makes a lot of sense, basically because you can't vote what work volunteers should do later - or rather, you can, but it's not going to be done if the people volunteering for work don't like to do it, they'll just leave.  

In theory, I can spend 5 weeks of my spare time coding something I don't like, but why should I do that? Do you expect me to sit down and do something I dislike just because you (or other users) asked me to do it? Am I supposed to get satisfaction out of doing something for others, even if I don't like it? I don't know if there are people like that, if so, I've yet to meet them. My idea of the deal is: If somebody wants a feature I don't want to code, he can get my help to do it, he can get advice and a well-defined interface, he can get documentation - but that's about it.

There is a continuous transition - people who 'just ask questions' have less influence than people who write frequent feedback and maintain the wiki, then come possibly 3d modellers, Nasal coders, Terrain specialists and finally core developers. So, rather than seeing elitism, I see the chance that every user can in fact start with a small contribution and grow into the project - and that's what I'd like to see improved.

I don't think there's a simple answer to such problems - philosophy has been struggling with them for thousands of years, there hasn't so far emerged a clear preference between an ethics of means and an ethics of ends.

And just how can we get there?

There will probably always be irreconcilable differences between those that _create_ a program, and those that _use_ a program. The extremely successful programs/environments are the ones where those that create can understand those that use, and those that use can understand those that create. Everyone here, in the long run, is really here for their own benefit, and until we all understand that, not much will change. Open source has it's downfalls. It doesn't have to please the majority, it doesn't need sales, it only has to please the person that created it. This doesn't mean that people are greedy or selfish. They have no problem sharing, but they don't need to _do_anything_for_you_, if they aren't interested in it.

You know, if I wanted to change the structure of a project for better, but would not have any real power (control over servers, commit rights, admin rights in the forum, ...), I'd do the following:

First, I'd try to make sure I understand the situation as it is - not as it appears from my perspective, but also how it appears to others, of what nature the obstacles to change are and so on. Then I'd try to get to talk to some of the people who have the power to change things, and convince them that changing something would not just be better for me, but also be better for them - in fact be better for anyone around. In order to do so, I'd go as far as I can to meet them - talk their language, start describing things from their perspective, value their efforts - and then talk about that one can also see things from a different perspective. I'd do that because I want something - I want them to listen to me, so I want to make that as easy as possible. I'd also prepare a compelling and persuasive case - I'd try up front to sort genuine structural problems from things which are just one-time mistakes which can happen because people are not perfect, I'd sort important things from unimportant things and focus on the important things. Above all, I'd think about what I personally did wrong and what part of the problem I can fix - and how I should do it. And then I'd see if I can't convince anyone that there is merit in my perspective. In the process, I'd also try to find like-minded people who might help me achieve my goals.

I don't see there's anything wrong with FG providing options - many of the features/options we have came into existence at different times, with different needs and requirements in mind. It is often only by accident that they start overlapping, sort of like various FDMs, scripting solutions, interfacing options or weather simulations.

Overall, the current situation isn't as bad as it used to be once

No, but at least historically, the FlightGear project tends to attract certain types of people, many of them having some sort of academic background and some involvement or interest in aviation, i.e. in engineering, maths, physics, IT/computing or just real life pilots (hobby, professional, test pilots, retired).

Some of these decisions are hard to understand without having a similar background, be it education, professional experience, families, real life obligations and such.

What can be done in a forum? First off, speak the same as if you were standing in front of the person you are talking to. If you _really_ do get up in their face when you speak, take the gold chains off for a minute and lose the Jersey accent. Respect goes a long way. Respect also goes _both_ ways. If you get an email from someone, respond to it, even if it's saying that "no, I can't help".

New people might not think to look in the wiki (yes, there are links all over the place), or try and find an answer there first. Or maybe they did try and failed but didn't mention it. The wiki is a fine repository for some deep, often esoteric information, but the information is spotty and it's not the easiest place to hunt for a specific answer. And I can well remember when the information in the FG docs folder might as well have been written in Martian, given what I knew at the time. Heck, some of it is still Martian to me.

What's at stake isn't getting person X to information Y. In 90%+ cases, it won't matter much-- person X will likely move on to some other hobby. But every now and then, that new person who asked that same tired-old question stays around and eventually becomes a Gijs, or a Heiko, or a Someguy, or a Melchior, or an Anders, or an Emmanuel, etc. The more open, friendly and patient we are, the more likely it is that we will retain these incredibly valuable sorts of people and keep moving forward.

It'd be really nice to have a better feeling for what is in the works and to know about what is going to change beforehand, rather than pulling the new version to learn that suddenly nothing works and spend the next week trying to figure out just what the change has been. Been there, done it, not pleasant.

Some interface to exchange that kind of information would be really helpful, because some developments depend on how others are structured. In general, more talk between core C++ developers and other developers wouldn't be a bad thing.

* Those that can't "create" an entire aircraft from a blank screen will have to wait for someone to build it. Don't post a blind "please build this" advertisement. My guess is that has never worked, and is borderline rude, asking for something without ever offering something. Accept your limitations, enjoy what we have.

* Don't believe that you are the _only_ user, and therefore represent everyone when you stand on your forum soapbox. _Everyone_ may not share your emotion.

* You have no power and control, and that's not a bad thing. You reap the benefits of many people that have come before you, and even those that may come after you.

* You have power in what you do, and you have total control. This does affect your relationship to the person that is a "Non-developer", whether you believe it or not. Choose to realize this, and be respectful.

* As a "developer", you have been given power and control over something that really doesn't belong to only you. Without a board of directors to oversee your actions, realize that _do_ have a responsibility to provide your part of the "development". You have to consciously choose to do this, for power and control are strong drugs.

* For the most part, there was someone before you, and their will be someone after you. Your actions will help ensure there is a place for someone after you. Remember the past. Don't be the reason that those before you chose to leave.

May FlightGear always provide the beauty of flight to those that are bound by gravity.

* don't like this conceptual division between users and developers. A user is just a developer who hasn't popped the hood on their car yet.

* most of us try to read the forum and the lists regularly, and we also try to respond to thoughtful topics

* I care if I can communicate with you on a professional level and if anything comes out of it in the end, or if I get the feeling I'm just wasting my time. That's all.

* The time I am willing to spend trying to talk to you in the hope of any productive outcome is limited, it is about to be exhausted because I am feeling increasingly annoyed and see no real outcome except more talk. That may not have been your intention, but since it's brought to your attention that people start feeling annoyed, it might be a good idea to change the way you communicate. The chances that the devel community will adapt to your style of work are very slim indeed.

* Your lack of understanding here is your inability to acknowledge that people are aware of the alternatives and have consciously chosen to organize the project the way it is. Speaking for myself, I simply don't want it done your way and would go away the day things become organized your way, and several other core developers have expressed similar sentiments on the devel list.

* You assume that people basically have no clue and all you need to do is to point out how to make it better, but several people have considered the alternatives already and decided otherwise. This is what you need to understand.

* Things are done the way the majority of contributors thinks they are best, not necessarily by some general consensus.

* unnecessary community interactions are eating up time

* People asking for increased project management and more coordination may want to ask themselves how they would respond if they were exactly told what to work on, rather than just doing what they are interested in. Seriously, nobody is asking you to contribute within a particular domain at all, which is also a good thing and attracted many of the long-term contributors to the project in the first place.

* If you are trying influence things: That's fine and a valid motivation. The thing is however, your ability to bring influence to the project is directly proportional to your impact and track record in the project. Actually, this isn't untypical for most OSS projects.We have people here who have been part of this project "just" voicing ideas, opinions and feature requests - some of whom have been involved for YEARS. While their feedback may be appreciated, their ability to direct things is still fairly limited - especially when compared to people who actually brought changes to FlightGear and who have a track record of doing so (sometimes even within a fairly short amount of time). You can find numerous examples actually, of people who have not been a member of this community for very long, but whose input and feedback is not just appreciated and respected but who are having a certain impact on the direction the project's heading. This is never because of "talking" or discussing things, it is because of DOING things.

http://forum.flightgear.org/viewtopic.php?f=18&t=13298&p=134793&hilit=supply+developers#p134756

* Will my voice be heard?

* We get to see new forum members posting interesting "project ideas" here every month, sometimes even several times per week. And we know from experience that "ripping FlightGear down to its core and rebuilding it" isn't going to happen that easily, it's not necessarily because of objection from the community - quite the contrary, sometimes people actually post ideas that everybody agrees would be great additions to FlightGear, ideas that would quite obviously involve tearing down some major subsystem and replacing it with something better.

* So I guess you see where I am coming from: new people now asking to "tear down & rebuild" the whole thing, or people asking to introduce DRM-like measures into FlightGear (content protection) are of course not going to receive a very warm welcome

* And like I said before: this is not necessarily because we don't want to see this happen: you could probably talk to any core-developer and each of them could tell you that there are a number of parts that SHOULD be ripped out and replaced eventually (i.e. such as some legacy code), but more often than not, things are simply not as easy as they may appear at first glance. When you take a look at the mailing list archives or at the wiki, you'll certainly find plenty of things in the fgfs source code that everybody agrees should be replaced eventually.

* And if people who have experience working with the code for a number of years refrain from making some important changes, you may want to re-consider your strategy.

* After all, this is all "for fun" - it's an open source project, so it should be "fun" and enjoyable.

* Suggesting "drastic" changes is all neat and dandy, but after familiarizing yourself with FlightGear you'll probably see quickly that it doesn't really need drastic changes at all: We have witnessed this in the "Local Weather" project, you could say it now *optionally* replaces the old system, but to work properly it only needed a way to switch off the old code - which just involves setting a bunch of properties (variables) from a Nasal script. There was no need to completely remove the legacy code, it was just made optional by setting a switch at runtime. Similarly, the bombable script leverages hard-coded C++ code for instantiating AI models dynamically - but the objects are controlled from scripting space.