Re: The endless influx of low-quality, low-realism, quantity-over-quality aircraft into FGAddon

I shared my opinion because I know the situation very well. I stepped away
in 2017 for personal health reasons, which I’ve finally resolved after many
difficulties.The “feuds” mentioned by other users are nothing new; they’ve
existed for a long time. My intention was simply to offer an external point
of view, hoping it might be useful. I still care about FlightGear, even
though I’m aware that most developers will probably not take my comments
into consideration.Today I see myself as a real outsider: I observe the
project from the outside, and this distance allows me to clearly notice
certain aspects that a user not involved in development perceives
immediately. It saddens me that, almost ten years after my voluntary
departure, FlightGear still seems to be a simulator used mainly by the
people who develop it. The trackers don’t show the full picture, but they
do indicate very limited usage on the user side. I tried to express my
point of view peacefully and constructively. Making this community more
welcoming is not my responsibility, but I believe that talking about these
issues is still worthwhile.

Patrizio.


Il mer 27 mag 2026, 11:56 Willie Fleming <[email protected]> ha scritto:

> Fabrizio
>
> Best of luck trying to address the excellent points yuo made the other
> day. Attitudes such as those expressed by Midnight Ploughboy simply
> reinforce your position.
> Its a volunteer project and Im not volunteering to put up with those
> attitudes to try make the place a little more welcomi g and user friendly.
> I wish you luck but you are dealing with too many hidebound grumpy old guys
> who are enjoying their own little circle jerk.
> Shame cos its a really good simulator crippled by crap documentation and
> crappier attitudes.
>
> All the best
>
>
> Regards
>
> On Mon, 25 May 2026, 13:41 Patrizio Melis, <[email protected]> wrote:
>
>> Over the last years, FlightGear has evolved into a project where the
>> majority of active users are also developers. This is not inherently
>> negative, but it has structural consequences that are becoming increasingly
>> visible. The following points aim to describe the situation objectively and
>> suggest possible improvements without assigning blame.
>>
>> 1. Developer‑centric ecosystem
>> FlightGear’s architecture, documentation, and workflows are optimized for
>> contributors with technical backgrounds. As a result:
>>
>> - onboarding for new or casual users is difficult,
>> - discussions tend to assume deep internal knowledge,
>> - and the barrier to entry keeps rising.
>>
>> This naturally filters out non‑technical users, reinforcing the cycle.
>>
>> 2. Lack of user‑facing communication
>> Most communication channels (mailing lists, issue trackers, commit logs)
>> are designed for developers.
>> For a non‑technical user, the tone can appear:
>>
>> - defensive,
>> - overly strict,
>> - or dismissive of non‑expert perspectives.
>>
>> This is not intentional, but it is a predictable outcome of a highly
>> technical environment.
>>
>> 3. Fragmented documentation
>> Documentation is spread across:
>>
>> - wiki pages,
>> - forum posts,
>> - mailing list archives,
>> - personal notes,
>> - outdated tutorials.
>>
>> This fragmentation makes it hard for newcomers to understand how to
>> contribute or even how to use advanced features.
>>
>> 4. No clear governance or moderation model
>> FlightGear lacks a defined structure for:
>>
>> - decision‑making,
>> - conflict resolution,
>> - moderation,
>> - long‑term planning.
>>
>> Without a shared governance model, discussions often escalate into
>> personal disputes or technical dogmas (e.g., YASim vs JSBSim), because
>> there is no neutral framework to guide them.
>>
>> 5. Absence of a “consumer layer”
>> Successful open‑source projects typically have:
>>
>> - developers,
>> - power users,
>> - casual users.
>>
>> FlightGear has effectively lost the third category.
>> This means:
>>
>> - fewer testers,
>> - fewer fresh perspectives,
>> - fewer people who simply enjoy the simulator without contributing code.
>>
>> A community composed almost entirely of developers tends to become
>> insular over time.
>>
>> 6. Perceived toxicity is a structural symptom
>> When a community becomes small, highly technical, and under pressure, the
>> tone of discussions can deteriorate. This is not due to malice, but to:
>>
>> - accumulated frustration,
>> - lack of new contributors,
>> - repeated debates,
>> - and the emotional investment of long‑time maintainers.
>>
>> From the outside, however, this can appear unwelcoming or even hostile.
>>
>> My Constructive Proposals
>>
>> 1. Define a lightweight governance model
>> Not bureaucracy — just clarity:
>>
>> - who decides what,
>> - how decisions are made,
>> - how disagreements are handled.
>>
>> Even a minimal structure reduces friction.
>>
>> 2. Improve onboarding paths
>> A curated “Start Here” for:
>>
>> - new users,
>> - new developers,
>> - aircraft creators,
>> - scenery contributors.
>>
>> Clear, centralized, maintained.
>>
>> 3. Document realism levels instead of judging them
>> Instead of “declassifying” aircraft, simply document:
>>
>> - intended realism,
>> - FDM type,
>> - data availability.
>>
>> Transparency without devaluing anyone’s work.
>>
>> 4. Encourage a more welcoming communication tone. Not by policing
>> behavior, but by:
>>
>> - setting expectations,
>> - offering templates for constructive feedback,
>> - reminding contributors that not everyone has the same background.
>>
>> 5. Rebuild the user layer
>> This could include:
>>
>> - curated aircraft packs,
>> - simplified installers,
>> - “recommended settings”,
>> - beginner‑friendly documentation.
>>
>> Lowering the barrier brings new users, which brings new contributors.
>>
>> FlightGear is an extraordinary simulator with a unique technical depth.
>> But its community dynamics increasingly reflect a project built by
>> developers for developers. Recognizing this is not criticism — it is the
>> first step toward making FG more accessible, more sustainable, and more
>> welcoming.
>>
>> A healthier community benefits everyone:
>> developers, users, and the project itself.
>>
>> The idea that “more users automatically means more contributors” sounds
>> intuitive, but it does not match how open‑source ecosystems actually work —
>> especially in a highly technical project like FlightGear.
>>
>> 1. User growth does not scale into contributor growth
>> In most open‑source projects, the conversion rate from “user” to
>> “contributor” is extremely low (often below 0.1%). Increasing the number of
>> casual users does not increase the number of developers unless:
>>
>> - the onboarding is simple,
>> - the documentation is clear,
>> - the community is welcoming,
>> - the contribution path is accessible.
>>
>> FG currently lacks all four conditions.
>>
>> 2. Technical barrier prevents conversion
>> FlightGear requires knowledge of:
>>
>> - aerodynamics,
>> - C++/XML,
>> - 3D modeling,
>> - FDM theory,
>> - build systems,
>> - Git workflows.
>>
>> A casual user who just wants to fly will not cross that barrier. More
>> users ≠ more contributors when the barrier is this high.
>>
>> 3. Community climate is a limiting factor
>> If the internal tone is perceived as harsh, defensive, or dismissive, new
>> users will not become contributors. They will simply leave.
>>
>> User growth only helps if the environment encourages participation.
>>
>> 4. Contributor motivation is not driven by user count. Developers
>> contribute because they:
>>
>> - enjoy the project,
>> - feel respected,
>> - see progress,
>> - have clear goals.
>>
>> The number of passive users has almost zero impact on contributor
>> motivation.
>>
>> 5. FlightGear’s real bottleneck is not the number of users. The
>> bottleneck is:
>>
>> - lack of structured governance,
>> - fragmented documentation,
>> - unclear decision processes,
>> - high technical complexity,
>> - limited mentoring for newcomers.
>>
>> Adding more users does not fix any of these.
>>
>> You can add more users, but unless the project improves onboarding,
>> documentation, and community climate, the number of contributors will
>> remain the same. FlightGear’s issue is not “too few users”, but too high a
>> barrier and too little support for those who might want to contribute.
>>
>> _______________________________________________
>> Flightgear-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>
>
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel