Three years ago, I was part of a team responsible for developing and maintaining Kubernetes clusters for end-user customers. One of the primary challenges we faced was downtime caused by failures in image registries. The standard solution involved setting up a stateful mirror, but budget and time constraints often made this infeasible. During a particularly stressful Black Friday, our Kubernetes clusters were hit with a surge of traffic while GitHub container registries were down, severely limiting our ability to scale. This incident led me to think about more efficient and less resource-intensive solutions, and the idea for Spegel, a peer-to-peer (P2P) image sharing solution, was born. Spegel quickly gained traction within the Kubernetes community, addressing the need for reliable image distribution without a stateful component and minimal operational oversight. My role as the sole maintainer was both rewarding and demanding. I dedicated significant time to community requests, bug fixes, and security updates, helping the project grow and solidify its place in the community. In the span of two years, Spegel amassed over 1.7k stars and 14.4 million pulls, demonstrating its value and popularity. Things took an unexpected turn when Microsoft reached out, expressing interest in Spegel. The initial meeting was positive, and I was optimistic about the possibility of collaboration and onboarding new maintainers. I continued to engage with a Microsoft engineer, helping them get Spegel running and answering architecture questions. However, over time, communication dwindled, leading me to assume that work priorities had shifted. My concerns were confirmed during KubeCon Paris, where I attended a talk about strategies to speed up image distribution. The talk included a discussion on P2P sharing, and my excitement grew as the speaker mentioned Spegel as a P2P image sharing solution. What surprised me was the introduction of Peerd, a Microsoft project for P2P distribution in Kubernetes clusters. Peerd's README included a thank you to myself and Spegel, suggesting that Microsoft had drawn inspiration from my project. Upon closer inspection, I discovered that Peerd was not just inspired by Spegel but was a direct fork of the project. Function signatures, comments, and test cases were identical to those in Spegel, including references to my previous employer. The project was maintained under Microsoft’s MIT license, creating a situation where large parts of the codebase were copied directly from Spegel without proper attribution or acknowledgment of the original source. This development had several negative impacts. First, it created confusion among new users, who often compared Spegel and Peerd, asking about their differences. As a maintainer, I tried to be unbiased and factual, but the contentious history made it challenging. Second, Microsoft’s brand recognition overshadowed Spegel, making it difficult for the project to gain prominence. I felt demoralized, questioning the value of my contributions and whether continuing to work on Spegel was worthwhile. Despite these setbacks, I persisted. I enabled GitHub sponsors to fund the ongoing development of Spegel, and the project continues to thrive. However, this experience has raised broader questions about the dynamics between individual open source maintainers and large corporations. How can smaller, independent developers ensure their work is respected and not appropriated? The recent changes in HashiCorp's licensing and the decline in investment in open source projects have only exacerbated these concerns. The Kubernetes community, in particular, has faced challenges with the rise of corporate involvement. Projects like Spegel, which start as community-driven solutions, can quickly be overshadowed by corporate efforts. This imbalance not only affects the visibility and growth of individual projects but also undermines the trust and collaboration that are foundational to the open source ecosystem. Industry insiders note that this incident highlights the need for better guidelines and practices in corporate collaboration with open source projects. While the MIT license permits forking and modifications, it does not condone the removal of original attribution. Companies must be more transparent and respectful of the contributions made by individual developers. This includes clear communication about intentions and changes, as well as efforts to contribute back to the original projects. Microsoft, known for its significant contributions to the open source community, has a responsibility to set a positive example. The forking of Spegel without proper acknowledgment not only disrespects individual contributions but also risks eroding the collaborative spirit that has driven the success of many open source projects. To maintain the health and integrity of the ecosystem, it is crucial that major players like Microsoft adopt more ethical and inclusive practices. In response to this incident, I am considering changing the license of Spegel to provide greater protection against such issues. This step, while not a panacea, could help mitigate the risk of exploitation and promote a more equitable environment for open source maintainers. The future of the open source community depends on fostering a culture of mutual respect and support, where contributions from all sizes and backgrounds are valued and protected.