 Hello, plenty of people joining in Liz. This one is yours. So yes, slides seem to be sharing just fine this morning. I know zoom has been having some challenges because reasons. But here fingers crossed. Yeah, give people a couple more minutes to join. I've just seen a couple more minutes to join. Yeah. Because it shams just the email that he's got power outage. So I'll be joining. And you'll keep track of who is with us, right? Running through the list right now. I see Schengen line. I see Brian Grant. I see just in court. Matt. Matt Klein. Brendan, I believe I see you as well. I think by the silence that yes, you're here. Yes, I'm here. Lovely. I wasn't sure. I wasn't sure if it was, you know, But when you don't put the last name in here, it's a little charred. You know, there could be a lot of Brendan. Okay. Sorry. Yeah. Let's just auto fill. Sorry. This is being Brendan. Why was asking all good. And we have Dan right as well. We do. I guess we could, we could get started with the sort of preliminaries. Maybe you can just step through those initial slides about anti trust. We all made it to the conference for Ray. We'll update those. And yeah, so in the last sort of week or two, there's obviously been a lot of. Activity around projects like operator framework and the, the new proposed projects currently called CNCF hub. And it felt to me that it would be appropriate for us to just sort of step back a bit and think about the strategy. For artifact discovery and distribution. So the individual projects. We'll have marriage that we'll want to debate and discuss, but I think we should also just step back a bit further than looking at the individual projects and think about how we want to best serve particularly our end user community. In terms of being able to find and obtain these different artifacts. And yeah, so. I think there's another slide. There's like a header that says the same thing. And then I thought maybe it would be a good idea if Dan just spent a few minutes. Discussing what he had been, well, discussing the project currently known as CNCF hub. Dan, do you want to say a bit about that? Sure. Before we step back, I think I would be appropriate for me to start with an apology where there has been a lot of Sturm and Drong about this, but some of it is quite deserted where CNCF should be operating in the open and was not in this case. The context is that I had organized a meeting in a Kubecon San Diego of some folks from operator framework and helm and Kudo to talk about the idea of CNCF, helping to organize a hub. And I'll just say all of those groups were open to it. There was no, I didn't ask for commitment and they weren't making one. And when I had the opportunity to work with a couple of well respected contract developers and was able to rely on a spec from Matt Farina of the helm maintainer, I kicked that off and the goal was for it to go for about a month and then to make it public. Essentially that got delayed by like another month, a month and a half because of all the issues around Kubecon and needing to delay that. And so that has been problematic. I do want to apologize for it. I have caused a lot of hassle for people, which I did not attend. So the aspiration was to create a project that could become a sandbox project of CNCF. I would emphasize that it's not. I also would propose a name change where I think assuming it is a sandbox project, it's assuming it could become a sandbox project and then emphasizing that this is pre-alpha code. This is not remotely production ready and won't be for many more months and particularly because I believe there's going to be high expectations on it in terms of organizations relying on it and not wanting to break the build that it would be useful to not use a term connected with CNCF. And so I would just go ahead and propose renaming it to artifact hub to also add more neutrality to that piece of it. And if there's not objections, I can go ahead and do that later today. But the aspiration here was to pull in contributors from different CNCF communities that create and distribute artifacts. And the idea is that there's certainly differences between those communities and in terms of the artifacts that they produce, but then there are a ton of commonalities. And I think we can see in something like NPM, which folks probably saw got acquired by GitHub this week, that huge industries like all front-end software in the world seems to often rely on, wind up relying on these kinds of platforms. And then there's a lot of security and reliability and maintainability and updateability and left pad and all sorts of issues that can result from it. And so I do want to emphasize that this is now totally in the open that assuming it does go forward, we very much would like to get contributions from a lot of different folks. And then that our hope would be that it would become a CNCF-hosted project that would have a set of maintainers and work with presumably, presumably SIGAP delivery and then critically would ultimately have an appeal up to the TUC because I think one of the key ideas is a piece of neutrality around it that folks understand they could deal with and such. So that is the background. These links have essentially all the information that's there, the entire repo is open and everything. And so I'll stop there. Hey, Dan, could you explain, is this a piece of software or is it a DevStats like service? Yeah, that's really sharing a decision of the TUC. And I think there was some confusion on that early on. I mean, so CMC has created several pieces of software like DevStats that we offer as a service to our projects and the interactive landscape. And I mean, we have like this minor thing we're working on right now that's going to take a YAML file and a GitHub repo and convert it to a Google calendar entries so that people can automatically schedule and cancel the conferences and such. This seems like a much bigger piece than that. But I think that one of the purposes of this call is for the TUC to decide what it should be when it grows up. But I would just emphasize right now it's nothing. I mean, it's just pre-alpha software. But I think we can have a discussion about it assuming that it did mature. It's a question from Matt in the chat asking, should the architecture and design be shared? Matt, I have a link to it. That's spec linked on the page. Is the document you wrote? Yeah, I'm just not assuming that people have read it and will understand the gist of it. And that's the reason I asked the question of it. Should a quick summary of it be shared here? And I know because people have asked me about it this week because they didn't read it. Matt, can you maybe give two minutes then? Sure. I mean, the gist is when you look at something like NPM or Docker Hub, they are hosts for the artifacts themselves where they're actually uploaded, stored and managed at that location. This isn't that. It is a centralized metadata store for search. And so if you look at what Helm has is the example because it's what's in there now, you have repositories that are hosted in many different places. In fact, anything that conforms to a repository can host it. And so people use the static built-in one that comes with Helm or Chart Museum or JFrog offers this ability. And vendors can host these things themselves. And then this provides a central point where you can register your thing. And then its metadata is pulled in so you can search it. But anytime you get the artifacts or you deal with it, it always goes back to the root source. And so it's more like a metadata search. I think PHP has something like this with packages where they don't host the packages. They're hosted in GitHub and in other places. But it provides a central discovery point for things that are distributed all over the place. And that's how the design is currently built. So it's not meant to take away from vendors hosting artifacts, but provides the ability for end users to be able to easily discover artifacts that are distributed all over the place. Oh, Matt, that does make a lot of sense because I kind of always thought this was more like Helm Hub, which was monocular and kind of I think I was a little confused. It was basically a running instance of monocular. But if it's basically a search engine for artifacts, what in the design have you, what thoughts do you have in terms of how to rank the results? That is a wonderful question. I haven't put much thought into that now. Monocular doesn't do much with that. And as far as the design of this, it's pre-alpha and figuring out how you rank things isn't something that I've put much thought into. The people who've been developing it may have put more thought into it. But there are things like official, you know, if somebody like the MySQL folks put out artifacts that are from them, it would be great if there was a way to note that and bubble those up. It could be usage if we're able to somehow determine that. But at this point, I really haven't put much thought into it. But that is definitely something that should be thought about. Yeah. Sorry, please go ahead. No, go ahead. You were just responding to a question on chat, but that we have two contractors based in Spain who've done the development and been so far been doing the partnering with us. But I do want to agree that I think it's a critical question. My most important focus on the results, I mean, if you just search for, I think MySQL is a perfect example where there's very likely to be multiple Helm charts for installing it. And you can imagine operator framework charts and other formats as well. The most critical one I'm focused on is how are we going to identify and remove any malicious ones that are trojan horses. But then the assumption is that we would be pulling in metadata such as GitHub stars or other kinds of indicators for it and then allow different forms of sorting and such. But I do think it's a really critical issue about how you percolate the quote best unquote option to the top. Thank you. Can I just ask a more general question? So I kind of get all of the all of the issues we had and some of the commentary that's been going on on the main list. Nevertheless, the concept of a service to find packages to cloud native software and to find cloud native software and deploy cloud native software is absolutely fantastic. And honestly, I think it's probably more key to the critical mass adoption of things like Kubernetes and the cloud native software ecosystem than probably many other things that the CNCF is doing. So from a support point of view, you have my full support and I think the support of a lot of people in the community to do something like this. That said, though, if the beneficiaries of this are the end users, shouldn't the end users want just a random list? Do they want a search engine that gives you access to repositories all over the place which aren't verified or curated in any way? And I kind of do really believe that there is an opportunity here to have the CNCF perhaps provide a curated list of different software packages because like I mentioned in one of the emails to the TOC the other week, things like the app repos and the RPM repos that the Linux distributions offer, for example, have been key to adopting Linux technologies. And if we look back at history, you kind of have these moments where mass technologies were adopted and almost all of them have coincided with a simple way to get a curated list of packages and software that ISVs and software vendors and the community in general can participate in that end users can consume. So while I'm completely in favor of something like this, I'm also strongly against just providing a random search engine list. It kind of does need to be curated and that could be the value added to the CNCF is providing. So may I make a couple of comments on this? Curation takes a significant amount of work and effort to do, especially when it is by hand. And if you look at things like the app stores that are out there that do a lot of the curation and put work into it, there's just a lot of work and people that get involved in that whole process. And so there's a lot of work. And if you look at things like the app repositories and the repositories for the different package managers across the different Linux family of Linux distributions, there's a lot of just time that goes into curating those lists. And we over at Helm discovered that it's very hard to keep up with that, especially with the pace of change that happens. For us on Helm, it has become un-maintainable for volunteers to do that work. And so I would expect we'll run into the same problem here if we rely on volunteers. So very quickly burn out and we'll be cycling through them because we've already found that at this scale. You run into that problem. To that point, Matt, I mean, this is exactly how Kubernetes is evolved. I mean, I can speak directly to, to storage. For instance, and having to test that and validate that and having confidence that what we're putting in customer's hands is something that is going to be useful and not potentially harmful to the customer. And I think it's still critical. I mean, essentially the community were all volunteers. And I think, you know, given the interest yesterday in the call, there are a lot of people that are interested in making this, you know, a lively accessible product. And I think if, if it's, especially if it's hosted by the CNCF that, that has a, that's kind of the rubber stamp of what people look to in the industry to have trust in it. So if we're not providing that level, I think that would be very detrimental to, to offering something like this. Yeah. Yeah. No. And I understand that with the whole curated thing, having gone through it, but I think there's, there's actually more to it than that. Because if you curate the list and there's many who are not on the list, then the CNCF starts to become the deciding factor in what's listed and how that's listed. And so of course it's got to be open and documented because we're very open. And then we're going to be debated on who's listed, why things aren't listed, and it's going to lead to a lot of complexities in, in that realm. And so it's going to lead to a lot of work. But then if you look at the ecosystems that have flourished many of them, and if you get outside of package managers, like apt and yum and things like that, and you look at things like homebrew, or you get into the programming language package managers, what they do is they normally provide. Well, everything and they give people the ability, the end users, the ability to decide for themselves and they try to make that easier. So if you look at something like packages, they provide you a ton of extra metadata about each package. And so you may find a bunch of packages that do the same thing, but they give you a bunch of metadata. So you can decide for yourself, do I trust these people? Do I, you know, what information gives me here gives me trust in it. And so instead of the decision being the curators, the decision is put in the ends of the end users and they're provided a ton of information to help them make that decision. Because ultimately it's, if you curate, it's the organization making the decision and not the end users who get the choice or the end users can get the choice, but you need to give them a bunch of information and it's somehow towing that line. And do we, does the CNCF want to be in the position, the people who do the curation, getting enough bodies to decide, these are the things that people, the end users should have here. Or do we want to be in the position of saying, end users, here's what's available. And we're trying to give you enough information so you can make that decision yourself. And for me, I would actually like to hear from the end user community that we have as part of the CNCF, because I'm tentative on a group of people coming together to decide this is what we think you should use and we're going to curate out the others. And I personally fall on the edge of, let the end users make their own decisions. So that's perfectly fine, but I think there is a big distinction between say a software development package, like Humber or the software language type packages, because they are different packages. But what we're saying here is we're kind of doing this global search of metadata and now people can search for EtsyD or MySQL and get back 10 different results for the same package, except they're all different and some are supported and some aren't supported. And there's no way to know that unless you actually install the 10 different things. And again, coming back to the curation, there's no easy way to get that metadata over what's supported and what isn't supported and what's being maintained and what isn't being maintained unless it is curated. And just because it's hard doesn't mean it's the wrong thing. And I think the end users are a higher level than necessarily a developer, right? This isn't a developer looking at code. This is a DevOps guy or a team that need to install a database instance where they need to install some type of software from this repo. They're not actually looking to compare the 10 different ways of installing the one package. They're looking for the right way to install the one package. So I think that the difference here is that at CNCF isn't, I don't think CNCF should be signing up to be a distro maintainer because effectively what you're talking about is a distro maintainer, right? I can install the Ubuntu version of that CD or the Arch version of that CD or whatever. And I choose sort of based on the distribution who I trust. That's how I solve this problem. And I don't think CNCF wants to be in that business. So can we take one giant step backwards? I wasn't involved in these other CNCF projects that help enhance this. I mean, so would it usually start that the CNCF has a list of requirements of what they want to accomplish as an organization and they go out and have that developed? Because now I'm given conversations we had yesterday and on the list, then we were also talking about making this a sandbox project. So are we, which direction are we going? Because a sandbox project essentially can do whatever they want and bring it to whatever SIG is appropriate and go through the normal process. If we're talking about creating a CNCF-owned and managed project, I assume, I mean, is that going to follow the same thing or the two mentioned things that were before this? Were they sandbox projects? I feel like we're like getting way ahead of ourselves talking about what it shouldn't do and we're not even talking about how it should start. I think you could make the same point in reverse in the sense that there are some existing projects. Should we be adopting those as sandbox or should we first try to establish what kind of thing we want to get out of this kind of discovery distribution project? And I think that's why I felt it was appropriate to kind of start having that discussion. There's so many, I think, questions around whether the CNCF should do this and if so, to what extent. I think these points about curation, search ranking, they're extremely valuable. And what I was really concerned about is if we start getting some sandbox projects in, then we'd sort of, by default, be following a certain route or maybe a couple of alternative routes but that we wouldn't necessarily really have strategically thought about what is the best way for our end user community to be able to get hold of these different artifacts. But surely the sandbox is working well. It should be exploring those things with the end users as a discovery process rather than coming in with a predefined view of what it's doing. I mean, is the sandbox is very remitted to experiment and do things and not to have fixed ideas? Yeah, we could very well view it that way. I just felt it was worth trying to, you know, just step back and think about, is this even really in scope? And maybe it is, but we haven't discussed that before. Yeah, it feels kind of weird to me that I think there's two things here, whether there's the need for a more, they combine discovery for health charts, operators and other things. I think one discussion and what we want to have with it, the second one is for me still kind of like this, this process, how this went out. And no offense here, but it feels like some people had an idea. They hired people, they implemented it, and they represented it back, and now we should accept it into sandbox. I'm exaggerating a bit here. So I'm totally with this here. Should be first, but do we want this, that discussion should have started in the open? Should we really take an error and you brought out as well? Take like two steps back. What do we really want? Which value do we want to provide to the end user community? What is the best approach to go forward? And then they find how we want to do this, because even for packages, I can think of a ton of things that run into issues here. There's many distributions out there. How can I test this against my distribution? If there's 10 MySQL operators, some might work against my disk row, some might not work because they're not built properly. How can I even say, please don't install this against, and I'm just taking one here, Ranger or OpenShift. So there's a lot of discussions and taking two steps back and not discussing the project submission first, is the right way to go. If you really have to solve a problem for the end user community, I think a lot of the companies in here will step up and actually help. But so far they haven't been asked for help, really. And I think that's the route that we should be taking here, from my opinion. And we are now asking for help. So I would emphasize that this project is very interested in contributors, in having new contributors and maintainers get involved. So I put up some discussion points that, you know, pulled together from various different people's comments, and we don't have to take these in any particular order. And in fact, Diane just posted in the chat, does CNTF have either the mandate or engineering resources to host the infrastructure for, I guess, a marketplace hub? What's the funding model and resourcing model done? Do you want to speak a bit about funding for this kind of thing? Sure. I mean, the CNTF provides funding for things like Helmhub and the different parts of Kubernetes and such. So I think the key distinction I've seen so far is that if we're talking about a set of metadata that is automatically generated in some ways, for example, is this artifact valid or not, and that it's essentially generated in some sort of CI process, then that seems extremely tractable and very much in line with the kind of project CNTF has funded in the past. If we're talking about the App Store or Homebrew, and we're hiring, you know, dozens of thoughtful developers to pick the best artifact, then it seems completely untractable and not something, I mean, I would question whether even some large companies could afford that kind of thing. So I do think there's different ways of defining the project. I think the real question for me is where is the mandate for doing this coming from? And I know that we have started, there's a small project that you and Matt started here that we, I don't see where the end users are demanding this at this point, and it's good to be forward thinking. I'm not saying it shouldn't happen, but I have not seen anything of a request from the community for this effort. And I think if we could take another step back and really think about whether or not this is something that we ought to be working on and go out to the community and find out what they want rather than starting coding right away, sort of one of the tenants of review requirements first and get... I agree with that question, and that was one of our goals on coming to this meeting today to discuss. Yeah, because I think that the meeting that we had in San Diego that keeps getting referred to was really about having a very informal conversation about the unification of some of the stuff from Operator Framework and Helm, and it was about kicking off some cross-community collaboration. It wasn't really about kicking off any sort of CNCF marketplace, though that was mentioned at one point, but there has been no requirements gathering, no survey of the community, and no request from the community for this effort that I have seen in the public domain. So I'd like to see us take a big step back, do some research, stop coding, and make this into something that actually might be effective for the end-user communities. And I think related to that point is the question of... I mean, whether or not people should stop coding or not, I guess is a question for individual projects. Let's assume that the artifact hub, CNCF hub, starts to behave like a normal open source project. Do we want to... It feels premature to me that we would make an assumption that says there is going to be just one central source for this, but I think that does have consequences for the TOC assessment of projects. So, for example, do we want to... Operator hub at the moment is part of operator framework. Do we want to be acting under a working assumption that that continues as an independent thing, that there will be some kind of Darwinian action that decides which of these different sources should happen, should continue, should be the long-term place for people to discover these things? I think that is a real question for the community. Do we want to let lots of different things try to exist or do we want to set a more central direction? I don't know the right answer. Liz, the principles for the TOC are about letting multiple projects flourish, not making kingmakers, not being a kingmaker. So, I think in your principles, you've already addressed that. Yes, I think that the one reason to pause on that principle is, did we anticipate when we draw up those principles this idea of end-user convenience for finding these artifacts? I'm not saying we should or shouldn't have a central, you know, repository for this kind of thing. I'm saying this has very significant consequences for our end-user community. So, I think it was just a question that we needed to open up to discussion. So, I do have a quick thought on this, right? The foundation's mission is to make cloud-native computing ubiquitous, right? And there's also goals of fostering and caring for the projects. We want them to help grow. We want them to get out there to a wide audience. And this is all baked into the charter of how we can really grow this whole community. And if applications are much easier to install and find and discover, then that makes it easier to just share and spread everything, which helps the overall growth, because right now it can be fairly fractured. And we've seen large growth in the Helm Hub because it's made Helm things easier to find. But Helm isn't the only thing that needs to share. Some, there's projects coming up with ways they need to share their things. There's projects that already have them, like the cloud-native security hub, but that's still disjointed and disconnected and people don't even know where to look. And by making discovery easier, I do believe it's going to help grow the entire space because everything becomes more discoverable, easier to find, easier to use and install and get going with. And that will end up helping the end users get moving more quickly. I'd like to have a slightly differing view on that. I think there are already a number of curated lists of software, right? Helm Hub is one of them, but the operator hub has a certification process. The Rancher catalog has a certification process. Different cloud providers are setting up marketplaces. And those are curated lists and those are genuinely useful to end users. We don't need to do a user survey to know that end users are finding it hard to navigate the landscape. There are too many options and giving them another 10 options to install one software package is not going to be a good thing. In fact, I'd actually argue that that might actually slow down adoption because it makes things harder to understand and it creates this perception of complexity and it actually slows down the sort of critical mass adoption where the technology gets adopted at a layer that doesn't require expertise at so many different levels of the stack. That's the point I'm trying to make here. If we are going to create a discovery service and this is a service, not a project, right? Whether or not we develop the software is another matter. But if we're developing a service that offers discovery, then it's beneficial to the end users. If it's curated and there's some level of clarity as to what the end users should pick. And it's not to say that we should pick just one thing. Maybe there are different packages for different distributions or whatever. That's fine too. But it shouldn't just be a random list of every operator or every helm artifact that's found in any GitHub random repository, right? There has to be some level of curation because at the end of the day, if we're going to do this, we're offering a service and this is not a project. It's a service that the end users are consuming and we know the end users are already confused by the state of the landscape. Nobody looks at the landscape picture that we put together because we allowed everybody to go into that and says, oh yeah, now I know exactly what to do. Nobody says that, right? So if we're going to offer a service, it needs a bit of curation. I just wanted to point out that an example would be NPM. NPM has no curation and it works quite well for people because of what Matt said about the metadata. So when you're going to load an NPM package, you look and you see when was it last updated, how many other people are using it, what's its license, and it's relatively easy to make a decision. So I don't think that curation is the great goal here. I mean, you could have a separate thing that does curation, but curation for an artifact repository is just not the right goal. So I don't think any artifact repositories actually do curation. Except for the marketplaces, I guess. But the marketplaces are a different kind of beast. I mean, I think that does. Yeah, I think, I mean, if you look at, I mean, Docker Hub has a curated path and a non-curated path, for example, I think it's quite common. Docker Hub doesn't have a curated part. Docker Hub has images. The official images are, the official images are curious. Yeah, it's a curated path. Well, that's more about provenance though, right? I mean, it's more like, oh, I trust Docker or I trust whoever made the, I mean, the fact that Docker. That's a form of curation. I mean, it's a form of curation. It's not. I think it's more like making the maintainer up there. It's not really curation. So even if it's not curation, Brendan, would you agree though, if someone, so this is always from four years ago, this has been the issue is perception. And when people go out to the CNCF and they look at the landscape, and this is why we've had so many arguments over sandbox, people put their trust in this foundation that when they publish something that it is a good choice that it's been, you know, the due diligence has been done. There's some level of curation that, that they can trust that. So I think there's a matter of, if we provide this service, that people are putting their trust in us. And how much do we want to ensure that their experience and what they're using it for? At least from Alex and I's talk, we've done at various cube cons. So I think that's a good point. Every single talk, people come up and say, I don't know what I'm supposed to be using. How do I know when I'm supposed to using this storage technology versus that storage technology. And we actually have an effort in this thing to kind of create these patterns and use cases to help people navigate it. I have no disagreements with any of that, but that's not the job of an artifact repository. And you may be completely right. I'm just saying like, what is, that's fine. I mean, but I think that if you look at like Docker hub as an example, you're going to be confused about the fact that you shouldn't trust anything on Docker hub, or at least that you should make sure that you understand who the publisher is. You know, before you decide if you trust something. Right. And I think that if you build the right kind of index, sorry, I was great. If you don't want to index people know that it's just an index. Aaron, you were cutting out there. Yeah, I didn't mean to interrupt my internet connection is, I'm sorry, Brennan, I just, I would like to not have the same perception as Docker. I would hope that when people come to us, but no, but I mean, I think I'll go ahead. I was, I would hope that they would have a level of trust that when we. Put something out there, we're standing behind it. So whether that's curation or certification or whatever direction we want to go. I just want to make sure that's a fundamental idea that that is the perception. I guess, I would think, I think that it's, I think, I don't disagree at all. I think it's a good idea, but I think that there's a distinction between an index or a repository for discoverability, which is not something that I think really provides that versus a publisher, which, which is. So if CNCF decided to publish a helm chart, for example, or CNCF decided to publish an operator, then I think you're absolutely right. People will expect that it's supported and all sort of thing, and it should be. And so if SIG storage or whoever decides to say, hey, this is the, you know, this is our operator for this database, then absolutely people will trust that and they should. But if we're talking about discoverability search, then I think the job of search is to, you know, is to provide you with the results, all of the results and let you decide. And obviously, you know, when you get into questions of ranking, then we actually have to take a certain amount of, you know, authority into account. But we're not talking about ranking yet. And so I think I just, I want to make sure that we don't conflate, you know, the discovery and search parts of the problem with the publishing and therefore the reliability and authority parts of the problem because they're distinct. I think kind of related to that reliability part of the problem. Ken was making some interesting comments as an end user in the chat and saying, you will never meet my security requirements. Ken, do you want to just elaborate on that a little bit? Ken, star six to unmute. Hi Ken, if you are. Sorry about that. My company is shut down on non-essential communication. I have to use my like my personal phone for these calls now. They don't consider CNCF and essential use of my job. So sorry. Trying to navigate things on the cell phone is not easy as on a computer. Yeah. So the, um, so, you know, end users don't, um, we don't, you know, we don't get confused as easy as you guys think we do. And we have a business that we're trying to support and, and, you know, things like fraud and analytics. Um, aren't hard to figure out what we need to do. And so for the most case, um, our requirements, we do not, whatever you think you're going to curate for us, isn't going to be curated enough. So we're going to curate it ourselves. No matter what you guys try to provide. Um, having a single place like the, you know, the CNCF hub would be great because then we'd have, you know, at least, you know, one less set of, of things to have to try to curate right now. We have about 17 different pipelines that go out and curate for 17 different artifact repositories. And then itself is not hard to solve for and something we solve for it, but, you know, having a single place for this type of use case, I think it makes a lot of sense. That's great feedback. Uh, I think like it'd be nice to just, it doesn't seem like people object to this initiative. So I'd really love for us to talk about how to kind of move forward, but then also leave room later to kind of build on these requirements, uh, with specific end user surveys, like can just provide it really good feedback. Um, so maybe if we could find a nice MVP to, to agree on, we can just move forward from there with hard data from end users on, on what features we really want to support. And I was about to, um, to chat on the chat message that Cheryl is on the call and she hosts a, um, end user, um, meeting every week. And so we could, um, you know, bring this up as a discussion point, um, in one of our future meetings and provide, you know, some real time feedback to you guys. That'd be great. Absolutely. That would be great. Yeah. Yeah. I think you know how to get in touch with me already. I'm really happy to connect to you with a bunch of end users or invite them to join a future TOC call. If that's easier and give feedback in this form. Yeah. Well, very, well, very, very adamant on the no key makers type of, um, you know, um, Charter that we developed in the CNCF. And so I don't, I don't believe any of the end users are wanting to make or trying to provide any sort of feedback that would allow any sort of key making to happen. And so I think in general you'd be very, you know, pleased with the hype of, of interaction and, um, feedback that the end user community can provide in this area. Uh, this is Matt Farina. I'll take the action to reach out to Cheryl to set something up with the end user community. That sounds good. Yeah. There is one other sort of group of constituents that I think we should just be aware of, um, you know, that our vendor community are part of this. Um, I guess I just want to flag up the concern that, you know, everybody is going to want to own a bit of this. And I am very concerned that we make sure it, it maintains its neutrality. And if we're going to have a single point of, uh, discovery that it's, you know, I think we're all on the same page about trying to find a neutral way to, to present these different artifacts. Um, but I did just think it was interesting that, you know, the fact that Docker owned the, the Docker hub and were able to, you know, maintain that site and continue to maintain that site was probably an instrumental part of the success of container images, Docker images. So I just, I, I wonder whether anyone has any thoughts around the impact of this on vendors and whether it's a good thing. And it may well be a very good thing. I just wanted to raise it as a discussion point. I think actually though that the presence of the Docker hub kind of put a chill in the ecosystem to a degree. Because it may have been good for Docker adoption. Maybe, maybe, but I think a lot of ecosystem people saw it as Docker putting their, their sort of thumb on the scales to try and lead people towards their product. Which was not good for it, which is not good for the ecosystem. And so with us, I think having it in CNCF is better because it means there's a hope of neutrality. Yeah, I guess we've ended up in a situation where it's now being maintained by, you know, a company. But it did turn into a free way for lots of people to, you know, I think we should distinguish between two parts of the hub. I think one is the free image repository, which I think was very great. I think the other piece was Docker's decision to make their own images sort of privileged within the hub. Which is, I think probably not good. Right. So like the only, if you do Docker run MySQL, that is the only way that exists is with the image that Docker control. It would be great to capture those concerns Brennan so we can avoid slipping. Sure. Yeah. I mean, and I know Joe, Joe beta and others are some of the people who really brought up this concern a long time ago with Docker about how like, I mean, and I think Helm would have the same problem, right? Like one of the good things in Helm three is that you have to install every Helm repository via URL. There is no, you know, Helm stable, whatever isn't just sort of built into Helm. And that's so that again, you don't put your thumb on the scales. And I think if you look at any of the good package managers that are truly open, this is true. Like apt, like apt, you have to have a file that lists all your repositories. It's not like it goes to Ubuntu or Debian by default. And, and I think one of the challenges with NPM historically has been that that wasn't true. And I'm sort of optimistic that now that it's part of GitHub that's going to potentially change. But I think those are some principles that are really important about, about sort of not having the tool be too tightly bound to any particular repository. Yeah, I think that's a really great point. I agree. So what are we doing next? Liz. So I, I think this has been hugely helpful and productive discussion. Was there anything else? I guess there was a kind of community call from yesterday. Was there anything else that came up yesterday that maybe the TOC should be aware of? Well, there is one thing, right? So there's been the discussion early on of, should it be a service or should it try to come in and structure as a sandbox project? And the call yesterday we were leaning in the direction of a sandbox project and run it like a CNCF project. But it is also similar to the services like dev stats and things like that. And there's just so many services the CNCF offers. And so I figured it was probably worth hearing the TOC's thoughts and getting some direction on that since you all are the ones who make decisions about sandbox projects. That point. I guess my initial sort of feeling on that is that it's probably easier to go from a sandbox project to a service than the other way around. So perhaps while we're still in this early phase and you probably don't want to be signaling too strongly to users that this is in some ways sort of blessed yet. Maybe sandbox is the better experimentation approach. Yeah, I would think so. I mean, Dan specifically said it's pre-alpha and no one should use it at this point. So I don't see how we could possibly agree to run it as a service at this point. And given that there's so many outstanding questions about what kind of things it should and shouldn't do that are quite fundamental, I think it makes much more sense for it to apply as a sandbox project. The other part of yesterday's conversation was also that if we ran it, if it stood itself up as an open source project that it could be something that CNCF ran as a service or someone might run and stand up internally as a service behind their own firewall. So if we created this project in a way that it could be deployed anywhere and CNCF just created a service out of it that might be a way forward here too to help folks like Ken and others who aren't allowed to trust a service provider like CNCF or Docker Hub for their compliance. And just to reiterate Diane's point that's how it already is set up that the software is all Apache 2.0 and can be running independently. And then CNCF would be running a privileged version of it or a well-known version of it but not the software wouldn't be any different. I think that's a great point and sort of learning again from history, Docker registries and so on people being able to run their own instances would be really valuable. Yeah, I think that for me part of the I think the curation conversation here is a really good one. Also the testing and the CI CD pipeline behind it. We've had lots of conversations with people around the operating framework and testing and certification and how important that is. So getting that right in the infrastructure is going to be key. And I think that might take some reframing and rearchitecting of the existing code base. I just wanted to say that running a service is actually very time consuming and it takes a lot of resources so yeah, so having that choice for people to run For people to run the service internally in their own, in their own organizations, I mean, it would be great. But, you know, thinking about like hosting repository repository for everyone around the world, you know, you something like that, you know, CNCF would do what required a lot of resources and, you know, something that will be able to handle like large scale deployments right so So maybe that will be something that could be used for certain types of users that wouldn't require large scale, but if you want something to have reliability and, you know, redundancy and all those different type of production type of things, you know, having that choice to run it in their own private networks or their own cloud will be great. I guess it's also possible that people could take instances of the project and, you know, host their own public versions for particular types of part of that if they say chose Right. But, you know, you look at Docker Hub, you know, they, they were being used by so many people around the world right so and then I would imagine Docker had like this massive infrastructure behind it right so and and that's what I'm getting at like, you know, having something like that requires massive scale. Yeah, and I think the one difference here is Docker was actually hosting all of those images and those large files and so they had to do so many things because they're doing the hosting that and this is a lots of artifacts are distributed all over and this is a centralized metadata search, and it doesn't do the actual hosting so it isn't holding all of the helm charts for example, or other bits that are going to come in after the helm charts. Those are hosted by others. Many of them are vendors, and that really lightens the burden, because it's essentially a metadata search which takes a lot less resources. It doesn't one caveat of that is the possible introduction of any number of broken links. And how quickly that metadata is refreshed and the hub updated, given that that won't be a well it'll be a curated but uncontrolled experience in some respects. Just just something to watch out for it'll be eventually consistent dependent on update cycles and catching and notifying. If somebody for example has they've said here's a group of assets that need to be listed, and we've detected problems. How do we unlist those how do we notify people that there's problems because many times they're accidental. That's all just in building that out and building out the user experience not just for the end users, but for the people who list their things to be curated as well. With three minutes left in the hour I just wanted to briefly touch on operator framework because we put that assessment somewhat on hold, so that we could have this conversation more broadly. In the remaining three minutes does anyone have anything they want to say about it. Operator framework and what we should be thinking about in terms of that project. I mean I think we're hearing it's no king making. I'm not here. I'm here from a seed. We are a security company and I mean operator hub is considered as the North Star or very cool concept of operators but I'm wondering like from a security perspective like what kind of the diligence was made around you know introducing components into that in some cases. It's a kind of sense but in some cases it's a nonsense. And, you know, speaking here on CNCF hub and the resemblance into operator hub would be interesting to hear like what's the to see perspective on that. Along the lines. I was going to say that. Having had all this discussion the TSE sort of owes the community a description of what our goals are for this kind of stuff. I mean I have no problem with just putting all, you know, put all the hubs into sandbox just like we've put lots of other competing projects into sandbox, although, you know, so it's a TSE decision, not one person decision, but I do think also given all the sort of discussion we owe the community a description of like, this is what we're thinking about. I think it was going in as incubation. And I think it was going in as incubation. Yeah, and that's a higher bar then and so yeah. Absolutely. And, and we should definitely Would one one consideration maybe I mean, you know, just an idea maybe splitting the operator hub out from the other parts of operator framework and then because I think it would send. I think that's I think that's a great idea to Yeah, and I think we talked about that at length as part of the zig zig apps discussion and I don't think that was contentious say but but would it be worthwhile since we've had this very long thread going on in the PR to maybe be back with the project and clarify any misconceptions I just think a lot of things have been lost maybe in that I think maybe the TSE needs to have a discussion. I think, you know, I think at this point TSE needs to have a discussion and owes a response back. Yeah, completely. And so why don't we set a goal. Liz, how do we set a goal of getting that. Oh, sorry, someone else is talking. Yeah, so this is others from the secret deliveries. I think the operator people have been waiting for quite a while so I think, giving us some attention right now it's definitely the right time just what I wanted to point out and if we can get this. And one of the next to see me that would be beneficial I think it has been almost for me to four months that they have been waiting. Yeah, I think we've I mean, I think we should probably just commit to doing any private TSE email thread and get it sorted and, you know, by say the end of the day tomorrow, something like that. I don't know. Liz, what do you think. Should we say this week and then this. Yeah, I feel like that puts like not quite enough pressure on everybody and we'll let it. I'll take quite on it. Great. Great. Wonderful. Thank you. All right, I think this was really productive and helpful. I hope everybody feels good about this kind of getting some of this out in the open. I'm sure we'll be talking more. But thank you very much everyone. All right. Thanks everyone. Bye.