20,741
edits
How the FlightGear project works: Difference between revisions
Jump to navigation
Jump to search
m
→too many options: http://flightgear.org/forums/viewtopic.php?f=14&t=20413#p186983
m (→Background) |
m (→too many options: http://flightgear.org/forums/viewtopic.php?f=14&t=20413#p186983) |
||
| Line 180: | Line 180: | ||
First, I'd try to make sure I understand the situation as it is - not as it appears from my perspective, but also how it appears to others, of what nature the obstacles to change are and so on. Then I'd try to get to talk to some of the people who have the power to change things, and convince them that changing something would not just be better for me, but also be better for them - in fact be better for anyone around. In order to do so, I'd go as far as I can to meet them - talk their language, start describing things from their perspective, value their efforts - and then talk about that one can also see things from a different perspective. I'd do that because I want something - I want them to listen to me, so I want to make that as easy as possible. I'd also prepare a compelling and persuasive case - I'd try up front to sort genuine structural problems from things which are just one-time mistakes which can happen because people are not perfect, I'd sort important things from unimportant things and focus on the important things. Above all, I'd think about what I personally did wrong and what part of the problem I can fix - and how I should do it. And then I'd see if I can't convince anyone that there is merit in my perspective. In the process, I'd also try to find like-minded people who might help me achieve my goals. | First, I'd try to make sure I understand the situation as it is - not as it appears from my perspective, but also how it appears to others, of what nature the obstacles to change are and so on. Then I'd try to get to talk to some of the people who have the power to change things, and convince them that changing something would not just be better for me, but also be better for them - in fact be better for anyone around. In order to do so, I'd go as far as I can to meet them - talk their language, start describing things from their perspective, value their efforts - and then talk about that one can also see things from a different perspective. I'd do that because I want something - I want them to listen to me, so I want to make that as easy as possible. I'd also prepare a compelling and persuasive case - I'd try up front to sort genuine structural problems from things which are just one-time mistakes which can happen because people are not perfect, I'd sort important things from unimportant things and focus on the important things. Above all, I'd think about what I personally did wrong and what part of the problem I can fix - and how I should do it. And then I'd see if I can't convince anyone that there is merit in my perspective. In the process, I'd also try to find like-minded people who might help me achieve my goals. | ||
=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/forums/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. | |||
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 | |||
= Is this program just for scientists and engineers? = | = Is this program just for scientists and engineers? = | ||