Brian Dawson and Kohsuke Kawaguchi – A Server-Side Chat: 10 Years of DevOps and Beyond

Hello, thank you for joining us. I'm Brian Dawson, and I'm happy to have you here for our server side chat, not a fireside chat on 10 years of DevOps and beyond. I'm joined by Kohsuke Kawaguchi.

Kohsuke, how are you doing today? Hey, hey. Glad to have you.

Thank you for participating in this session with me, for our audience to kind of give an overview of what we're hoping to accomplish as we were preparing for this for this event, which I'm excited to be a part of the DevOps Experience. We started to think about, there are so many things going on in the DevOps space today in terms of tools, technology and practices. Maybe it would behoove us to talk about how did we land in the place where things like get ups are so prevalent and so critical to what we do.

And I thought it would be great to bring in somebody that was really early stage and at the forefront of our modern automation movement coach and discuss how the industry has progressed since the time that Jenkins' was introduced to now. And what does that mean for the future of DevOps and the community? And my friend here, as well as a former colleague, as well as someone I look up to, Kohsuke has been kind enough to join us before I hand it over to Kohsuke, because I believe most of you are like, yes, I know him, but who is the guy in the weird polka dot shirt?

I'll introduce myself. I am Brian Dawson. I am DevOps evangelist for CloudBees, as well as a director and product marketing.

I arrive here by way of, I think, twenty five plus years in software development. I started as a developer in game development, ran a tools and technology or shared services team for Sony Computer Entertainment in the early days of PlayStation, and then had the privilege between then and now of being multiple what were largely forefend portion. One thousand companies implement agile continuous integration and continuous delivery and most of the time we did that with Jenkins'.

Kohsuke, the man who needs no introduction, as I always pick on him, is an adviser to CloudBees, the former CTO of CloudBees. Today, he is the co-founder and CEO of Launchable Inc. Hopefully he'll tell us more about what Launchable is doing and is particularly relevant to today's discussion.

He is the creator of Hudson and Jenkins'. Again, welcome, Kohsuke. Can you tell us a little bit more about your background as well as what you're doing today after an introduction like that?

I don't know what else I can do, but yes, I you know, I've been working in the part of this space for, I guess, the past 15 years or so. It seems like there are two kinds of engineers in the world that the ones that keep going down and down the technology stack and then there's and then some people just keep going up and up the more focused on solving people's NDs problems. And as a former CEO and then so aside being so that's what I've been doing that.

And, you know, the you this was a major part of my career and then I sort of switched to back and in this new startup. So hopefully I get to talk a little bit more about that in the coming hours. Yeah, well, I absolutely want to talk about about that.

So I have on the list and for the audience as well as us, you and I agree that there's a number of things that we want to try to hit is we had this discussion and they include but are not limited to the founding and creation of Jenkins', really the growth of continuous delivery that everything is code movement, that is the foundation for getups. But then also in there is machine learning and artificial intelligence, which is why I think we're we'll dig in with with launch. But I'm pretending I'm interviewer for a sec before I go there.

Kohsuke, I have to pin you down on on the relationship between the continuous integration and possibly even considering the agile movements and the creation of Hudson and Jenkins. And I'd like to ask what drove you to create Jenkins'? And then, moreover, what impact have you seen with all of your humility, Jenkins, have on the community since?

Sure. Yeah. So, I mean, there are a number of reasons, a few reasons that inspire you conspire together that led me to create what eventually became and what was it the I guess I wasn't occupied enough by my day job that's been very prolific.

And so I had a number of open source projects going and this just felt like just another one of them. And then so I'm behind this fund that became particularly popular. I can carry hundreds of projects that I don't think anybody has ever heard of.

So I just happen to be one of the many that I was going to step out of. But another one was the discussion around the time when the Sun Microsystems either losing a lot of people. So I was looking for ways to kind of use the technology to beef up the team and people around me, and that can make more people productive.

And that part of the things was, you know, when the developers are working a team, they are spending a lot of time communicating. So they're figuring out the what the collecting truth the team shared through like is this test passing or failing to break something or not? And then we only had that one phone system to do these things.

So we felt betrayed. I felt like this could be a software problem that we can solve. So that was one of the reasons.

Yeah. So those are a couple of reasons. So I'm curious, so so first to share, then I had a couple of questions on it.

So around that time I was at Sony Computer Entertainment. Now the PlayStation company trying to figure out how we increase team productivity. A little bit of background right around that time we went from I believe it was PlayStation one to PlayStation two.

We had 16 processors. We went from from one dedicated geometry transformation to CPU and an audio chip to those plus 15 additional processors. We had to figure out how do we increase efficiency enough that we can capitalize on that increased power.

But to put it very grossly, not not require 16 amount of 16 times the amount of resources or 16 times the amount of time to bring a game to market. And I'll talk a bit about what I saw on open source there. But or ask you I'd like to get your thoughts, but that's when we started to engage around.

This was a time when Source Safe was asked and sources were still prevalent and version control systems build Forge was just gaining traction and and around. I servers already out there. I think Continuum was out there.

I think Thoughtworks had taken a first pass it go. I'm curious, when you thought to create Jenkins', was it identifying a problem, sort of independent of these practices that are now well-established or you were watching what was going on in terms of agile, XP and specifically can can you continuous integration? Yeah, no, I never I thought of it that was almost completely blind to what was going going in the broader market, like where the industry is going and figured out that this is the right thing for me to work on.

It's nothing like that. But I think it's just more of this. It's more like just to be at the right place at the right time.

This was around the time and the notion of using more and more computers effectively for people. So like I became popular, the practice itself has been kind of our own for a while. And I do remember like seeing a number of open source software in this space, like a cruise control think cruise control.

That's one I forget. Yeah, yeah, yeah. So I was looking at those software and I felt like I could do a better job than these guys if I could just be from the perspective I can program.

Right. So and then there's a targeting system. I think that was another.

Yeah, so that was another key for me that got the key ingredient in that I thought everything would be better with the filing system and if I was looking for opportunity to insert one and then this felt like another metro vehicle to do so. Yes. And maybe if if anything can be attributed to you like a careful design, perhaps that is the one that can be pretty worthwhile investment.

Well, I think, you know, and in my opinion, we'll sharing memories, too. Actually, I go back I don't know if it was 2011 Kohsuke when the first JCS Jenkins user conference was held. Is that correct?

Yeah. Yeah. Maritime Theater in San Francisco.

That's right. And I remember I think it was Liferay said, you know, they love Jenkins. They talked about how they scale it and use it, but they said they view it as chron on steroids.

Mm hmm. So sort of a job management job scheduling system. And it had a lot of power as a general automation server.

And it still does something I think was really powerful and to be interested in your thoughts around it, but is what really supercharged it and there may be other things I'm missing was the fact that it had a a a reasonably easy to understand, but also very powerful plug in architecture and and the ecosystem that grew from Jenskins. And since then, I would beg to say, and I know I probably pump you up too much sometimes, but that that has had a lasting influence and impact on the way tools in this space are built, that in order to implement or support CI and CD and the enterprise, the ability to treat a term, I use tools as micro services and having an architecture that supports kind of plug and play of additional tools is is is key. So to stop for me, just talking and asking is how how do you think Jenkins' itself and then maybe a bit more specifically that that that that plug in approach has had at impacted what we do since the time it was implemented.

Hmm. Yeah. I mean so for me that I do well..

Key source... a key product that I got inspiration from. I actually I think a and netbeez both of them are very extensible platforms and use those plug in mechanism is a huge success.

And so that was I think, the main source of inspiration. But back then it was kind of hard to do that for Web applications. E platform.

In which Jenkins was built, so I was trying to convince the senior people around me that we didn't need to be able to do these things. And for me, providing these of the services that I couldn't make them understand what I was trying to do before. So I something I didn't invent it, but I did what it does, I think, and maybe I also didn't quite understand that the the the social or the implications like a white my in success, while it is also a technical construct, it's actually more of an incentive to do the work for the social structures in the community, like it allows people to experiment and do something they want without spending too much time communicating and arguing and convincing other people why doing it is worthwhile.

And that turned out to be a great way to unleash people's creativity. And while it's somewhat chaotic because I know there are a lot of failed experiments and but there also could be bubbles up the successful ones, and collectively that works very well because this idea of open source projects expanding around the globe and people doing their thing. So, yeah, so that's that was a surprise that I felt like my bit was paid off on that one.

Yeah. I mean, I, you know, you moved on after that being serendipitous development and not without, I think, a level of background and thought that was important, even if it's serendipitous. I mean, you you know, you had since made a long stretch of your career really focused around, I guess I'd say, for want of a better word, bettering DevOps.

Right. And bettering DevOps while you better Jenkins'. And what I think is really interesting about your your your reference to the impact on a plug in architecture and ecosystem on the social components it.

It starts to cascade into what was another key thing in the past 10 years within DevOps or enabler, and some people may argue that slightly before, but DevOps, I believe where we are with the community and its collaboration focus, we wouldn't have achieved it without open source. So there's some of those tenets of collaboration, experimentation and empowerment that the plug in ecosystem provided that that open source enabled for experimenting with new practices and tools within the enterprise. , bring IBM and 50 guys in to solve the problem, and then only to have the market move beyond you.

The next order be on that is that, you know, we talk you know, you talk to Patrick De Bois, Kris, Kris Buytaert, you talk about what they were thinking when they launched the first DevOps days. And what I've heard from them is they just saw that there were people working independently on an area of shared concern and there was a lack of collaboration. And I still hear to this day from them that they see DevOps.

It's not about a process or a practice. It's about community and collaboration. It's about community collaborating to solve problems.

Yeah, I don't know if you have thoughts. What are your thoughts now since that time on the DevOps movement? What interested you in it and where do you think sort of DevOps practitioners can do or be better?

Yeah, since I mean, you're talking about the sort of the communities exchanging practices and so on. And one of the things that I keep reminding myself is just how diverse, you know, when it comes to how we build software, the software industry is pretty big and different, like you talked about the Sony building PlayStation. So that's like a kind of sustainable band.

And then there are other people doing like a microcontroller inside or whatever devices, cars and whatnot. And and then there are people like service companies and the constraints and the factories surrounding them are so different these days, the different kind of DevOps practices. And it's it's also so so funding about handicapped state..

There's not a lot of uniformity compared to, let's say, something like CPA. It's a pretty universal thing across the entire nation. But so we start with that background of diversity.

But then, like, we need to suck at communicating or sharing and extending the practices. So the spread of these things are pretty slow. And I think the most primary vehicle is the second poking or the prison thing and so on.

But that's actually still pretty efficient. And what's the best, I think, about some of the decent presentation to you so that you felt that this is really cool and then think about what it takes to actually apply that in your own team and organizations use there for them. So I think if you feel what you know, based on what you see or you see a lot of different, see that might.

But I do feel the sense of this similarity or some convergence factors that's playing. Well, so. K.

And I feel I still feel like first I'll say that that at the end of the day, irrespective of the space or the type of software, even if it's an embedded system going inside a car's MCU module, at the end of the day, we're developing software as developed by humans, for humans. Everything else in between is enabling and optimizing that. So why do I bring that up?

Because I think what Jenkins has done to an extent, what opensource has done, what the DevOps community has done, has sought to build connections between humans so we can get from that Star State to the end state better. And frankly, whether we're influencing that via automation, whether we're influencing that via, say, moving to Kubernetes for container orchestration so we have more deterministic managements, et cetera, et cetera. At the end of the day, we still need to and will continue to need to better build connections between different people in the same organization, outside of the organization and functional organization to better enable collaboration and unlock the flow of ideas.

And when we talk about like CI and CD, and you and I both experience this work in at CloudBees, so I'll probably flip it and ask you a question again. But I think what we realized is that. That when implemented in a local and a local area within a given functional team and a group within a small company, within a given space CI and CD, while may be challenging, you can be wildly successful.

But then when you try to propagate that across multiple teams, multiple technologies, and what people are trying to do today implement this is the way they develop software at enterprise scale. I will now get to where I see the same needs you talked about converging again. What we have is various communities that are failing to connect and collaborate to achieve efficiency.

So what is our challenge is we need to figure out how to grow and scale these principles and practices across enterprises, teams and organizations of all types. They answer the right question. No, I don't think there's any right answer.

So I left very folks on what I was thinking of that I was doing, as you know, the, um, so so in this in my new company and exclusively doing a service, which is a big change from using open source software, which is mainly BS. And, you know, it's it's a very different mindset because the considerations are different. So I constantly find myself needing to support I myself.

And then so and then in some sense, like a similar things happen throughout the different lifecycle projects as well. So thinking is also evolving. And the way I was doing things was also changing.

And so part of what I think makes this adoption of CI/CD practice a journey that seems so tired and questioning is it's like it's like it's like a parent growing up as kids grow up. And if the parents need to be at the right mental state and phase depending on the kid. So you can just like so many dynamics.

So I think that that's something I think about this. Yeah, that's interesting. I can almost I know we're going to start from push for time, but maybe when you and I have another offline conversation I'd like to talk about because I had kids at this stage, I'm going to go on the tangent for a minute compared to a lot of people.

I had kids relatively young and it is really interesting to be learning yourself, growing and evolving as you have to steward the growth and evolution of a child. So I can see the correlation right with your practice is growing, the community growing and then having to store the product. I do want to do because we promised the audience that we talk about futures and we talk about Malini.

What I'd like to do in our last few minutes here and if you want to flip it and ask me questions, that's fine. I'd like to highlight one of the other advents that happened in the past 10 years that I credit you for, that I think also speaks to the future. And then let's talk launchable ML and MAI.

And I am so one of the things that that we actually collaborated on that was part of yours and the Jenkins' governing board and projects development was this idea of pipeline is code. So it started as Jenkins' scripted pipeline, then Jenkins' decorative pipeline at a time when a lot of prominent product projects were using configuration to describe things that needed to be done. But at that time they were largely static.

They were JSON or Yamal. And and your team came to market with pipeline as code really at the early stages of the everything is code moving. Now, today, we're seeing a real wholehearted embracing of things like GitOps for managing your SDLC and your environments and doing them in a repeatable way.

I'm curious, where do you think the pipeline is code? Everything is code and GitOps has offered value. And what role do you see it playing in the future going forward?

Yeah, I mean, yeah. So this I guess I also so this kind of I can move into the progression and I certainly don't think I can think that anywhere near the forest there are the well established ideas around this, you know, doing things that's code I think maybe probably back then as far as my immediate predecessor, I think like a chef and puppet. I think these people are really beyond those.

And so, yeah, that made sense and sense is obviously a good idea. And so as a CEO, you also know and it was helpful that you see so accessible so we can find something like that easily. And then I think that one came a little later.

But it's also like a continuation of the same thing. So, yeah, I think it's. I think generally I mean, there's no question it's established practice that now, I think very seldom commend you for the success of practices like it's combined with this collaboration that of progressed and closer to becoming a point of the collaboration.

And then it's also turning into a good handle between invisible big automation systems that the people are building behind the scene and the human physical activities. So that seems like a good today's roll separationists. You just align...

The technology boundary aligns with how people are organizing to work today, where I am sure you talked a little bit about this lack of productivity, engineering, a bit central DevOps these people wants to build this like a machine that's not necessarily need to be understood by the application developer. So that's not an organizational boundary. Or if the organization it feels like a dirty word.

You can think of collaboration like... But the connection point, the API, where is the API? And I think that I remember that the technology boundaries of these corporations structures.

So I think it's finding that complete alignment in that. And I attribute that success to that. Yeah, yeah, yeah.

I... Let me see if I know I'm racing against time now, but what I think was big and I'll add some commentary is that we were able to kind of take look so sourced source code management, especially modern source code management, since CVS, central version control system, moved from not just versioning, the work you did. So it was traceable and trackable, but also facilitating collaboration.

Right. And that was really unlocked and brought to bear with the pull request. Right.

As well as some of the other functionality GitHub built around that. And and so on the bright side, you on one side, everything is code kind of brought forth some of the best of software development practices, collaboration practices to managing your SDLC. But there was another shift, and that is that, as we know, a Jenkins' freestyle job was oftentimes heavily configured through through your GUI.

If you were dealing with any released orchestration solution at that time, you were dealing with a bully. Now there's times for GUI. But as you talk about that collaboration boundary to drill in on that look, now we're moving into a space where where your shared services, sort of your DevOps engineer, your developer and your release manager all kind of have to collaborate around this, the shared system of truth.

Now, what I believe is why we're going to see we've seen it with software defined networks and other things. We're going to see increased adoption of everything is code for the software development as best practices. But you know what?

The GUI doesn't go away. And when I'm starting to see that is that is my most call it a case of serializing what we're starting and then it's probably a better term for it. Right.

We're starting to see serialization into code and serialization from code that allows the different stakeholders to interact from the position and the perspective that is best fit for them, but still have it all reconcile to the same thing. Anyway, a lot of words there, but I think that aligns to the collaboration boundary or interface point needing to align with the technology boundary. Yeah.

So I mean, I wholeheartedly agree about the importance of DUI and in fact I can back in the days in Jenkins. That's why I made it accessible. I call this the fear of the blank job losses.

Like when you are asking... when people have ability to, let me tell people to, yeah, you can back up this like a computer science code, like they need to start with the state and that's pretty scary. So yeah.

And I think it makes sense that could do the same thing with Amazon. Right. I think it will not be the best console.

But yes, people are using their. So that you talked a little bit about the how those things might converge. So I, I, I think that would be maybe like one of the Holy Grail effects.

I think that might be some of the mountains to kind of solve. That would be I would have a far reaching implications there in so many domains like my kids program. I need to be using scratch to programming environment.

And and then if this is something can be defined between these sticks that covers uncontrollable world and the more accessible as you can point the thing that I mean, that'd be amazing. So I've every one of these programs, so. Know you want your money.

I was just going to say, when are you solving this point? Well, the shift I want to I want to talk a bit about Launchable. What are you doing at Launchable?

Why did you found it? You and Harpreet, your co-founder. And then if you can tell me and I'm also saying this, I know what you guys are doing.

I'd like you to share with the audience. I also know for whatever you say, you tend to always be very forward looking. So what are you doing at Launchable?

And how does what Launchable decided to focus on serve as an indicator for where we need to be looking at in the future of software development and delivery? Sure. So, you know, part of what makes me excited is like I, I want to be helping people.

And sometimes these are the conversations, like I say, the culture transformation, the digital transformation, the revolution. And all of that can be some that became a little too big for people having these challenges that in day out. So I was thinking about what are the kinds of things that I can bring some immediate help.

And that is the same thing is always going to be that the part of the motivation that gets through. And then another thing I was thinking is like I help make a pitch the state, the motivation for the leadership. And so more and more people are doing lots of automated work around them in the software development environment or as yet by, you know, using any of the information coming out of these automated systems to improve the process.

So and then that was an idea that I helped about keenly. Even at CloudBees, I could see the marketing people. Salespeople are far more number driven and more meticulous and vigorous in how they do work and how they measure their efforts and progress and what needs to change.

And I look around and I see my favorite engineering team and we can tell them, you know, that's a difficult task. So I and that made sense. I felt like there got to be some means.

It's like I can use all this data that's coming out of organizations to maybe help automate some of the decisions or make some of these some of the lifestyle DevOps easier and that respect race there. OK, so we have lots of test running. And at Jenkins project to the end, I was involved in the one line change is going needs to go through.

The full cycle of it is like an awesome one. Now that I know, like this one line ten doesn't need to be done in biopsy because most of the test of different parts of the system, we don't know which one is sensitive, so we just run them all that felt like a waste. And so, you know, we should be able to we should be able to do better than found to make a small ten second.

Just want to be able to run the I didn't need to run the test properly, so what can we do? And that felt like and this discovery that the machine learning can actually do some things in there that humans can go to become so big. So that's why we're working on that tool.

And you see to the end, does does you guys, you guys and I think intelligently so are solving a point problem around sort of a very popular and wide top topic matter and in a very wide space. Right. AIML, which has a lot of wide reaching applications and in CI/CD, which is I heard somebody say earlier, an end to end SDLC incorporates twenty five plus market categories.

Right. Types of things and functions. So, so you guys are right, you're hyper focused.

But then that leads me to say is do you see where either Launchable or the market in general. Right. Other other people would be expanding that focus of of AI or machine learning or or in line with your keynote data driven DevOps.

What do you see? What do you see the future? Can you give the me and the listeners a prediction?

It's like a fool's errand. But I do I am excited about the prospect of, I think, using more effectively to drive our work. And we can see in other like adjacent spaces.

Whenever I think about the space, you know, that grindy, the stuff that they need to do is become so large in numbers like the Sario folks, the hundred thousand, the machines, then at some point it becomes impossible for mere mortals to understand all the things that's coming out of the fire hose. So you need some means, like a kind of crash that made that into a small portion, the meaning of. Things so in the monitoring systems and generally the tools and services that the operations guys do like, those things have been going going for the past five or so years.

So, a QAs needs another facer, a month of fire hoses going out of control. And I think the development itself, I think, is going to be falling pretty quickly. So I think there's just so much opportunity for that to make our lives better.

And that's probably going to be coming along the low hanging fruit. Yeah, yeah, I agree fully. And I'd say to an extent cloud, but not to an extent.

CloudBees is is banking on a similar thing. And as software becomes more critical to core businesses, whether you're in software or not, qualitative signals are important. But we have to start to to gather and learn from quantitative cycles.

And that's going to require gathering data and then your point. But to surface meaningful, quantifiable signals out of that data is probably going to require more than than than realistic day to day human cognitive capacity. And I'll make the case today.

I think there are I was excited when I heard about the founding of Launchable, and I'm excited about the opportunity for Launchable in the overall space. I do believe and I'll make the case now that that there's there's a AIOPS, a space that is that is, I think, much further ahead in terms of predictive analytics, data capture and to an extent data management than the left hand side of development. I think there needs to be a whole market of DEVML definitely machine learning that as we talk about continuous improvement to the extent of what what, what, what you're doing, we're continuously capturing the outputs and outcomes across correlating them and not only on the macro sort of KPI level, but all the way down to your point, like in the narrow space of test, in their narrow space of code fitness.

Right. Let's continue to measure, learn and guide. And and what I will squeeze in and I keep squeezing stuff and so on is we did some persona research to like really kind of empathetically understand what developer's motivations, frustrations and fears were, you know one of the number one fears?

Were the imposter syndrome, not being perceived as knowledgeable by their peers. And when one of their number one frustrations that related to that fear was the wide range of emerging technologies and trying to keep up to speed with them and finding it very difficult to learn to achieve the competency. And so, as you and I, I think, talked about years ago about this idea of guided pipelines.

Right. I think at some point we can use machine learning on the dev side of the house to actually help humans learn faster and get better as they develop so and so forth. And so, I mean, the feeling here, I think most people are having imposter syndrome.

What do you think about that? Tell you? It tells me a couple of things that I'm going to try to answer it, I think it it it tells me that you have a I'm I'm stumbling and phrasing it.

It tells me that in a space where knowledge is is is heralded, it's highly valued that and and at the same time is rapidly, rapidly evolving. You end up in a place where where where people are constantly evaluating themselves based on their breadth of knowledge about subjects, and that results in people feeling like they're like they're constantly behind. But it is a false feeling.

Nobody knows everything. You know, as you started to when I was still hiring for and applying for engineering jobs, the list of languages and technologies that you needed to know started to get kind of ridiculous. When you have no COBOL, Pascale, no Ruby on rails, you need to know Ngine X, plus you need familiarity with Landstacks.

You need to understand artificial intelligence and algorithm development and you must have a bachelors, a masters in 10 years of computer science, it's not hard to feel like an impostor in that space. And where I worry, I think part of it is a reality that drives us. But where I worry, that is going to.

Hurt us is that it's going to have a lot of people with a lot of creative thinking that may have not have the depth of credentials behind them, it will stop them from joining in on the technology community and that will actually further increase the digital divide across race, class and otherwise. So we need to use culture tools and other items to mitigate the constant feeling of imposter syndrome so we can bring more people in, unlock their potential and help them drive the space forward. Is that the answer?

Is that the right answer? That's right. That's very.

I didn't think so. I guess what you're saying is, Sposato, for some people, this imposter thing and almost prevents them from entering the field in some other folks that didn't take it, didn't make it. And so that creates this diversity gap.

So, yeah, that that that's much bigger, which which translates to an economic gap, because especially in North America, the tech economy is kind of the most vibrant economy and it's the economy of the future. So not only does it potentially create a gap in and who were solving solutions for their solve with some bias. But you know what?

Those who who for various multitude of complex reasons sit on the sideline are not brought into this. They don't also don't see the economic gains of the growing job market and we increase the separation. But you know what?

I'm taking us off on a whole nother slant. I was thinking about what I was hearing about this imposter syndrome. I was thinking about this interview that you and I made a point of doing.

Now, when people come to conferences and talk about how they are getting things that they put themselves into, the sort of mental state or like, I'm doing great, I want to talk about this from the position of the strings. But when I go visit them in their home, they fix their workplace. And so I ask, how are you developing software and tell me, why are you telling people suddenly you like everywhere else, like a grass is greener everywhere else, like falling behind.

And that's surprisingly mundane problems that are actually still there and they're pretty universal. And that's part of the consideration that for me that is Launchable. A best thing, if I may say so.

It's boring. It's been known to be a program for like half a century probably, but still it's still very much with us. So sometimes I feel like, you know, like people going with of other meaning that those that are the major challenge, if they're having some sense, I think it's kind of pulling us from all the shiny new things that's worthwhile that needs to be done.

It's like a lot of mundane things that and I'm actually glad you brought that up, but I think there's a couple of things we need to realize that we can do. I'm sure let's let's continue to try to mitigate the tedious right. Mitigate the mundane.

So some people can do bigger, more important things faster. But you highlight that we we maybe do the community a disservice when the only time we share is when we're showing the happy path and success. I would probably do the community better service as we transparently and in a vulnerable way share failures or struggles.

Right. OK, I know I can talk to you for hours. I've never been short of an opinion or a question.

I think I think DevOps experience is going to force us to wrap this up before we sign of Kohsuke, I'd like to ask, do you have any final comments for the audience on the past, present or future of DevOps and software delivery? Oh, wow. It looks like.

I don't know. Hmm, yeah, what would I say? Yeah, I feel that maybe we have I think we had opportunities to make impact, just keep getting bigger like our developer, despite all the challenges we just talked about.

I think that kind of like a mountain, we can move single handedly. So much bigger now than just 10 years ago or 20 years ago and so on. So I think that that opportunity is incredible.

And I hope, like I hope that I was the last and the scratched services into different, you know, different directions. I feel like that's the civic obligation to our mankind from us. So that's how I think about and I hope we will be our share double or.

Thank you. And that's what I've covered, I think what I would have said. So Kohsuke, thank you for joining me for this conversation.

Thank you for sharing your thoughts, your experience, and, in fact, taking the time to ask what some of my thoughts are and and to the audience. Thank you for joining us. Please make sure you look into Launchable inc and and see what what Kohsuke and team are doing there.

com and learn how we're helping people build stuff that matters at enterprise scale. So much more than Jenkins now. Yeah.

Bye bye.