Two Days, 20 Commits — How I Started Contributing to GitLab Orbit

Context: I'm a GitLab Community Contributor. Orbit is developed by an internal GitLab team, but community members can submit MRs through the community fork. This is my first contribution experience.

What Is Orbit

One sentence: GitLab Orbit turns your code and development lifecycle data into a queryable graph.

More specifically. Your repo has code. GitLab has MRs, issues, pipelines, deployments. These things live in different places, and answering cross-cutting questions like "who calls this function," "what pipelines break if I change this file," or "how's the test coverage for this module" means stitching together multiple APIs yourself.

Orbit indexes everything into a property graph — code definitions, call relationships, inheritance chains, import graphs, plus MR / issue / pipeline SDLC data — and lets you query it with SQL or a Query DSL.

Two modes:

• Orbit Local: Standalone CLI, indexes a single repo into a local DuckDB. No GitLab account needed. Takes a few seconds.
• Orbit Remote: Hosted service, indexes an entire GitLab group into ClickHouse, with authorization and API endpoints.

Tech stack is Rust. A single workspace with 28 crates, supporting 11+ programming languages (Ruby, Java, Python, TypeScript, Rust, Go, C#, C/C++, Kotlin, Elixir, Bash). Code parsing via tree-sitter, OXC for JavaScript/TypeScript.

Sounds massive. It is. But that doesn't mean you can't contribute.

Finding an Entry Point

I started contributing to Orbit because of a hackathon. The GitLab Transcend Hackathon had a track built around Orbit. My team built a tool that uses Orbit graph queries to make AI code review auditable. While building it, I kept digging through Orbit's source code and docs, and kept finding things that could be improved.

The first entry point usually isn't code — it's documentation.

When I set up Orbit Local, the quickstart docs assumed you already had GDK (GitLab Development Kit) installed. But running Orbit Local doesn't need GDK at all. A lot of potential contributors probably give up at that step. So I wrote a quickstart guide that doesn't require GDK.

That was my first MR.

My Four MRs

In two days I submitted 4 MRs, each a different type:

1. docs/690 — Orbit Local Developer Quickstart

The simplest one: a from-scratch quickstart that doesn't assume GDK. Covers protoc installation (Linux / macOS / Windows), build commands, running tests, common issues.

During review, the maintainer asked me to add Windows protoc paths and a note about ontology E2E test caveats. That's the beauty of submitting MRs — the review process itself is learning.

2. feat/847 — Java Sealed Type Permits Clause Extraction

This was Rust feature development. Java 17 introduced sealed classes (JEP 409), allowing a permits keyword to restrict which subclasses can extend a type. But Orbit's Java indexer never read this field, so sealed-type hierarchies were broken in the graph.

What I did:

• Found the permits field in tree-sitter-java's AST, wrote a java_permitted_types() extractor
• Added a new EdgeKind::Permits to the code graph
• Registered the new edge kind in the ontology schema
• Reused existing name resolution logic from link_extends (extracted into resolve_disambiguated_targets)
• Added test fixtures

13 files changed, +237/-36 lines. Sounds like a lot, but most of it was following existing patterns — Orbit's code graph pipeline is well-designed, and adding a new edge kind has a clear path to follow.

3. fix/741 — Indexer Log Fix for Skipped Long-Line Files

Classic "found this while using it" bug. When Orbit indexes a repo and hits a file with lines exceeding the limit, it skips the file silently — only logged at DEBUG level. At INFO level, you'd finish indexing with no idea files were skipped.

Simple fix: log a line at INFO when files are skipped, keep details at DEBUG. The maintainer's review simplified it further — drop the aggregate, just log each skip at DEBUG. A cleaner approach.

4. docs/850 — Prerequisites as an On-Demand Reference

Orbit's prerequisites were scattered across several docs. I consolidated them into a standalone reference page — look it up when you need it, don't clutter the quickstart.

Other Small Contributions

Beyond the four main MRs:

• Documented Gemini CLI authentication for the Orbit MCP endpoint (turns out you need to explicitly request the mcp_orbit OAuth scope)
• Added Kotlin suspend function test fixtures
• Updated CLI docs for v0.74.0
• Created a production runbook skeleton
• Fixed a troubleshooting page redirect

Total: 20 commits, +1,260/-235 lines.

A 2,800+ Commit Rust Project Is Less Intimidating Than It Sounds

A few things that lowered the barrier:

Orbit's code graph pipeline is modular. Adding a new edge kind means following the pattern of EXTENDS or CALLS — add an extractor, add an edge kind enum variant, add ontology config, add fixtures. Every step has existing examples to follow. For the Java permits feature, roughly 80% of my time went to understanding "what's the current pattern," and only 20% to writing new code.

Orbit Local needs no infrastructure. No ClickHouse, no NATS, no GDK. Just cargo build and go. Local indexing takes seconds, so the edit → test loop is fast.

Documentation is real contribution. Don't think "it's just docs" means it doesn't count. My quickstart MR got just as thorough a review as the Rust code MR. For a fast-growing project, docs that lower the barrier for newcomers are genuinely valuable.

Maintainer reviews are constructive. I learned something from every MR. The feat/847 review had me flip the permits edge direction to align inversely with EXTENDS (better graph semantics). The fix/741 review taught me log-level design trade-offs. That kind of review quality is something you don't get from solo side projects.

If You Want to Contribute

A few suggestions:

1. Run Orbit Local first. glab orbit local index . on your own repo, then run some queries with glab orbit local sql. Whatever you bump into is probably your first MR.

2. Check the issue tracker. Orbit has good first issue labels — usually docs, small fixes, or adding test fixtures for new languages.

3. Docs always need help. Especially installation steps, platform differences, common error handling. The pit you fell into is someone else's MR.

4. Submit through the community fork. GitLab community contributors use the community fork to submit MRs. Same workflow as any GitLab MR.

5. Don't be afraid of Rust. If you have experience in other languages, Orbit's Rust code is more approachable than you'd expect. The code graph layer is mostly tree-sitter AST operations and pattern matching — no deep lifetime gymnastics or async wizardry required.

Wrapping Up

Two days, 20 commits, 4 MRs. Looking back, the barrier was genuinely lower than I expected.

Orbit is a fascinating project — unifying code analysis and SDLC data into a queryable graph is a direction that will only become more important as AI-assisted development grows. And it's actively expanding (more languages, more query capabilities), so now is a good time to jump in.

If you're interested in code analysis, knowledge graphs, or Rust, GitLab Orbit is a great contribution target. Hope to see you in the community.