Why I'm Building Open-Source Tools for Platform Engineering

After years in enterprise cloud engineering, building open-source tools is a deliberate career strategy. Here is the reasoning.

The Gap

Platform engineering is booming. Every company with a Kubernetes cluster needs tools for incident management, CI/CD optimization, and infrastructure automation. But the open-source options are either too simple (just a dashboard) or too complex (requires a dedicated team to operate).

There is a gap between "run these three kubectl commands" and "deploy a full observability platform." The tools being built here fill this gap: single-service agents that solve one problem well and integrate with existing infrastructure.

Why Open Source

1. Portfolio over resume. A recruiter can read a resume bullet about cloud migration. But they can look at source code and see exactly how the author designs systems, handles errors, structures code, and thinks about production safety. The code is the interview.

Feedback loop. When building internal tools, feedback is from one team. When building open-source tools, feedback is from the industry. Different teams have different infrastructure, different failure modes, different constraints. This diversity makes the tools better.

AI agents are the future of platform engineering. Tools like KubeHealer, IncidentBrain, PipelineSage, and CloudShift will be table stakes in the near future. Starting now means having production-tested implementations when every company is looking for this expertise.

The Approach

Each tool is a standalone Spring Boot service. No monorepo, no shared framework, no vendor lock-in. Each tool solves one problem: KubeHealer fixes K8s incidents, PipelineSage optimizes CI/CD, CloudShift automates migrations, IncidentBrain correlates alerts. They are designed to coexist, not depend on each other.

IP Disclaimer

All open-source projects are built entirely on personal time, on a personal laptop, using no proprietary code, data, or internal tools from any employer. The ideas come from publicly available knowledge, industry best practices, and personal engineering experience. No employer's intellectual property is used in any of these projects.