Hi FlightAware team!
Thank you for maintaining dump1090. This issue proposes a prioritized roadmap that explicitly incorporates existing open Pull Requests, so ongoing community work can be discussed, evaluated, and (where appropriate) unblocked or scoped.
The intent is to align roadmap priorities with real contributions that already exist, rather than proposing entirely new work.
🎯 Guiding Principles
Stability and decoding performance first
Backwards compatibility by default
Opt-in enhancements where possible
Prefer merging or resolving existing PRs over creating new ones
Clear scope to reduce long-lived open PRs
🟢 Priority 1: Core Maintenance & Platform Support
Rationale: These PRs have been open for a long time and represent significant user demand.
Checklist
[ ] Review and decide on Windows support approach
🔗 PR #146 – “Added Windows support”
#146
(Opened Aug 4, 2021)
[ ] Clarify supported platforms and build expectations
🔗 Related to PR #146
(May include documenting “supported vs experimental” platforms)
[ ] Document maintainer expectations for large platform PRs
🔗 Related PRs: #146
Notes
Even if full Windows support is considered out-of-scope, a documented decision would help reduce contributor uncertainty.
🟢 Priority 2: Networking & IPv6 Support
Rationale: IPv6 has been requested and implemented but not merged for several years.
Checklist
[ ] Review IPv6 support in web server configuration
🔗 PR #29 – “Enable lighttpd to listen on IPv6 addresses”
#29
(Opened Nov 5, 2018)
[ ] Decide whether IPv6 support is:
[ ] Fully supported
[ ] Optional / opt-in
[ ] Out-of-scope (with documentation)
Related Issues
IPv6 support discussion: antirez#162
🟡 Priority 3: SDR & Hardware Support
Rationale: Hardware support PRs tend to age poorly if not reviewed promptly.
Checklist
[ ] Review additional SDR hardware support
🔗 PR #37 – “Add support for BladeRF 2.0 Micro”
#37
(Opened Mar 31, 2019)
[ ] Clarify policy on accepting new SDR backends:
Maintenance expectations
Test coverage requirements
Supported vs experimental devices
Notes
Even a decision not to merge would be valuable if documented clearly.
🟡 Priority 4: Web UI Quality & Maintenance
Rationale: Small UI PRs can linger despite being low risk.
Checklist
[ ] Review and assess UI layout improvements
🔗 PR #28 – “Remove containment for splitter resizing”
#28
(Opened Oct 30, 2018)
[ ] Clarify intended scope of built-in UI vs external UIs
[ ] Decide what level of UI polish is expected upstream
Notes
This aligns well with documenting recommended external frontends (e.g., tar1090) while keeping the core UI stable.
🟠 Priority 5: Process Improvements for PRs
Rationale: Several PRs have been open for 4–6+ years.
Checklist
[ ] Add CONTRIBUTING guidance covering:
Expected review timelines (if any)
Criteria for accepting large changes
How to keep PRs from stalling indefinitely
[ ] Label long-running PRs as:
needs-rebase
needs-decision
out-of-scope
Related PRs
#146, #37, #29, #28
🧭 Suggested Next Steps (Low Effort, High Value)
Triage the four long-standing PRs listed above
For each PR, explicitly decide:
Merge
Request changes
Close with explanation
Document scope boundaries so future PRs align better
This roadmap is intentionally grounded in existing work, not new feature requests. Even closing PRs with clear rationale would significantly improve contributor experience.
Thanks again for maintaining dump1090 and for considering this proposal ✈️
Chris
Hi FlightAware team!
Thank you for maintaining dump1090. This issue proposes a prioritized roadmap that explicitly incorporates existing open Pull Requests, so ongoing community work can be discussed, evaluated, and (where appropriate) unblocked or scoped.
The intent is to align roadmap priorities with real contributions that already exist, rather than proposing entirely new work.
🎯 Guiding Principles
Stability and decoding performance first
Backwards compatibility by default
Opt-in enhancements where possible
Prefer merging or resolving existing PRs over creating new ones
Clear scope to reduce long-lived open PRs
🟢 Priority 1: Core Maintenance & Platform Support
Rationale: These PRs have been open for a long time and represent significant user demand.
Checklist
[ ] Review and decide on Windows support approach
🔗 PR #146 – “Added Windows support”
#146
(Opened Aug 4, 2021)
[ ] Clarify supported platforms and build expectations
🔗 Related to PR #146
(May include documenting “supported vs experimental” platforms)
[ ] Document maintainer expectations for large platform PRs
🔗 Related PRs: #146
Notes
Even if full Windows support is considered out-of-scope, a documented decision would help reduce contributor uncertainty.
🟢 Priority 2: Networking & IPv6 Support
Rationale: IPv6 has been requested and implemented but not merged for several years.
Checklist
[ ] Review IPv6 support in web server configuration
🔗 PR #29 – “Enable lighttpd to listen on IPv6 addresses”
#29
(Opened Nov 5, 2018)
[ ] Decide whether IPv6 support is:
[ ] Fully supported
[ ] Optional / opt-in
[ ] Out-of-scope (with documentation)
Related Issues
IPv6 support discussion: antirez#162
🟡 Priority 3: SDR & Hardware Support
Rationale: Hardware support PRs tend to age poorly if not reviewed promptly.
Checklist
[ ] Review additional SDR hardware support
🔗 PR #37 – “Add support for BladeRF 2.0 Micro”
#37
(Opened Mar 31, 2019)
[ ] Clarify policy on accepting new SDR backends:
Maintenance expectations
Test coverage requirements
Supported vs experimental devices
Notes
Even a decision not to merge would be valuable if documented clearly.
🟡 Priority 4: Web UI Quality & Maintenance
Rationale: Small UI PRs can linger despite being low risk.
Checklist
[ ] Review and assess UI layout improvements
🔗 PR #28 – “Remove containment for splitter resizing”
#28
(Opened Oct 30, 2018)
[ ] Clarify intended scope of built-in UI vs external UIs
[ ] Decide what level of UI polish is expected upstream
Notes
This aligns well with documenting recommended external frontends (e.g., tar1090) while keeping the core UI stable.
🟠 Priority 5: Process Improvements for PRs
Rationale: Several PRs have been open for 4–6+ years.
Checklist
[ ] Add CONTRIBUTING guidance covering:
Expected review timelines (if any)
Criteria for accepting large changes
How to keep PRs from stalling indefinitely
[ ] Label long-running PRs as:
needs-rebase
needs-decision
out-of-scope
Related PRs
#146, #37, #29, #28
🧭 Suggested Next Steps (Low Effort, High Value)
Triage the four long-standing PRs listed above
For each PR, explicitly decide:
Merge
Request changes
Close with explanation
Document scope boundaries so future PRs align better
This roadmap is intentionally grounded in existing work, not new feature requests. Even closing PRs with clear rationale would significantly improve contributor experience.
Thanks again for maintaining dump1090 and for considering this proposal✈️
Chris