← Back to writing
Resume Evolution 10 min Part 4 of 7

Contributing to Meshery: Learning Design Systems at Scale

How contributing to a CNCF project with 9,500 GitHub stars taught me what design systems actually solve — not through theory, but through the pain of a codebase with four different button styles.

Five years of writing zero frontend code. From 2017 to 2022, my work was in a different universe: RHEL administration, Azure cloud infrastructure, NIST 800-53 compliance auditing, DISA STIG hardening. I’d gone from CodePen resumes to firewall-cmd --permanent --add-service=ssh and oscap xccdf eval.

The return to frontend started with a Go upgrade. In September 2022, I submitted my first PR to meshery/meshery — a Go 1.19 module upgrade. Nothing to do with the UI. I was there for the backend, the infrastructure, the cloud-native tooling.

Then I started looking at the frontend.

The Consistency Problem

Meshery had ~9,500 GitHub stars, dozens of UI views, and a React + Material UI frontend that had been contributed to by hundreds of people. Each contributor brought their own approach:

  • Some pages used MUI’s Button directly with inline styles
  • Others had custom wrapper components with different prop APIs
  • Color values were hardcoded hex strings scattered across files — no shared palette
  • Spacing was a mix of pixel values, rem values, and MUI’s spacing utility

This wasn’t a code quality problem. Every individual contributor wrote reasonable code. The problem was that “reasonable” meant something different to each person. There was no system — no single source of truth for what a button should look like, what spacing to use, what colors were available.

I’d seen this pattern before, in a different domain. In security compliance, the same problem manifests as “every team implements the NIST control differently.” The solution there is a shared baseline — an organizational standard that removes the need for individual judgment on decisions that should be consistent. A design system is the same thing for UI.

First Real Contributions: Infrastructure

My early Meshery contributions were backend-focused:

  • Go module upgrades (1.19 → 1.21 over several PRs)
  • Package dependency updates
  • CI/CD pipeline fixes
  • Documentation improvements

198+ commits across 2022-2023. I was learning the codebase’s shape — how the Go backend served the React frontend, how the extension system worked, how Meshery connected to service mesh adapters. The UI codebase was something I walked past every day on the way to the backend.

The Moment It Clicked

A new contributor submitted a PR with a button component. The review feedback was: “Make it match the existing buttons.” But which existing buttons? I found at least four distinct visual patterns for buttons across the Meshery UI:

  1. MUI Button with default props
  2. MUI Button with custom inline styles
  3. A custom wrapper with its own color props
  4. A styled-component button that didn’t use MUI at all

Each was “the existing buttons” depending on which page you looked at. The contributor couldn’t match something that didn’t have a single definition. This was the design system problem made concrete — not as an abstract architecture discussion, but as a pull request that couldn’t be completed because the standard didn’t exist.

What I Learned About Scale

Working on Meshery’s codebase taught me things about component design that you don’t learn from personal projects:

Props are a contract, not a convenience. When 50+ contributors are using your button component, the prop API is a published interface. Changing it is a migration, not a refactor. I learned to design props by thinking about who would consume them, not just who would build them.

Theming is organizational, not aesthetic. A theme isn’t “what colors do we like.” It’s “what changes when the context changes.” Dark mode, high contrast, brand variants, embedded contexts — theming is a system for managing variation, and the variation comes from organizational needs, not design preferences.

Consistency beats novelty. The best-looking button in the world is a liability if it doesn’t match the other buttons. Design systems exist to make “boring and consistent” easier than “creative and inconsistent.” The value isn’t beauty — it’s predictability.

Open source compounds. One well-designed component, documented and tested, gets used by dozens of contributors who each would have otherwise written their own version. The leverage of a shared component in an open source project is enormous. My single Button wrapper eventually meant 50 fewer ad-hoc button implementations.

The Bridge to Sistent

By early 2023, these observations led to action. The Meshery team started Sistent — a dedicated component library to give the UI a shared vocabulary. I didn’t start Sistent alone; it was a team effort with Layer5’s design and engineering contributors. But the problem I’d identified — four button patterns, zero standards — was the problem Sistent was created to solve.

The next post covers the Storybook setup, the first components, and what it’s like to build a design system from inside a moving codebase.

What This Taught My Portfolio

Everything I later built into the Stratos design system for acaldwell.dev came from Meshery:

  • Token-driven architecture — because I saw what happens without it
  • Component API design — because I experienced the cost of inconsistent props
  • Dark mode as a first-class concern — because Meshery needed it, not because it was trendy
  • Documentation as infrastructure — because I watched contributors struggle without it

My 2016 CodePen had five colors and no system. My 2026 portfolio has 600+ CSS variables, 19 components, a three-layer token architecture, and an OKLCH palette derived from those same five colors. The difference isn’t talent or time. It’s Meshery — the project that showed me what design systems solve and why they matter.

This is Part 4 of 7 in the Resume Evolution series.