 Hi everybody, thanks for joining. My name is Tomo Nakahara. I run a developer experience team at a company called Weaveworks. I'm really appreciative that Diane invited me to speak with all these fantastic speakers. So hopefully it has something to contribute. Maybe you've seen my title, which is quite obviously quite of a bookmark title because we were kind of in conversation. So hopefully, yes, I have some lessons that I've experienced that would be helpful for thinking about DevRel for open source. So I was talking with Diane and asked, well, what would the audience want? Like what are you thinking? How can I be most helpful? And some of the things that she shared was obviously people here have quite a bit of experience with open source communities, building them, educating them, driving adoption and participation. But that thinking about it from a DevRel perspective or a DevAdvocacy perspective might sometimes fall by the wayside or maybe be a blind spot. So hopefully I have something to offer here that I guess in my world is definitely a core part of doing all these things. So perhaps this will be a reminder for things that you already know. And hopefully maybe there are some pointers that will help you think about these levels of advocacy. So some, I wouldn't, I think this is kind of a grandiose term. It's not necessarily I have a grand models and patterns, but I hopefully will share some of the ways that you might be being pulled into these areas. So one thing shared also was that maybe part of the blind spot is that there's a corporate angle or a business driven angle that for a very good reason. Some people might feel concerned about and feels very antithetical to the community, but you do often need to support your community. So you might be supporting your community completely on your free time because you're involved, you're a member and you care. A lot of times you still need to find financial support or certain types of support. And so you might be able to find for lack of a better term, I was just thinking like a one for one where like there's a clear kind of exchange. Maybe you need some financial support for technologies or a series of events or meetings. So there's a clear exchange of brand awareness in exchange for support. But that kind of keeps that angle very delineated and safe. And for a lot of us supporting a community may be specifically part of our day jobs. Our job titles, our job descriptions or certain parts of our job requirements are about supporting this community. So how do you advocate for both sides or various sides? So I'll be speaking mostly to this third category from my own personal experience of having roles where it is explicitly my day job and I'm working with teams where it is explicitly their job or others who are kind of in the periphery or part of like the shared community. So hopefully that will be helpful there. So as part of supporting your community as your day job you might have been hired for a particular role because you've already created a reputation for an existing community that this company is looking to build its own reputation. So they're kind of building upon you and how you've already built trust. You may be understood as an expert or very helpful. And maybe if you gave a talk a lot of people would come because they already know who you are and they're looking to learn from you. So you might be hired for that reason. That's like an example of something that we did when I ran developer relations at New Relic or we had a team around Cloud Foundry at VMware and Pivotal. So we had particular experts that were already established in different communities. Or you may be in a new group and you've identified or the company is vaguely or clearly identified, oh, we need to sort of build thought leadership in an existing community and you yourself are interested in growing and learning in that area as well. So you might have a good alignment there. So you're both building your reputation and helping your company with that. Or maybe you've created a new open source community and the company is invested in growing it. And so that's part of yours. That was my experience with Cloud Foundry. I was in for intensive purposes, the first community manager of this brand new thing and nobody had heard of us. I'm like, who are you? Why do we care? So there's different levels of that where there's a lot of stuff to grow in. And there are clearly serious concerns, especially if your main commitment is to your open source community. Hopefully I'll cover some of these like nightmare scenarios where maybe the company's just basically enforcing its own benefits onto maybe the roadmap or how the community is managed and not really caring about the growth and the health of other members of the community itself. Or just seeing it as this rife space that they should be marketing or selling to in a very direct way that is very not respectful of the culture that's there. Or maybe you have your own communities that you've been building up but you're so focused on measurements and like forcing people to sign up for things and making requirements that, yes, metrics are important but being able to have a balance between that that's another area that you wanna advocate for. Also attitudes of like, it's all about taking and not giving back. It's like a one-way thing. Like, oh, we're missing this opportunity that we're not going in there. And then some of the worst case scenarios or maybe the community started within the company and they're like, we don't understand the benefit. This is just taking time, resources and money. We need to just close source it and make money off of it. And so sure, there are many other concerns but these are definitely ones that I'll be talking about that you wanna protect your community from these kinds of dangers. So this was the slide I was just covering for not all but some concerns that you might be thinking about if you're engaging with different business groups in the company. So when you are advocating your company and I kind of highlight, I won't dive into the terminology around evangelism, advocacy, developer relations, marketing and all that. We're really gonna just focus I think a core part of that even across all those terms around a team developer experience, right? Is that advocacy is a key part of that? Having empathy, having understanding and being able to manage these different relationships. Obviously there are many, many reasons that you would be advocating for a community that I'd share some kind of generic ones that we can agree upon. You wanna keep it open source. You want it to be innovative and collaborative and you want it to have longevity and not be interrupted or cut short. And I'll add a sort of a footnote on longevity here. Just an underlying assumption of the things I'll be talking about moving forward. My underlying assumption around longevity is that you want for wherever way you can natural or organic longevity for the community and other relationships. But I think holding on to longevity just for the sake of longevity will lead to a heartbreak. So with a community, technologies might change or new things might come up. And sometimes a community might shrink but it's still really powerful. So I've definitely been through communities where people sort of mourned like, oh, it's not as big as it used to be or this and that. And so I kind of take from, if you look at relationships and partnerships, a lot of times the model is that you're always assessing between partners like what's the shared benefit that you're getting out of it? And as part of the life cycle, there's a natural winding down if things change or technologies change where you might put a pause or an end to that relationship if it's no longer equally beneficial. And so that way you're not really having that heartbreak. And then similarly, I feel that way about all these teams, developer experience, relations, developer advocacy and that. I advocate for this general approach and understanding what your communities need and your technical audiences need. And those responsibilities can be held across many different organizations. And in fact, it would be very healthy if it is. There is value in having a, for example, a developer relations team that kind of is the central source and owns that. But if the company evolves and changes in certain ways, people do care about job security but there are shifts that are going to happen. So I think that that's also part of understanding longevity within that context. So going back to this, there are many ways to protect your open source community but here I'll talk a little bit about how being able to articulate and understand and constantly be testing the business value of having a healthy community is really important to protect them and to understand how your open source community fits within the company's business strategy or the line of business strategy will also help with that. And then building allies and stakeholders who understand that and to keep re-educating, don't assume that because they got it in one meeting that they're going to continue to get it over time because people will fall back on ways of measuring success and models that they know. So being able to do that is really a way that instead of thinking that it's antithetical, it will actually help to help people understand why they want the community to be protected and kept the way that it is. And so in some ways, right, it's not just a two directional relationship but a multi-directional relationship. So you'll be managing expectations across business owners and I'll be sharing some of the examples I have to find ways that if you have metrics for success, that seem antithetical, that you're measured on your success in different ways and if they don't understand the way you're being measured, then of course you're probably the bad way. They're gonna be like, oh, you're the way that you're just spending company resources and time and not being helpful. So being able to say, well, no, let's find the metrics that we have together and this is going to help you understand why the community should be protected and kept that the way they are will also help to manage the perception of the community. Because again, going back to, oh, you guys just spend time, resources and money and you're not really bringing any value. We need just be going in there and taking advantage of it in the way that we understand which will be very detrimental to the community. So being able to manage all these are very helpful to protect your community. Also share that you may be in a company that you feel like, well, I don't have to spend that much time on this because we're a company that's founded on open source. We totally understand it and maybe you will spend less time on it but leadership can change, companies can get acquired, directions may pivot that change priorities. So with that, I think it's still important to think about these metrics and how you fit in so that if you care about the open source community itself to be protected, these are things that are still important to at least be articulated. Okay, so moving forward, I'm gonna be talking about my personal experience. So it's definitely not comprehensive or exhausted anyway, but hopefully it's a part, a small piece of the puzzle that will contribute to this larger event and the conversations that are happening. So I'm going to share some of the ways, not all that you can help keep your communities healthy and engaged and understood within these business metrics. So I thought I'd think about the categories based on certain types of comments that maybe you've heard or probably have heard that can be sometimes somewhat alarming. So like let's say you're participating in existing community, right? So we're gonna like, why aren't we selling to this community? Like Java communities and Xfold are currently, we're in the Kubernetes community at Weaveworks where I think last time I checked there's 90,000 people in the Slack channel, like why aren't we downloading that list and emailing all those people? Well, one, you can't do that, it's not legal. And two, like, okay, like, what if we were to like bombard that Slack list with all kinds of marketing and stuff and trying to pull into webinars or what have you? Immediately, probably I would be banned. The company's reputation would be at stake and it would not be the way to respect the culture of the community. So there are many ways to slice and dice this, but one way you could say like, well, let's have a shared metric that we understand. Yes, this is a pipeline, but the way that we engage with that pipeline is through building relationship, like first through giving back and helping people, being understood as being helpful, building a reputation for the knowledge that we have. And if they end up coming to an open source project that we've used because it's very much in alignment with the larger community, they'll build reliance on our open source technologies. And depending on what your business model is, if you have an upsell or you sell support or you have free open source and paid, you have different ways of continuing to build that relationship. And then from there, when you have those relationships, you can just say explicitly, hey, can you do me a favor? A group of people like, hey, we love to, we have a new features that we have, we'd love to have some product feedback or would you be willing to just sit through a demo and hear what we have to say? And a lot of times, once people have understood where you're coming from, they're very helpful. Like, sure, 20 minutes, I'm happy to sit there. I'm probably not gonna buy, but I can tell you what of your messaging works or doesn't work or a lot of times they'll say, well, I actually know somebody who I think would really use that or we actually would really need that. So it's a smoother transition and the transition built on trust versus, hey, you guys are spending all this time in the community and we're not getting anything out of it. And also, I'm a little short on time here, so pretty quickly, you may have your own community. It's a common thing that people want to recruit from the community. Well, make sure that you understand that there's a shared goal of growing that community for itself. So if there is recruitment and it does happen, I remember back in the Mongo days and in the spring days, a lot of people would come in and try to find a balance. And you're doing well if people really wanna work for you and that's natural. We get that at WeaveWorks, which is really exciting. And so we have a great base of people if we do need to hire, but we also wanna make sure we have a shared goal that we want in our community size to grow. And more specifically, this was, I thought, a useful case where when I was part of the spring community, it was already very mature and very established. The company was very established in terms of having all these different orgs and there was one education award that they were measured on selling paid training. So here we were as dev advocates, like we wanna be really helpful. We wanna give away free workshops, give away a lot of great resources. And they said, hey, that makes us really nervous because you're basically giving away for free what we need to make money on. So I could have just said, you guys don't get it. Like, we're trying to help the community here. But instead I said, oh, this is kind of an interesting challenge. I understand what the metrics are, but what if we were both measured? I'm like, what would happen if we doubled the size of the spring community? What if we 10xed it? What would that mean for your pipeline of people wanting certification and paid training? And of course their eyes were dazzled. And they said, well, yes, that would be lovely. But like, how do we make that actually happen? And so we obviously respected each other's short and long-term goals. And so we were still able to offer a lot of stuff for the community. But now we had an explicit tie-in, so to speak. We're like, hey, if you want to get the full version or you need to share code, it has to be under NDA, what have you, then this is not the place for this. This is like a two-hour workshop, but here's more that can be done. And you can go onto that. And so that way we actually became, we were in partnership with the training team where their trainers would actually help with these free workshops that we offered. And it was a win-win because they're like, well, now they already have a relationship with me. They know that I'm a trusted source of training and if they want more, then they'll want it with me. So that's one, another way, right? Where you have a particular organization understanding why you want to keep your open source community safe and not being kind of plucked and marketed to for paid training. Of course, metrics based on giving. This is something I hear quite a bit. Oh, we can get free labor, free support, documentation. We should be just tapping this community for free stuff and free Q and A, free testing, right? And so first of all, again, labor laws are in place. That's not really something that you can do or is healthy for the community. And so there are many different ways to slice and dice this again, but I thought I'd highlight in some ways like by keeping the community safe and protected, you can actually gain a lot of information that you're looking for. Maybe you'll find that there are open source integrations that you can have for product growth. If people are localizing in geographies that you haven't tapped into quite yet, you can at least start, your sales team can start getting that information and seeing maybe there's reasons to start investing in those areas because there's a lineup of companies that are interested. Maybe you see partner integration opportunities that you're working together on and so you can see what next steps are there. And then ultimately, if you're really begging for a free support because your current system is completely unsustainable, maybe it's time to be thinking about re-architecting and redesigning the way your offering works because it's gonna be limitless anyway. Like even if you had some insanely helpful community, it's not gonna be enough, right? And this is one of my favorites. I do think if you have like an open source version or paid version, having a PM who totally gets it and isn't just saying like, oh, these are in competition. If you have a PM who understands, wow, I literally have this active, engaged community, not just giving feedback and submitting issues or making requests, but also like being in communication. Like you can tap them and say, tell us your use case. What tools are you using? What are those problems you're trying to solve that can help you understand the trends of where you need to take your product, what people are willing to pay for? And then if they're actually building upon your open source project, then you know what gaps they're trying to fill and then you can kind of figure out like which are the ones that are kind of too custom that we can't really address them, which are the ones that we're seeing a trend that like, oh, this is a gap that people need to fill and they'll be willing to pay for the paid version for that, right? So it's called road ahead. So Diane gave me a little bit of outline. So I'm not sure if this is quite a road ahead, but I'd share maybe a different model that we put together. So I work at WaveWorks. Maybe you guys have heard of GitOps, which our CEO kind of put out there in 2017 and said like, I noticed a trend that people sort of doing operations by pull requests. You know, you're using versioning, you're having a single source of truth and there seems to be this thing. I'll give it the name GitOps and it kind of took off and we just did a GitOps days online a couple of weeks ago and a lot of people talked about like, this is the year of GitOps. And so I kind of wanted to think about like, if I put together this event, like what would be the way that it would be meaningful as opposed to, okay, we did an event, we got a bunch of speakers. And so I really thought, well, we've been trying to kind of understand if there's such a thing as a GitOps community. So we've used this to launch that community. So first of all, we created a site on GitHub. We wanted it to be for anybody to come and join. Currently we have a community manager, but we should have community managers from different companies. And it should be a place of at least resources and collaboration. So it's interesting, it's a community, not necessarily based on a single open source technology, but of this concept and how we hope that it'll stretch and grow and maybe shift over time. So one thing I did create was a GitOps conversation kit, which was very beta. So if there's any kind of product, that's the first one right now. And it's because a lot of people came to us and said, oh, I'm really trying to push the needle with GitOps in my company. And I talked to leaders and stakeholders and dev and platform teams. And sometimes I hit some walls and it's really been a struggle. So a lot of the talks around the conference were around addressing those from different angles with a lot of great speakers sharing their stories. And we've been in the process of kind of collating and inserting the great quotes and perspectives into this kit that we then feel we've donated to this community and we want it to grow and people would submit issues and add their own. Like, oh, I tried this pitch that you had there that someone from a company shared, but it didn't really work for me. And this is why I think so. And so this is one way in which we might think about communities beyond just a single technology. So in closing, just again, some of these are some of the top things that we would be thinking about when we wanna think about a healthy community that is advocate that receives advocacy and is protected. And so these are some of the ways in which among many others, you can think about how understanding the business value, being able to articulate it and to constantly test it and to see if you're right or wrong and what works. And using terminology too sometimes that doesn't scare away people who don't really understand where you're coming from. Those are the types of things that you can get alignment on that will help people to understand the value of having the open source community be healthy in the way that it is, as opposed to a place that requires poaching or interference. So I hope that was helpful. And please stay safe and be kind to one person. And I have to add if anybody hasn't seen this link or many others, please do check it out, especially during this time of need. I think that was brilliant. And I'm so glad that I asked you to give this talk because I have known Tamal probably, I don't know, six, seven years, we've run across each other with different conferences and different tasks. And I had an inkling, you had a lot of great advice and a lot of good lessons learned. And one of the things that I've been really on it about and that you did a very good job of talking about is that personally, I think that developer relations or advocacy or experience or whatever evangelist or whatever you call that role is really a key to any technology community being successful. And sometimes we poopaw that a little bit as you guys are in marketing or you're not, you know, whatever. And I think that is a big mistake. And what we've gathered here today as well as Tamal, but is Ryan Jarvenan, who's been a cohort of mine at many conferences and Tony Wilberg who is from Microsoft and Gina Rosenthal, otherwise known as Gina Mink sometimes who popped off the camera for a second. So I'm not sure why that happened, but we'll see if we can get her back. Gina, I can hear you. Try, yeah, your camera just turned off for some reason. I'm here. I don't know what's going on with my camera either. This is not a camera friendly platform. Let me just put it that way. But I'm really thrilled to have you all here because all of you sort of represent from different angles, key people, there you go. I can see you again, Gina. From the developer relations, now we use that term for now, side of the house. And I'd really like you to maybe weigh in a little bit as well. The other thing that I thought was brilliant was the, in defense of community and open source is that the community is really what highlights the gaps in your offering. So when you see people coming in to create a Japanese version of the documentation or there's a big hole in your DNS server or whatever it is, when they want to fix something, that should be a flag for engineering or product management or sales that there's something missing in your offering. So brilliant presentation, Tamal. Thank you very much. So I'll open it up to Ryan and Tony and Gina to see if they have some comments or additional commentary. I just, first off, wanted to say thank you very much, Tamal, great, great talk. Love that session. And interested to see how things are evolving specifically around developers using Kubernetes. And I know GitOps is one kind of way to help reduce the complexity and simplify things. But I think in the dev rel space, it's been really interesting trying to help give people advice on how they can optimize their productivity while the complexity of the tool set and the topics is like going up at such a rate that there's this huge amount of time spent on upkeep and refreshing your skills and relearning as well. So it's a really interesting field to keep an eye on and a great topic. Thanks, Tamal. Yeah. I think one angle that we kind of landed upon that we probably didn't really think about so much explicitly in the beginning of throwing out the term GitOps and such was that Kubernetes itself with its complexity is still set up for all these capabilities and that GitOps is really just part of that evolution that it really brings back the value. And it's not that we necessarily have all our eggs in just the Kubernetes basket, but we understood I think one of the strengths of this tiny little company that made some right decisions, one of the right decisions was, I think this Kubernetes thing might be the thing that we need to pay attention to and at least investing our time and resources to a decent extent that we can in this space will pay off. And so luck, knowledge, whatever, that's kind of worked out. But then now it's sort of like whatever this term is and the direction we're going, it really does reinforce this value that Kubernetes brings, that we're just part of this journey and that hopefully we're not just kind of waiting these little flags to give ourselves attention within this really noisy and large community, but that, hey, we've kind of hit upon this thing that is justifying Kubernetes itself. It's justifying this technology that is worth investing in because like you said, it is quite complicated. There's so many things in the landscape. The DNCF logo board is now just overwhelming, I know. So yes, hopefully, in our small way, we contribute back to kind of give some clarity and sense to all that's going on. And not that we're the only ones, but that's just the small way we're trying to help out. So Tony and Gina, from your perspective, how has the DevRel role at Microsoft? And Gina, I know you come from, I think it's a VMware Dell background, like very background there as well. How has that influenced the community building and the community outreach that you guys have experienced? I think listening to all the presentations today they're really good. And I think what's, there are so many things that I thought with the DevRel, especially what you're talking about, the whole idea of recombining, of going back to, you know, trying to figure out the communities again. All of the community properties we've talked about, they apply to the big company communities too. People have been fighting the hard fight internally for a while. And I think even now, just especially talking about Kubernetes, some of the things that are really hard, but the things the operations people know all about, they just don't understand potentially some of the software development side of it. So there's enormous opportunity for MindShare and for, you know, making sure that there's some way for these communities, somebody mentioned before, you know, being able to be permeable and to be able to go along the borders of the communities and work together. There's, I think we forget sometimes that the people that make up the communities, they don't just stay in open source or in proprietary or in development or in operations, they, the kind of, people kind of go where it is interesting and where it's going to pay them and work for their families, right? So there's people that have amazing, amazing strengths. And I know that I would see that, you see little pockets of things starting to pop up internally at the communities and when something gets decided as a big initiative at one of the big companies, then those people that get brought up into the communities or they find their way into the open source community, it's very permeable. Penny, what do you think? Yeah, coming from Microsoft, of course, open source communities, they used to be a little bit less close to the company's heart and they are now, I joined three years ago, coming from Red Hat where the community is where my day-to-day job and it's been quite a challenge or it was at least in the first years to convince the people first around me, I work in the field sales team basically for partners in here in Finland. So it was quite a challenge to convince the people that open source is kind of okay and then it's the right thing and then it's the best thing. So there's kind of a transformation of stuff around the communities and there were lots of interesting good points in the presentation and one thing kind of I wanted to ask about is how you see the commercial kind of communities and versus the partner ecosystem? And what I mean there is that most of their open source people I work nowadays, they are actually working for our partner companies, they can be system integrators or ISVs, those are individual people's paid by some third party companies to do something else but they still want to do open source. So you see the same in your companies. Oh yeah, I think there's so many different models I couldn't possibly make a blanket statement but I'll just share in my history, I was at VMware in the early days and this thing came up called developer relations and it was after VMware had acquired Spring Source and I said, wow, this whole space that seems pretty interesting and then that's where I thought, well, we're at VMware, I heard this thing called user groups and talked to the VMware user group person and said, oh, this is a very different beast. We're using a lot of same terms but these are very much dedicated people to the commercial product, they gauge in certain ways, they have certain expectations and that's a great thing too but it seems a bit troubling that we're all using the same words and then I think there was even a certain point where at a high level they're like, oh, I hear all these same words, this should all be in one org and it was just like, no, we're like, yeah, just because you have the same words doesn't mean anything about the cultures, right? And it never happened but that was interesting to observe how people's thinking happened and I guess that's some of the things I was trying to address when, you know, people aren't being mean or evil, they just understand the ways that they've been measured for success, they understand certain terminologies, certain categories and it's hard, it's hard to, one of the things we talked about at GitHub's days is that it changes hard for people, not knowing words is hard and a lot of times people know enough that they need to know to move into a certain space but they don't feel that they're ready, there's a lot of imposter syndrome so being empathetic for all of that is fine and then as part of that, curiously, before I had gone into developer relations, I was actually in the partner org at VMware where we owned building our presence in the Oracle space because, you know, Oracle was gonna embrace us and we were gonna be best friends which of course never happened at least at the time that we were there. It's happening now! Hurry up! Yes, we, but so, yes. So I was laughing like, why are we even in the partner org and assigned and we had such a fantastic team of people who just, in a weird way, I hadn't heard of DevRel at that time but we had to be very scrappy in the way that we worked because Oracle wasn't going to come and just do a straight partner agreement and this and that so we discovered these Oracle user groups. Again, right, they were commercial user groups but they are huge, they were all over the place and they were very active and when we'd go there we'd say, are any of you guys virtualizing your Oracle apps and such databases like on VMware? And they'd be like, of course, yeah, we wanna hear talks about that and so that was a way that then, it was very kind of suited to the way I worked as well so it was just kind of a lucky happenstance that here we were working with all these different communities all over the place who were very welcome even though sort of the mothership was not and so then soon when I found out about this thing, DevRel was like, oh, so it's a lot of the ways that we're operating even though like you're talking about commercial, you're talking about open source, you have very different cultures the way that you could engage and find like-minded people, people who are excited and they weren't worried about the politics, that was some of the ways that we got started and I was able to get certain types of models working and in fact, we had a very small shop that was willing to say we will be the experts of helping people virtualize their PeopleSoft or virtualize even their Oracle databases and so our greatest success during the three year window was going from people going, no way I'm not gonna think about it to at the end of the three years, oh yeah, we've virtualized everything, even our databases, because there's like a middle park where they're like, oh yeah, we're totally, we're all about VMware, but don't touch my databases, right? And so it was sort of like this journey and to hear these just stories coming back was I'm not sure if I've answered your question but these different ways of engaging with user communities that were commercial and so I felt like it's a case by case basis the kinds of cultures that they brought up and what they were amenable to. Yeah, great question. I see, I haven't seen exactly the same, yeah, when I joined, there was like the most valued professionals community which was everything about.net and all the traditional Microsoft stuff that I knew nothing about. I even learned the acronym like two years after joining the company. And then there was this set of time presenting like the open source that it's like, what are these two communities and how we make them go together? Yeah, yeah. I do think, yeah, you just have to put your anthropologist hat and go in and see how they do this. With that great hat on. Yeah, yeah. I mean, I often joke like developer relations doesn't really need to exist in the sense that if you put your hat on and you respect each culture and how they want to be communicated to and how they want to engage, like anybody can do it, but strangely they're like, oh, I don't know how to talk to those people here, I'll give you a paycheck and you go do it, right? But I mean, I feel like I could be doing this with any different communities. You just go and you respect how they are and you enjoy how they are and you work within that culture. So it doesn't even have to be developer relations or analyst relations or business relations or what have you, right? I think it's community relations. And I mean, Diane and I met 10 years ago when I was at EMC and then Del dropped me on to do the same thing. And I think even at VMware, they're for sure are, I don't know what's going on. They're for sure, for sure, I hear myself. They're for sure corporate groups and user groups that are one thing, but that's not where the real work gets done. And that's not, I don't think a lot of times where the real community is. And you'll find there will be sub sets of community that run to the developer communities because from an operation standpoint, you've got people that are building the servers and the virtual machines, everything on-prem and in the cloud, wherever now, that need to understand what the developers are going to build upon it. So you've got lots of operations, people learning the dev stuff. So I kind of, I think it's more than just DevRub. It is a community relations. I don't think that big companies till Kubernetes has kind of reinvigorated it. Of course at VMware, as of the people that brought Kubernetes to VMware, right? And made it workable and got everything pulled together into one united message. They're coming back more and breathing more into the true community, which is not necessarily the marketing community, even the partner community. It is where the people are, where the customers are, the people actually having to support it in real life. You've got, if it's an all cloud platform, there may not be any operations person. The GitOps is really important there. They can totally learn from the ops people who have done this. I'll give you an example of MuseoES, which was hard for me until I started remembering, oh my God, I did this in college. I did it by hand on AIX. I understand what I'm doing now. So I think there's such a wealth of, that's the piece of community that we miss sometimes when we don't remember to talk about the ops people, the real old-timey ops people. Like me. Yeah, I think that's a really interesting point about a couple of things resonate for me too, is like one is different cultures within different parts of the organization. The user group one reared its head recently when Red Hat was acquired by IBM and all of a sudden there were, there's a lot of user groups out there. We also still have user groups inside of Red Hat and we have ops culture and we have dev culture and there's all these different cultural shifts. And I think one of the things that Tony mentioned and Tamau was mentioning too, is we use the same terms for many, many things. And really setting the stage and creating shared understanding of what the terms mean within each of these different groups is really hard. And leaning back on the old-timey, which I would consider myself an old-timey ops person, having been a BBA and it's just admin ages ago, I got the white hair to show it. That there is a lot to be learned from all the different parts of the companies and the organizations that we work within and with externally as well. So I think that's one of the things that I've actually seen at DevRel, people navigate very nicely often and bringing them to the foray. Ryan, you seem to have something to say. Yeah, I was just gonna pile on thank Tony for the excellent question about partners and say I'm sure that Diane especially understands this issue more than most folks because she's directly at the intersection between community and users and partner efforts and a lot of this stuff internally within Red Hat. And I think it's especially true what Tamau was saying, how you have both segmented external community and different kind of personas that may need to get treated differently and marketed to differently. You don't wanna spam all of your partners or your users the same way you would other potential people market to them successfully. But then you also have to map those different persona groups successfully to your internal stakeholders and be able and that's almost like a matrix comparison of internal personas and external personas that need to be translated back and forth so that everyone understands how they can be aligned in order to create as a whole. Yeah, I think that that's an interesting perspective. I think Commons is one of those community models that we intentionally decided to bring in end users, partners, ISV, cloud hosts, and all the contributors and all the engineers and all the participants in the community. And I think in my very opening talk, which was supposed to be my closing talk, but hey, who's keeping track of time here? Not me. I think one of the things that I tend to send to talk about now is who's participating? They're all participants as opposed to members or specific roles and they all have different personas and really beginning, I think the science of community development, which is kind of the topic that I'm keen on unraveling is that really understanding who is participating in your community and how do you engage with them where they are? How do you meet them where they are? And that to me is the thing that's interesting about all of these conversations because everybody has different definitions of who is in their community. And one of the bees in my bonnet is really making sure that the people who are managing communities or doing community nurturing or whatever you wanna label it, really understand who is in their community. Because often people really just focus on the contributors and who's making sure we onboard the contributors because you know damn well that those engineers and those resources doing the coding are pretty damn important. And but it's the contributions and the feedback and how the community shows the gaps in what needs to be filled. There are so many other roles that participants fill that if we ignore them, we do it apparel. Yeah, and then as part of that, there's also just a logistical issue of platforms. I think I didn't have time to get into this but I've been in a couple of examples where I get how people might think, oh, this is just not scalable that we have people in this role that they're on Stack Overflow, they're looking here, they're looking there, they're on these crazy places. Like we really need to be able to centralize this and measure it, which I know it can work but I've been in examples where the spring community originally had a forum and I think even Cloud Foundry but they were just like, well, why would we physically force them to come to our pond when they're already in the ocean of Stack Overflow or wherever else it may be, right? And yes, you can't get this sense of control but what you gain is knowing that these are your participants, these are all your members but this is where they're hanging out so to sort of force a behavior that's against what's naturally happening as opposed to honoring it is definitely challenging. So like when I joined New Relic the first week, they're like, we're so proud, we've just created our new forum and I didn't want to like put them down or anything because I was just like, okay, let's see what we can do but I just came from a company that just shut it down because like they had to maintain it so much and it was just constantly like and we as DevRel had agreed to own a certain metric that we were going to help bring people from the ocean to our pond and it really is sort of, I'm not saying that it fails or it's just a complete waste of time but you shouldn't understand that you kind of going up against the challenge from the get-go and then here we were also like trying to create customizations to the forum that we didn't really even have engineering resources for so people have different opinions but my personal opinion from that was I just felt like you should definitely think about all the different options and again, not only meeting people where they are like in terms of their level of knowledge and what they needs are but also like physically or online where they are like understand that's also part of understanding and respecting the culture that they're stuck over for a reason so there's some challenges and I was just talking to another company trying to do the same thing oh, let's create our own platform and bring them here and I just keep going it's really interesting how that desire kind of keeps repeating but I think it should be assessed I know in my Facebook feed I keep getting served up startups that are offering to create community portals for me what is the new like, I don't know why like obviously why but that's been an issue lately but Gina Yeah, there's an old, the research in this space is literally 30 years old ever since there's been an online message board but there is an old accent that there's a 991 participation inequality rule so in addition to like respecting all the things you're saying it's also realizing that you're gonna have 1% that is that they're the ones contributing code they're the ones always answering questions they're the ones there you'll have 9% of people you'll see pop up one in a while once in a while that means 90% of your community are just lurkers and that's a pretty good measure of community too I know when I was actively doing community management we would look at those numbers over quarter over quarter it always broke into those buckets we'd have, you know we could guess by the number of registered users this is how many people we have who's gonna be active, who's not I think it's important because I know my first community was Solaris, Big Admin and I didn't dare, dare comment because I was such a junior admin that I didn't ever comment it but I always went there to get answers to questions and do things so the importance of community you know it kind of goes around that too like if you're out there providing a resource for for your community maybe that's resource lives a whole bunch of different places like you said just a matter of keeping track of it and going where people want to assemble one comment on this are creating new platforms and creating new communities especially when operating here in European Union the GDPR and other privacy regulations are extremely expensive if you make mistakes in this and so appealing to create your own community to cater to marketing lists and then fail fast yeah so that's a good advice for anyone don't do it, use existing platforms and make someone else have the onus of the GDPR data collection and privacy so thank you CNCF yeah for hosting that Slack channel and making that happen and especially when working a like a bit larger corporation where there are opens of communities and it's already really difficult to work across the departments like one department could be one funding some community building like events or something and then like yourself is working in another department and you have a different manager and that's already challenging then if you have to go to this GDPR I think with the legal department and communications department it's quite hassle sometimes definitely recognize that our legal department knows me well every time I launch a new website or a new something community it's like oh okay and I think that also we at Red Hat and a number of companies they have open source program offices too and they've been really good about giving guidance on governance and GDPR issues so if you have that at your company that's a great thing but if you're in a smaller startup the temptation to not follow the rules is strong sometimes the force to get those pipelines filled is strong so just the advice from the aged ones that have it's not just in the small companies let's be really honest there sometimes you have to be very willing to have that fight with bigger companies with sales managers, partner managers that also have numbers they're wanting to meet and they're like just like your presentation look at all of this opportunity yeah, yeah explain why it's not for them and I really I think what's wonderful about the evolution of the developer relations role inside of companies is that it is I mean I see it as another arm of community development another arm of open source I mean every one of you I have met through an open source project and then informed like from some of Ryan's work doing amazing things out on things that are completely tangential to open shift and you know just and Gina and Tony and I've seen you on like a bazillion other projects besides the ones that you get paid to work on so I think this the thing that we bring is to dev rel is you bring in ethos or I'm trying to pick a good word here for it but a way of understanding how open source works to the corporate side of the thing of the animal and and help to inform even at Red Hat Tony's been there Ryan's there now I'm here now you know it's like we are an open source company but we still have the same conversations with sales and marketing and partner relations people and navigating that is tricky and showing the value proposition for open source and community work is really been a key thing Diane do you think that the fact that because I think everyone has mentioned like looking at the user and how to connect them and enable them or do you think that's the key to to to working to working with or working around the the chat the roadblocks we all tend to go up against I'm trying to think of you know I know right now especially in commons we have a real emphasis on giving the podium away to our end users and I think the CNCF is doing that as well and trying to get more of our end users to tell us their lessons learned and their best practices for using our technologies or giving us feedback telling us that so I I think the end users are becoming have always been they're very you know high value objects for sales and marketing teams but they're they're becoming more and more recognized as the keys or the linchpins of the success of companies so when we go back to the metrics conversations we had earlier we're talking about measuring pull requests and issues and you know participation on forums and that and quite often those are not the end user actually more often than not the end users are another whole conversation and another whole very key part of how we drive innovation into our projects and get our feedback and I for me I think one of the futures you can't ignore everything else but one of the futures things that keeps community healthy is making sure you have engagement with the end users and that's kind of one of my tenants here besides giving away the podium which we're going to have to do really soon here now wonderful I I feel like I really did pick the right person to give that that presentation I had an inkling there so thank you and Ryan and Tony thanks for coming and Tony I know it's getting late where you are so thank you for we have midnight sun now so it's okay it's like it looks like it's on its side yeah we never got sun today here in Canada it's been gray and rainy the whole time so it's good so then I just don't have any time so thanks again