openrocket - Moses Yebei

The Problem

OpenRocket addresses a real gap in model rocketry: you cannot safely or affordably iterate on rocket designs through physical testing alone. Each test flight costs time, materials, and carries risk of losing hardware. OpenRocket replaces that trial-and-error loop with six-degree-of-freedom flight simulation, letting a designer validate stability, altitude, and motor selection before anything leaves the ground.

What This Does

This is a Java desktop application with two Gradle modules: core/ (974 code files) holds the simulation engine, aerodynamics calculators, and file I/O; swing/ (505 code files) is the GUI. The aerodynamic model lives in core/src/main/java/info/openrocket/core/aerodynamics/, with BarrowmanCalculator.java and BarrowmanStabilityCalculator.java implementing the classical Barrowman method for stability prediction. The core/src/main/java/info/openrocket/core/file/ package handles import/export of .ork files, RockSim, and RASAero formats.

The project is a fork of openrocket/openrocket (3,055 stars upstream) with zero stars of its own, suggesting it is a personal or experimental branch rather than a primary distribution point.

How It Is Wired

The static analysis resolved one internal module with zero import edges, so the module graph provides no map of internal control flow. The wiring has not been meaningfully mapped for this repository yet. What is clear from structure: core/src/main/java/info/openrocket/core/database/motor/ThrustCurveMotorSQLiteDatabase.java reads motor thrust curves from a bundled SQLite database at core/src/main/resources/datafiles/thrustcurves/initial_motors.db. Simulation results are written back as .ork files through core/src/main/java/info/openrocket/core/file/openrocket/OpenRocketSaver.java. The swing GUI is the only entry point; there is no CLI in the tree.

How To Use It

Setup: The repo uses Gradle, with a wrapper at core/gradlew. Clone and build:

git clone https://github.com/moses-y/openrocket
cd openrocket/core
./gradlew build

Running it: Launch the GUI from the swing module. The run configuration .idea/runConfigurations/SwingStartup.xml exists for IntelliJ; there is no documented CLI invocation.

Configuration: No environment variables or external config files are required. The bundled SQLite motor database is loaded automatically.

Real-World Use

A club designing a high-power rocket for a competition uses OpenRocket to simulate the flight envelope: they model the airframe in the GUI, select a motor from the bundled thrust-curve database, and run a 6-DOF simulation to verify the stability margin is within the 1-2 caliber range before committing to expensive hardware. The design is exported as an .ork file and shared with the build team.

Code Health & Issues

Static analysis found 486 issues (185 high, 281 medium, 20 low), dominated by one kind: deep nesting (max indentation depth 9) in AbstractAerodynamicCalculator.java and related aerodynamics files, which makes control flow hard to follow.

High - Third-party GitHub Actions pinned to tags, not commit SHAs - .github/workflows (e.g., gradle/actions/setup-gradle@v5). A moved tag can execute arbitrary code with your CI token.
High - CI never runs the test suite - .github/workflows declares no test command despite 295 test files existing.
High - Committed SQLite database dump - core/src/main/resources/datafiles/thrustcurves/initial_motors.db. Remove and purge from history.
Medium - No permissions: block on build.yml, leaving the default token scope.
Medium - No Dependabot/Renovate configured.
Medium - No dependency vulnerability scan in CI.
Medium - No pre-commit secret gate.
Medium - Three blobs over 5MB tracked in git, including a 17.8MB .afphoto file.
Low - No timeout-minutes on workflow jobs.

The Bottom Line

The codebase is a mature, feature-rich simulator with solid domain coverage and a real test suite that CI currently ignores. The high-severity issues—unpinned actions, a committed database dump, and a test suite that never runs—are fixable in an afternoon. This is a working fork for someone who wants OpenRocket internals; the upstream project is the safer choice for production use.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

2,692 files

Java1479
reStructuredText35
Markdown8
YAML6
Shell6
JSON2

ExpressTransformers

Findings

LowDependencies declared without a lockfile - non-reproducible builds build.gradle

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high3

medium5

low1

Pin third-party GitHub Actions to a commit SHAhigh

.github/workflows

gradle/actions/setup-gradle@v5

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Make CI invoke the test suite it hashigh295 occurrences

.github/workflows

295 test files, no test command in any workflow

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Remove the committed database dumphigh

core/src/main/resources/datafiles/thrustcurves/initial_motors.db

A dump is the one artefact that leaks other people's data rather than the owner's, which turns a hygiene problem into a notification obligation.

Fix: Remove and purge from history; if it held personal data, assess it as a disclosure.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/build.yml

1 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Add a pre-commit secret gatemedium

a secret-shaped file is tracked and no repo-level gate is visible

Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.

Fix: Add a pre-commit hook scanning staged content, and enable push protection.

Move large binaries to Git LFS or out of the repositorymedium3 occurrences

swing/resources-src/pix/icon/logo.afphoto

3 blobs over 5MB: logo.afphoto 17.8MB, banner.afphoto 14.5MB, github-social-preview.afphoto 5.0MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Set timeout-minutes on the workflow jobslow

.github/workflows/build.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.