From Real Problems to Core Open‑Source Contributors: A Practical Guide

For engineers, participating in open‑source projects is a fast track to sharpen technical skills, broaden industry perspective, and build influence, yet many wonder how to evolve from a user to a core contributor.

We interview three Didi engineers who became core members in 2023: Ray community new member Fan Shilun, Apache Auron new committer Gui Hua‑wen, and Linux kernel new maintainer reviewer Li Nan. Each started from a concrete business pain point, followed a path of deep usage, digging into internals, and giving back to the community.

Fan Shilun – Ray community – His team faced large‑scale multimodal data‑processing bottlenecks; Ray Data was the key solution. After mastering Ray Data, he moved from a user to actively discussing issues, fixing bugs, and improving module stability, eventually earning Ray Member status. He gained a systematic understanding of distributed data‑processing principles and stricter engineering quality standards, while his team benefited from clearer knowledge of Ray’s capabilities and direct upstream feedback.

Gui Hua‑wen – Apache Auron – Working with Spark‑based workloads, she needed vectorized execution. Auron’s Rust‑based native engine matched the requirement. She began with documentation, test additions, and bug fixes, then contributed to core operators such as sort, join, and aggregation. Her sustained PRs earned her committer status, bringing Rust and Arrow expertise to her team and raising the team’s influence in the community.

Li Nan – Linux kernel – Encountering RAID module issues in production, he subscribed to the linux‑raid mailing list, started with small patches, then refactored code and added new features. Over several years he became a reviewer for the md/raid module, improving code quality and gaining global impact. His team now tracks kernel evolution early, integrates upstream changes smoothly, and reduces long‑term maintenance cost of private patches.

All three emphasize a two‑way win: they feed real‑world problems into upstream projects, and the matured upstream capabilities feed back into their products. Their practical advice for newcomers includes starting with lightweight tasks (bug fixes, documentation, test improvements), learning community rules, following issues, contributing consistently, and treating open‑source as a long‑term investment rather than a one‑off effort.

Key steps to take the first open‑source step: identify a real problem, read the source code with that problem in mind, begin with small contributions, learn the community’s workflow, stay patient through iterative reviews, and maintain steady involvement.