 So, let's remind the lovely audience, just very briefly, who you are and what you do at Redhead and with OpenShift. All right, so you all know me by now. I'm Diane Mueller and the Director of Community Development for the whole cloud platform BU now. So, I get the operator framework and OpenShift and a little bit of OpenStack and anything else they throw at me. So, it's a lot of fun. I'm Ilka Tengval, solution architect at Redhead here in ESPO and mainly doing OpenShift, OpenStack, cloud-related automation stuff. And Jeremy Brown, Redhead Open Innovation Labs, I kind of look after the whole thing here in Europe. There are 100 OpenShift specialist solution architect working pre-sales, so I do these POCs that are so successful and people buy OpenShift. And he is so modest. Yeah, I'm most of that, yeah. And Ed Seymour, working with our customers to help them with OpenShift adoption. Yeah, first of all, as Diane mentioned earlier with, you know, the cross-community collaboration, I want to thank Diane for letting me have this chance to... Collaborate. Collaborate, yeah, and learn more about OpenShift and also get to know the wonderful community that she works with. So, thanks for that. Thank you. And speaking of community, and because I also, you know, do something similar, and you mentioned earlier on today with the change of the name from OpenShift Origin to OKD. And it wasn't mentioned until Ed came up and, you know, talked a bit about it. Maybe you can tell us more about what you want the messaging to be like and how you want it to do. Well, conceptually, when OpenShift was first created, it was, as I said earlier, a Ruby on Rails platform as a service using MongoDB. And we had all these wonderful, almost proprietary naming conventions of gears and cartridges. And I've been with Red Hat now a little over five years. So, for the first couple of years, we were always trying to evangelize that platform as a service. And then when we pivoted to Kubernetes, the open-source project has always been Origin. And when we pivoted, we kept the same name for the open-source project that is under the hood. But it didn't really reflect what the true nature of the open-source project was. So, the renaming initiative is really around making it very clear that our open-source project that is upstreamed into OpenShift, all the products, is at community distribution of Kubernetes. So, I think there was a little confusion about that. So, we're hoping that by coming up with OKD as a name, much like RDO, it means you are not legally allowed to say exactly what it is, you know, or call it an acronym. It's not an acronym. OKD is the name. You can think of it as, OK, Diane, you know, really? So, anytime anyone says OKD in the engineering team, I think they're just agreeing with me, right? So, yes, I need that in OKD. Yeah, cool. So, but it really is all about making sure that the people who are using the project are aware that they are getting a distribution of Kubernetes every time they download and install it. So, we're hoping the name change isn't too confusing. I don't think it is. And to make sure that it's really not that confusing, we didn't change the repo at all. So, any of your scripts, you know, if your playbooks or anything that you wrote or any download automation that you've written should absolutely still work as is. So, we're trying just really to make it very clear that this is not a fork of Kubernetes. It's not a platform as a service anymore. It is a distribution of Kubernetes. If that is clear as well. OK, Diane, I agree. And we hope to hear more about OKD as we go along. And I'm thinking maybe we should have something called TKC dot the guy, Carol. Yes. Dot the guy means, of course, Carol. Yes. Anyway, so maybe we can let Dero ask himself a question for now. Yeah. Hey, Dero, what about the K native? That's a great question. Google announced, you know, Google Next K native initiative, which is basically a framework to help build serverless solutions on Kubernetes. So it uses customer resource definitions to build the basic clue between the serverless implementation and Kubernetes. And the Red Hat's platform functions will be built on top of K native and we are contributing to it. And there's a proof of concept code on GitHub at the moment that Ben Browning has been doing. Yeah. So check it out. And a demo. There's a video demo as well. He's published a blog in a demo. So, yeah. It's quite cool. All right. So maybe at the end of this, we'll share all the different links and slides. Oh, yeah. Yep. There will be a recap blog. Trust me. Sounds good. So this is the first time I'm actually hearing more details about the innovation labs. So maybe you can tell us. You mentioned that there are pop-up labs that can provide very similar services. But what is special about the physical labs that maybe people who, like me, like to travel, who want to go and, you know, how would you describe what the additional stuff you can provide at the physical labs? Spaces. So, by the way, what's the secret sauce about what we do? It's the open parts of the open innovation labs. I think, in some ways, I think that there's nothing special about the physical space at all. But actually, we did design the physical spaces with a lot of intention about how we were using the space. So if you come and visit us in London, I hope some of you do come to London to visit. It's kind of a funky space because we didn't have, like, a huge big room. It's quite a long, thin space. And we use it for a lot of different things. So we actually built it to be constantly changing. So everything in the space is on wheels. So we even have lots of plants. I kind of actually originally wanted a living wall in the space. But our workplace solutions, people told us that living walls are expensive, Jeremy. And we're an open source software company. We don't make that much money. So you can't have a living wall. But you can have some plants. I said, can they all be on wheels? And they thought, well, I'm sure we can put them on wheels. So everything is on wheels. And the reason is because we wanted every team or, you know, we can host, like, up to about two pizza teams in this main space. Every team can build the space for how they want to use it in their configuration. So part of the practice that we have, even in the pop-up labs that we do, is actually that the teams build their own physical space. Actually, other companies are also doing this. So Valve, who make computer games. All the desks in the office are sit-stand desks, the actual desktop machines that developers use are all mounted inside. And they're all on wheels. So literally when a developer wants to work with another team, they can just unplug, roll their desk somewhere else, and actually plug in again. And that's kind of the principle that we used. So that's kind of cool. Also, I should say if you come to us, we basically surrounded most of the space with writable whiteboard walls. And we didn't have enough space, so we've actually taken over all the windows. And we also have, like, post-it notes everywhere. And I think that's one of the things that you can take from our physical space. And I think if you talk to any of the people that have been in some of our residencies who are here, is that we really like making all of the work that we do visible and transparent, so that we can have a conversation about the work. So we actually use physical Kanban boards or physical Sprint boards. All of our architecture is kind of in the open. So that's some cool things. I could talk loads about it, but yeah. Sounds nice. I like to visit it myself. I have more questions for our panel, but maybe it's time for me to get some exercise. So if there's anyone in the audience with some questions, we'd like to hear from you. Come on, Finlay. We need to bring in the beers now. The trick in Finland is you just have to wait longer. Okay. All right. All right. So for Ed, you mentioned about figuring out how an application can be containerized. But as Dero, when he talked about serverless, there are some cases where you don't go serverless. Is there some very obvious or clear-cut cases that you don't containerize enough? Yeah, absolutely. So we touched on a couple of those in the presentation around maybe the architecture isn't quite right and things like that, but you might have applications which technically you could containerize, but maybe they're nearing their end of life or the actual business value that you would get out of moving it into OpenShift just doesn't justify that effort needed to do that. So that's quite often you can see that. And what we typically end up with, when we do things like, and Jeremy mentioned things like Pathfinder which help us make these sorts of assessments, is you look at a range of applications. There's probably some very quick things that you can do to filter down. So you maybe get a body of applications that you know portfolio that we then go and do run those assessments on. And then based on those, we might decide that we'll just leave it alone. We might just be doing a re-host. So we just take the app, put it in a container. We're not changing the app at all. We're just running it now in a container. We talk about re-platforming. So say you wanted to modernize, say you were running a JEE application. It was on, I don't know, JEE 6 and you wanted to go to JEE 7 or 8. Then we can do that so we could re-platform. And then you start getting into refactoring. But ideally what you do in that first phase is to basically get the apps onto the platform and the development teams adopting that and the operational teams adopting that approach is the way that we deliver that application into service. And then once you're at that point you've got what you might call a fast moving monolith. And so we can then very quickly then iterate around that and start making improvements to it and innovating around that. Can I comment on the fast moving monolith? So so many of our customers are coming to the Open Innovation Labs to do microservices for the first time. And I really think that they're trying to go in the wrong direction and the fast moving monolith is actually what they need. Microservices introduce a super complex distributed system problem for developers and the only reason you would do that is where your monolith cannot, you know, I think in the rule of thumb is that with the monolith usually especially it's basically down to the number of people that can concurrently work on that monolith at the same time. And the reason you go in microservices to split it out so more teams can work in parallel but a lot of our customers are doing microservices with like a development team of six. And I don't understand that, right? So I know that it's kind of cool to do it but we've had to kind of tell customers maybe just take it back a bit and do the monolith because that's all your business really needs because we all want to do cool technology. I don't know if you've... One other thing. You don't need the microservice to start the cultural change. Yes, exactly. Yeah. All very good considerations. I think, yeah, the thing about people always want to chase after the latest coolest technology and sometimes we need to pause and think about is it really necessary, you know, doesn't apply to all cases. So again, any questions? Good. All right, I can run them. Uh-oh. We're going to get the next kernel question. Oh. Sort of. Oh, great. Well, the technologies here and the kind of open source and everything like that is all about the community. So I would like each of you to describe what do you consider the top first most meaningful contribution to the community here? That we personally made or... Oh, my God. But in our entire lifetime, this could be interesting. Oh, you've got the best... You can tell the best stories, Diane. No, I think the oldest story is probably... I think some of the work... I've done a lot of work in the early days of XML and HTML and some of the XML standards working on financial standards if any of you are filing corporate reports or doing anything with XBRL. It's not my fault, really. But yeah, so a lot of my very first experiences were with highly regulated industries creating standards for that and doing open source contributions to some of the taxonomies around that. So really ridiculously, our counting knowledge. But it taught me a lot about working with bringing open source awareness to companies that have very restrictive interactions with other companies and how to create collaboration in the financial sector, which is one of the toughest arenas and still working with other organizations like FinOS and banking industry standards groups or open source groups. They still struggle with being able to collaborate in the open. I think we've cracked through a few of the walls but there's still a lot more work to do. That was sort of my first taste of community contribution. How about you? Well, I started my open source work roughly. I decided to check if I could get paid by just doing open source around year 2000. So at the time I was working in the company that wasn't any kind of open source publishing because at that time it was about do not release patents or something. It was a heavy time of fear, uncertainty and doubt. So my contribution at the time was inside that company. So it was a rather big company. So I was doing all kinds of like Linux and Linux kernel maintenance and stuff like that. Distribution maintenance for the company and building community around that within the company. The company was at the best so it was like open community but within the walls. Luckily I got the chance to go to Linux Cons and such events to interact with the other community members but could not unfortunately post anything in the public at that time. So after that also similar it's also contributing to the community I think when you, like for example this open stack fin group that I've been similar group like not this big but anyway local meetup I think it was 2012 or something when I started it. So acting as kind of accelerator for bringing up some communities. Maybe that. And nowadays of course everything if I write some instruction or something I probably put it also into GitHub. I think for me I have two personal stories to tell you. With a friend of mine some of you guys know Keith I travelled through Africa on a motorcycle and if you go to twowheels2africa.com the number two each time you'll see our old website. We accidentally ended up starting a software company in Cameroon and the company was the company that I was talking about was the company that I was talking about or something. Keith had a problem with his very long story but he had a problem with a little magnet inside his KTM that basically stopped working on the engine. We had to get apart this size sent from Germany and the company that we did was it was a software consultancy company and in the end we did some local consulting within Cameroon and then we had a partner in Switzerland who gave us photoshop files of designs of websites and we created PHP themes and wordpress and plugins and stuff to make the actual websites look like the photoshop where we employed some guys in their office into a co-working space and this is the real reason why we wanted to start our own company we felt like we wanted to find Cameroonian guys who didn't have a lot of access to seed funding and capital to find guys who were starting little internet companies in Cameroon and we got them seed funding and in order to actually find these guys we actually started Cameroon's first bar camp and first conference for developers so that was super cool and that was kind of community I've done lots of contributions to open source in minor tiny ways I think most of my background is not Linux it's Java, I worked doing Java apps but I think the thing that I'm proud about now is I think I contribute a lot towards Red Hat's commercial success and I know that doesn't sound like funny in a kind of a community way but I'm really motivated by the idea that open source is transforming the world and making everywhere better for Red Hat as a company to continue to exist we need to make money we need customers and I feel like one way that I contribute to that is the continued commercial success of Red Hat so while we have shareholders that are all very greedy and all the rest being able to satisfy them definitely helps us continue to do the open source thing that we're doing yes exactly my words actually most reason is actually with Tania and I and I arranged in this event but I haven't done my code contributions but let's say that sometimes I find a feature in our product so creating back to the tickets so informing about those features that we might have so that they can be fixed in the upstream I think that that's the most important how I have influenced okay cool so I started in development actually in the mid 90s and around 2000 we started writing in Java as well so I started off as a developer I don't write code now but if I do then don't touch it because it would be horrible container it would be nicely contained but what we found with doing Java in the early 2000s was there were all these libraries and we could start building stuff together and I became more and more aware of open source as a real force for good from a technical perspective as well in that we could build our application in a way that was right for that application and the application design and not be locked into making choices that were there to drive a particular proprietary business case that we would if we were buying software from a vendor so I felt it actually improved the quality of our software it was still pretty bad by using open source technology I'd say nowadays moving on actually getting involved in communities it doesn't need it can be this taro was saying we can contribute just by raising issues there may be a dox bug or something like that I mean just I remember the first time getting a PR accepted it was like wow this is really cool I'm really part of something and it was just a really simple thing it must have been one line of code that kind of stuff is really great it really feels like you're actually contributing something really valuable and worthwhile so that's my experience great question I actually got to learn a lot of my own colleagues and I've actually heard of Tools to Africa nice to meet you in person and I agree contribution to community is not just code, organizing events attending events, telling your friends about it translations, design there are many many ways you can contribute and I'm actually going to abuse my moderator privilege and tell you a little bit from my point of view what I did I used to work for Nokia and I was working in the multimedia team and we contributed to this open source project called Helix Engine I don't know if anybody know about that my real networks it was cross-platform multimedia framework so that was my also first open source kind of experience I've used Linux before but more as a user so that was that but there wasn't as much of a community around it so I would say even more influence or stuff that I did was after living Nokia I started organizing like Migo, Meetups and later joined YOLA the company which I think many of you here might know and built a community around selfish OS so and of course then a couple of years later I'm here at Red Hat doing more for open source and for the community alright thanks for that question any others I would add one more thing to the experiences in community not needing to be code contributions one of the very early jobs I'm a python person not a Java person probably the only python person on stage probably alright there's more than one of us and we do no go but one of the first jobs I had for the python community was reviewing all the licenses in all of the readme in all of the python libraries for active states distribution of python and talk about learning curve because you needed to make sure there wasn't like a poison pill kind of license in the distribution and somebody had snuck one in or forgotten to put one in so my big lesson that I learned through that was I probably could tell you yeah all the different licenses that are out there in the python world or were about 10 years ago but also the one thing that I would always say is if you're contributing code back in there make sure you put a license in there don't leave that blank because that is almost worse than putting a bad license in or a prohibitive license in there because by not putting one in you're causing anyone who consumes your code to have to go back and review it and reach out to you, find you and get you to put it in or it breaks their license agreements too so there's lots of aspects of community and contribution that you can really help with but if my one pet peeve is please pick a license put it in there and make it in your repo and make it available Can I make a comment on the license thing? I think don't just pick the most permissive license be really thoughtful about what you're doing when you're doing the license and also when you put a license on a piece of work it's kind of affects that work and if someone finds that you had an old license and you changed it there's some implications my personal view is I would strongly recommend that you consider the copy left licenses for a lot of use cases to protect your work think about it like DJs if you don't mind that another DJ remixes your work and gets a record hit and makes all the money from it you can put a permissive license on it but if you want to somehow make sure that that DJ who makes a piece of music from your work you can then remix their work and use their work to make other hits then make sure you put a copy left license on it and I think there's a little bit of an interesting reddish story that's just kicked off so that's what can happen if you don't quite pick the right license so just think about it like in the concept of DJs remixing music if you're okay that someone can take a piece of your work and make a proprietary and you don't have access to that work anymore think about copy left is that you can all if they make a fork and it's better than what you did you can always pull it back into your work whereas if it's permissive the remix ability disappears just a thought we could have a long conversation but yes thank you for bringing that out great advice Nero did you have something? if you want to contribute feel free to catch us from the meetup.com and have an open shift meetup if you have a team, you have a venue you have free beer that's fine we can help you we can help you find a speaker if you have a topic we can find speakers so if you want to basically build this open shift community in Finland yeah very good any other questions? or for each other perhaps? I would also add along with the meetup stuff we do on OpenShift Commons tons of OpenShift Commons briefings like two to three a week and the SIGs do usually when the SIGs happen I make them do at least two mini talks within each SIG meeting on different topics so there's lots of content out there but what I'm always interested in is hearing what you want to hear about so if there's a topic that we didn't cover today that you want to hear more about could you let us know over beer or something like that or if there's a topic that you want to talk about if there's some open source project that you want to hear about pontificate about or promote please let us know we really I always joke I don't like to hear the sound of my own voice anymore I really want to hear what's going on out there and we've been talking a lot on the sidelines today over coffee at different times about trying to figure out what the next big thing is and a couple of things have happened two things is one because OpenShift and Red Hat is doing so much work on Kubernetes we really get a lot of insight into where Kubernetes is going and stuff so I'm going to try and do a little research about what the network effect is where the next hotness is in the Kubernetes world and it's very hard to predict that but I also think that there's quite quite a bit of one of the things that's been wonderful about being part of the Kubernetes there is sometimes I get to be one of the reviewers for the call for papers for a KubeCon and I think KubeCon this time had over 6,000 submissions so if you submitted to KubeCon and you didn't get accepted I don't feel bad because there really weren't I forget exactly how many speaking slots but it was like somewhere on the order of 300 speaking slots so you didn't get in but if you get asked to be the reviewer of a conference volunteer and say yes because you can't believe how much you learn about what the new things are or what people want to talk about and are passionate about and I have learned so much by just looking at the agendas conferences and reviewing people's papers about what's coming down the pike but it's you guys out there that are really going to help us understand where we should be going with OpenShift and with Kubernetes and with all of the other projects at Red Hat so please if you have topics that we didn't cover today or we're not going to cover tomorrow at the Red Hat Forum please let us know and tell us over the beer that's coming shortly as a promise of beer and shouldn't they also present at the comments? Oh absolutely Customer stories? Customer stories are great we are a POC a production use case if you're an OKD user you're an online, a dedicated at Google Cloud an Azure user if you've got a production case study and you want to talk about your journey like the folks did earlier today please let me know because again I probably look like I love the sound of my own voice because I talk so damn much but I really want to hear and have you share your stories so that everybody learns from your lessons and your worst stories and your successes so that's really key to keeping the conversations and the stories flowing I really like Iwka's drawings and also his voice so I'd like to ask you a question about being like Gimi Reichenan where you focus on stuff and don't worry about the things happening behind you and gain speed but occasionally something you might be blindsided and something hits you or something how do you deal with that? How can you prevent it or how do you recover from it? I think the openness could be something that if you just do stuff on your own you get blind to whatever you do so also when you create it's a forum where you open up let others open up you also and be open for the criticism and discussions when you have healthy discussions I think that's the way I would add that whatever approach you adopt you need to be looking at an agile approach where you're able to assess what you're doing and the direction that you're going at regular short-term intervals so if the unexpected happens then you're able to adapt your plans and change and reconfigure around that What's the last thing of your drawings? Oh, shoot Is it license or is it creative comments? It's creative comments We'll put the deep end of the pool one Those are actually on it back You don't want to remix those? It's really funny that you mentioned openness is the place to start with some of this because what we've been learning is we've worked with customers in their transformations We talk about the pillars of open organizations but we found that transparency is actually the first step in transforming organizations just sharing more widely the work that you're doing and making your work visible is a really powerful part of that It's really interesting It's part of breaking down the silos Absolutely Alright Any other questions for our lovely panel? No technical questions They want the beer When we wrap up I'll do the closing bits and then we'll get to the beer Big hand for the panel Thank you