Hello everyone, I am writing to discuss the current status of Apache OpenServerless and the concerns raised about its potential retirement.
At first glance, this situation appears unusual: the project is not inactive or lacking contributions. On the contrary, development is ongoing, with regular contributions across the operator, runtimes, and related components, which represent the core of the system. Activity has continued as recently as this month. However, I understand that the concerns raised are not about activity, but about alignment with Apache processes and expectations. I would like to address these points directly. *Communication channels (Mailing Lists)* It is correct that the mailing list is not the primary communication channel used by contributors. In practice, most contributors interact through platforms such as WhatsApp, LinkedIn, Discord, and via pull requests. This is not a matter of preference alone: many contributors are simply not accustomed to mailing lists, and participation tends to happen through modern, real-time platforms. As a result, discussions often occur outside the mailing list, with the mailing list not reflecting the full extent of project activity. At the same time, I recognize that mailing lists within Apache serve an essential purpose: ensuring transparency, traceability, and an archived record of decisions. If required, we can work toward summarizing and reporting key discussions and decisions back to the mailing list to improve alignment with these expectations. *Release process* Another concern raised is that the project does not produce releases in the expected Apache format. >From a practical perspective, the project *does* have a release mechanism. We provide a downloadable installer, introduced early in the project, which allows users to install and continuously update the system: curl -sL n7s.co/get-ops | bash ops setup mini Updates are delivered continuously, effectively resulting in frequent incremental releases. This model reflects how many modern developer tools are distributed today, prioritizing ease of installation and rapid iteration. However, I understand that Apache requires formal, versioned source releases for reasons that go beyond distribution convenience, including legal clarity and reproducibility. Technically, producing a source archive (e.g., a tarball with a version number) is straightforward. The challenge lies in what that release represents. *Complexity of source releases* Apache OpenServerless is not a single-component system. It includes multiple elements (operator, runtimes, images, and supporting components), each built and updated independently, primarily through CI pipelines. Rebuilding the entire system from source in a fully reproducible way is significantly complex. It would require reconstructing a coordinated build process across all components, potentially without relying on the existing CI infrastructure. Given the limited resources typical of open source projects, building and maintaining such a system represents a substantial effort. We do have volunteers willing to work on this. However, the complexity is such that there is currently no clear or agreed approach to achieve a fully reproducible end-to-end build of the system. *Core issue* The situation we are facing is not a lack of activity or commitment, but a mismatch between: - Modern development and distribution practices (distributed contributions, CI-based builds, continuous delivery), and - Established expectations within Apache (mailing-list–centric communication and formal source releases) Conclusion It is difficult to accept that a working and actively developed system may need to be retired primarily due to this mismatch. The ecosystem has evolved significantly, and complex systems like this one are no longer easily represented or distributed as a single source archive in the traditional sense. The key question, therefore, is whether a practical alignment can be found—one that preserves the principles of the Apache Software Foundation while acknowledging the realities of modern software development. I would appreciate guidance on whether the adjustments outlined above could be considered sufficient, or whether the gap remains too large to reconcile. Michele Sciabarra | CEO m: +44 747 984 8388 e: [email protected] l: https://linkedin.com/in/msciab Nuvolaris Inc | 1209 Orange Street, 19801Wilmington DE - US www.nuvolaris.io linkedin.com/in/msciab
