Getting Forked by Microsoft

Summary

Three years ago, I was part of a team responsible for developing and maintaining Kubernetes clusters for end user customers. A main source for downtime in customer environments occurred when image registries went down. The traditional way to solve this problem is to set up a stateful mirror, however we had to work within customer budget and time constraints which did not allow it. During a Black Friday, we started getting hit with a ton of traffic while GitHub container registries were down. This limited our ability to scale up the cluster as we depended on critical images from that registry. After this incident, I started thinking about a better way to avoid these scalability issues. A solution that did not need a stateful component and required minimal operational oversight. This is where the idea for Spegel came from.As a sole maintainer of an open source project, I was enthused when Microsoft reached out to set up a meeting to talk about Spegel. The meeting went well, and I felt there was going to be a path forward ripe with cooperation and hopefully a place where I could onboard new maintainers. I continued discussions with one of the Microsoft engineers, helping them get Spegel running and answering any architecture questions they had. At the time I was positive as I saw it as a possibility for Micorosft to contribute back changes based on their learnings. As time went on, silence ensued, and I assumed work priorities had changed.It was not until KubeCon Paris where I attended a talk that piqued my interest. The talk was about strategies to speed up image distribution where one strategy discussed was P2P sharing. The topics in the abstract sounded similar to Spegel so I was excited to hear other’s ideas about the problem. During the talk, I was enthralled seeing Spegel, my own project, be discussed as a P2P image sharing solution. When Peerd, a peer to peer distributor of container content in Kubernetes clusters made by Microsoft, was mentioned I quickly resea...