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

In response to Patrizio's detailed analytical post:

I think this is very helpful because .... most of this discussion has been
about, I'll call them, symptoms. Patrizio seems to be addressing causes.
And that's vital to solving any of these problems.

I'll add this as to users vs developers. I tried FG in the early 2000's
when I started using Llinux full time. I had no intention of being a
developer or contributer. I got my pilot license in 1991 and probably like
many in my situation, getting the license was THE accomplishment. I flew a
lot from 1991 to about 1994. After that it was hit and miss and dropped off
completely in about 1999. But in the early 2000's I wanted to get back into
flying, possibly to work toward IFR certification. I discovered FG, either
downloaded it or built it from source (it wasn't as complex to do that back
then as it is now .... for me!). The last time I flew a sim before that was
.... Commodore 64 MS in the mid to late 80's. So I tried FG using keyboard
controls and was impressed with the realism. I bought the CH yoke and
rudders, made a little table mount and flew FG a lot ... a LOT. It was
quite amazing how I could use the VOR realistically. I do remember the
first time I took off in the 172 how it wanted to pull or turn and it
puzzled me a bit. So I wrote to the forum and was informed that it's
typical due to torque. And the light came on and I realized I should have
remembered that from real flying. But I really enjoyed it and even flew the
Cessna 310 a lot back then. I flew other planes too, possible the P51 (or
some WW2 fighter) and maybe some others. I just "chose" a plane and flew
it. I knew nothing about the concept that different developers designed
planes. To me, when I selected a plane, it was a plane offered by FG. I
think that's the beauty of a new user, being offered a selection of FG
planes. If a user has to unravel the underlying plane development
mechanism, it makes it difficult. In time that's fine. But for me, I could
pick a plane and fly it and they all seemed like official FG planes. That
scenario really helps a new user, And as I recall, even later when I would
see hangars and FGAddon, I really didn't know what they meant I tried some
that didn't work and just avoided them.

After that I kind of got out of it until about 2018 when I decided to get
back into flight simulation and build a lot of custom hardware and
instrumentation. And that's where I am now. It's slow going, as a lot of
these projects are. But my first choice was FG. Not because it's free, but
because I found the goals of this project to be admirable and honorable and
I had a great experience with it in those years in the early to mid 2000's.

I wouldn't call my role in FG as being a contributor in the sense of a
developer making source code changes and merge requests. But I feel like I
am somewhat a part of the project because I have ideas and have posted
videos of my project online and want to ask and answer questions if I'm
able to.

But to the point, I was a regular user drawn in to the realism of FG and
later wanted to advance my projects and hopefully in the meantime share my
work and ideas. Now, this is a situation where my experience is not
representative of ALL people in my situation. To me it simply means that
contributions take many forms and interests are broad. But if FG was broken
or if the airplane had issues that I had to debug, I probably would have
dropped FG and just bought MS Flight Sim because I wanted to pick up where
I left off and get back into flying.

In response to this: >  Adding more users does not fix any of these

I don't know if anyone really knows that. More users could mean more
feedback, more input to the process and maybe even the addition of
experienced developers, testers and designers.

To me this is like saying: "I don't wear my seatbelt because I heard of
someone who got badly injured because he was wearing one." Well, we can run
our lives by the exceptions or by the best bets.

Thanks,
Dave

On Mon, May 25, 2026 at 8:41 AM 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