From a Curious Outsider to a GreptimeDB Advocator: My Journey into Open Source Contribution

4 min read Original article ↗

📢 About the Author ​

Yihong — runner, reader, gamer, and open-source enthusiast.

GitHub | Twitter | LinkedIn

Preface ​

Project repository: GreptimeDB

GreptimeDB is an open-source observability database written in Rust. The official description goes:

The unified observability database. OpenTelemetry-native, cloud-native, capable of processing metrics, logs, and traces in real time, delivering sub-second insights at any scale.

So far, I’ve submitted 51 PRs, 44 of which have been merged, ranking me 20th among all contributors.

This article is about how I went from a complete outsider to a long-term contributor—and eventually an advocator—for GreptimeDB.

The Spark: A Series of “Accidents” ​

My journey into GreptimeDB wasn’t planned. It was more like a chain of coincidences that led me here:

  • First encounter: I heard about it at the Cloud Native Conference in Dalian, when someone mentioned a Rust-based database.
  • Knowing the CTO: I had followed @sunng87 on Twitter for a while, only later realizing he was Greptime’s CTO.
  • Good First Issues: At the time, Tison was active at Greptime, regularly posting beginner-friendly issues.
  • Rust motivation: By the end of last year, I was frustrated with AI-generated Python code being full of bugs. I figured switching to Rust might be the cure.
  • Funny mishap: At one point, I was even “mistakenly blocked” by a team member, which only made me more curious about the project.

The real trigger was when Greptime’s CEO followed me on LinkedIn. I was already looking for a Rust project to practice with, so I opened the repo—and never looked back.

First Step: Starting with Bugs ​

My very first PR was db#5274, which was eventually closed. I like starting from bugs when exploring a new project.

Even small fixes give you a window into how the system works. Though my patch was rejected for architectural reasons, it taught me a lot:

  • How to fully compile the project
  • How the lint test and CI pipelines work
  • The clever design of their makefile—especially make help, which later inspired my patch to TiDB

That was the moment I realized:

Open-source contribution isn’t that hard. If you can run the project, you’ll naturally discover what to do next.

The First Merged PR ​

My first merged PR was db#5279.

It came from a simple annoyance: make fmt was taking 40 seconds. I optimized it down to 4 seconds.

The patch wasn’t complex—anyone could’ve done it, even AI. But it taught me something important:

In the age of AI, models can write code, but spotting the right problem to solve still requires human intuition.

Learning Rust, Making Friends ​

From there, I began contributing more while learning Rust:

  • db#5301: my first Rust code contribution (plus a test)
  • db#5313: fixed a bug that also resolved a panic
  • db#5338: cleaned up unused imports while studying OpenDAL

One fun comment I got: “LGTM. Why does cargo check or clippy not report this?”

  • db#5349 that led me to discover the limitations of cargo check and explore new static analysis tools. Eventually, I submitted db#5352 using those tools.

Later, I dived into RAPx, a more advanced Rust static analysis framework, and pushed further optimizations: db#5383, db#5388, db#5507, and more.

Through this, I not only learned Rust but also internalized the philosophy of memory safety and the strength of its tooling ecosystem.

Three Patches I’m Proud Of ​

Among my contributions, three patches stand out: db#5518, db#5561, and db#5497.

They taught me that:

  • Performance optimization isn’t magic—concepts like fast paths can deliver immediate impact.
  • Algorithms matter—sometimes a few lines of code can bring a 10x performance boost. Going from LeetCode problems to production-grade database code was a powerful experience.

From GreptimeDB to OpenDAL, and Back ​

As I grew more comfortable with Rust, I also contributed to OpenDAL. Understanding it gave me fresh perspectives, which I later applied back into GreptimeDB—for example, db#5585. Since then, whenever I find something interesting that could benefit Greptime, I just contribute it.

Code is only half of open source.

Offline, I met @fengjiachun and reconnected with @sunng87 in Japan. We shared drinks and stories.

That’s when I realized:

Open source is not just about code—it’s about building human connections.

Final Thoughts ​

Through GreptimeDB, I’ve learned Rust, gained insights into database optimization, and made new friends. If you’re looking for a way into open source, start small. Pick a bug, open a PR—you never know, it might be the start of your own story.