4,400
edits
How the FlightGear project works: Difference between revisions
Jump to navigation
Jump to search
m
How the FlightGear project works (view source)
Revision as of 19:22, 25 October 2013
, 25 October 2013Update forum links
m (→too many options: http://flightgear.org/forums/viewtopic.php?f=14&t=20413#p186983) |
m (Update forum links) |
||
| Line 2: | Line 2: | ||
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. | 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://flightgear.org | 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 = | = Background = | ||
| Line 182: | Line 182: | ||
=FlightGear is inconsistent and overly complicated = | =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 "embarassing" to "ready-for-commercial-release" [http://flightgear.org | : 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 "embarassing" 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. | 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. | ||
| Line 293: | Line 293: | ||
* 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'. | * 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 | 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 your project involves? | ||
* Do you have a clear idea what is already there? | * Do you have a clear idea what is already there? | ||