Source-linked AI summary
Characterizing the Landscape of Open-Source Satellite Software
Jinfeng Wen, Qi Liang, Yuehan Sun, Federica Sarro, Ao Zhou, Xuanzhe Liu, Shangguang Wang
TL;DR
A systematic empirical understanding of open-source satellite software has been missing despite its growing role in satellite engineering. This study analyzes GitHub projects and finds a growing, heterogeneous ecosystem with varied software goals and task-aligned language use.
Problem
A systematic examination of open-source satellite projects is lacking, despite the growing role of open-source software in satellite engineering.
Source: §1 · p. 2Method
The study analyzes 22,286 GitHub projects, manually classifies a random sample of 646 to construct a goal taxonomy, and examines development practices.
Source: §1 · p. 2Results
The ecosystem shows sustained growth in projects and active developers, 43 software-goal categories, and task-aligned use of 66 programming languages.
Source: §9 · p. 11Takeaways & Limitations
The authors identify the scarcity of end-to-end satellite platforms as a reason to develop open-source whole-satellite platforms using modular architectures.
Source: §7 · p. 11Manual taxonomy analysis may introduce researcher subjectivity, although two-author classification and expert arbitration were used to mitigate it.
Source: §8 · p. 11
Abstract
from arXiv · showhide
Satellites have become fundamental components of modern technological systems, supporting critical infrastructure in communication, navigation, Earth observation, and scientific research. As space exploration advances and demand for satellite-enabled services grows, reliance on complex, heterogeneous satellite software continues to increase. A systematic understanding of the satellite software landscape is therefore increasingly important, yet existing studies still lack a comprehensive empirical examination. To address this gap, we present the first characterization study of open-source satellite software, examining its ecosystem and development practices. We mine and analyze 22,286 satellite-related GitHub projects through three research questions on popularity trends (RQ1), software goals (RQ2), and development practices (RQ3). First, we characterize the temporal evolution of projects and active developers, revealing increasing popularity. Second, through manual inspection of 646 projects, we construct a taxonomy of 43 software-goal categories spanning conceptual design, datasets, system implementation, simulation, testing, and tools. Third, we conduct an in-depth analysis of projects with source code, revealing a highly heterogeneous and task-specialized ecosystem with 66 programming languages and diverse implementation strategies. Finally, we summarize key findings and derive actionable implications for satellite developers and researchers.
1 Introduction
Satellite software supports mission-critical functions, yet its landscape has lacked systematic study despite software-related reliability concerns and growing open collaboration. This study analyzes 22,286 GitHub projects to characterize popularity, goals, and development practices.
- About 24.2% of satellite missions suffered total failure and another 11% partial failure; some failures are linked to software behavior, design defects, or unexpected interactions.Satellite software coordinates mission-critical functions and is a primary determinant of mission reliability and operational lifetime.Source: §1 · p. 2
- Open-source satellite software is increasingly collaborative, with implementations covering core functions and potential benefits including knowledge sharing, code reuse, lower costs, and faster progress.The authors report that no prior work had systematically examined open-source satellite projects and derive implications for developers and researchers.Source: §1 · p. 2
- The study examines 22,286 GitHub projects as the first comprehensive analysis of open-source satellite projects, addressing popularity trends, project goals, and development practices.Source: §1 · p. 2
- The study finds sustained growth in community attention to satellite software, showing its increasing prominence and the timeliness of examining the ecosystem.Source: §1 · p. 2
- A manual inspection of 646 projects yields a taxonomy of 43 goal categories spanning datasets, system implementation, simulation, testing, and tools.Source: §1 · p. 2
- Source-code analysis identifies 66 programming languages, with language choices aligned to task requirements and implementation increasingly integrating heterogeneous models and solutions.Source: §1 · p. 2
2 Background and Related Work
Satellite software faces distinctive resource, communication, mission-risk, and standardization constraints, yet open-source satellite software remains underexplored. This section positions the study against prior satellite and open-source software research.
Satellite Software vs. Traditional Software
- Satellite software must accommodate constrained onboard resources, specialized communication over unstable links and long delays, mission-critical functions, and high-fidelity simulation before deployment.Limited power, thermal capacity, and hardware bound computation and storage; the ecosystem may also be less standardized and mature than terrestrial software.Source: §2 · p. 2
Related Studies on Satellites
- Prior satellite studies examine networks and performance [46] [52] [55], devices [76], latency and reliability, modem security, and onboard-data effects on learning.The cited work includes Starlink end-to-end network analysis [52], satellite-device thermal and power management [76], modem security risks, and data scarcity and skewness effects on learning accuracy.Source: §2 · p. 2
Related Studies on Open-Source Software
3 Methodology
The methodology examines popularity trends, software goals, and development practices in open-source satellite projects. It combines GitHub repository filtering, representative sampling and taxonomy construction, and source-code analysis.
3 Methodology
- The study asks about popularity trends, project goals, and development practices in open-source satellite software.Source: §3 · p. 3
3.1 Data Preparation
- From 32,347 GitHub repositories retrieved on October 10, 2025, filtering for accessibility, essential project artifacts, and English yielded 22,286 projects.Source: §3.1 · p. 3
3.2 Methodology Designs
- Popularity was measured through annual new projects, active developers, cumulative active developers, and commits across the 22,286 repositories.Project creation used created_at timestamps; developer counts used unique identities from commit records, with deduplication for cumulative counts.Source: §3.2 · p. 3
- A statistically representative sample of 646 projects at 99% confidence and ±5% margin of error was coded using open coding to construct the software-goal taxonomy.The 99% confidence level concerns estimating the population proportion of projects in each labeled category.Source: §3.2 · p. 3
- Two authors inductively coded 453 projects, excluding unrelated projects and allowing multiple category assignments, with disagreements resolved by a satellite-research expert.They reviewed project descriptions, README files, source code, and related files iteratively to derive a hierarchical taxonomy.Source: §3.2 · p. 3
- Independent labeling of the remaining 193 projects achieved Cohen’s Kappa κ = 0.857, and arbitration added four categories to finalize the taxonomy.Projects that did not fit the initial taxonomy were marked Pending before discussion and reclassification.Source: §3.2 · p. 3
- The 620-sample analysis showed similarly increasing annual project creation and active developers, suggesting growth was robust to sampling and not mainly driven by false positives.Of 646 sampled projects, 34 were labeled False, 604 assigned to one category, and 8 to two categories.Source: §3.2 · p. 3
- Development-practice analysis examined language shares by goal category and inspected source code and cross-referenced documentation for implementation practices.Because projects may use multiple languages, per-project language proportions were normalized and aggregated within each goal category.Source: §3.2 · p. 4
4 RQ1: Popularity Trend
Open-source satellite software gained increasing attention from 2008 to 2025, with growth in newly created projects, active developers, and development activity.
4 RQ1: Popularity Trend
- New projects rose from 1 in 2008 to 4,997 in 2025, while annual active developers grew from 1 to 9,018 over the same period.The project count in 2025 was 42.24% higher than in 2024.Source: §4 · p. 4
- Cumulative active developers reached 37,246 by the end of 2025, while annual commits rose to 136,248 in 2025.Annual commits reached 97,893 in 2020, a 35.89% increase over 2019.Source: §4 · p. 4
- RQ1 finds that rising attention to satellite software underscores this study’s timeliness and the need for software engineering support in the domain.The findings characterize the ecosystem as increasingly visible, with broader participation beyond isolated project-level efforts.Source: §4 · p. 4
5 RQ2: Goal Taxonomy · 5.1 Conceptual Design (A) · 5.2 Dataset (B)
The taxonomy organizes OSS satellite projects into 22 inner and 43 leaf categories spanning the satellite software workflow. The sections characterize conceptual-design projects and dataset resources, including their main dataset types.
5 RQ2: Goal Taxonomy
- The taxonomy comprises 22 inner and 43 leaf categories, covering the workflow from conceptual design and datasets through implementation, simulation, testing, and tools.Leaf nodes are the most fine-grained categories; parent nodes grouping subcategories are inner categories.Source: §5 · p. 4, Figure 3 · p. 5
5.1 Conceptual Design (A)
- Conceptual-design projects introduce satellite-related concepts or designs without concrete code implementations, serve mainly illustrative purposes, and account for 0.48% of projects.One example is a satellite design supported by multiple illustrative documents.Source: §5.1 · p. 4
5.2 Dataset (B)
- Dataset projects provide resources for analysis and experimentation and account for 3.39% of surveyed projects.The resources are classified into four primary types.Source: §5.2 · pp. 4–5
- Observation Data accounts for 1.61% of projects and is the largest dataset subcategory, providing satellite-captured remote-sensing images or videos.Examples include land-cover imagery, river-inundation imagery, and infrared videos for small-target detection.Source: §5.2 · pp. 4–5
- Positioning Data accounts for 0.32% of projects and primarily comprises GNSS datasets for satellite navigation and geolocation analysis.Source: §5.2 · p. 4
- Satellite Mission Data accounts for 0.65% of projects and includes onboard datasets for satellite planning and operations.Examples include launch-history records, energy-monitoring data, and mission-scheduling requests.Source: §5.2 · p. 4
- Communication and Network Data accounts for 0.81% of projects, comprising communication specifications (0.16%) and network-operation datasets (0.65%).The former describes satellite communication band parameters; the latter includes network security datasets and associated resource collections.Source: §5.2 · p. 4
5.3 System Implementation (C) · 5.4 Simulation (D)
System implementation makes up 14.03% of surveyed projects, spanning mission-related and hardware-related systems, while simulation accounts for 7.42% and covers five types. Orbit simulation is the largest simulation type, and mission-related systems are the larger implementation subcategory.
5.3.1 Mission-related Systems (C.1, 8.87%).
- Mission-related systems cover satellite control (2.74%), communication and network management (1.94%), and satellite-ground exchange (4.19%).Satellite control includes tracking (2.10%) and attitude control (0.65%); communication and network systems include signal processing (1.13%), transmission (0.65%), and routing (0.16%).Source: §5.3.1 · p. 5
- Satellite-ground systems form the largest Mission-related Systems type, and satellite-generated data management accounts for 3.23% of projects.Data visualization represents 70.00% of satellite-generated data management systems, covering geographic information, positioning, imagery, telemetry, and event-tracking data.Source: §5.3.1 · p. 5
5.3.2 Hardware-related Systems (C.2, 5.16%).
- Hardware-related systems comprise onboard data handling (0.65%), integration (0.97%), and control systems (3.55%), the largest hardware-related type.Control systems include satellite bus control (1.77%) for power, thermal, and propulsion regulation, and communication signal control (1.77%) using transceiver modules.Source: §5.3.2 · pp. 5–6
5.3 System Implementation (C)
- System Implementation accounts for 14.03% of projects and comprises Mission-related Systems (8.87%), focused on high-level mission functions, and Hardware-related Systems (5.16%).Mission-related systems abstract from hardware, while hardware-related systems provide low-level support and interfaces to satellite or ground hardware.Source: §5.3 · p. 5, §5.3.2 · p. 6
5.4 Simulation (D)
- Simulation projects model physical operating conditions, attitude dynamics and control, orbital trajectories and corrections, or multi-satellite constellation architectures and strategies.These correspond to environment simulation (0.32%), attitude simulation (1.13%), orbit simulation (3.06%), and constellation simulation (1.13%).Source: §5.4 · p. 6
- System simulation (1.77%) models system-level capabilities through internal subsystem simulation (1.29%) or external interaction simulation (0.48%).Internal simulations address individual subsystems such as communication and mission planning; external simulations examine satellite interactions with the environment.Source: §5.4 · p. 6
- Simulation accounts for 7.42% of projects and includes five types; orbit simulation is most common (3.06%), while environment simulation is least common (0.32%).The other types are attitude simulation (1.13%), constellation simulation (1.13%), and system simulation (1.77%).Source: §5.4 · p. 6
5.5 Testing (E)
Testing evaluates whether satellite-related software, algorithms, or operational functions meet expected requirements, rather than modeling systems or environments as simulation does. It accounts for 1.94% of surveyed projects across four subcategories.
5.5 Testing (E)
- Testing comprises system performance, algorithm effectiveness, instrument calibration, and software stability testing, together accounting for 1.94% of surveyed projects.Performance and algorithm effectiveness are the most prevalent subcategories.Source: §5.5 · p. 6
- System Performance Testing (E.1) and Algorithm Effectiveness Testing (E.2) each account for 0.81% of projects and are the most prevalent subcategories.E.1 evaluates metrics such as networking efficiency and communication link quality; E.2 assesses task-oriented algorithms such as image processing and orbit determination.Source: §5.5 · p. 6
- Calibration Testing (E.3) and Stability Testing (E.4) each account for 0.16% of projects.E.3 examines onboard-instrument calibration accuracy, while E.4 focuses on flight-software stability.Source: §5.5 · p. 6
5.6 Tool (F)
Tools form the largest category in the taxonomy, covering 72.74% of projects and spanning satellite-data collection and processing, spatial and orbit analysis, communications, and visualization. Data Utility dominates, accounting for 53.71% of Tool projects.
5.6.1 Data Utility (F.1, 53.71%)
- Data Utility (53.71%) covers data collection (4.68%) and processing (49.03%), including retrieval and download as well as imagery and non-imagery workflows.Retrieval accesses existing data through queries, metadata filtering, or catalogs; download obtains raw or pre-processed data from repositories or ground stations.Source: §5.6.1 · p. 6, §5.6.5 · p. 7
- Non-Imagery Processing (7.26%) includes scenario-specific projects (5.16%) and scenario-independent workflows (2.10%) for telemetry, sensor, and radio-frequency data.Scenario-specific applications include environmental monitoring, astronomy, geolocation, reconnaissance interpretation, and Earth-observation market analysis; general workflows cover preprocessing and analysis.Source: §5.6.1 · p. 6
- Imagery Processing (41.77%) spans scenario-specific analysis (22.90%) and generic workflows (18.87%), covering four application scenarios and 117 generic-processing projects.Scenario-specific work includes cloud assessment, environmental monitoring, land and vegetation analysis, and human activity; generic workflows include preprocessing, enhancement, analysis, and visualization, with some end-to-end tools.Source: §5.6.1 · pp. 6–7
- Spatial-information tools cover satellite coverage analysis (0.65%), geolocation analysis (3.06%), and scheduling satellite overpasses (0.65%).Source: §5.6.2 · p. 7
5.6.3 Orbit Computation Tool (F.3, 3.55%)
- Orbit computation tools determine orbital elements from tracking or optical observations (0.81%) and propagate future orbital states (2.74%).Source: §5.6.3 · p. 7
5.6 Tool (F)
- Communication-subsystem tools analyze link quality, throughput, and reliability (0.65%), protocol correctness and compliance (0.65%), and signal quality (1.61%).Source: §5.6.4 · p. 7
5.6.5 Visualization (F.5, 8.23%)
- Visualization tools render satellite trajectories (5.65%) and analytical data outputs (2.58%) to clarify spatial dynamics, mission behavior, and data interpretation.Source: §5.6.5 · p. 7
5.6 Tool (F)
- 72.74% of projects belong to the Tool category, the taxonomy’s largest, spanning 9 inner and 16 leaf categories.Data Utility dominates the category at 53.71%, covering collection and processing of imagery and non-imagery data.Source: §5.6 · p. 6, §5.6.5 · p. 7
6 RQ3: Current Development Practices
The section analyzes source-code-available projects, excluding Conceptual Design and Dataset, and finds a diverse language landscape alongside varied implementations across satellite software goals.
6.1 Programming Language Practices
- 66 distinct languages appear; Python (32.91%) and Jupyter Notebook (28.06%) lead, followed by JavaScript (7.40%), C++ (4.40%), MATLAB (4.06%), and HTML (3.57%).The findings characterize this landscape as heterogeneous and task-aligned rather than reliant on one dominant ecosystem.Source: §6.1 · p. 7
6.2.1 System Implementation (C).
- Mission-related systems combine orbit tracking and attitude control with radio processing, robust communications, adaptive routing, mission management, and satellite-data storage and analysis.Implementations include SGP4 and PD control as well as reinforcement learning; they also support scheduling, power management, and data visualization.Source: §6.2.1 · pp. 7–8
- Hardware-related systems span onboard data handling and CubeSat integration through bus control and communication-signal acquisition and processing.Examples include custom PCBs, dedicated onboard computers, Arduino and STM32 platforms, RF front ends, and GNU Radio pipelines.Source: §6.2.1 · p. 8
6.2.2 Simulation (D).
- Simulation projects cover satellite environments, attitude and orbit propagation and control, constellation operations, and internal subsystems and Earth-observation interactions.Methods include thermal and electric-field modeling, quaternion-based attitude integration and feedback, SGP4 or Keplerian orbit propagation, TLE-based constellation configurations, and communication, networking, and mission-planning simulation.Source: §6.2.2 · pp. 8–9
6.2.3 Testing (E).
- Testing covers network and communication-link performance, mission-specific image-processing and estimation algorithms, antenna calibration, and flight-software stability.Evaluations include realistic sensor noise and operational constraints, satellite signals as stable calibration references, and command execution with telemetry handling.Source: §6.2.3 · p. 9
6.2.4 Tool (F).
- Tools support multi-source data retrieval and processing, spatial coverage and scheduling, orbit computation, communication management, and trajectory and data visualization.The described implementations use open APIs and remote-sensing platforms, orbit propagation and optimization, link-budget and protocol analysis, and signal processing.Source: §6.2.4 · pp. 9–10
- Across implementation practices, projects combine hardware-related design and mission-level optimization with analytical models, numerical integration, and data-driven methods.The section emphasizes physics-based modeling alongside machine-learning enhancement and hardware-grounded operational realism for real-world constraints and mission requirements.Source: §6.2.4 · p. 10
7 Discussion and Implications
The discussion identifies gaps in datasets, configuration management, simulation, onboard data utilities, and end-to-end platforms, and outlines priorities for developers and researchers in each area.
Satellite Datasets
- Observation data dominate satellite datasets, but datasets tailored to onboard computing and in-orbit execution remain scarce.Community-curated, standardized datasets reflecting realistic onboard workloads could support development, testing, benchmarking, and research on architecture, performance optimization, and lifecycle management.Source: §7 · p. 10
Software Configurations
- Mission-related systems dominate implementation projects, while resource constraints make configuration management increasingly important for satellite–ground coordination.Developers need configurable architectures and runtime-adjustable parameters; research opportunities include configuration modeling, validation, and testing for resource-constrained systems.Source: §7 · p. 10
Thermal Environment Simulation
- Orbit simulation dominates satellite simulation projects, whereas thermal environment simulation is least represented despite its importance to in-orbit reliability and performance.Software-aware thermal simulation should model how execution workload, task duration, and scheduling interact with space thermal cycles, enabling thermal-conscious scheduling and performance–energy co-optimization.Source: §7 · p. 10
Onboard Data Utilities
- Data utilities are the largest Tools subcategory, but most support ground-based processing rather than in-orbit data processing.Moving lightweight preprocessing such as denoising, calibration, and image clipping onboard could reduce redundant downlink; research can examine in-orbit data quality and processing partitioning.Source: §7 · p. 10
Open-Source Satellite Platforms
- End-to-end open-source satellite platforms are largely absent; most projects target isolated components, limiting system-level experimentation and cross-layer analysis.Developers can integrate open-source subsystems through modular architectures and well-defined interfaces; researchers can use whole-satellite platforms for reproducible studies bridging simulation and in-orbit deployment.Source: §7 · pp. 10–11
8 Threats to Validity
The study acknowledges possible subjectivity in manual taxonomy construction and uncertainty about taxonomy completeness, addressing both through independent review, reliability checks, and expert validation.
Researcher Subjectivity
- Cohen’s Kappa of 0.857 indicates high agreement between two independent classifiers, whose disagreements were resolved through discussion and satellite-expert arbitration; classifications are publicly released.The final taxonomy was also reviewed by authors with satellite-domain expertise.Source: §8 · p. 11
Taxonomy Stabilization
- Four categories added while classifying the remaining 30% of projects each contained no more than three projects, and iterations mainly made minor adjustments rather than adding high-level categories.The number of new categories was smaller than in prior studies [29].Source: §8 · p. 11
9 Conclusion
The study characterizes open-source satellite software across popularity, software goals, and development practices. It finds sustained ecosystem growth, diverse software goals, and heterogeneous technologies.
- Satellite software and active developers have grown steadily, highlighting the rising importance of open-source ecosystems in this domain.Source: §9 · p. 11
- From a random sample of 646 projects, the study derives a taxonomy of 43 software goals spanning datasets, implementation, simulation, testing, and tools.Source: §9 · p. 11
- The ecosystem uses 66 programming languages in task-aligned ways, with increasing integration of analytical and data-driven models.Source: §9 · p. 11
- The first empirical study of open-source satellite software examines 22,286 satellite-related GitHub repositories across popularity trends, functional objectives, and development practices.Source: §9 · p. 11