>From my perspective the really relevant paragraph in my posting is this
one:

Martin Spott wrote:

> The idea I had in mind, the motivation which drove me into dedicating
> so many hours was to focus as many of the available ressources as
> possible on building the best _common_ Scenery we could make for
> FlightGear.
> Yet I have to realize that this idea has become pretty unpopular.  The
> sort of collaboration which is being carried out at improving
> FlightGear's source code and the sense for continuous development
> obviously don't work in the Scenery department.

Basically I see two different approaches in FlightGear Scenery world
(aside from a few minor blends):
1.) Focus all ressources on one common World Scenery.
2.) Build pools of individual (and sometimes even contradicting)
    scenarios - also known as the M$FS way.

It's obvious that 1.) was the one I tried to accomplish.  I was
convinced that, as a non-commercial OpenSource project, we could do
"better".  Anyhow it's obvious that 2.) draws magnitudes more developer
ressource and the gap is steadily increasing.  I've even watched people
explicitly trying to persuade/convince contributors _not_ to contribute
to common, collaborative Scenery ressources - and, what's really sad,
not one single voice objected.

That's why I consider my approach as a failure, maybe not generally,
but at least in FlightGear land because apparently there's no critical
mass of fertile soil to make it grow even half as fast as it could. 
For a long time I thought this would be a failure of "The FlightGear
Community", but the more I think about it, the more I'm getting to the
conclusion that there is simply no community in FlightGear Scenery
land.  Either there's a fundamental difference in the understanding of
the term "community" - or 95 % of those who are repetitively exercising
this term are just a crowd of narcissists ....

Actually I doubt wether a continuation of my approach makes sense in
the context of The FlightGear Project.  At least I see no point in
further working on 1.) whereas 2.) is getting by magnitudes more
appraisal and, what is most important, support.  If I were convinced
there's a light at the end of the tunnel, then I would certainly
continue instead of giving up, but under the current conditions I
don't.
This is the actual reason for my decision, not the lack of time (people
who know me have already familiarized with the fact that I'm
notoriously running out of time, thus there's nothing special now).

In the long term I'll probably leave the entire project because I
basically haven't done anything else than Scenery infrastructure over
the past years.  Trying to write and coordinate documentation wasn't
much of a success story either ....  but that's a different topic.


Ah, btw, indeed two recent incidents convinced me to make this decision
now, but they were having no effect on the decision itself, just on the
particular timing.

Cheers,
        Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to