Why build OSS
as an engineering practice?
The goal is not to collect repositories. OSS is a way to turn real platform problems into reproducible systems, verify them in public, and keep the lessons reusable.
Software becomes useful when the seams survive.
Platform engineering problems rarely live inside one tool. They appear between identity and RBAC, Git and runtime, PVC and storage, ingress and service mesh.
OSS makes those boundaries visible: the code is inspectable, the setup can be reproduced, failures can be recorded, and design choices can be compared over time.
Start from an operational problem.
Leave a reproducible implementation, not just an explanation.
Continuously verify integration seams and failure points.
Evolve through releases and visible development history.
Publish reusable documentation and engineering standards.
What the work optimizes for
Not stars, repository count, or technology breadth. The target is durable engineering evidence.
How evidence is measured →Someone else should be able to rebuild it.
Success and failure need visible signals.
Commits and releases should show change over time.
Lessons should survive beyond one repository.
OpenForge
Turn repeated OSS decisions into reusable standards.
Narwhal
Integrate identity, delivery, networking, observability and storage as one system.
Beluga · KubeMetal
Test the platform against data and AI/edge constraints.
Why OSS explains the practice. Story explains the evolution.
If you want to see how my engineering judgement evolved from framework work to platform engineering, OSS, and AI-assisted development, continue to the Engineering Story.