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

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