Implementing new features for FlightGear
 |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors. Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.
We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".
Currently, this article is entirely based on a write-up that Thorsten contributed based on having worked on a variety of novel, and unprecedented, FlightGear features over the years which initially also didn't receive much support at all, and which also caused lengthy discussions (or even flame wars) on the forum and the devel list, including features like Advanced weather, Atmospheric light scattering, Procedural Texturing and most recently the EarthView orbital rendering engine. These are just a few examples to put some context around the advice given here. Also note that the people who contributed to this particular write-up are not core developers per se, we are also primarily middleware/base package contributors. And when we started out a few years ago (and several thousand postings back), we were also highly critical about the way the project works, and all its shortcomings. And now, we're often the ones being "yelled" at on the forums when dealing with newcomers, even though that's exactly how we started out. Yet, fast forward 5+ years later, we are still trying to contribute in meaningful ways to the project, despite some (or even many) of these problems still persisting even today. So this is an attempt to provide a lessons learnt intro based on newcomers trying to become contributors, and trying to turn their ideas into features that actually end up in FlightGear, without having to be expert programmers necessarily, or even programmers at all.
What is this about?
Like many FG users, you probably reach a point when you think 'Wouldn't it be nice if we had feature XY?' From this point, there are various options available:
- You mention it in the forum:
A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there.
- You make a formal feature request on the issue tracker:
The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen.
- You make it your own project to get feature XY implemented:
This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on.
Some (unpleasant) truths up front
First, to avoid disappointments, it is important to understand how FG as an OpenSource all-volunteer project works - if you start with your project without understanding these essentials, it is bound to fail.
- Flightgear relies on having a contributor base, but not on a user base
Unlike a commercial project which needs customers to survive, FG does not. As a result, FG development is not focused on the end user. Developers tend to work on features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting.
- Developers are free to do what they want
This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily.
- Flightgear development tends to be inclusive
There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers).
Test the waters
If you want your idea to be part of Flightgear in the end and not a fork or an addon, test the waters early on. Working for a year on some project which won't be committed in the end is frustrating for both sides. Use the forum or the mailing list to talk to people, get a feeling for how the response is, just don't leave it there.
Some events that have occurred in the past, and what to learn from them:
- Beautiful airport scenery (and certain aircraft/cockpits) could not be committed, because it was textured using material from a source that has free textures with a no commercial use clause. This however is incompatible with FGs GPL license which permits also commercial use. Lesson: If you use any material other than your own work, check the license early!
- A large collection of Swiss airport scenery could not be committed because it was structured in the wrong way - scenery data has to be submitted in a certain format to the scenery database, other data to the FGData repository. Lesson: Study the structure of FG - don't expect that the whole structure of the project will change for you, it is what it is for good reasons, even if you don't know them, others do.
- The bombable addon providing support for air combat could not be committed because the devel community feels strongly that FG should remain a civilian aviation simulator. Lesson: Test the waters, see what the response to an idea from developers who can commit are. They will decide, regardless of what users say.
Gather information
Regardless if you want to proceed on your own, or if you want to find people to help you - you need information. If you want to see a new visual effect implemented, at minimum you need to find out who inside the FG project can help you, even better is to have an idea what options FG provides, how the effect framework works, how effects are configured etc. The Wiki is your friend, but usually if you show some interest, people in the forum will post helpful links. If you want to be taken seriously later, work through the information and make sure you know what you're talking about.
Make a proposal
Now it's time to approach the people who can help you. Remember - they're volunteers. So you need to get them interested.
Do...
... point out how your idea will make FG a better simulation. ... make a point out of what you would be willing to do if only XY were available. ... be as concrete as possible, point out what precisely you would like to see changed. ... demonstrate that you have looked at the relevant information and know what you're talking about
Don't...
... demand anything from anyone. ... be rude or angry if people are critical - it's part of the process. ... point out how bad FG is going to be or how it will fail if your idea is not implemented. ... say you can't do anything, because you don't understand C++ - the human mind can learn Compare 'Wouldn't it be cool if we had better-looking cities like X-Plane?' with 'Would it be possible to make the random building shader configurable such that it loads a pre-defined set of 3d models and assembles them in naturally looking groups by a placement mask of this and that format? I would then take care of the buildings and textures, but I'd need some help with the code. Here's a picture of how FG could look like.' - which of the two proposals would you support?
Even good proposals have a fair chance of failing to get any support. The reason is that experience has shown that the majority of people who say that they would do X if only feature XY is implemented do in fact not do X afterwards. Which is to say, before starting to join a project, developers want to be reasonably sure that their work will not be in vain because you lose interest and walk away. The magic words here are 'track record' and 'proof of concept'.
If you already have a history of bringing projects to a conclusion, people are far, far more likely to support you. If you have not, because you're just starting out, the best thing you can do is a proof of concept. Perhaps something should really be in C++ for performance reasons - but you can make a simple proof of concept in Nasal scripting space. Once people see that you're actually investing time and work rather than talk, and once they can see what you want to do, you're again more likely to get support.
Be persistent
If you fail to get help you need, think about why. There may be fair reasons for it - your priority may not be everyone else's priority, or some criticism may not be mean but actually valid, or your contribution isn't apparent enough - go back and try to revise the proposal. If you can't get help in some area, perhaps there's a workaround which is less perfect? Nasal often is a viable alternative to C++, and subsystems can always be converted later. Trying to get things perfect up-front is likely to get you nowhere, because making things perfect is very hard - starting with something 'good enough' and improving it is more likely to succeed. If your project is truly good, it will get support on the way. Investigate your idea critically, but if you truly believe in your idea, stay with it and make it work in some form.
As an example, in the beginning the idea of using Nasal to implement a full weather system was not taken seriously by anyone in the development community. Once written in a very inefficient but working way, the system however did get lots of help from developers on the C++ side and is now known as Advanced Weather, one of the most sophisticated weather systems which exist in a flight simulation.
Honor your commitments
This should go without saying but: Keep your end of the bargain. Seriously. If you got someone to do a month of work for you because you proposed it would enable you to do XY and you in fact don't do XY later, that's pretty much it - no one will ever lift a finger for you from that point.
Release early, document your efforts
Use the forum and/or the wiki as a platform to show people what you are doing and how you are progressing. People need to be aware of things before they can help you, and you may get useful pointers just at the expense of posting your current vexing problem in the forum. It is also always a good idea to do a forum/devel list search to check the archives for related discussions that took place in the past, this should give you a good idea on discussed approaches, but also people involved in these discussions (and if they're still around or not).
While the forum and the devel mailing list are great places for discussions, there are sometimes topics that have been discussed at great lengths, this includes topics like multiplayer improvements or even combat support for example.
For such popular discussions, there are often 5-10 threads per year on the list/forum with typically dozens of responses. Another popular debate is better multi-threading support, but also scenery improvements.
Accordingly, given the popularity of these topics, there are typically hundreds (or even thousands!) of postings and statements that have been made over the years.
Often, with little -if anything- materializing from such debates directly, no matter how good the discussed ideas were. Postings may contain good suggestions, useful feedback, but also lots of controversial arguments. And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved.
Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time.
Time really being the keyword here - some topics are not about a single isolated feature that can simply be implemented by some random developer, those are often large-scale architectural changes, or even proposals to change the project's philosophy (Release Plan) or some of its infrastructure (e.g. the FlightGear Build Server). Thus, these topics are often not about people disagreeing that something needs to be done, but the suggestion really is a long-term item, that needs to be tackled over time - typically many months, often several years.
Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time. We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA effort is another example for this. Typically, complex ideas may very well have a shelf life of several months - often, 12-18 months. The Canvas system only took shape 18 months after it had been discussion on the FlightGear wiki for example.
Thus, sometimes good ideas may take time to materialize - and whenever timing doesn't seem to work, it's a good idea to let time work for you, by creating a corresponding wiki article to document something, and maintaining it over time.
Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release.
If you made it to this point, you may perhaps appreciate much better why the devel community is how it is!