Since discussions along that direction keep emerging, Hooray has started copying responses in discussions to a wiki page.
http://wiki.flightgear.org/How_to_the_F ... ject_works
I thought that's a bit too long and unstructured, so I have drafted a summary Q&A of how I would describe the how and why of the project structure.
Maybe the long-term users can comment, we can refine and then post it is sticky in the forum to have something to point to in case of questions?
How is the Flightgear project structured?
Loosely speaking, there are three layers (with certainly blurry boundaries): Developers, contributors and involved users. Developers work with the code and in general with the interdependent parts of the project where changes are likely to affect many different areas and need to be discussed and co-ordinated. Contributors work on more easily separatable issues like creating aircraft, textures or scenery models. Involved users do not contribute to the project software and data directly, but may participate in discussions, file bug reports, contribute to the Wiki or provide help in forum disucssions.
Part of the relevant development also happens outside the Flightgear community, the most prominent example is probably the JSBSim flight dynamical model which has its own development community, with some people being active in both.
How does one become a developer (contributor,...)?
By starting to work on the Flightgear code, to discuss it with other developers and by requesting to merge the changes into the central repository.
But is there no formal structure?
In a sense there is - there are people who have control over the project infrastructure and hence represent Flightgear in these areas. For instance, only a limited number of core developers has commit rights for the Flightgear and Simgear GIT repositories, a few people have access to the scenery and object database, contributors usually have access to their own aircraft development, but a limited number of people has rights on whole FGData repository, then there are Wiki admins and forum moderators and a handfull of people who have access to the Flightgear project webpages.
How are these people selected
Usually the person who originally created the piece of infrastructure or the people who currently maintain it and have access rights decide who else should have access.
Is there no project management, project leader or development plan?
No, there isn't. Basically each developer works on what he thinks is the most important issue at the moment. Any larger-scale changes are discussed on the development mailing list which is used to co-ordinate the efforts of different people. There are some agreed-upon structures like the timescales of the release plan which arise by being proposed by interested people, being discussed and modified in response and then being published.
Isn't this a very unprofessional project management model?
For a business, it probably would be. For a collection of volunteers, it isn't. It has a close analogue in the way scientific collaborations work for instance, and it has already worked for a decade.
Any more centrally managed project would require a leader with the authority to assign developers to certain tasks. In a company, this can be done because developers are paid, and so they may accept to do a task even if they don't like it in exchange for money. For a volunteer project, there is no way of getting people to submit to any central authority if they don't want to. Several developers have expressed that they wouldn't want a central project management structure with the power to assign tasks. Just imagine, you would be asked to first place 100 models into the scenery database before your forum question is answered - how would you feel about being requested to do a task you didn't volunteer for?
That's not very user-friendly, is it?
Admittedly not if compared to a business model which is centered on what the customer likes. But then, you get the product for free.
The primary motivation of most developers is probably that they're interested in solving a particular problem and that they like creating a very realistic flight simulation just as they prefer it. Pleasing a large number of users is a factor, but probably in most cases not the highest item on the priority list. Having motivated developers is better than having satisfied users at the expense of frustrated developers leaving the project.
But Flightgear needs feature XXX, how can it get it done?
In the current project structure, there are two ways to implement a new feature: 1) you do it yourself 2) you convince people of the merit of your argument.
Manpower and time are scarce resources in the Flightgear project, and to get them assigned to your needs is not an easy task. Every week, projects are proposed which could easily tie a few people for a month while tasks like bug tracking and fixing or documenting new code also need to be done. It is necessary from a developer's perspective to sort through feature requests and priorize, and it is quite normal that your own request may not receive high attention.
Unless you start working yourself on a feature, you have to live with someone else's decision that you rather than Flightgear needs feature XXX and that it will not be implemented.
But how can I start working on something, the documentation is so lousy?
Unfortunately, the combination of no central project managament and lack of time means that developers are primarily focused on creating running code, then bug-free code, then efficient code, and then technical documentation. While there is user-friendly documentation for the simulator as such (The Manual), guides on how to get started with contributions and development are often not optimal.
However, if you are serious about something, there are people in the forum and in the mailinglist who can help, explain things, point to the right documentation and get you along a contributor or developer path. Admittedly this is difficult in the beginning,
I don't like this project structure!
The Flightgear source code is GPL, you can take it and any like-minded people and start your own BetterFlightGear project in any way you like.
Alternatively, influence within the Flightgear community roughly scales with your contribution to the project - if you are a long-term, well recognized contributor, people will tend to listen to your suggestions and accomodate your requests much easier than if you are a newcomer. In other words, you have to earn your respect in the development community, but once you have done that, you can also change the way the project is going to some degree.
The key is talking to people and exchanging arguments. Complaints simply do not help if the majority of developers has decided the project runs the way they like it to run.
But it could be so much better if there were proper user support (documentation,...)!
Prove it!
Experience suggests that the number of people who say they would do something if ony X were realized is far larger than the number of people who actually do something when X is realized.
There are many areas where the barrier for contributions is very low (Wiki documentation, texturing, populating the scenery with stock models,...),so if the difficulty of getting started with C++ coding, Nasal or scenery creation is keeping people from contributing, then why are there so few contributors where such barriers do not exist?
In other words, while focusing attention towards user support (documentation,...) is a good thing in itself, it is not obvious that it is still good for the project in the long run if that attention must be taken away from coding new features or bug fixing, so this is not something you can simply claim as being true.