+1 thanks Eduardo
Quinton
I understand and I think agree with the principles, but I don't think the details are clear. Let me list some examples.
1) Nats has non-Synadia maintainers & core maintainers. In the event of Synadia stepping back for any reason, maintainers could also step into core roles.
2) Let's say that Synadia added 3 more core maintainers from end user firms. Would that lower the risk of project failure? In which scenarios? (eg funding, capture, deus ex machina) How would the LF and CNCF be able to help? In my view a key VALUE ADD of CNCF should be to help Nats succeed with current governance *and* provide non-market mechanisms to help Nats in extremis. Users should be reassured because of what CNCF can and will do in the event of Nats hitting difficulties.
3) Which projects are most at risk and why? * CNCF Nats * CNCF Envoy * Hashicorp Vault * Hashicorp Nomad * Apache Kafka
-
alexis
On Thu, Apr 2, 2020 at 11:46 PM Eduardo Silva < eduardo@...> wrote: ...about NATS towards graduation:
Maintenance of a project is critical, we all agree on that. Now I think is important to consider in the equation "which other companies contribute to the project"; I see the following contributions in the NATS devstats dashboard:
Contributors are:
1. Synadia 2. Independent 3. Cruise 4. Codiicon 5. Global Nuclear Fuel - Americas 6. VMware ...
I see the project has a lot of traction and joined incubation two years ago, in addition, I found NATS it's pretty similar to Fluentd: a strong core with several individual/companies contributing to different components of its ecosystem, with ecosystem I mean SDKs and other stuff.
Nats-server is primarily maintained by Synadia and Google, while the nats-operator has another maintainer which is not related to Synadia (per my understanding):
Despite I see one company paying the bills and supporting the majority of core maintainers, I see other external maintainers. The project was started in 2014 and it has a lot of traction since then. I am sure there are hundreds of end users, but I doubt they have an interest in to become maintainers (the same thing happened on Fluentd)
I think the project and its ecosystem is very healthy, at least I see serious companies already vouch for it.
regards,
On Thu, Apr 2, 2020 at 1:49 PM Quinton Hoole < quinton@...> wrote: Regarding requiring multiple maintainer organizations for graduated projects, specifically: Alexis: "Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation. For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project. Is it then risk-free? NO. So what are we trying to
achieve?"
I've also discussed this at length with the NATS folks. I'll repeat the essence of the conversation here. I don't think it's about being 100% risk-free. But let's face it, if only one organization is de-facto maintaining a project, and that organization decides to no longer do so (of simply ceases to exist), then users of the project may find themselves in a bad situation. Given that this sort of thing happens a lot (organizations changing strategy and which projects they fund, and startups disappearing) the chances of this happening are high. The intention of requiring more than one maintainer org, is primarily to bring that probability down significantly.
So the ultimate litmus test is, in my opinion, what are the chances of the project ceasing to be effectively maintained? One simple argument is that there are 3 maintaining organizations, the chances of all of them defunding, or ceasing to exist, is sufficiently low. IMO, if there is only one maintaining organization, particularly if it is a relatively small organization, then the probability it unacceptably high for us to label the project as Graduated.
On Sun, Mar 29, 2020 at 12:12 PM alexis richardson <alexis@...> wrote:
Please can I put in a word for Nats, and its backers. I think many
others are in a similar situation or could be.
Some projects have a core that is driven by a single vendor (ISV). We
need to make sure that ISVs have a happy path all the way through CNCF
- and an 'end game'. They are a vital source of innovation, software
support, community creation. Their posture to OSS projects can be
different from Big IT, eg it can be less inhibited.
Historically foundations have been good at creating a way for big
vendors to work on one codebase, alongside a community of individual
contributors. Long may this continue.
More recently CNCF and to some extent CFF have worked hard to bring in
End Users, as we call large companies who are not in the business of
selling software or SaaS, but who can make it (much) better through
their use of that software and iteration therefrom. This is Fantastic
and for me a key step forward CNCF has taken eg with great projects
like Prometheus, Envoy and now Argo that come from end user tech
firms. Innovation can now come from end users *and be driven into the
mainstream*.
But there is a fourth "leg of the table" in this new level playing
field of Big IT, Big End Users, and individuals. That leg is ISVs
(and SIs) who may be backed customers and/or VCs. We need these ISVs
and their backers to be actively investing in the foundation, or they
will find a way to exist independent of the commons. Our loss is our
community's loss.
Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation. For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project. Is it then risk-free? NO. So what are we trying to
achieve?
I'm just throwing this out here to start the debate. I have failed to
find a clear set of answers on my own or in conversation with others
who care about this.
alexis
On Sun, Mar 29, 2020 at 6:11 PM Dan Kohn <dan@...> wrote:
>
> Thanks. Added as slides 127-128 of https://docs.google.com/presentation/d/1JnK8XKxFV2xQJT_fumzUedLhscP-w0CZ-Qs8URjbCG4/.
> --
> Dan Kohn <dan@...> +1-415-233-1000
> Executive Director, Cloud Native Computing Foundation cncf.io
> dankohn.com or book on my calendar: dankohn.com/c
>
>
> On Sun, Mar 29, 2020 at 12:51 PM Liz Rice <liz@...> wrote:
>>
>> Hi everyone,
>>
>> Looking forward to meeting with you all tomorrow. We have two slides (minimalist design!) highlighting the TOC priorities we'd like to discuss in the joint GB-TOC session: https://docs.google.com/presentation/d/1xhuwdKfkh1ROGk_JE6n0mf9xHOWKNFeKeRFGFirHHoY
>>
>> Hope everyone is staying well,
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>
>
--
--
Eduardo Silva
Principal Engineer | Arm
.
. . . . . . . . . . . . . . . . . . . . . . . . . .
m. +506 70138007
Arm.com
Treasuredata.com
 
|
