Contributing to Meshery: My First Steps in Large-Scale Open Source

Before SciML, my open-source education happened in Meshery — the cloud-native manager. It was the first time I worked in a codebase too big for any one person to hold in their head, and that turned out to be the whole point.

Where I started: tests, not features

The fastest way into a huge project isn't a feature — it's the test suite. I picked up Playwright-based end-to-end tests, which forced me to actually use the product the way a user would, and to understand the flows before touching internals.

test("user can apply a design", async ({ page }) => {
  await page.goto("/extension/meshmap");
  await page.getByRole("button", { name: "Deploy" }).click();
  await expect(page.getByText("Deployment successful")).toBeVisible();
});

A flaky e2e test is a tour of the architecture you didn't know you needed.

MeshSync and issue triage

From there I moved into MeshSync (the component that keeps cluster state in sync) and spent real time on issue triage — reproducing bugs, labelling, and narrowing reports down to something actionable. Triage is invisible work that maintainers love, and it teaches you the codebase faster than reading it cold.

What "at scale" actually means

• Conventions over cleverness. In a 1,000-contributor repo, the boring, consistent solution wins.
• Communication is the bottleneck, not code. A clear PR description saves three review rounds.
• Small, reviewable diffs. Nobody wants to review 800 lines from a new contributor.

Meshery is where I learned that open source is a social skill as much as a technical one. It set me up for everything that came after.