View source for How the FlightGear project works

{{Working together}}

The official [http://www.flightgear.org/flightgear-policy-document/ FlightGear policy document] details how the project works.

As FlightGear is becoming increasingly popular each year, we've been seeing a number of controversial discussions regarding the inner workings of the FlightGear project recently. Meanwhile, it is a well-known fact among long-time contributors that the FlightGear development model may seem irritating at first and it is known to cause some confusions or even frustration among new contributors who may already have experience contributing in other flight sim communities or even other OSS software. 
So here's a collection of responses intended to clarify why things are set up this way. People interested in getting involved in the FlightGear community and contributing in one way or another, are encouraged to read this and understand how FlightGear has been able to be successful despite the fact that it does not have any commercial backing or a really structured development model.

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).

== Background ==
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.

This is something that all of us appreciate, because this is important to keep the project alive and kicking, so we do truly appreciate and welcome new community members, because this is an important part of enabling FlightGear to grow even more popular. 

There's such a huge range of ways to get involved in FlightGear, so that we truly appreciate everybody's skills. 

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.

== Irritations ==
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.

Apparently, this occurs frequently when dealing with people who already have experience developing software or contributing to open source software, be it professionally or as a hobby.

Over the last couple of years, such discussions have taken place increasingly and they are obviously eating up considerable resources, given that spare time is our most precious resource to contribute to the project.

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.

The best approach when encountering such problems is to take a step back, evaluate the goals and the means available, and come back with solutions or valid proposals. Several developers have taken long breaks, then returned to contribute again many features.

== Passion ==
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.

== Welcome to the club ==
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.

Honestly, you could search the forum and mailing list archives and probably find heated responses posted by even the most seasoned contributors. Some of us may have a track record of thousands of postings now and may seem like fairly knowledgeable contributors , but this is just a result of having been part of the community for a number of years, despite the deficiencies that we may have perceived initially. Frequently, some of our very first posts were also just voicing criticism.

It isn't even unlikely that new community members are bringing up long-term issues that have been annoying most of us for quite a while already. We are probably more aware of these issues and their implications than you are. But just saying that something is "broken" is simply not the way to affect the situation for the better. Some of us have tried and failed doing exactly that. To no avail.

Like you can see now, we've changed our strategy: We are trying to act like we want others to act, we are trying to be the change we'd like to see.

Really, your situation may not be any different than ours: We've all been there. You need to be patient and absorb what we're telling you. We have no doubt that you'll get along with most of us, especially if you can demonstrate that you are actually listening and absorbing the advice we are handing out and applying your new knowledge.

So this is an attempt at explaining things in a non-heated fashion, so that we can point aspiring contributors to this article explaining some things which may not be directly obvious, but which we feel are important to understand why some things are done the way they are.

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.

== Proposing changes ==
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. 

So, we would like to ask you to keep these factors in mind when proposing changes and when voicing recommendations, and when discussing such issues with fellow community members, publicly or privately.

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.

== Ideas getting ignored or rejected ==
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). 

There are many questions asked where the answer can be found in the Wiki with a short search. There are suggestions being made which even on first glance are impossible in practice. It's not the developer's job to deal with these things - it's your job as a forum user to do so. And not every rejection needs to be taken as personal grievance carried around for the next years - sometimes one just has to allow for the possibility that one has been wrong.

Often, it does require a certain amount of background knowledge to truly understand why a certain idea or feature cannot be implemented. New users, and even new developers are likely to lack this knowledge. You need to be somewhat familiar with the code bases involved in order to understand some things.

Since I work on FlightGear, I have suggested a lot of things - about 10% of which have been reacted on. To give you a current example: I've noticed that models from Nasal load way slower than needed, and I've asked that someone looks into it. I have not expected that somebody immediately jumps on it and spends 10 hours of his time tracking what is going on and delivers a detailed report in non-technical terms later. It has taken a few months and posting several examples to convince people that what I see is real. Then somebody looked at it and traced it to the (non)-existence of the osg texture cache. Now, people are debating the pros and cons of activating the texture cache by default, because it might affect stability and memory usage in an unwanted way - and I don't know if it will eventually be there.

I have no problem with that - neither with convincing people that my suggestion is worth looking into, nor with the fact that other issues I have not thought of need to be taken into account. But it seems a lot of people in the forum expect that because they suggest something, someone will take it very seriously and act quickly and are then disappointed when this isn't actually the case.

Coming from the other side, having worked on a problem I often know that a particular thing suggested cannot be done easily. If I have the time, I can take 20 minutes to explain why. Sometimes I don't have the time, then I just write a small sentence indicating why it doesn't work. Probably then somebody feels ignored. Can't help it - if I'd try to take the time, my 3 year old daughter would feel ignored, and she needs my attention more.

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.

Sometimes rejecting new ideas can be painful to contributors who had spent a considerable amount of time researching and implementing features. Some new ideas have been the seeds of a similar implementation by the more seasoned coders. In any case, it is always best to evaluate the pain/gain benefit, and to keep older solutions to problems rather than having a half-way semi-realistic solution. Ideas tend to get the proper recognition in time, if they are beneficial, or are quickly forgotten if they are not worthy. Keep in mind to do this for fun, and always attack the idea, not the person, to keep things calm.

== Lack of feedback ==
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. 


And to people who have stated (rightly or wrongly) that they don't feel the core developers are active enough in the forums:

When asking on the devel list why people keep the mailing list separate from the forum, the response I got was along the lines of 'We like to exchange information, and in the Forum we get to hear only noise - petty complaints, lazy questions and so on - so we stay where the information relevant for development flows'.

So, it goes two ways (I have been saying this before, haven't I?) - the probability that people will listen to what you have to say increases if you can convince people that they take you seriously.

When I started to write that I want to rewrite an integrated weather system, pretty much no one took me seriously because it's a large chunk of work and you need to know what you're doing, and, face it, there's a lot of noise being made about what people will do who drop it later after a week. After I had written a working demonstration, people started to believe that I know what I'm talking about. Sometimes that's what it takes.

From the other perspective, I would do the same. If somebody tells me he's going to implement volume rendering for clouds, I'd simply say 'Go ahead, I don't think it can be done.' Once he demonstrates to me that it can be done, I'd be willing to work with him. That makes a lot of sense, because the amount of ideas that can be realized and have a person behind them who is willing to see it through is a tiny fraction of the amount of ideas being presented - so it pays to focus on those who have a shot at success.

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.

Sometimes, there is a rift between new people and older members, simply because the latter expect all things to go through the proper channels and procedures. Unfortunately, since these are hardly policy, some prior research on the best communication channels and the best people to talk to in person can be valuable and time saving.

== Users vs. contributors ==
We have here two groups of persons (with blurry boundaries): The first group takes something for free, which is a flight sim which you download from servers for which someone probably pays real money. The second group gives something, which is their time to create the simulation.

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.

On the other hand, a 'user' in your concept of course is supposed to be entitled to not only acquire FlightGear, but also get support in the forum and should also have a voice ( in what is done for the project (by others), and for this he's expected to do what in return? Nothing.

If it disturbs you that I don't share this sentiment, then so be it, but let me be very clear: I have every sympathy for people who come here and offer to return some (whatever small) contribution back for getting FlightGear. I get angry when I see their contributions rejected for opaque reasons, when I see disparaging comments made that this is 'merely modelling' or 'just Nasal', when I see someone being discouraged from honestly trying to contribute. I have also sympathy for people who take FlightGear, enjoy using it but don't want to contribute and still ask politely for some help in the Forum.

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.

== Lack of Support and Backwards Compatibility ==
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.

For JSBSim there been has incremental changes in almost every version of FlightGear. These changes did things like add features or change the way a specific feature acted. For example around FG 2.4 there where changes to the engine cooling code (to allow modelling of cooling systems with things like cowl flaps) and also to the nose/tail wheel steering code (to allow toggling between locked and swivelling steering wheels). Many aircraft are unaffected by these changes because they don't make use of the enhancements but some aircraft do use these enhancements. For example the JSBSim P-51D uses both of these features and it probably will not work correctly (IE. it will over heat/run cold or not have correct ground handling) if used with FG versions before 2.4. There is also the possibility that it will throw all kinds of error messages when used with an older version of FG but none of this has been tested at least by me. So it may be OK with a few missing features on 1.9.1 or it may fail totally. We simply do not know. If someone complains about the JSBSim P-51D not running correctly on FG 1.9.1 my reply is too bad you need to upgrade to 2.4 or later and get back to me if things aren't working after the upgrade. There may be other more recent features that other aircraft use/leverage that don't affect the P-51D so I think this is a significant issue.

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.

== Priorities in bug fixing ==
{{cquote|I stopped filing bug reports after too many instances of our omniscient developers denying a problem exists, or telling me to fix it myself (yeah, right). Bug reports are a waste of time. You'll have a hard time convincing me that anyone cares about fixing bugs that don't bother them personally. I'm really glad some folks are writing free software for me, but you gotta admit, most of them are pretty arrogant about it.}}

Let's start this with the obvious - how much of your free time do you invest into things which don't bother you personally? Do you volunteer for 3 hours per week to make the world a better place? Because preciously few do, whereas the average FG developer does.

For a bug to be fixed it takes the coincidence of a few factors:

# Attention - someone who has the ability to fix it must know about it
# Relevance - that person must judge it worth his time
# Information - that person must either be able to reproduce it or be given enough information
# Access - someone needs to commit the fix to the repository

If you tell me that you find that you get a shader compilation error of someshader.frag in line 401, you have covered 1) (told the right person), and 2) (we shouldn't have shader compilation errors) and 3) (I have all I need to fix it, a line number is as good as it gets) and since I have 4) covered myself, you'll see a fix overnight.

Sadly, that's not how bugs are usually reported. They're told to the wrong person with insufficient information given, follow-up requests for more information are ignored, and as a result nothing happens. Because I'm not going to spend hours guessing what people might be doing such that a problem becomes visible if I can't reproduce it, and neither is anyone else I know. Arrogance is to expect users have the right to such a chunk of developer's time and hence feel they shouldn't need to be asked for more info and to do checks.

Relevance stalls another bunch. The time of core-developers like Stuart or James (who do a hell lot of unpleasant bug-fixing) is precious - if they work on fixing something for 5 hours, I'd rather have them fix something important. Relevant things get priorized. If I judge a problem relevant which I can't fix, I gather enough information to make it easy to find the cause and then ask someone to look at it. TACAN got fixed within a day, lack of solidity of the carrier within a week. These are flight-critical, spawning on the carrier upon reset is not, it's a luxury - the sim can be operated just fine without the ability to reset and we could simply disable it.

Access stalls a fix really rarely - only if there is concern that the patch might have unwanted side-effects.

Also, in a fair share of situations, the problem is with the user or his system. A number of 'FG doesn't run' reports have to do with users messing up paths on their system during re-installing something. Many 'AP is broken' reports really are improper usage of correctly modeled systems (I'm guilty of that one myself in two instances). If FG has a problem only on your computer, it's unlikely to be a problem of FG. And so on. Of course, all users 'know' that the problem can't possibly be on their side...

== Number of aircraft vs. quality of 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. 

Taking the P-51 issue as an example; even if the FDM did closely emulate the real thing, the reaction time to correct for any divergent yaw on takeoff will be much slower than it would be in real life with more sensory cues. Once you do react, you can't react with the same accuracy as real life due to the lack of control feedback, so your inputs will tend to over correct the situation which in turn you will be slower to react to.

This can obviously be corrected by making the FDMs less touchy than the real-world aircraft, but this then compromises reality. So it takes a bit of a balance.
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.

So, you ask why some posters are so enamoured with the FG FDMs. For once, because I know physics. When I do certain things, I know how the aerodynamics works out, and I expect to find that in the simulation. 

For two, I've been flying gliders for a while. I distinctly remember the feeling of making tiny not really conscious movements with the stick all the time to fly the thing. I want to have that experience reproduced by a flight sim, it's part of the feeling of immersion - and the top-end JSBSim models do that for me. Also, I want to _do_ something while flying, not just get my plane on rails and watch the scenery.

Third, because I find it educational. I for instance happen to know that the F-104 Starfighter was pretty accident prone. Just 10 minutes flying around with the thing told me why - when the plane becomes unstable, what manoeuvres you can and can't do (I think the Starfighter is also one of these FDMs with plenty of real life experience used by the creator...). I find it interesting to explore how the SR-71 reaches Mach-3 and why it needs to do the funny 'dipsy' manoeuvre. I find it instructive to understand why one has to fly the Concorde by the book and how fuel consumption figures change if I don't. I want to understand how thrust vectoring can be used and how stable it is. I want to learn what's different about a helicopter. For all this, I need the real physics of flight simulated as faithfully as possible.


As the creator of several aircraft made for FlightGear including a heavily researched Velocity XL and an Edgley Optica, I can say the above observation is nonsense. Fly one of my planes and the controls won't do diddly under 30 knots unless a pilot's handbook or a pilot's report indicates they should. Even the worst flight models in the FlightGear world don't have fully effective controls while sitting still. As for inherent stability, my own efforts are easily trimmed at cruise speeds for relatively benign, hands-off flight to match the flight manual or pilot reports.

Why are some so enamoured of FG flight models? I'll state what Thorsten wrote in another way. I'm not a licensed pilot, though I do have stick-time in several light planes. But I'll never fly in an Optica, and I'm very unlikely to ever fly in a Velocity or a Grumman Goose, and no sane airline is going to let me into the flight deck of an MD-80. By building these models, I can gain an understanding, an insight, and an experience with these aircraft that would otherwise be closed to me. I can know them in some ways that even a pilot might not know them. The closer the simulation matches the real aircraft, the closer my experience comes to that aircraft. I can't experience these planes unless they are correct in every detail that matters, and pursuing that correctness is a long journey, perhaps one without an end.

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.

Are there "crappy" flight models in the FlightGear world? Sure. Plenty of them. Maybe most of them. But there are some darn nice ones, some made by pilots with hands-on experience, some with the feedback of pilots, and some by non-pilots using meticulous research. Many are simply nice modelling efforts, waiting for someone to come along and create a good flight model, or add systems simulation, or cockpit instruments, or some other contribution.

In the MSFS world, the typical model is a commercial product, released as a complete and well-rounded package. In the FG world, few models are finished, complete efforts. Developers work on what they know and what interests them, and most are open to contribution from others. Few works are above improvement. The neat thing about the FlightGear environment isn't that it's free. It's that if you don't like some aspect, you're welcome to help refine it. You can learn to improve it yourself, or you can help by suggesting well-conceived, objective changes to the authors. Most will listen. And you just might learn something along the way that will surprise or enlighten you.


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!

== Fictional Aircraft ==
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.

FlightGear isn't only developed with a single role or purpose in mind, FlightGear is to be understood as a framework for developing new aviation related features, including fictional features. We have hundreds of "aircraft" and "vehicles" available in FlightGear, only a fraction of those are fictional, and most of the fictional ones are not even well-developed, you will surely be able to find other aircraft that you are interested in, see: http://www.flightgear.org/download/airc ... ilterable/

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.

Aircraft like the ufo, ogeL, bluebird etc were usually created by people in their initial phase of becoming familiar with FG - for example, the ogeL was made by the same guy who ended up modelling the Seneca, one of our most-developed (and maintained!) GA aircraft in FlightGear: http://wiki.flightgear.org/Seneca

s you can tell from looking at the wiki, the ogeL aircraft developer has not only become the developer and maintainer of the Seneca aircraft in FlightGear, but he also has become a FlightGear core developer writing C++ code and maintaining the autopilot system for example, and he also happens to be a CPL-IFR/ME rated pilot in real life, who owns the Seneca he modelled for FlightGear.

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...
Still, 3D modelling is a completely new skills, and needs to be learned from scratch - which applies especially to people who "only" have a real background in aviation, but not in computers and/or games.

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 need development guidelines ==
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?

The problem is that the reason that these things do not exist already have to do with how things are in practice. 

The consequence of developers paying more attention to what users want, rather than what they are interested in, and not being free to ignore suggestions is that a developer potentially is asked to work on something he personally dislikes, just because enough users want it. 

Who gets to decide what a relevant suggestion for the benefit of the project is and what a petty suggestion for the benefit of a single user is?

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.

I've learned in the past year or so that FlightGear development is a messy place. It simply isn't structured in the clean and neat way I have in mind. Unfortunately, I've also come to realize that I am part of the mess - the way I work simply doesn't fit in with the equally clean and neat way others have in mind.

== Telling volunteers what to do ==
Posted by MAKG:

; Rule #1
: You can't tell volunteers to do anything. You can ask, but you have to motivate it if you want good and timely work, or any work at all.

; Rule #2
: Volunteers may or may not be inexperienced -- it has to be evaluated and management is different for the two cases. Allow a lot of time for inexperienced developers.

; Rule #3
: Let the volunteers learn something. You can tell them the right way to do something, and they may or may not listen. They are volunteers; let them do what they want even if it means redoing the work at a later time (example -- I had an undergrad student code an early telescope trajectory algorithm -- he wanted to numerically integrate rates because it was a whole lot simpler to derive; I explained that numerical stability would be much better with analytic positions. He coded rates, it was unstable, and he redid it as positions later. This was an extremely valuable lesson). Keep in mind that sometimes the volunteers are right...be prepared to learn something from them (the same student insisted on making a simulated sky, over my objections that it was unnecessary for the task at hand and time consuming -- and it turned out to be the single most valuable feature we have).

; Rule #3A
: Volunteers may want to exceed their abilities. Let them unless it's far beyond their abilities and you can't tolerate a delay (if you're in that zone, reconsider whether a volunteer effort is really appropriate). They may need a lot of help, or their work may need to be redone, or they may not finish the work. This is part of the cost of a volunteer effort.

; Rule #4
: BE GENTLE. These are volunteers. They won't do work you want/need if it's painful. Coax as needed, but nicely. Steer, don't push.

; Rule #5
: Though management is necessarily loose with volunteers, it cannot be completely absent. There has to be a coherent vision coordinating the effort, or it will be unfocused and will not serve the needs at hand.

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.

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

The notion you may have in mind when you talk about 'elitism' is that everyone should be equal - applied to FlightGear, that everyone's opinion of how things should be heard and should matter about equally. In real life, that's how democracy works - everyone gets a say how to run a state. But there are many situations which do not work like this. Consider a shareholder's meeting - here influence is proportional to the investment. If I meet with 100 other shareholders, but I own 60% of the stock of a company, I alone get to decide what will happen. Or consider a scientific conference - here your influence is proportional to your expertise. You may have your favourite theory why Darwin was wrong, or why climate change is a fluke, but without some scientific merits, you won't be even admitted to the room, and it takes quite a bit more of reputation to get a talk.

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.

Experience shows that it makes a lot of sense not to uphold the pretence that everyone is equal with respect to some property when this is in fact not the case. I've been observing internet language communities over the last 10 years where you have basically two classes of users - those who know the language in question, and those who ask questions as they are trying to learn. Almost without exception, communities which treated everyone equal did not work - the experienced users were annoyed at being interrupted in technical discussions, were told that everyone has the same right to enter a discussion, decided that they'd rather discuss in a place without interruptions, thus the communities were left with the users who bring only questions with no experts left to answer them, being unable to get answers they also left and the communities died. The communities which respected expertise worked - it's better to start as low-influence user in a forum and get your questions answered than to start as equal-influence user in a forum and not get your question answered.

Perceived elitism is not a problem only for the Flightgear project, and the best way to avoid misjudging people is to make contact in a polite but ferm manner, expose yourself in a very matter-of-fact way, and keep it technical as much as possible. Always remember that with great power comes great responsibility, and if you get one day to be in a elite position, you might regret the old happy careless days.

== FlightGear is a meritocracy ==
FlightGear, as best as we have managed to understand the somewhat opaque workings in core development, is a meritocracy - your influence is proportional to the amount of work you do for the project. It's not closed, i.e. you can, if you invest a lot of work into the project, work yourself into a position where you have a lot of influence even starting today from zero.

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.

Question: Are you personally ready to work for FlightGear on something you dislike if enough users ask you for it? If you answer with yes, then the best way to proceed is that you poll users what they think you should do (within the limit of your abilities), and then do whatever is requested. 

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.

They are different areas of expertise, to be a good 3d modeller and graphics expert is quite possibly as demanding as to be a good C++ programmer, Nasal coding isn't per see inferior, ... so why are they not equal?


The reason is, simply the dependency structure: FlightGear can run, live and be developed without detailed 3d models, but it can not run without C++ code. If tomorrow all C++ developers quit, that's quite possibly the end of FlightGear, if tomorrow all 3d modellers quit, that's the end of eye candy in FlightGear.


It's not particularly fair that this translates into the existing project structure, and in fact if you go through my posts here and on the devel list, you'll see that I continue to make the same point. As I said, can't all be fixed in a day... I don't have a particularly large influence either, all I can do is talk to people and ask for patience. You can read up what I wrote in the case of the Bo-105... Good work tends to be recognized eventually - be it modelling or coding. But there's no guarantee, sometimes you have to accept being frustrated, get up and try again. Or you walk because things are not perfect as they are, which is a pity.


Another thing I don't like is that I feel that the power which comes with having a lot of merits for the projects gets sometimes abused by people who behave in a way that would never be accepted from newcomers.


And yet - it's a fine line between idealism and realism here - so suppose for a moment I had the power to do as I want with the project - what would I do? I feel that all users and contributors should be treated with some basic level of politeness. Assume someone violates that rule, but happens to be a core contributor. Idealism tells me that I need to enforce the rule, because everyone is equal in value as human being and deserves to be treated with respect - so quite likely the developer feels pissed off and leaves, creating a huge gap in the project (and, no kidding, there are people who are really important...) - in the end, no one benefits if the project collapses. So realism tells me to let things pass - it's better to mistreat one user than to kill the project and to make all users unhappy in the process. 


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.

So, perhaps a few folks can step back and see the bigger picture - and maybe share a vision: How would it be if contributing to FlightGear were as easy as contributing to Wikipedia - just what would, e.g. our scenery look like?

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 guys need some serious changes ==
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.

== FlightGear is inconsistent and overly complicated ==
: the fact that it's overly complicated, lacks a single design or even feature set, defies any semblance of cohesion, daunts and confuses would-be contributors with equal severity, and thus produces a wide range of results quality from "embarrassing" to "ready-for-commercial-release" [http://forum.flightgear.org/viewtopic.php?f=14&t=20413#p186983]

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.

Admittedly, it's far from cohesive, but there's really nothing that we can do about it: It would require a coordinated effort, not just people telling others what to do, but others willing to listen.
The T4T/combat support situation isn't any different: we have flug's bombable addon as the most sophisticated option available in FG, and then we have various more or less "competitive" approaches, including T4T - yet most folks are not actively seeking collaboration, and doing very little to unify different concepts and approaches. Instead, the focus is often on differences rather than shared needs and common goals.

Which is part of the reason why we have so many "unfinished" aircraft in comparison to other simulators. But like I said, there's really nothing that we, as a project, can do about it - short of adopting a commercial development model and a corresponding hierarchy.

Absent that, we'll have to continue embracing the "Darwinian's development philosophy", where everybody is free to contribute in whatever form they see fit, and it will be up to time to decide which features are going to stay, and which are going to be ripped out eventually.

All of us have real life obligations, and very few of us are willing to accept additional duties/deadlines, no matter if it's aircraft development, core development, texturing, scenery work, wiki administration, forum administration or other "duties" - still, all this needs to be done by someone. 

Thus, it's those who roll up their own sleeves and spend their time contributing who get to influence the way FG development is heading, no matter if others agree or not - the only "hard currency" that counts in this project is time, i.e. the amount of time you have to contribute to the project

Which is also the reason why we are seeing some really skilled and experienced contributors (with very little time on their hands...) being increasingly fed up with the way FG development is going recently, simply because there are quite a number of guys who may not be as experienced or skilled (i.e. not holding multiple CS degrees), but who may be able to spend more time contributing to the project in a different form, which -at least in part- also explains the sheer rate of growth of Nasal scripting in FlightGear, especially in comparison to relatively little new C++ code being committed to the core repository (the canvas system being the obvious exception here, but ironically the Canvas system additionally fosters scripting adoption even further, because base package developers can suddenly contribute in areas that were previously reserved for C++ developers only, such as the GUI, avionics and other fancy stuff).

Honestly, we do have various accomplished core developers who do not particularly like the way Nasal is increasingly used, or the way the Canvas system is becoming a viable alternative over some hardcoded solutions - likewise, the weather system being 95% scripted is another annoyance to some - but at the end of the day, it's really just software evolution taking place: We have a decreasing number of experienced C++ developers, more and more becoming increasingly inactive - which is why the base package has been seeing so much development in comparison, and under these circumstances it is only natural for some core developers to recognize these issues and focus on providing building blocks and infrastructure to empower base package developers.

It's not that your assessment is totally off, but we cannot really deal with it, unless we are telling people what to do - and as you may have witnessed before, that doesn't work out too well usually (remember the various T4T discussions). Thus, we need to accept what's brought to the table, no matter how inconsistent it is, and "absorb" it until something better comes along - even though that may mean that we'll end up with various different approaches in the meantime.

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

== Is this program just for scientists and engineers? ==
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).

This applies especially to long-term contributors. Obviously, the people who contribute for a long time, get to shape the project more so than people who just happen to show up and post some ideas, features requests or bug reports.
In part, this is also due to the reputation they get to enjoy among fellow contributors, so their feedback has automatically also more weight, too.

That might explain why many long-term contributors seem to have a fairly similar mindset, and why some things are done the way they are.

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

== Community interactions ==
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".

=== The forum ===
Regarding helping others on the forum, thinking back on my early days with FG I'd have to say that what's obvious to a long-time FlightGear person isn't necessarily obvious to others. Sometimes people do search for answers first, but they may not be asking the right questions or have a deep enough knowledge of a system or community to proceed.

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.

It's usually obvious when people are asking questions in the forum thoughtfully, and when they are being casual, lazy, or discourteous. But sometimes it isn't so clear. There may be language barriers, or they may not know exactly how to ask, or they may simply be shy of a new environment. Like Someguy, I cringe when I see our good people tell somebody to go on an Easter-egg hunt for their answers. If it's tiresome, which is understandable, or one doesn't feel like helping, then it's wiser to simply not respond.

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.

=== Coordination ===
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.

=== User facts of life ===
* 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.

=== Developer facts of life ===
* 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 there 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.

== Conclusion ==
There's simply no use in complaining that FlightGear isn't the community you'd like it to be - but there is use in working to make it the community you like it to be. It's just requires more effort 

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

== To be discussed ==
* 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.
* Fact of the matter is - you're a potential contributor until proven otherwise, and as far as I am concerned, that gets you basic politeness, some measure of attention and some measure of help from my side, just like I would do for anyone else asking in the forum. If you want more (information, help, of my time, of Hooray's time ...), you should keep in mind that at this point you want something from the community, and so *you* need to adapt to the community, understand how it works and play by its rules - not the other way around. To say it very bluntly - FlightGear will survive without you if needed (as it will survive without me if needed).
* 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.

* Influence in the FlightGear community scales roughly with level of your contributions.
* Obviously, long-time contributors have a more sizeable track record of contributions which in turn gives their voice more weight
* 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 able to build FlightGear from source, who know C++, who have some spare time to contribute to FG are in very short supply
* developers getting involved in lengthy discussions cannot write code at the same time

* Asking people to work on some particular problem that's bugging you, is generally alright - but you need to be willing to make your case and do that in a fairly compelling fashion. We have some really long-standing issues in FG, some of which most of us (including core devs) agree are IMPORTANT. This is a rare situation, but there really are things that pretty much everybody agrees are REALLY IMPORTANT to work on. So there's some very real competition and it won't be easy to talk people into doing something for you. 
* Another important thing is staying focused: it isn't helpful to raise dozens of issues in a short amount of time if you cannot also solve them, regardless of how "real" and valid these issues might be.
* signal/noise ratio

* Frequently, people keep emphasizing that this attitude is related to their  inability of fixing things themselves. Now, we are not going to suggest you learn how to build FG from source or how to program in C++. But rather, we suggest you focus on a handful of issues that truly annoy you, and where you think you could actually help and contribute solving them. That would surely help improving your signal/noise ratio, basically giving you opinions more weight here. There should be a fair share of opportunities to get involved in meaningful ways. We have a bunch of wiki resources to get people started contributing in various ways.

* 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.

* When comparing FlightGear to other OSS project, it is important not to compare apples and oranges from a manpower perspective. We don't have the manpower here to establish a proper hierarchy like many of the more prominent projects (think Mozilla/Firefox). There's is TONS of management work happening behind the scenes, there's the Mozilla foundation and there are donations and so on - so Mozilla development is not only about coordinating a bunch of programmers who happen to develop a piece of software in their limited spare time, they have passed that point long ago.

* 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.

* FlightGear has never been in a better shape than it is in right now. In fact, admittedly FlightGear -as a software project- has actually been in a much worse shape for many years (for example: no forums, no wiki, no bug tracker, no git repository, no Gitorious merge requests, no build server, no formal release procedures etc)- still it somehow managed to stay around for over 10 years, despite all its deficiencies...

=== Mods and forks (built on top of FG) ===

* You're here asking for help from the FlightGear community. Help is hard to find in the first place (that's a fact, not a threat - there are calls for volunteers for many different projects that go unanswered).

* You're planning to fork in a substantial way. The difference for me is - as long as what you're doing is FlightGear, I will care that my own development work (integrated weather system) runs fine on your system because I develop for FlightGear. If T4T is off to the degree that I'd have to download and compile different code, then I won't care that my weather system runs (it may or may not, dependent on what you do to the environment) - it has become your problem. Not because I am mean, but because I don't have the time and inclination to maintain compatibility to two different development branches. Whenever you develop using a different repository, you are 'them' and we are 'us'. We can be a friendly 'us' and 'them' as between FlightGear and JSBSim, we can exchange code, people can be part of both projects and maintain compatibility and work together - but the basic fact is that there is 'us' and 'them', and (probably like many others) I feel responsible for my part in 'us' but not for my part in 'them'.

http://forum.flightgear.org/viewtopic.php?f=18&t=13298&p=134793&hilit=supply+developers#p134756
* Do you have a clear idea what your project involves?
* Do you have a clear idea what is already there?
* Will it help Flightgear?
* Will my voice be heard?

* This community is far more likely to get involved if you involve it - and that'd mean opening your previous decisions for debate - than if you ask people to get involved with a project of your design which is no longer up to debate (speaking of resistance to change...). Again, that's your call, I'm not threatening in any way, I'm simply trying to explain how things (according to my best understanding) are and what the likely consequences of your project design are. I don't mean to imply that I or others would actively block you if you're not doing it 'the FlightGear way' and hold information back. I hope that is sufficiently clear.

* 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.

* Really, FlightGear is where it is now after 10+ years of ongoing development, many contributors (especially core developers) are long term contributors who have contributed to FlightGear for several years.
Still, FlightGear is a complex piece of software and there is probably not a single core developer who is familiar with ALL of FlightGear (features, code etc).

* all long-term FlightGear users know for a fact that there is usually a short supply of C++ developers, knowing not only how to program in C++, but also familiar with 3D graphics, OpenGL/OSG programming and many other aspects that are important when creating/developing a simulator.

* So we are really standing on the shoulders of giants here, because we are now -after 10+ years- in the position to create significant new features within the constraints of the FlightGear base package, without even touching the C++ source code at all - simply because FlightGear has become so flexible and extensible. 

* 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

* I consider what you want to do perfectly possible, but I advise you to rethink your strategy: your decision to build upon FlightGear to create a combat simulator illustrates an admirable degree of foresight and experience that many other people with similarly ambitious ideas lack, but announcing to "rip out parts" and rebuild the whole thing is very unlikely to happen any time soon.

* 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.

* you'll have a better chance of getting your code upstream (if that really is your goal) by coordinating your plans with the fg core developers and asking for recommended paths to proceed. Getting your code contributed back is obviously a good idea because it will be much less of a maintenance burden for you guys if your changes become part of the mainline.

* Ultimately, this being open source, you don't need the approval of anybody - as long as you obey the requirements of the GPL, but rest assured: it will be much easier to deal with the FlightGear community and to get help if you play it "nice" and this very help will be very much needed in the beginning.

* 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.

* Today, with much infrastructure available for free or easy obtainable, forking a project has become easier than ever. You might end up in a position to fork Flightgear to support your own pet projects, perhaps your own little business based on said pet projects. The thing to keep in mind is that it is quite hard to keep up with the latest developments. Be prepared to spend lots of hours just to add all the new features being developed in the mainline. However, it can also be a very satisfying experience, especially if you base your own fork on a slightly older code version, and try as hard as you can to keep it stable. A successful fork is hard to achieve and maintain over time, but you may be in a situation where this is required. Do not hesitate to try it. Always bring your contributions to the attention of upstream. They might get merged and save you some trouble in the future.

[[Category:Working together]]
[[fr:Comment fonctionne le projet Flightgear]]