Life Without Kubernetes

We continue our discussion of what would the environment look like without Kubernetes? We started with the idea of what if Kubernetes went away, what if there was a copyright or a trademark or an API issue that made us have to abandon Kubernetes altogether?

In this episode we played what if scenarios, exploring what made Kubernetes unique, and if parts of Kubernetes or parts of the architectural model could exist outside of Kubernetes? What would be necessary?

We identified enough parts of Kubernetes individually where we saw how it itself is an interesting convergence of some core technologies. Nothing new except in the combination of those architectural paradigms, designs and open source models. Through this, we dig into why Kubernetes is so powerful in the market.


Kubecon Retrospective

Klaus and I go through what happened at the Kubecon North America event in Detroit. Specifically, lessons learned in watching how the community reacts to new technologies like CRDs, declarative programming, and cluster APIs.

We also discuss the health of the community and the operators and vendors who were involved.

We give our impressions and insight – this conversation deep dives into practical use and futures in Kubernetes.


Project Mgmt Vs Development Process

Our discussion about development methodologies quickly turns into one about product management methodology.

Those things are interlinked, and we spend a lot of time talking about how product management and the influence on user and operational experience has been transformed by the forces of the market. We also discuss how difficult it is to then organize team development processes to fit these quickly evolving, targeted product delivery challenges.

It’s a fascinating conversation about just how interlinked our development process is to the way we consume products in general.


Successful Vendoring in Open Source

How can we make Open Source go faster, and how can we improve its interaction with vendors, especially hardware vendors?

We explore different ways that open source helps foster innovation, as well as where it creates ethical, financial, and legal conflicts in that process.

Thinking through how we want to bring vendor information into Open Source communities is an ongoing challenge.


How Open Source is Like SpaceX

What makes Open Source projects work? Today we discuss open source business models, motivations, what and how these projects work.

We moved from that into testing quality maintenance and ultimately SpaceX and Tesla. This conversation dives into how Elon Musk is transforming the industries that he’s in by looking at the delivery process.


OSS, Promotions, and Lava Lamps

How can promotion boards be hostile or hurtful to open source technology? We talk about the dynamics of corporate support in open source technology, and if being rewarded for internal work at companies translates into challenges for open source technology.

This discussion starts to peel apart what makes open source technology sustainable, and what it works for. We bring up an analogy of a lava lamp where things heat up and then cool down as part of a natural cycle, which can be a normal cycle for all software, and that led us back to how promotion boards work.

We covered a lot of ground through the dynamics of corporate software governance and open source and interweaving those together.


APIs With Composable State

What makes API’s complex? In this episode, we talk about how we compose APIs into higher level systems, and how we think about the design elements that go into building durable, reusable API’s.

This is a classic topic for us, and in this discussion we looked beyond the API itself and started talking about the state of the system and how you manage that state.


Reliable License Models

We talk about software licensing in open source, and what it means to the broader market. In fact, we cover how it’s changing what the market actually is!

This is not not just open source licensing in general because at the end we didn’t care about the license. We are more concerned about utility, serviceability and operability of the products we use. We need to understand whether or not we can rely on them!

In short, the supply chain of the software was much more important than the licenses of the software


Software Supply Chains [#Log4Shell]

Our scheduled topic was supply chains generally, but the Log4Shell vulnerability dominated the discussion. We dove into the challenge of patching and fixing a library that is literally in nearly every device or service for years and years.

That led us to supply chains in the context of software, and specifically Java Log4j. This is a critical topic and our conversation about it was very thoughtful. We really covered the angles of what it takes to produce and maintain a supply chain for software. Then we discussed alternatives and things to consider when you building anything: software products or physical products in which embedded systems and components impact your designs.