Cloud Native Computing Foundation Technical Oversight Committee, 19 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF TOC Meeting 2021-10-19

Description

CNCF TOC Meeting 2021-10-19

A

Good morning, everyone's taking a few moments to be able to come on in hello, hello,.

B

Good morning,.

A

Liz couldn't do that mic check again. I was not quite.

C

Sure yep, that was all I don't.

A

Want to lose listen here, that's terrible.

A

I know saad isn't going to be joining us, but um we also don't really require quorum for this particular meeting as it's going to be a discussion and um I really hope no voting, um so I would be very surprised liz if you come up with something to vote on then.

D

I think so too. um So, let's see if I can find the.

C

Deck, I know you'll be sharing it anyway, but if you can post a link to it, that would be great.

D

Thank you done.

C

All right do you think we're ready to get started. We got enough yeah, we can rock and roll welcome. Everyone hope everyone's fitting, both energized and recovered after kubecon.

C

All right, so I think the main topic for today is the devsecops end user radar, uh which I think a few people. Actually it's justin here. Yes, indeed,.

A

C

How you're feeling better um and ricardo- and I and I think, a few others sort of had some opinions on this radar. So I think, maybe, if we go on to the next slide, it sort of illustrates what it is that we're talking about.

C

um I think so. The end user radar is currently something that's handled entirely outside of the toc community by the end user community, and uh I guess some of what I'm going to say is probably just my own opinion, but um I think a lot of these have been really useful and and give us some insight into what end users are really adopting in the real world.

C

But when it came to this particular one, uh certainly I had some concerns. I heard some concerns from other people um and I think we need to have a conversation about how the tic community, like what value we would like to get out of these end user radars, how we could potentially.

C

Exit, I mean we're a technical oversight committee, so perhaps we should be exercising some technical oversights and making sure that these radars actually make sense uh as they get published. Particularly you know they're getting published in the cncs name. We should you know. Ideally we would all be aligned and have confidence in these radars.

C

um So I think I wanted to just make sure we had the opportunity to air concerns about these and maybe try and think of some constructive ways that we could engage with the end user community to you know to go forward and make sure that we're producing good versions of these things.

C

um So I think the next slide has some of the concerns that we sort of, and I would love to hear if other people disagree or if they feel that um you know we're missing things, then you know this could certainly be. A discussion should be a discussion.

C

I believe that the fundamental source of issues for this particular radar was the scope in the first place.

C

um I think devsecops is such a broad scope that it's not very clear which projects would or wouldn't be included in that there's a lot of different solutions in that radar that have some kind of association with security in a very loose sense. But I don't think it really serves very well to compare github solutions against key management solutions or cni plug-ins against ci cd platforms and that's what this particular radar seemed to be um presenting.

C

I know that when they brought up the whole proposal of the end user radar, it was a deliberate decision not to include not only to include cncf projects. I think that's great, because it means we may get exposure to some other projects that we're not really aware of, and it gives us some ideas about what maybe is missing from the cncf landscape.

C

But personally, I do not believe we should be promoting commercial products in these radars and I think, as a kind of corollary to that, we should be very consistent about whether we're including vendor names in those radars.

C

So some of those projects, if we just skip back to the the previous slide, amy yeah, so there's some things in there that are open source projects. There are some things in there that are commercial products. There are some things that additionally have a vendor name associated with them.

C

I mean yeah hashicorp, a big fan of hashicorp, but why do they get to have their name associated with vault and sentinel, where jfrog doesn't get to say jfrog for x-ray as an example? um So I feel like there needs to be a a kind of sense check on these radars when they're published.

C

So I think those were the concerns I had about that particular radar and ricardo dims. You've got your hand up. Please.

E

Oh, I can wait for ricardo to go first.

C

F

Yeah, sir, can you hear me.

C

F

Just do a disclaimer. I have my son here with me. So if you hear some shouts, you know what it is I was. I was just gonna say um yeah. I agree with what liz said. uh I would also say that one good thing I find in this user raiders is that we get like a kind of uh dump of what the end users are actually focusing on which products they're actually uh focusing and coming back from kubecon last week.

F

One thing I noticed is that there, even if we have like a mix of different different projects here, there is some value here to see.

F

For example, a lot of people are using things like argo and flux, and they would probably traditionally do something like subs to encrypt their secrets when they're doing git tops- and it's so kind of mixing things together, and one thing that I saw is that a lot of people started using, for example, argo with volts and they suddenly start doing like rotation of their passwords uh just for free um and and it's it's a huge improvement instead of just encrypting and get their one-time passwords and basically never changing them. Now.

F

Suddenly, there's a solution that allows them to to do like constant rotation of the passwords without having to focus on this, and when I look at this uh like multiple projects uh like I I agree with. Ladies, like argo and and and all these other projects in the same like diagram, it's kind of confusing, but but they do start mixing in in the ways and users focus on them.

F

uh One of the things that came out in when the in the discussion, video of this end user radio was this uh that the focus on devsecops was actually at the expense of developer experience, and maybe maybe these things are kind of helping. I I don't know it's just. um I agree it's a bit confusing, but they do start giving some value by connecting to each other.

C

Do they give value through this diagram or is there value from combining? I? I don't think that this this diagram really tells us anything about using vault, to store secrets for our ocd.

F

Yeah, exactly no, it doesn't come out out of this, but but they do like when combined- and maybe maybe it's just not expressed properly having them like as single bullets. Maybe maybe we should say more like what is used with what not just thumping names down.

C

Dimms, you had your hand raised before.

E

Yeah um I was trying to figure out if there is a github repository where they assemble this, and you know just like you know, landscape. We have a github repository where prs are made, um so I couldn't exactly figure out how this came about or how this specific set of things came about and whether that process is, uh you know open where we can go in and chime.

F

So we answered that. Yes, this is a form that is sent to the end users and it's basically an excel sheet where each end user puts a column for themselves and then they for each of the products there. They say the level assess trial adopt for the ones they actually touched, and they can add new lines if new cells, if they they have other products too.

E

Got it, then, then, the follow-up question record would be like how did these names came about uh that ended up in the form right like so what? Basically I'm looking for like what was the transparent process where we as cnc, uh the toc, could insert ourselves to provide some feedback at some point before it gets published. That was basically what I was looking for.

C

I think that is at the heart of the problem. I don't think there is such a yeah.

F

Such a point right now.

C

G

I think you were next yeah, I mean, I think, that um I think the process of people just adding things that they lump into this area is just a little bit weird.

G

I mean, I think that, like if people, if this was stories about how people had learned to do, you know devsecops better by using these tools, I would it would be really exciting like if, if, if github actions has helped your dev and security and ops teams work better together, that's a that's a great dev setup story that I'd love to hear, but it's just this, uh as I said previous, just the um the kind of us just having access trial adopt as being the only data just makes like it just makes it a really weird list of things that appears to be fairly random.

G

You know it's just like you know it's different things. These are not fulfilling one purpose at all. There are lots of different pieces of infrastructure that um you know it's not it's not clear to me that devsecops I mean you know I kind of given up on devsecops being a being a movement or or about people anymore and but but even if you think it's about tools, it's a really weird set of tools, um but I'd love.

C

G

I'd love to hear people's stories about how these made their devsecops process better.

C

And adam making the point in chat, but isn't that more of a problem with the definition of the category and I, as I said it began, I completely agree. I think that the choice of category is or the scope of what these things are is unclear. In this example harry you were next, I think, and then matt.

H

Yeah, yes, so, first of all, I just want to share the same feeling with justin and I think the first impression I saw this radar as a user. I want to fit. I want to say it's more, like some kind of recommendation. For example, if I want to adopt the dev security ops practice, I will definitely look at the adopt section. I will say: oh there is argo city, there's opa, there's terraform, but I think the issue here is: there are many projects here or many products here that that are actually have very wide scope.

H

For example, terror form. It's not guaranteed that if I adopt terraform, I can adopt the best practice of the dev security arts and also this kind of issue. I think also applies to many projects like istio, like various github actions, it's still very hard for the user to get. How can I practice these dev security? Ops philosophies?

H

Even I saw this picture right so that that is one thing that I'm thinking about. Maybe we need more five grand um items in this project. For example, I think somebody mentioned that by reference by referencing github actions- maybe we are talking about github, actually, security module or something like that, instead of the whole github action thing. That is one feeling when I first saw these the names in this reda yeah.

C

Matt, you also had your hand.

I

uh Yeah I mean I concur with much of what's already been said, uh but in addition, just you know if I didn't have context right, if I had just heard about the cncf, but I was into open source and I saw just this slide. What does it tell me right? Does this mean that the toc and or cncf says I should only assess linker d? It's not really ready for me to adopt. Even though linker d is you know a graduated project and foundational, you know for some for many technology stacks right.

I

You know mtls everywhere, like that's a great building block, but does this mean that I shouldn't use it yet because it's not ready, like you know, you could very easily get some very interesting takeaways in terms of like what does the toc suggest? I do to secure my cloud native systems, so I think in addition to everything else, that's been said uh you know. Maybe you know, I think it's an opportunity for folks to contribute- and you know in terms of like optics and just overall messaging visually like so.

I

Every slide should be able to stand alone, and this one is highly ambiguous for me in in a number of different ways.

C

Yeah agreed and- and I think the point you make about uh the implication that the toc thinks this and we don't at the at the moment- have any yeah involvement at all.

I

C

I

Disclaimer, this is not from the coc. Yes, of course, of course I just mean like. I would just want to highlight it as an opportunity for folks for the background, and you know how to do this and what the nuances are. This is a wonderful opportunity to to contribute and to broaden our tent and to bring on new new voices to to help with these this kind of of uh of an issue so yeah, I don't mean to win a rant. I just I want to highlight it. It's an opportunity that we have.

C

That makes sense alex you're next.

J

Oh yeah, um so, apart from you know the ambiguity- and this particular one because obviously defcecops is- is a weird conglomeration of different technologies.

J

um I think the challenge is: how do we, because this this this some of the issues you mentioned around you know commercial companies versus open source- and you know who's contributing to um the list of products in the first place is, is not something which is specifically just this radar, but it's also something that maybe happened in some of the other radars you know, and and should this even be a cncf technology radar as opposed to the ccf end user group radar, and you know, what's the sample size and how many people are contributing as well.

J

You know so if, if 20 organizations which are particularly vociferous in a particular area, are contributing to to this list, it doesn't necessarily mean it's the generic list for everybody, um in fact it might, it might actually be a misrepresentative sample right. So the way it's branded right now it makes it look as if the cncf is endorsing this and I and I think, that's a fundamental problem, because the cncf is not endorsing it and it's not actually involved in generating the list other than facilitating the forum with the end users.

C

Yes and bob making the point that the site and and if you looked at the uh the link that someone posted earlier with the methodology that quite consistently calls it the end user technology radar, cncf and user technology radar. But then the uh the image does not. I'm not quite sure where I pulled that image from. But it's very it implies that it is representing the view of this cncf.

J

Right and and and the issue with that ambiguity is, of course you know, then it gets misused in 101. Other marketing blocks all over the place right.

C

G

It you downloaded it from the link at the bottom on the radar page where it says download png os.

C

G

You're right, I did and it's different from what's displayed on the page. Yes,.

C

Bob's also posted uh an older one, the secrets management one, and that I think, is a really interesting contrast, because it is much more, you know concentrated on actual secrets, management solutions.

C

It does again include quite a lot of uh commercial tools as well as open source. I don't know whether that is something that we should be concerned about, whether we should I. I certainly have a concern that if the cncf is seen to be giving kind of a free, free promotion to some vendors and not others that will so bad feeling- and I know it does say a bad feeling, because some of that bad feeling has been expressed directly to me by some of the vendors.

C

uh Ricardo aravani, you have your hand up.

B

Yeah, so I I think everybody talked about you know how this is very broad and I think most of us agree that may not be that useful for end users. So I think the next I'm thinking of the next steps it would having like a process uh where the toc and the attack um engage with the end user uh folks in the cncf from the end user community to um to improve this or to to to help out right.

B

So they'll have some some some way of engaging or maybe having some way of saying you know before this is published. Can it be reviewed by the tfc or by the tax.

C

Yeah- and I think erin suggested at the uh right at the beginning of the call yes aaron, should we have the tags that these before they're published, which is.

K

I think I guess if we have it as the cncf tech radar for sure, but if we want to just change it explicitly to this is what users are using, and this is their experience outside of the cncf. It's a blessing. I don't know I'm kind of no matter what we publish, even if it says cncfn user group, it's still going to be associated with the cncfs. I think it's hard to detangle that relationship.

C

Yeah, I agree. I wonder whether one of the good points we could try to get inserted or you know insert as a technical group. You know whether it's the toc or the tags um right at the beginning, where an end user group is picking a particular area to focus on.

C

Maybe the the tag or the toc could kind of just sanity check that the scope makes sense and maybe propose a list of projects that we think should be considered, because I think somebody else made this point that the way it works as users fill out the survey or the spreadsheet, they can add new projects.

C

So, if you're the last person to fill in the for the sheet, you might add something that actually everybody else is using, but it wasn't on the sheet when they filled in the form- um and you could imagine that actually significantly affecting given the small sample number that could really affect the uh the outcome so maybe having a hopefully pretty knowledgeable group pre-populating that spreadsheet, with a set of projects that we think should be under consideration, might help.

C

Matt, you have your hand raised.

I

um Yeah, I think um so I participated in the end user uh radars as an end user, uh and I think they are very valuable and, and your assessment that folks can just add things is correct. I think perhaps we need to do two things really and to reiterate what you had said earlier, liz which I I fully agree with. You know the technical oversight committee can express some opinionated technical opinions which it does through.

I

You know the whole projects, but perhaps if there was, you know this in its current form as a as an adoption uh metric or an adoption radar, uh you know what are people actually doing and if a project name is there?

I

That might you know to me that means that they're running the project directly themselves via leveraging a vendor, and I think it's useful to understand what vendors are being used out in the community to to you know, do to have the market that we hope to build and we have built where open source projects fuel an ecosystem of you know competitive friends right right that are leveraging the same underlying technology. So perhaps the toc you know should additionally produce a radar where the only thing on it are projects right.

I

So you know we say hey for devsecops, which I agree is a tortured category, but for category name you know we, the toc, think that these projects and highlighting graduated and particularly relevant incubation projects to me, would be like where I would start so that technology, leaders and architects that are crafting their own solutions using these technologies have some guidance. You know at a high level about what the the landscape of building blocks and legos is. If you will so, um I think filling that vacuum versus trying to make the one radar all the things.

I

uh My my might again be an opportunity. You know to to expand the tocs um perception as more concretely useful to solutions solutions. Builders.

C

Yeah I'd love to find a way that we can kind of get content, because I completely agree it's very useful to get an indication from end users about what they're actually using, but it would be really great if we could get consensus over what even falls into the same category. I think.

G

We do have categories in the in the landscape: they're, not perfect in any way.

C

But they exist.

G

And they're maintained, and they have a list of projects in with with reasons why projects in there.

C

So that would be one possible ask would be to say to the end users.

C

Perhaps you could concentrate your and concentrate your themes on either an area from the landscape or possibly even a subset of an area from the landscape.

I

Yeah, we could also empower them right, like we could actually just generate this. It wouldn't have to be subjective. It could be driven from the landscape, just a more zoomed in view at a particular sector that might be cross-cutting or maybe if the categories don't fit, but so these end-user technology, radars or adoption radars might be prefaced uh with you know from the toc, like a format like a you know like for this sector. Here are the projects. These are the graduated ones, the incubation ones sandbox. I.

C

I

I think probably not, but I don't know but at least to preface the discussion and then here are you know the ecosystem of vendors, which are thriving in an expanding market right uh that that are that are being adopted, and then it's not subjective. It's just it's data useful though.

C

D

C

A question of why and maybe just because nobody thought of it, um but why the end users didn't start from a selection of projects that were together in an area of the landscape.

I

If I could just be so bold I'll mute after this and go back to raising hand, but I think the reality for many end users is it's difficult to assemble the talon or the the bench that has the capacity on top of you know, keeping the lights on to really go deep and do these assessments? That's why, as an end user? For me, probably the most useful artifact has been the uh due diligence reports for incubation and graduation right.

I

But but you know many of my colleagues just it requires a base level of technical complexity and a deep enough technical bench to do those you know start from the projects right. So it's a a quick start here would might really accelerate.

C

Amy, I think I did have another slide that had some broader ideas for things. We could do. Oh, no, that.

B

Was right, it was just.

C

Other considerations about.

B

At least one comment that I had about this is that you know having a separate uh raider for open source project may not be necessarily the best, because there's a lot of gaps in the the open source projects and the cncf I mean they're, I mean, and some of those apps are covered by some vendors.

B

So I think it might be useful to to show that some of those things are going to be covered by vendors right. So um but yeah just a comment.

C

Yeah, I think somewhere, obviously um specifying which ones are open source and which ones aren't as part of the the radar. That sounds pretty useful to me.

F

Maybe one thing we could do also like taking your your sentence during the slide about getting the toc community input into the end user radars. One thing that would be useful is also the other way to have more input from the end user radars into the tlc community, because all these interactions between the different projects and how they are used together would be actually very constructive uh to to to better understand the landscape.

F

C

F

In the projects that that, in the scenes here.

C

Yeah, I actually think that's one of the potential things that we can learn from these radars is, you know where we see there are non-cncf solutions. That's super useful input for sure.

C

So I think, in practice, some of the things that I've heard people suggesting- and I think these make sense- were um that at the start of this process with end users- um maybe the the ts, I'm just going to say the toc community- I I don't know whether it devolves to tags or how we do that, but that we could kind of help preface that that end user discussion by saying okay, if you want to look at I don't know, I'm just going to pick storage here- is what we currently have on the landscape for storage.

C

This is the set of projects. This is how we currently see them from a sandbox incubation graduation perspective.

C

Maybe there are other projects, you would also add to this set of projects, um but use that to kind of seed, the the set of projects under consideration, um the labeling of whether they're open source or not- and again that could be done. You know in the spreadsheet. Couldn't it there's this.

C

You know, I think, we're we're at risk in some cases of ending up with the open source project and the commercial implementation of that project, potentially even being in different parts in the radar, and that would be kind of odd.

B

Yeah and there's also the concern that you know a lot of companies have their open source project and then they enhance the open source project. You know like open core right and they enhance the project, then to make it a some solution that they can actually charge for.

B

Do we want to specify that there in the radar or not or um but that that will go beyond like the scope of what open source is.

J

I mean just at a more generic level, though you know if the end users are voting. What they're using that may have sub overlap with the cncf in terms of projects that the cncf is involved in, but actually the overlap might be minimal in many areas. Right I mean it. I I don't think it's necessarily a given that the radar is going to be cncf projects.

J

I mean it's going to be they're, probably going to be products from vendors or from projects which are in the broader landscape, but that doesn't necessarily mean they're cncf projects and in fact, that probably just anecdotally hasn't guessed that half or more easily or not cncf projects right to me.

J

So so you know, that's that's where, like the whole king maker thing comes into play right because effectively, the cncf ends up promoting things which aren't even cf projects.

C

C

And I suppose, if I'm a if I'm a cncf project, and I see a competing non-cncf project being promoted by the cncf, I may feel somewhat aggrieved.

C

Matt, you have your hand again.

I

uh Yeah, I mean, I think, in terms of the king maker, concern one way potentially to ameliorate that, but also you know set. What we do want is that the cncf's, really you know, they're deliverable, if you will their value, is, is fostering the ecosystem of vendors that are using these projects in all manner of creative ways.

I

So as an end user, you know what I really look to from the cncf, you know is to say, okay for the vendors that might deliver value to my business, with whatever level of ux and optics and and usability you know is valuable to me, based on my needs as a as an end user. um You know I want to part of my diligence.

I

You know, as a decision maker is to ensure that the vendors that we're using um happily right, because it's hard to run some of this stuff or it's complicated whatever um uh that they're in alignment with the overall, like open standards and and protocols and core technology building blocks, so that you know fast forward a few years. I'm not you know having business critical things. You know that are not that are then reliant on something: that's not in alignment with the overall architectural and technical roadmap of the cncf umbrella and family.

I

If you will so you know, for me, it's an opinionated thing from the toc doesn't mean like we're. Making it's not a king maker thing like thou shalt use this or we we bless that. But it's here's. The building blocks that come from this open source communities that we're fostering and then here's the vendors that are using these in overlapping in different and creative ways.

I

um uh That's that's still in alignment with the overall trajectory of the cloud native ecosystem, uh and so I think it's nuanced, but the governance piece you know really is providing the framework. Like that's the output, that's the value of the toc to to let the whole thing exist.

I

You know with some guide rails, so I don't know if it's messaging or if it's just making it clear that you know the first said.

I

Maybe the preface that comes for all of these radars is like here is the here's, the source, material, that these vendors pull from in the form of project, and then some of those projects can be used directly and are, and others you know can be used by having somebody else run it for you or delivering sort of a batteries included approach, but but understanding the relationship between those two kind of building blocks and concrete usable.

I

You know by a business today. Now I I think you know is more than the sum of either of those two parts right put together.

D

I

Like that would supercharge the radar did you know what I mean, and it would make it like a go-to. You know, and then that like feeds this virtual cycle that that expands the breadth, um you know of the cncf in in a way that meets people's needs, where they are people being end users, and you know that feeds more vendors and all of it.

B

But isn't that sort of like landscape in a way or maybe landscape has something that the radar doesn't or the landscape is too broad? And the radar is just kind of like this uh yeah.

I

Like kind of workshop.

B

I

Yeah that first part is like a filtered subset of the landscape right, you know if you I actually made it. I actually put this in, and I talked just a coupon last week you know like, like the the eye chart of the entire landscape. It's just it's like it's too much to rock it once so. It's not perhaps used as much. You know I would advocate. You know minimally as a starting point.

I

Just like make a filtered subset, that's auto-generated that generates all of these radars and then they're just available as a as a template framework. You know to the end user radar efforts, which I don't want to disparage right. You know they're, wonderful, they're, the best data point. I've got.

C

Yeah- and I I don't want to- I don't want to end up with it. Looking like the toc is trying to force the end user community into a certain opinion that they don't actually hold. I just feel that we well yeah in in this particular example, we probably would have suggested a different focus and we might have suggested some additional projects and I'm sure we would have used the landscape as a as an initial point to see that- and I think, maybe not even just the landscape, because there might be.

C

You know, projects that the tags are aware of, and it would be really I'm thinking, for example, of run time where we know there's a ton of wasn't projects, kind of bubbling up and and knowing whether or not end users are looking at particular projects.

C

Out of that set might be really interesting, just as an example um but yeah I feel like we do need to seed seed. Some of this dims.

E

um So uh as an organization we, you know, uh you know the end user, community and toc and other people, what we have in common is the landscape, which is structured information that we have. uh I think, if the end user community doesn't see stuff that they are using there, then it should be added to the landscape and then uh making it complete and then, like matt was saying there should be like a filter.

E

On top of that, which is what is called the radar right now, but it is actually a survey right like it is. No, it is uh the it is a reflection of what people are doing right now or what uh people are thinking end users are thinking right now and it's not like a recommendation going forward either right like it's where they are right now in terms of like yes, some people have adopted issues, some people have not and it reflects what they are using right now.

E

So if we shift it around to say, hey, look. The here are the end users. This is the landscape out of this landscape. Here is the list of things that they're using, and these are the things that fall into different categories right, so if we set it up that way and showcase it as the current cncf end users, this is what we got from them. This is what they're, using in the uh you know in their day-to-day work, rather than you know what it is right now.

E

So, if you can change it around in in this case like whether it is uh the tags or the end user, all they will make sure is that the landscape is complete and then any um you know voting. um You know stars whatever is on top of the landscape uh and a subset of the landscape, which can then be published periodically right.

C

So they would potentially be running the survey based on a section of the landscape right.

E

Or they could pick like multiple sectors too, like this year, we're going to do storage and we're going to do um observability, for example, right like and have two radars published um and.

C

I think it could be smaller than that. Potentially I thought secrets management was really interesting because it was a subset of what we right. It's almost.

E

Like magic, quadrant kind of scenario right, like so.

G

C

If so, maybe this is a question for um end users, like ricardo or matt, having been through the process of these end user radars? Do you think it would work to start from the landscape and work from there.

F

I I can say something: I think it would work, but we would lose this this additional feedback of like things that are not in this ncf, that end users are integrating into their deployments um like this. This would be maybe valuable input for for everyone, actually um what I, what I think would be great would be to have more information than just adult assessed trial, but this is uh maybe an um like a demand for the end users. That would probably reduce the number of replies.

F

If there's like too much effort to start writing these things right now, it's quite quite quick to go through this process. Maybe that's. Why also the results.

C

So maybe the answer is to start from the landscape or section of the landscape.

C

Have the ability for the engineers to add these additional things that we're not currently listing for whatever reason, and then we can look at that and say well, should we be, should we be adding those.

I

Yeah, sorry, I had a bluetooth kit uh problem yeah, I think, starting from a subset of the landscape, maybe not like to me it's less important that it follow the lines and the categories in the current landscape um you know, but over time. I would think that we could use. If there's a big difference.

I

You know, then perhaps we want to make more sub-categories in the landscape, but but but certainly starting from just like these are the set of projects, because it can be a lot right like if you, if you have to come up with a platform and a roadmap, you know and then put it into production and into practice, meaning your onboarding skills on your teams and whatnot. um You know it can be hard to keep track of all the things in all the sectors that you're responsible for.

I

So I really think again if, if there were just a data driven, you know these are the these are the these? Are the things in scope for this sector? You know as liz and others had been talking about. um That would provide that that context and a mental model, and you could actually think of visualizations. That kind of like show, like you know, like a node graph.

I

You know with with with fan outs, you know for what vendors are leveraging, which technologies and we could even engage vendors and they, you know just like they're, proud to say, I'm a cncf member and a vendor. You know they they're they're, proud to say I contribute to this project for that project. Right, um that's something in the in the tag observability we we have as a work stream. That is, is no small feat.

I

So if there was sort of some top-down guidance to meet the bottom-up grassroots efforts already underway to make those mappings a little more clear, then you know it could be. You know, here's the context, you know and then here's the end user radar, which is again easy to generate and low friction for the reasons that folks had said.

I

You know that that can remain it just the first part of it shows that mental model, so that, when someone looks at that radar, they they can kind of make the connections uh that that that they need to make about what's important for them right, which technologies are are more or less important to the bottom line of the business.

C

Thank you, yeah alex. You have your hand.

J

Yeah, so I actually think linking into the landscape might be a good idea, but I think the key thing in all of this is going to be about the quality of the data and that's both in terms of you know which products get looked at, whether they're open source and commercial and whether they're on the cncf landscape or not, and secondly, who's providing input to those surveys, because it's it's not just the number of end user companies, but it's also who, in those end user companies we're polling.

J

You know so so, if there's a nominated person say for some of these companies, which I suspect is how this runs.

J

Then some of these organizations are huge organizations with potentially tens of thousands of engineers, and it's you know it's unlikely that any single person is actually going to know exactly what's happening in all the whole organization anyway.

J

But the the key thing is, you know if it's these um these end user radars are valuable. If, if somebody can look at them and actually make useful decisions based on this- and I think that's the value of polling, the end users, because we find out what the end users are actually using.

J

But if if on the one hand you know, the data is maybe too specific or too focused because we're not pulling the right people or we're not including or excluding the right projects, then it either becomes too broad or too focused, and then people don't find that useful. So so this is. This is part of the equation.

J

The data is the most important thing and how we keep it up to date, because, if you're going to go through the you know, if you're going to go through the phase, where you're actually saying these things definitely use, and these things only evaluate, then we should probably also specify some sort of review or at least get the end users to review after a period of time, because you know some of those end user radars are now a year or two old, and you know we're kind of condemning certain organizations one way or the other yeah, which is also a factor here.

C

Should do you think we should actively be archiving these after, let's say a year.

J

um Potentially I mean it would be better if, if you know, if we were doing this under a cncf banner, we should probably be reviewing them or at least say provide. You know some sort of information as to why they're current or not current, you know what I mean otherwise, otherwise,.

J

Otherwise, data becomes expired and poor and the poor data is the thing that I'm most keen on to to uh to to to make sure it's it's appropriate because, sir, you know 30 people from 30 individual companies, which might only be responsible for specific things in those companies, doesn't necessarily mean it's actually a valid set of data.

J

It could be very focused or we could be missing entire chunks right, but you know it's it's it's hard to tell and we're we're we're then sticking the cncf stamp on it to kind of indicate that it's it's supposed to be fair, but it doesn't necessarily mean it's right.

C

Yeah and ricardo- a conversation that I think is relevant to this about how sometimes we have graduated projects that uh maybe appear as assess, which is kind of weird and confusing. But as ricardo points out, it's weird that that happens, because we interview end users for incubation. So there must have been people using these things, but maybe those people who we spoke to you know for incubation or graduation reviews are not necessarily aware or involved in these radars and we're getting a very different picture.

J

Well, you know: there's a cost to entry to being an end user in the cncf right. People have to pay for that subscription. So so so you're you're getting people who are you know committed to the ecosystem and wanting to help the cncf. But that doesn't necessarily mean it's it's.

J

You know their end users that um that we would have interviewed in the incubation stage.

C

Okay, I think we've got a lot of very useful ideas here. I don't know how we resolve some of these like how do we? What do we do when we have a graduated project that is not appearing?

C

You know when it's appearing in the ss phase. I don't know that we have a good answer to that, but I do think we have some suggestions here that we should take to the end user, community and katie and ask for input at this earlier stage.

C

I think the things I'm taking away now is starting from the landscape as a first point of sort of listing. What should go into the survey? Agreeing the scope of that survey um crossed my mind that this is an opportunity for the end user and toc communities to work together, which we don't have enough of those. So I I hope, that's seen as valuable from the end user's point of view as well.

C

I think we should raise the possibility of archiving them after some period of time, because yeah, if they're two years later and we're still saying this graduated product project, is, is in assess, that's going to be very misleading and we should try and look for ways of keeping these more up to date.

C

I think we need to be more prominent about the fact that these come from a set of end users and maybe indicating the number of respondents like including that in the graphic so that when it's downloaded, it's more clearly labeled as a hopefully representative, but nonetheless it's a snapshot of a survey of a certain number of end users at a particular point in time.

E

Yeah, did I miss it yeah, the last one I had was: um don't. uh You know position this, as you should do this uh it's more of like this is what we have found so changing the way to look at the data to reflect that it is a consensus of end users up to this point, and it's not like something uh looking forward right. It's looking backwards.

C

That's a great point that the those words assess trial and adopt sound imperative. Don't they.

E

B

I think there was another point about connecting the dots between the you know: the vendors and the open source projects. Yes,.

L

B

Yeah, I see that as actually providing a little bit more information in the radar, because when you take a snapshot or you when you see the visual, you know there's a lot of questions right. So if you try to think about how to address those questions in that first visual right when you, when you see that and connect the dots, it's yeah, so something to keep in mind.

C

Yeah, I think that's a very good good point to add.

C

All right uh with five minutes to go, anyone have any other points they want to make about this general topic.

J

I'll just make one small point I I kind of you know I kind of probably might have come across a slightly negative here. I actually think the end user raters are really valuable and useful and there's probably more right in them than than you know wrong, and so this is. This is one of those things where um you know the last 20 is probably 80 percent of the work, and we should.

J

We should think about how we how we factor that in um but 80 of it is actually pretty pretty good and very, very useful and there's, you know, been a lot of positive feedback for it too. um So yeah, I didn't want that. You know, I don't think we should throw the baby out of the bathroom so to speak.

E

And then the other one that I also thought about was uh the ricardo's uh point of how we use these things together. It's almost like this is our stack like. So if you, if, if we let the end user, say design their own stacks like I use these set of technologies together and then basically vote on them saying hey, this is the most popular one. You know that might be another way to look at it. um This is the whole reference architectures.

C

E

C

E

I use argo cd and I use walt, and then I use litmus with whatever right like this is my stack that I use uh in my company right like so that would bring out these additional. um You know tidbits, instead of like, if we just have a radar for storage, it really doesn't make any sense. But if we work on like here is the stack here is a different set of different variations of stacks.

E

That might, there might be something there too,.

C

Yeah, I I love the idea of this and in fact it did come up as a suggestion in the the governing board. That could we be doing more in in terms of reference architectures, and I think this has come up in the toc before and I I I think everybody you know everybody is in favor just a question of finding the time, um with the caveat that we we shouldn't have one reference architecture.

C

We should try and have several and ideally they come from end users and it's you know, this is what end user a is doing. This is what end user b is doing. This is end user c again it can be a snapshot in time, but if we could get those, you know uh kind of case studies, I suppose, in the form of reference architectures. That would be amazing.

C

Some plus ones uh bob sang. I like the idea of a user story and a stack letting them describe why and where they're. Why and what they're using yes hearing decision on logic on why they chose a specific thing would be useful, completely agree, really good all right.

C

I think this is super useful, um I'm sure, because people like ricardo are representing end users on the toc, but um we'll also, I think, in the tfc just write up some notes to kind of propose to the end users in a you know, formal sort of a way so that we've got something written down, but I think we can. uh We can take this to the next level of usefulness together, brilliant thanks, everyone for all your ideas and input. This was super.

C

All right, thank you. Thank you.

A

We didn't have.

C

Anything else did we nope that was it all right, brilliant, take care. Everyone see bye.

B