Actually, the OP mentioned that he is a programmer (python), thus my response was definitely not for the layman - it was intended to be full of technical information and facts that people without a programming background would not understand. The OP will agree that the amount/density of information was more than he expected - but that isn't a problem at all, it's a good thing for people looking for this type of knowledge/expertise.
Usually, people would not receive any responses at all, or very little information included - sort of a like challenge to do lots of research, I decided to provide lots of pointers to present the options, as I see them.
Most developers familiar with the mailing list will agree that not even the devel list will provide this degree and density of information.
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.
Admittedly, it's far from cohesive, but there's really nothing that we can do about it: It would require a coordinated effort, not just people telling others what to do, but others willing to listen.
The T4T/combat support situation isn't any different: we have flug's bombable addon as the most sophisticated option available in FG, and then we have various more or less "competitive" approaches, including T4T - yet most folks are not actively seeking collaboration, and doing very little to unify different concepts and approaches. Instead, the focus is often on differences rather than shared needs and common goals.
Which is part of the reason why we have so many "unfinished" aircraft in comparison to other simulators. But like I said, there's really nothing that we, as a project, can do about it - short of adopting a commercial development model and a corresponding hierarchy.
Absent that, we'll have to continue embracing the "Darwinian's development philosophy", where everybody is free to contribute in whatever form they see fit, and it will be up to time to decide which features are going to stay, and which are going to be ripped out eventually.
All of us have real life obligations, and very few of us are willing to accept additional duties/deadlines, no matter if it's aircraft development, core development, texturing, scenery work, wiki administration, forum administration or other "duties" - still, all this needs to be done by someone.
Thus, it's those who roll up their own sleeves and spend their time contributing who get to influence the way FG development is heading, no matter if others agree or not - the only "hard currency" that counts in this project is
time, i.e. the amount of time you have to contribute to the project
Which is also the reason why we are seeing some really skilled and experienced contributors (with very little time on their hands...) being increasingly fed up with the way FG development is going recently, simply because there are quite a number of guys who may not be as experienced or skilled (i.e. not holding multiple CS degrees), but who may be able to spend more time contributing to the project in a different form, which -at least in part- also explains the sheer rate of growth of Nasal scripting in FlightGear, especially in comparison to relatively little new C++ code being committed to the core repository (the canvas system being the obvious exception here, but ironically the Canvas system additionally fosters scripting adoption even further, because base package developers can suddenly contribute in areas that were previously reserved for C++ developers only, such as the GUI, avionics and other fancy stuff).
Honestly, we do have various accomplished core developers who do not particularly like the way Nasal is increasingly used, or the way the Canvas system is becoming a viable alternative over some hardcoded solutions - likewise, the weather system being 95% scripted is another annoyance to some - but at the end of the day, it's really just software evolution taking place: We have a decreasing number of experienced C++ developers, more and more becoming increasingly inactive - which is why the base package has been seeing so much development in comparison, and under these circumstances it is only natural for some core developers to recognize these issues and focus on providing building blocks and infrastructure to empower base package developers.
It's not that your assessment is totally off, but we cannot really deal with it, unless we are telling people what to do - and as you may have witnessed before, that doesn't work out too well usually (remember the various T4T discussions). Thus, we need to accept what's brought to the table, no matter how inconsistent it is, and "absorb" it until something better comes along - even though that may mean that we'll end up with various different approaches in the meantime.
Overall, the current situation isn't as bad as it used to be once
Stiglr: I suggest to briefly take a look at the following posting to see what I am referring to:
viewtopic.php?f=42&t=15267PS: My original response to the OP may have been sizable, but it was also biased, as you may have noticed: I was specifically trying to convince the OP that he should drop his current approach and reconsider the options that I have presented, in other words: I
was trying to get him on the "right" track (which I reason IS Nasal scripting and the Canvas system), to increase consistency and code reuse - but as you can see, people are usually pretty set on having their own ideas followed through, regardless of the approach - which is also why we've had so many different "standalone cockpit" programs over time - people will not listen (and, I also wouldn't listen right away probably, but I'd at least argue that I am informed, and willing to make my case)