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

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