Hello dev list, If you're in no mood to critically appraise a rant then read no further.
For quite a while now, since I stopped actively contributing to FG, I've been sitting here watching the direction in which FG development is heading and if ever there was a good project, which has potentially boundless scope in the field of VR, but which has lost it's way and is now chasing it's tail up it's own fundament then FG is it. What finally broke this camel's back was the thread about release schedules, but it goes further than that. The idea that FG should be updated and released to what is a purely abstract schedule is disingenuous and destructive nonsense. The origin and sole purpose behind the idea of releasing new versions of software on any sort of regular schedule is to upset and exploit the market for the type of software you're producing; it's a thinly veiled attempt to deter your market from trying, and perhaps adopting, alternative solutions by promising even better things in your future product. This simply doesn't apply to open-source software projects because maintaining or increasing market take-up of your product brings no benefits to you, other than massaging your egos. The idea then, that new versions of FG should be released on a regular schedule, is an attempt at competing with something that has no intrinsic value - it's a worthless fight, not only for the effort that it consumes, but for what could be won. The reason that Open-source projects occur at all comes down to one major factor; someone has a better idea. There are a number of secondary reasons for open-source projects, but without that single primary reason they're pointless - what is there to be achieved by simply duplicating what has already been achieved? Simply doing it so that people don't have to pay money for it is not an adequate answer; if people need the software they'll pay for it, if necessary. The 95% of computers that run MS software proves this. The justification for the existence of FG is to make a better solution. 'Better' in this context encompasses several areas: being 'open' is the primary benefit of open-source projects, because whatever you do will never be perfect for everybody, but being open means that other people can progress in their own direction by standing on your shoulders; but they couldn't do whatever they want to do without you doing your bit first. But being 'better' also means other things too. Another important aspect of 'better' includes the overhead of using the FG solution over others, and in this respect FG is getting worse not better. FG development has become chaotic. While people are still having new, and very good, ideas, the method of implementing them frequently breaks all that has gone before. Now this may seem to be a single and easily identified problem but it's actually just a symptom of a deeper and more fundamental problem caused by two factors: these are lack of foresight, and lack of foresight. The first lack of foresight is short-term lack of foresight, and it's due to the second lack of foresight, which is long-term foresight. This isn't actually anyone's fault - there's no blame upon anyone for this. What has happened is that FG was designed, in computing terms, a long time ago, when computing at this level was still in it's very early days and just making a workable solution with the available hardware and software was an achievement in itself. Since then however, not only has an awful lot has been learned about system design and the practicalities of maintenance but a paradigm shift in computer hardware has swept over everything. FG's architecture was designed around h/w and s/w designs that were leading edge at the time but everything has moved on since then. The short-term lack of foresight is a consequence of this; as new ideas and features have been thought of and implemented, in the light of new technological advancements, they've had to be massaged to fit an architecture that has become obsolete, both in design, maintenance and in terms of the h/w it runs on. As a consequence, while the overall design of FG is familiar to many of the developers, no one knows all the details. This is normal in such a complex software project, but in such a complex project everyone _does_ need to know the scope of their work; what their work will effect, and how. For FG though, this is absent; no one can be sure that the scope of their change will not extend beyond what they intend and it's almost become a case of random guesswork as to the scope of the consequences of source-code changes. In just about every case, the software changes that make it in to FG are a good idea, and should make FG better, but in practise now, they are just making a confused situation worse. In summary then, for FG to survive in any greater form than a quaint alternative to better alternatives, which I admit may not exist yet but will certainly do so at some point in the future, FG _needs_ to be re-designed with an architecture that not only makes use of current hardware, especially with regard to multi-core/distributed computing systems, but also enforces scope of sub-systems and allows multiple concurrent versions of sub-system. Doing this is a daunting but necessary task. It also cannot be the only task that people work on, but it has to be done nonetheless, and sooner rather than later. It will also not be a quick and easy task - it will probably take a couple of years of thinking, experimenting and testing to just come up with a viable architecture, let alone implementing a 100% solution, but it needs to be started now. Having got that off my chest, I'd like to make it clear that I'm not trying to criticise anyone, or the FG dev community in general, and as such, I'm not interested in arguing about any of this. The reason that I've bothered to spend a couple of hours composing this post is not to annoy & diss people but because I care. If I didn't, I wouldn't have bothered. And at least I waited until after xmas so I didn't spoil it for anyone:) Happy new year, LeeE ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
