Re: Proposal for a new "Steering Committee Charter"
Derek Collison <derek@...>
toggle quoted messageShow quoted text
I think as the CNCF was formed its vision was to guide an end user ecosystem and to assist projects to navigate and gain acceptance with the end users.
For the end users, they look to the CNCF for guidance around which projects and technologies they should consider. In my opinion these projects should add value and solve a specific problem, be production proven, be security minded, and should minimize risk to the end user who is adopting. I believe our area of concern on graduating status and this email thread is specific to reducing risk to the end user who is adopting a technology or project. I also believe that the list I presented is in priority order, at least for me, meaning that minimizing risk is important but behind the others.
Even within the risk category, I believe looking at this from an end user perspective the things they probably care about are as follows.
Note this assumes basic market forces are at play and that a project is popular or applicable to a large enough audience, meaning users are voting with their feet.
End user concerns around risk
1. Can I continue to use the software as I see fit (no license changes).
2. Is the software supported such that issues and/or bugs are addressed by the project.
3. If the project is missing features will the project ecosystem move forward in a way that aligns with my needs as an end user.
We have #1 covered, so I believe the debate is around #2 and #3 and how the CNCF sees projects that it moves to a graduated status.
This is the main issue of debate. How does the CNCF suggest end users look at #2 and #3.
Right now the guidance is around a fairly specific project profile that does not take into consideration ISV led projects, and more importantly mature ISV led projects. I believe the CNCF should promote a diverse set of projects, including ones that are led by ISVs.
For certain projects diverse maintainers and multi-vendor participation can help with #2 and #3, but it's not black and white by any stretch, even when the project profile aligns well. The idea of a steering committee was to see if we could help with guidance to the end user community on de-risking #2, but mostly #3 around ISV led projects.
The CNCF should be seen as a good steward of the ecosystem and the things end users and project maintainers should be aware of and prioritize, but it should be careful not to be a gatekeeper.
Speaking from my personal experience with NATS, I would like to see more conversation and debate on ways to support ISV projects and companies trying to make a viable business from OSS as something the CNCF wants to support. This in addition to the large multi-vendor projects like k8s. NATS is older than any other project in the CNCF, it has been downloaded over 120M times, so it has been around and even prospered as an ISV led project (although by 3 different companies now). I believe the project and ecosystem have done a good job at minimizing risk on #2 and #3 over the last decade.
For #3 we have been engaging with the ecosystem and providing early access to new features through design docs and early tech previews to gain an understanding of what the end user ecosystem is interested in. That ecosystem can include other large vendors and actually does. We feel the steering committee idea could be a path forward to help formalize that part of the governance of the project and be beneficial to the end user ecosystem.
For the NATS project, and for all projects, I think as issues and bugs and new features want to be added, you always want the best folks working on those problems and care should be taken to not have incentives that go against that outcome. Our end users do not want to fix bugs and code new features, they want the maintainers to do so. Note that many times this is the best use of time and financial resources for the end user. If it is not, that usually suggests a project is not being properly maintained. NATS is not open core, and we have a diverse set of contributors across the board, especially for the nearly 40 different client implementations. But we do lead development and new features for the server, but I do not think this is a bad thing and I do not believe anyone wants to game the current system to progress through the CNCF. I think a steering committee can help formalize a process for #3 to make sure that it's aligned with the ecosystem and that end users (including other vendors) are represented. In the end users will vote with their feet regardless.
My hope is that ISV led projects are an important diversification for the projects that make up the CNCF and that the discussion around how best to support them through the CNCF journey continues.
On Thu, Jul 9, 2020 at 11:04 AM alexis richardson <alexis@...> wrote: