A few years ago I stopped writing here. Not because I ran out of things to say. Work got loud. Conferences stacked up. Open source work filled the nights. The site sat there while I kept doing the work instead of writing about it.
That was a mistake.
This is the reboot. Same domain. Same person. Different emphasis.
Why now Link to heading
I have spent more than twenty years in technology. Most of that time started in .NET and Microsoft shops, then moved to cloud when those tools became first-class citizens there. I never really left that path. Cloud Foundry. Kubernetes. Helm. Home labs. Modernization projects. Community work.
What changed is the center of gravity. The interesting part is no longer just the stack. It is the people who keep the stack alive.
Open source does not ship because a company published a slide. It ships because maintainers review PRs, users file issues, docs get rewritten, and someone stays in Slack long enough to help the next person through a bad upgrade. Community is not a marketing channel. It is the product.
I want this site to reflect that.
What this blog is for Link to heading
The tagline on the homepage was: developer, DevRel, community caretaker. Now it has shifted slightly to Experienced Technical Executive, Cloud Native & Open Source Leader.
Going forward, writing here will lean on four things.
Technology. Practical writing. Clusters, charts, platforms, developer tooling, and the decisions teams make when they try to modernize without burning the house down. Less theater and more of “here is what I learned.”
Open Source. Helm, Kubernetes, CNCF projects, and the unglamorous work that keeps them usable. Packaging. Governance. Docs. Release cycles. The difference between using open source and taking care of it.
Community. How communities actually work. How they stall. How they grow new contributors and maintainers. What happens when a project is popular and the contributor bench is thin. What “community” means when it is not a booth, a Slack badge, or a conference party.
Thought Leadership. I dislike that phrase, but the idea is simple. Say the thing plainly. What DevRel is and is not. Why communities are not the same as customers. Why numbers are a weak substitute for trust. Why leadership in this space is mostly service. If a post does not help someone do the work, or think more clearly about the work, it does not belong here.
What I will not do Link to heading
This will not become a highlight reel.
I already wrote that Developer Relations is not about the person writing. That still stands. I will use “I” when a story needs a point of view. I will not make this a personal brand machine.
It also will not be a sales pitch. I have worked across companies and products. Some of them I like. Some of them are not ready. Honesty is the only way this stays useful.
What you can expect Link to heading
Shorter posts when a single idea is enough. Longer posts when the subject needs room. Occasional technical walkthroughs. More writing on maintainer health, contributor growth, and how companies should show up in open source without swallowing the project.
I am going to treat this site as a workshop again, not an archive.
If you have been here since the Raspberry Pi posts, the .NET anniversary post, or the old DevRel piece, welcome back. If you found this because of Helm, KubeCon, or some Slack thread, start here.
The blog is open again. The work never really stopped. The writing is catching up.