 Do hey Terrence, okay, I guess we will go ahead Hello Don't know what April is So far just us it's been very quiet in the channel today if you noticed I've noticed most slack sick channels aren't super super active Yeah, well, I mean a lot of people I know in the land of cloud native are involved with the protests in some way Yep That and like I think mailing lists tend to be the primary form of communication. Yeah Anyway Well, really I Honestly have to admit that Don't pay a lot of attention to the mailing list. I Just know a lot of the since you have communication seems to happen into the mailing list So I think I know with like at least the other sick that involved is the app delivered six Yeah, we just use the mailing list for announcements though There's no real discussion the So Given that if In the event that April does not show up We'll just end up taking up the whole meeting for the whole end user requirement discussion So in the meantime because it's being recorded, let me do the obligatory stuff Howdy I this is officially a meeting of the CNCF governance working group This is being recorded for CNCF documentation purposes We are also subject to the CNCF code of conduct And so everybody on this call promises to be a nice responsible human being at least while they're on this call Um the And so that out of the way we can discuss stuff just wait did you used to work in heroku? I Still work at heroku. We still work at heroku. Yeah, cool. We were you there when Craig and Peter were there? Yes because they're both friends of mine, so Your name does sound familiar, but I can't yeah place why I Showed up in the office a number of times I used to be a postgres committer, so Gotcha Okay, so There is the notes feel free to add anything you want to that We will focus Pretty much entirely on the end user stuff because it's you and me and punt on the other issues until next meeting or some other time So Now one of the things in our profits this with is I actually kind of don't feel like the end user requirements is really a governance issue But looking at it there's no other good place for it to be You know and since we are dealing with a bunch of the other titular requirements. It seems It's not really governance, but it's not really anything else either So it might as well be us But later on somebody might decide that they actually are going to lay claim to the requirement I mean if not you then the TOC I guess is the fallback right? Yeah I know and you never want stuff to originate in the TOC Yet honestly what you'll get is you will get an updated requirement that is equally confusing So I guess as just for context I think you weren't at the last TOC meeting last week or something. I was not and so that Harry actually from the After delivered sick brought this up because it's like blocking their whatever recommendation on Bill packs of like What they want to say with regards to it for incubation and yeah, I came up in the meeting I think the thing that was kind of decided was like Case by like basically very unsatisfactory like case-by-case basis shrug question mark like I guess we'll see when it comes in I Mean that those are terrible because what that means is projects That have a project contributor who's on the TOC Get okayed and and projects that don't don't Which is not how we should be deciding things but Um, yeah, maybe maybe worth re-watching that like five-minute segment or whatever from okay to see But I I believe that was like kind of the conclusion like it was brought up And there was some examples like I know even for app delivery say like this is a thing that cloud events Which is an incubation project? Brought this up because it's you know an even more stringent requirement going into graduation, right? Like what are end users? What what does that mean? It's like mostly a spec tools projects in that regards like how do you consider what the end users should be? Yeah Well, I guess So I guess two questions that I have there is I mean number one one of the problems I'm going through with the TOC in general is that we have this list of requirements for incubating and graduated But not one of the window a couple of them do but most of them have No rationale behind them as to why those things are requirements and Without the rationale it's really hard to figure out how to judge these Right because like you have two possible definitions of end user, right in end user could be specifically how this has sort of put on The CNCF website, but that's really for the end user council, which is companies that are not vendors as a company, right? But then you also potentially have this other definition, which could be You're an end user if your company Is not in a position to ever Have a product Based on the project if you follow me Yeah, that makes sense Which would be a second potential definition and not one we'd want to use for the end user council But potentially one we'd want to use for an individual project And without the TOC telling us what the rationale for the end user requirement is then I Don't know if that's completely reasonable So like if we were to actually make the requirement of the end users just have to be companies that Do not and are not likely to have a product That is in some way based on the project then that would solve the problem for build packs and cloud events Yeah, I mean, I guess my question is like why is it problematic to have like I get in certain cases where that's true, but like Yeah, I think specifically for build packs too for me It's just when I think about end user like the people we were most interested in initially of like targeting our people that very much are producing products on Top of the software that we're building not because we're making money off of that But because like it has the largest breadth of in rent or like of like kind of reach so like if for instance like Heroku for instance, right like has a pass that uses build packs as the way to build stuff for it like And they may like for sure like broken makes money off of that, right? But like I would personally count that as an end user if you follow me They're not selling build pack They're using build pack to build something and then selling that thing, right? Yeah, it's just like if I'm General motors. I'm not a Linux vendor. I'm using Linux to put it on the onboard system to sell a car So Yeah, I guess that distinction is definitely not clear to me Well, so so I think part of the for my perspective part of the problem here is The CNCF is trying to use the same definition for the end user council and for the end user requirement for projects and I think personally, I think those two should be different Because the purpose the end user council is to have involvement in the CNCF by companies where the entire company is not a vendor I can come up with a couple of possible rationales for the end user requirement So I'm trying to take notes at the same time I speak So rationale number one is obviously Potentially to push all of the individual projects to help build the end user council Right, that's a possible goal of the CNCF right obviously end user involvement in the CNCF helps the entire CNCF and Therefore individually all of its projects and therefore the CNCF maybe wants a requirement to push projects to actively participate in this But another possible reason for that requirement is what I call avoiding the C++ problem I Don't know if you ever did any C++ very limited mostly in school, but not in a professional context So back during the peak year of C++. There was this International committee called the object management group Also colloquially known as oh my god for lots of very good reasons And the object management group's job was to meet twice a year somewhere in the world and Pass a bunch of C++ specs and The way these specs work is a Vendor would write a spec They would get a couple of their partners to support it They would shove it through and no one in the world would ever use that spec to ever write any actual code and That's the other possible rationale for the end user requirement if you follow me because The companies that are most heavily involved in the CNCF are vendors and because the vendors often partner with each other There is the possibility of creating basically shell projects That is projects that are good for each company's marketing even though nobody actually uses them And the CNCF as an organization doesn't want to get in a position Where they are promoting a bunch of shell projects because that harms the CNCF brand and harms the brand of the Individual of the actual projects that do have users Do those companies also not use that project that they are putting in? Oh, yeah I Can't go into specifics because I work for a vendor But let me say I could name quite a number of Projects created in the cloud native space that are used by nobody including the company that originated them So I guess like as a more concrete example like I know in our case right for Bill Pax like I put down both of the two companies involved as example end users because we are using it in a context where like We are actually we want to use the thing the reason we're working on this because we want to use the thing We're building right, but we also wanted to work kind of outside of just the scope of the two things the two companies involved Right are those like good examples of end users or do you not want to count end users that are basically founding members of that project? Well, I mean the problem with say the originating company having internal end users Is that anytime you're talking about a single company? We have this issue with the maintainer diversity thing also? that company can have a company wide policy change and Then a race support for the project The however The reason why I was going over those two possible rationales And why I really want the TOC to pick one of the two as The primary rationale is because which one is the primary rationale really makes a huge difference, right? If the primary rationale is to get more end users for the you see then we have to stick to the definition for the end user council Right, and you have to find companies that are not software vendors who will say yes, we're interested in this but If the goal is to avoid publishing empty specifications, then it's very different, right? then VMware could be an in not VMware, but then Red Hat could be an end user for cloud native build packs because we don't have anybody contributing to it But we could use it if you follow me right and so You know what the rationale is kind of makes a huge difference in in how this is supposed to be implemented Now in the case of cloud native build packs, I don't see why you wouldn't have SIs I see companies using it. I mean cuz theoretically anybody who develops containerized applications should be able to use it, right? Yeah, no requirement that it be a big company You know, you could have a I'll tell you from some of the existing projects They've made use of end users that are really three-person consulting companies, but that's still considered legit as far as You know any of this is concerned so we listed one one company that an RFC that I think is like in that vein where they are like three or four people maybe and they are using it internally As well, but There's also I guess like because there's distinction between like like Harry from the absolute base he made us differentiate between end users By I guess like the end user council definition and like cloud vendors So there's I mean like a lot of interest from the majority of stuff tends to be like cloud vendors that are interested in adopting this so like Yeah, for instance, like get lab, right? Like they want to use build packs as a mechanism for people to be able to run Get containerized stuff for CI right like as example, and that's why they're involved the project like right technically like they're a cloud vendor So Google is also a cloud vendor Microsoft's also a cloud vendor, right? Salesforce cloud vendor right like building a platform on top of it. So a lot of our people that we interact with tend to be that type of At least at the stage of the project is now like they're definitely are this other group of people like you're saying but they It's hard for us like I guess like find that information out. Yeah, it has been so far Yeah. Oh, no, it's always it's always difficult. I'll tell you Somebody who ran a BSD lessons project for 17 years Figuring out who your users are there's not only that figuring out who your users are and then finding users who will let you publicly reference them Right. Yeah, I mean that was always a huge challenge because like, you know Because consultants talk to each other like we knew that say The army in the Coast Guard were using postcards, but that doesn't mean we were allowed to publish that information Right. Yeah. I mean, I know that even at heroka, right? Like we're not allowed to talk about our customers unless they're on the marketing page Yep, you know of like all these people that are using your product, but you can't say anything about it the so Yeah Okay, so But you see so overall I mean like I think our next steps are to pressure the TOC to make a judgment call on what the primary goal of the end user requirement is Because and and you wanted this for everything not Because as I was saying so right now we're arguing about the whole maintainer diversity thing is and I have to say look We need to stop making these stupidly simple rules that Makes the assumption that everything is black and white Because in every single open source project is its own special snowflake and we actually need guidelines more than we need rules Because like for example if we say this is if we say like If we say the requirement is the purpose of the CNCS requirement is that projects should need Users to participate in the end user council Then That's actually kind of a different requirement to be following Yeah, in which case you could even say hey the requirement is actually to recruit a certain number of users for the end user council Not to publish them on your website because that might actually be different Right particularly like for example Say that one of my end users was a bank. I Would actually have an easier time getting them to join the CNCF end user council Then admitting publicly which software they actually used Because a lot of the banks have policies not to ever disclose what specific software they use Right, the CNCF is so big that just like yeah Yeah, or if the requirement is hey, we want to avoid empty specs and show that projects have actual adoption Before they advance Then there should be substitutes right it should be even hey this project can be used entirely by cloud vendors But if you have five or more cloud vendors who have adopted it then it clearly has industry wide adoption And it's not going to go away tomorrow Yeah, I do get the sense it is more likely the latter based on the conversations from the Meeting last week, but yeah, it'd be good to get clarity. Yep So and you know and then if we get clarity we can proceed because I it is harder for some projects than others and most definitely is The I mean in the meantime given that the TOC tends to take a long time to make decisions on anything I would suggest Trying to probe in your various community meetings and stuff to see if you can find some ICs or SIs because those count And if you can find three of those then you've met the letter of the requirement And and you know we stop having to We don't have to argue out the larger issue for cloud-nated build packs specifically get passed if you follow me No so the and it's interesting because there's also this distinction on cloud vendor because like I Would honestly not have considered heroku a cloud vendor by the CNCF definition Just because Well, I don't know did did cloud native build packs originated heroku. I thought it originated at VMware It clouded well, so build packs originated at heroku and clouded build packs is built is a joint effort between both Heroku and Pivotal basically Pivotal who's now VMware and heroku who's now Salesforce through acquisitions Like taking the things we learned over running this thing in production for nine years from different angles and trying to We had kind of a fragmented build packs ecosystem So it was like we want one build pack ecosystem that's built around basically kind of containers and tooling and leveraging all that stuff versus our own like Proprietary really proprietary tar ball slugs and said use container images and like build the thing kind of with a new spec And a new thing kind of taking those ideas and bring them forward and that was kind of the premise of it So we were both like co-equally co-founding this project and that's how we got into sandbox Yeah, I don't know if they answered your question, but yeah, I know it's just well One of the things I was thinking about is is the sort of fuzzy line between cloud vendor and cloud service provider Right, right because if you're to take sales force the parent company They're kind of not a cloud vendor if you follow me they use other people's cloud technology to supply a cloud service Right, it's like to give you an example of one that's all the way on the other end, right? That is nevertheless in the cloud business automatic with one T Not automatic with two T's which is a cloud consulting company therefore on the border but automatic with one T is a company That allows you to use the cloud in order to do things with your vehicle That is they basically connect the cloud to the vehicle computer readout in a whole variety of cars That's definitely an end user though, right? They're never going to have their own Kubernetes distribution or you know and it's highly unlikely they would ever sponsor a project to the CNCF And then you get into some of these fuzzy things right of well, okay, what about a company if you have a company That never has sponsored a CNCF project, but potentially could someday in the future Where do they fall on it or if you have a company whose main business is something else entirely right general motors could sponsor a CNCF project I mean they haven't but technically they could you could imagine there being a future in which they did I don't know the whole end user thing confuses me because there are things that are obvious right red hat is obviously a vendor VMware is obviously a vendor right But there's a whole bunch of companies in the middle where it's like is this an end user or not Yeah, I mean I guess to me like most of this stuff comes from the app delivered sake of like telling me that these are vendors and so that's kind of how I bucketed it but Maybe part of even the end user thing is like what is the definition of vendor it probably also fits under it's worth clarifying what that is Like I basically split it up into end users cloud vendors and then the third category was like open source software projects because for instance There are open source software projects that obviously they're not a service or anything like it's open source software that uses cloud and a bill packs as part of like they have support for cloud and bill packs as part of that Wait, wait, so actually hold on let me look at the requirements because I'm not sure that the end user requirement says company And if it doesn't say company then an open source project would count and for that matter if the open source project has a foundation, it would also count Yeah, and that's actually I basically just listed those three categories and put a bunch of things in there and basically left it up to the TOC or whatever to kind of make a decision on that Okay, the limitation there though which would make it difficult with open source projects is used in production Which actually believe it or not it could cloud native bill packs could be used in production by an open source project If the open source project is distributing their software via cloud native bill packs And the project itself is not staffed by a vendor company then I would list that so where it becomes sticky is if it's if the cloud if the open source project is staffed is primarily staffed by a vendor company right because you could say hey fedora is You know releasing cloud native bill packs for applications, not that they are but if they were and then turn around and say, but fedora is primarily staffed by red hat and red hat is a cloud vendor and therefore this doesn't count Yeah, we definitely have some of that stuff with VMware has a bunch of open source projects that use it but they aren't the only ones. Yeah, I guess is there distinction between Like a contributor who is like not part of the core team but like is an extra contributes project so for instance like Google has open RFC's and has made patches the project and we're trying to get them to be a contributor Because they are pretty active in it, but they have projects that use it kind of independent from the people I guess that are actually running that actually contributing to cloud native bill packs right like And parts of Google like so scaffold for instance or kf from Google side both have cloud native bill packs as part of their documentation. The Yeah, so Okay, and you said you actually have to run now yeah Yeah If it's helpful I can link the due diligence doc to you. I don't know if that is Sure Here is the I mean I think you're all of the issues you're bringing up our lack of clarity issues that you know already kind of readily apparent when you read the requirements Because you know they give you listings of obvious examples of companies that fall clearly on one side of the line or the other but there's a whole bunch of entities in the middle The and again the rationale matters right because if it's the empty spec thing then showing it had broad enough vendor support would also cover it Yep Okay Yeah, I guess for next steps is that the say just talking to or the governance or you're talking Yeah, I'm going to take this up with the to see because I'm already pushing for clarification on a bunch of the other requirements because I'm like look I'm about to write detailed guidelines for you guys on how to implement these requirements But I can't do that if you won't explain why the requirements exist Sure The but the problem is that the requirements were not necessarily created by the current to see And they don't actually know why they exist and so they have to hash out from scratch Sure Make sense Probably without the next to see if they had that information to Yeah So so that's the next step for me is to take this to the to see and start a discussion and ask hey we need clarification here The next step for The next step for you I would say the thing I would advise doing because again that discussion may take a while in the in the to see is you know do don't just focus on the big companies look for smaller organizations that would call As end users because if you could meet the letter of the requirement and you've met all of the other requirements you'll probably get passed So The and honestly it's not even the letter of the requirement right if three completely independent s eyes found the software useful it's useful it doesn't matter whether we're talking a three guy consulting shop Or unisys Right Because honestly unisys may say we're using this but they're only using it on one project whereas the three person I see might use it for 10 projects so The it's still legit it still counts and I my general my personal experiences consultants are a lot more willing to talk about what they do Then Then more established companies often who have a PR process etc Right Makes sense Okay Thanks for the advice Oh, you're welcome Let's know how it goes and you know how to communicate And I'll let you know what happens with the to see or you can just follow the to see mailing list and the issue that we opened on governance WG Sounds good Yeah Thanks Ash And that's it for this meeting Thanks all