Re: [Flightgear-devel] Grr... I am so angry
I'd like to thank the people who have responded to my rant - they have all done so in a considered, thoughtful and positive manner and have not taken anything personally, for which I am extremely relieved. While some people have pointed out that work is already being done to address some of the issues I tried to highlight, I still think that many of these efforts are a case of trying to ameliorate problems that need not exist in the first place. Just as these people disagree with what I've said, and even though I have immense respect for their opinions and views, I'm afraid that I still have to disagree with them. I'd also like to thank Brain Schack for that link to the "A New Architecture for FlightGear Flight Simulator" document, which I think everyone involved with the development of FG should read. This document really trumps my posting because not only does it raise the same issues but also suggests some specific approaches and solutions to answer them. While the issues that worry me might still beyond the horizon I think it is certain that they will arrive here one day, and in the not too distant future. Indeed, it has been the early signs of these issues, which has forewarned of their coming, that motivated me to post and the authors of that doc to put the time and effort in to researching and producing it in the first place. If the only thing that my post achieves is to get more people to read and think about that doc then it will have been worthwhile. Regards, LeeE -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grr... I am so angry
Hi Lee, Thanks for taking the time to write. It's well worth airing these issues, even if I disagree completely with your analysis. :) Others have already addressed a number of points, but my own tuppence is below. LeeE wrote: > 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. You are correct that a regular release schedule brings no benefit to me personally (ego aside). However, I think that is to completely ignore users who don't compile from source and track CVS. It also ignores the altruistic side of the FG project in favour of a very self-centered viewpoint, which I doubt you intended. We now have a huge variety of contributors: those that develop scenery models (sometimes using sketch-up - ;)), contributors to The Manual (yes, there are some, and their help is very much appreciated) and aircraft developers. Many of these people have no interest in compiling CVS. They do have an increasing stake in the FG project, and are an important part of our community. I think it is very easy for those of use who inhabit the -dev list to forget about them. Producing regular releases so they can benefit from new features and developments is extremely worthwhile, if only to keep them closer to the core developers, and therefore a single community. For a lot of new contributors, having their work available to the public is quite important, and encourages further contributions. Having to wait a year for your grammatical corrections to The Manual to finally become public is hardly encouraging! > 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. Sorry, I have to diagree with you on this. There have been significant code clean ups by James Turner and Tim's work in moving to OSG. For my part, a significant part of the 3D clouds work involved unravelling what was a mess in the METAR / Environment code (admitedly, that took a couple of goes to get right ;) ) > 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:) No problem. These sort of issues are much better discussed openly. > Happy new year, > > LeeE And you too! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grr... I am so angry
(I essentially agree with everything Tim, but want to add one technical detail) On 29 Dec 2008, at 13:12, Tim Moore wrote: > Putting snark > aside, I'd suggest that FG is not in as bad shape as you think. The > property > system is already a great mechanism for communication among the sub- > systems of > FG. A great project would be to look at making the property system > thread-safe, > and follow that up by turning it into a "blackboard" that can be > used by > distributed copies of FlightGear. Just to add, Simgear now has some good threading primitives, and so does OSG. The refcounting system is thread-safe, and I'm planning a TLS / pool-based system to make property nodes thread-safe as well (hopefully without incurring a per-node lock, but that's getting into deep technical debates). (If anyone wants to have a technical discussion about this, great) The key thing is, we have a good modularity thanks the to SGSubsystem and properties. It needs some enhancements in some limited ways, and we have state that violates the property-tree abstraction for various (valid!) reasons, but I don't believe there is any major obstacle to running batches of subsystems on worker threads in the medium term. It's not a high priority compared to other things, since the biggest multi-thread enhancements come 'for free' thanks to OSG. But it does not need some major re-think or re-design, as far as I can see. For everything else, I can only agree with Tim. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grr... I am so angry
I agree with Tim here. There are many secondary benefits of time-boxed releases. Getting bugfixes and mindshare improves interactions with the user community and attracts users which ultimately attracts new developers. Of course there is a percentage effort cost to ensure broad stability - but ultimately that comes down to developer discipline and branch structure more than anything. By project agreement you sacrifice a release for high value/high risk changes (like the OSG transition). But beyond that you push for a greater focus on complete changes and as was originally suggested an improved architecture that allows subsystems to be added and removed is the main driver. With this new release, flightgear's multihead capability will be added to the Phoronix Test Suite as a test. (Google for more info). If someone wants to take leadership in improving testability/automated testing with flightgear, that can go a long way to pushing flightgear out further, as well as ensuring that standard releases can be tested. If there is someone willing to step up to the task I can provide more information. Any takers? Regards... Matthew On 12/29/08, Tim Moore wrote: > LeeE wrote: >> 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. > What we're talking about is doing "timebox releases." I suggest you Google > the > term. There is a steady stream of new features checked into CVS. However, > most > FG users can't or won't build Flightgear from source, so these features > don't > see wide use until a release. The fact that we make a release is a signal > that > we believe the code to be stable and that it is worth the time of packagers, > within the FG project and outside, to make a package out of the code at that > point. The timebox idea enforces some discipline to get the code ready and > not > noodle around with new features indefinitely. It's used by many open-source > projects today. It will certainly work better with several independent > source > branches in the repository. > > So I reject the breathless cynicism of your proposition :) > >> >> 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. > I think many would say that an open-source flight simulator is already a > better > idea than a closed source one. Not only is it useful for many projects, it > is > more fun to work on :) >> > ... >> >> As a c
Re: [Flightgear-devel] Grr... I am so angry
LeeE wrote: > 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. What we're talking about is doing "timebox releases." I suggest you Google the term. There is a steady stream of new features checked into CVS. However, most FG users can't or won't build Flightgear from source, so these features don't see wide use until a release. The fact that we make a release is a signal that we believe the code to be stable and that it is worth the time of packagers, within the FG project and outside, to make a package out of the code at that point. The timebox idea enforces some discipline to get the code ready and not noodle around with new features indefinitely. It's used by many open-source projects today. It will certainly work better with several independent source branches in the repository. So I reject the breathless cynicism of your proposition :) > > 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. I think many would say that an open-source flight simulator is already a better idea than a closed source one. Not only is it useful for many projects, it is more fun to work 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. > Part of the problem is that it's hard to comprehensively test new work against the wide range of aircraft and possible scenarios, to say nothing of the varieties of hardware and operating systems people are using. I don't have any great insight there, other then perhaps using more pre-recorded FDM data like Matthew Tippet has done in his demos. Frequent releases help flush out bugs too... > In summary then, for FG to survive in any greater form than a quaint > alternative to better a
Re: [Flightgear-devel] Grr... I am so angry
> What finally broke this camel's back was the thread about release > schedules, but it goes further than that. The idea of release schedules for an open source project struck me as odd, as well. Jon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Grr... I am so angry
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 ad
