Tool Perspectives: ExpressLRS (Respectful Adoption)
On using ExpressLRS responsibly — acknowledging the maintainers, accepting stock firmware, and adapting our workflow instead of demanding changes.
This isn't a setup guide. There are no range claims, no config recommendations, no step-by-step tuning instructions. This is about how we approach ExpressLRS as a project — and open-source tools in general.
Thank You to the Maintainers
First: explicit thanks to the ExpressLRS team.
A small group of people maintains firmware that thousands of pilots depend on daily. They handle GitHub issues, Discord questions, hardware compatibility problems, and feature requests — often in their personal time. The support load is enormous.
When we use ELRS, we benefit from years of unpaid engineering work. That's worth acknowledging.
Stock Firmware Fits Most Needs
In approximately 95% of our use cases, stock ExpressLRS firmware does exactly what we need. Default settings, recommended configurations, standard hardware — it works.
The temptation to customize is strong. Different packet rates, modified telemetry ratios, experimental features. But most of the time, this complexity adds risk without meaningful benefit.
Our Default
Unless there's a specific, documented reason to change something, we run stock firmware with default settings.
Non-Intrusive Adoption
This is what we mean by "non-intrusive adoption":
- ●Adapt our workflow to the tool — not the other way around
- ●Don't disturb upstream — avoid filing issues for edge cases we created ourselves
- ●Accept limitations — if stock doesn't support something, reconsider whether we need it
- ●Respect maintainer time — read existing documentation before asking questions
We don't publish config files. We don't make range claims. We don't write tuning guides that might create support burden for maintainers.
What This Looks Like in Practice
When we encounter an issue:
- ●Check if we're running stock firmware and settings
- ●Search existing issues and documentation
- ●Test with a known-good configuration
- ●Only then consider whether it's worth reporting
If the issue exists only in our modified setup, it's our problem to solve — not the project's.
The Broader Principle
ExpressLRS is one example of a larger pattern. Every open-source project we depend on has maintainers with limited time and energy. Our job is to be low-friction users:
- ●Use tools as intended
- ●Contribute back when possible
- ●Stay out of the way when we can't
Human Factors
Maintainer burnout is real. Every unnecessary issue, every "works on my machine" report, every demand for features adds to the load. Be mindful of the humans on the other side.
Summary
ExpressLRS is excellent software maintained by people who deserve respect. We use it gratefully, conservatively, and without creating unnecessary noise.
That's respectful adoption.