How the FlightGear project works: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 136: Line 136:
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.
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. If your answer is however no, I feel you have no right to make the statement.
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.
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.

Revision as of 18:51, 8 February 2012

This is a collection of responses to various flame wars concerning the inner workings of the FlightGear project that we've been seeing recently.

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 everbody'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.

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.

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.


Not getting feedback

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.

Users vs. contributors

We have here two groups of persons (with blurry boundaries): The first group takes something for free, which is a Flightsim 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.

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.

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

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 se 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 repsect - 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.

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

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 sizable 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 compae 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://flightgear.org/forums/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 anytime 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.