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 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.
It's easy to suggest this when you're not contributing actively. 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.
> 
> 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:)

Despite the fact that I disagree strongly with almost everything you've written 
:), I respect your opinion and I know it takes time to write mail that one 
cares 
about.

Tim

------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to