In this episode of The AI Kubernetes Show, we talked with Troy Connor, Senior Software Engineer at Microsoft and a maintainer of Porter and Kubernetes controller-runtime maintainer (two CNCF projects), about the balance between enterprise work and open source contribution and the impact of AI on software development and community maintenance. This post summarizes our discussion, live from KubeCon in Atlanta.
This blog post was generated by AI from the interview transcript, with some editing.
Connor shared how he manages his life as an enterprise software developer and an open source maintainer. For him, it’s not a balancing act; it’s just part of the job. Contributing to and respecting the software he uses is an integrated part of his professional role. This contribution actually makes his day-to-day work much easier. By engaging with the software we consume, he gets to influence its direction, and that feedback loop improves how the business uses it—that's powerful!
It's also incredibly valuable to have contributors from various places so they can bring their diverse enterprise mindsets to the open source project. This diversity is essential for a healthy project.
Connor gave an interesting example of how enterprise requirements can actually push open source forward. For example, many existing Kubernetes controllers are built on the controller-runtime package. As Connor and the other controller-runtime maintainers tried to actually use it to solve internal problems for their enterprise projects, they realized that controller-runtime lacked capabilities that they needed, so they added them – and these new capabilities which they added from their own self-interest became available for the wider community, gained traction, and became valuable for everyone using the project.
When discussing the role of AI in development and platform engineering, Connor likens it to adopting new workflows, where we need to learn how, and how much, we can trust them. The classic trade-off of AI is whether it helps or hurts a developer's output. But ultimately, it all comes down to the developer's existing expertise. For tasks that are already well within a developer’s wheelhouse, they simply don't need to lean on AI. They don't need to trust the AI because they already know what they need to do. That kind of domain expertise means the AI is a nice-to-have, not a necessity.
Where AI really shines is in accelerating the learning curve for unfamiliar territory. Take a seasoned Go developer who wants to pick up Rust. They can fast-track their learning because they can skip the tedious part of figuring out basic syntax. They can ask the AI, "Hey, can you write me a function that shows me how to do the Fibonacci sequence in Rust?" This allows them to focus on understanding the language's core semantics and structure a lot faster than slogging through documentation.
Connor provided an example of how AI can fundamentally change how development teams handle testing and continuous integration (CI). The traditional development workflow involves writing code, writing tests, and then pushing it all to CI, where a ton of resources are spent running those tests. The new, AI-driven workflow allows developers to gain much greater confidence before the push, “moving it left” by using AI's inference capability to shift testing earlier in the cycle. This means we don't have to wait for everything to build in CI, which ultimately saves money on resources.
This shift also addresses the infamous "works on my machine" problem. Instead of blindly pushing and hoping, developers can leverage AI to simulate other environments or, at the very least, analyze the code and try to predict what might fail before it ever reaches the CI pipeline.
The conversation about AI adoption always boils down to two camps: the "full speed ahead" crowd versus the "I don't want change" folks. But the resistance isn't necessarily about being afraid of AI; it's often about integration with existing tools.
People have built many tools and systems they're comfortable with. The challenge isn't a fear of the new technology itself, but figuring out how to blend it seamlessly with what's already working. If you can't easily integrate new tooling with current workflows, or if you’re trying to push ahead but you’re getting results that aren't predictable or reliable, that’s often best understood as a failure of integration. The key is making the new tools fit the existing process, not forcing a complete overhaul.
The rise of AI brings new challenges to open source governance and policy. When it comes to contributions, the community is figuring out what it means to accept a change generated by AI, especially since an AI can't sign a Contributor License Agreement (CLA). The current strategy is to keep the human developer responsible for the AI-assisted contribution, ensuring someone is accountable for the change. This isn't just theory; organizations like the CNCF clearly see the value in AI, evidenced by their provision of tools like Copilot to enterprise GitHub users who maintain projects.
A major topic that the open source community isn't discussing enough is accessibility. Connor sees AI as a potential lever to make contributing to open source much easier for everyone. While consuming open source software can be fairly straightforward, actually contributing to it often involves a steep learning curve. Without tooling like AI, maintaining projects becomes unnecessarily hard, creating a higher barrier to entry for potential contributors.
Beyond simply lowering the bar, AI offers significant relief to maintainers battling burnout. Think about offloading those initial review tasks. AI can handle the first pass on contributions, giving maintainers the trust to delegate that work and focus their energy elsewhere.
For organizations that are looking to adopt AI, especially within an enterprise setting, easing the change process requires a balanced strategy. They need to "walk slow but run fast." The key is making the initial changes slow and deliberate to build trust and confidence in the new tools and processes. This trust starts at the top. Leadership needs to clearly articulate the value of AI and explain why this shift is important in the interim, setting policy that guides the adoption and establishes a foundation of certainty.
Troy Connor can be found on:
Enterprises that "give back" by supporting employees who want to maintain a project can influence a project's roadmap. That was the case for controller-runtime. Maintainers noticed limitations while using it internally; though improving the situation started out of self-interest, the new capabilities rapidly became available for the wider community.
For tasks already well within a developer’s expertise, they may not need to rely on AI but can use it to boost productivity. AI truly excels in accelerating the learning curve for unfamiliar territory, enabling a developer to quickly grasp the core semantics and structure of a new language.
Shifting testing and inference "left" by leveraging AI to build more local behavioral determinants reduces the necessity of running all tests on CI. This saves resources that would otherwise be wasted on tests unlikely to pass.
.webp)
