Howto:Understand the FlightGear development process

From FlightGear wiki
Revision as of 18:25, 23 November 2013 by Singaearth (talk | contribs)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
Cleanup.png This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.

Usually, the process of "compiling a program" refers to taking its source code and running it through a so called "compiler", which compiles, assembles and links the human readable source code to come up with the resulting binary and executable files, which contain the machine code that can be run by your computer (CPU).


When you simply download a pre-compiled FlightGear release, you do not have to do this yourself, because other people have already done this for you. These are so called "release managers", who often also happen to be software developers themselves.

This is because the process of compiling a piece of software such as FlightGear requires a so called "build environment" which consists of a number of tools (such as a compiler), and custom project configuration settings to turn human readable source code into the machine code that is required for actually running a program.

Programs are usually written in a plain text editor, imagine it like a word processor. There are very complex "word processors" just for writing programs, that are specifically designed to deal with source code in various programming languages. These "word processors" are called "Integrated Development Environments" or "IDEs", because they usually also provide comprehensive integration with the build environment, including its various tools.

People who build FlightGear from source code and make modifications to this source code, are usually called "programmers" or more generally "developers". People who have commit rights to the master repository, are called "core developers" - because they are the ones who develop the FlightGear "core".

Other programmers/developers may provide patches to the source code, which need to be reviewed, improved and committed by those core developers.

People who do development largely within the confines of the base package (i.e. by creating or modifying aircraft and/or scenery or other base package resources) are usually also called "developers".

Terms you might see here are for example "aircraft developer" or "scenery developer". Both of which implies that their work takes usually place in the base package. Some people may refer to them as "base package developers" or as "middlware developers".

This distinction is largely due to the different set of skills required for producing these resources. While programming and software development in general requires dealing with source code of programs in different programming languages, aircraft or scenery development is no longer primarily about programming in general.

These people don't "program" aircraft or scenery, but usually they "design" things primarily (i.e. 3D models, textures) and may then add various other resources (such as for example sounds).

Programming in this context usually refers to tiny scripted programs that are stored in and loaded from the base package. Programs written in such "scripting languages" are usually not compiled, and can be easily created by people new to programming or software development in general.

To cater for all these differences, these people are called aircraft/scenery "developers" because their work does not primarily comprise software development in general.

Of course, you can also literally "compile" parts (like certain scenery or aircraft) of FlightGear to create a custom version of it. So, someone who simply takes FlightGear, and who creates a custom version of it by downstripping the base package, ommitting certain resources and adding new ones or creating custom configurations, would probably not normally be referred to as a "developer" here. The most appropriate term would be "Modder" in that case, because you are "modding" FlightGear to come up with a special version for a specific purpose, without doing any actual "development" like for example C++ coding, Nasal scripting or more generally aircraft/scenery development.

Normally, "developing" something implies changing functionality and logics, in the sense of "programming" and "creating" things, features and code. Someone who customizes a piece of software by editing configuration files and by adding or removing such files would usually not be called a developer.

A configuration file provides a convenient interface to customize a program's behavior without having to be a programmer or developer.

Similarly, command line arguments are another way for customizing program behavior without having to change a program's source code.

Imagine it like the difference between a carpenter and someone who merely takes a pre-fabricated piece of furniture (like a chair or table) and customizes it by changing its color, or adding/removing some features.

Similarly, just because you are able to refuel your car or change your tyres you would not necessarily be referred to as a "car mechanic".

So, unless you start modifying the source code (logics) of the program (FlightGear) in order to change existing behavior, your changes would normally not qualify as "developing", even changing XML files does not fall under "development", this is largely because XML is usually considered a markup (=description) language and not a programming language.

If you were now to start documenting your experiences modding FlightGear, you would become a "contributor" and a "documentation writer" ;-)