Sacha Labourey - A Dive Into Blue Ocean

Andre Pino: Welcome to today's episode. Joining us today is Sacha Labourey, CEO of CloudBees. Sacha, welcome.

Sacha Labourey: Thank you, Andre.

Andre: Sacha, you've been involved in a number of open source projects. In fact, one of them – JBoss – was in the very early days of open source. Can you tell us what that was like?

Sacha: Yeah, actually, I sometimes joke by saying that I was born in open source because it's really one of my first jobs. I started contributing to the project, then started focusing more on the business and managing people, hiring people, and so on. So I really saw, I think, a lot of the aspects related to open source, from how you work in the community to how it works to create a business on top of that. And, remember, it was early 2000. I think my first interactions of product – with the JBoss community were towards around the end of 2000 or early 2001, so, basically, open source was already there for quite a while. But the business models associated to open source were still very much in discovery. Red Hat was a company that was, obviously, already the leader in open source, but it's just at that time, I think, that they moved to a subscription business model, focusing on enterprises and not trying to sell DVDs to students. So, yeah, it was changing every day. Lots of passion, lots of opinion about people because we're trying to define the culture, trying to define the businesses, and sometimes it was compatible and sometimes it was at odds. So I remember very vividly this period and I absolutely loved it.

Andre: And so that was at a time when open source had a very disruptive nature to it. Was there a lot of energy amongst the community because of that?

Sacha: Yeah, it was kind of the revolution of the geeks, you know? A lot of people came to open source projects because they love to do something very specific. Think about it. You're in Siberia; you love how to do – I don't know – transaction monitors and two phase commits. Where are you gonna find a job where you can do that? Well, nowhere. However, with open source, you get to work with the best in the field, exactly on the piece of tech that makes you excited and wanna wake up in the morning. And that needs a huge amount of talent and energy, so that was pretty amazing. And, at that time, I would say that open source, first and foremost, was building its foundation, right? So it's like open source rebuilding all of IT, from the bottom up, to have a very competitive offering. And so, initially, open source was very much a replacement technology, right? You have a better operating system, a better routing mechanism, better DNS, better everything, right? And I think this is what's changing now a bit, right, and, not just now but in more recent years, we've seen a lot more open source take place and be innovative – not be in replacement market, but really creating new market. Innovation. Just think about Docker. Docker created things that didn't exist in Microsoft, for example, right, in Windows, so it's expanding, actually, the scope of what we can do. And that's also very amazing to see.

Andre: And, as you compare today's open source projects to those in the very early days, do you see any difference in the development community and the communities associated with those projects today, versus back in the early days?

Sacha: Yeah. You know, I would say the keyword is “pragmatism.” I think there was more ideology back in the days, and I say that like if it was 50 years ago, but, back in the days, in the good, old days, I think people were very opinionated about some specific things – what was open source or not open source. And a lot of business models were considered to be not good open source business models, like, if you take open core, for example, which is kind of related to the model we're using at CloudBees, where we invest a lot of energy and resources in open source, but, at the same time, part of our product is not open source but really expanding and building upon. Those type of business models were pretty much considered dirty back in 2003, 4, 5, 6, and you had lots of debates defending open core versus pure open source. And just look at a company like Red Hat, right? Red Hat – what's impressive is that not only do they do 100 percent of their business on open source, but they remain true to this initial statement that anything had to be open source. They don't sell a single line of something that's not open source, and so it's part of their DNA now – that's fine, right? – but, if we observe the companies now in the market, for the most part, they make slightly different choices, they use hybrid business models, and nobody complains about that anymore. I mean, people are free to do whatever they want; that's part of open source and why we call it “free and open source” software.

Andre: Interesting. So I think that one of the things that we see today is greater acceptance amongst enterprises for open source software utilized within their organizations. What do you see that's driving that?

Sacha: So I just think that open source, in so many ways, won the war. I remember business calls back in – even in 2006, where you had to explain open source licenses to companies, you had to justify why the risk of issues, IP issues, and so on was no different from the software they were doing on their own and so on. And so a lot of education, uphill battles were required back in the days, and I think this is different now. Even Microsoft is doing open source extensively now. And so I would be very, very surprised to even know about a single company not using open source somewhere, and that's a bare minimum. I think, probably, tens of percent of the software consumed by organizations is actually open source or based on open source, but, yeah, this is not a debate we have anymore. The debates now are very factual. When we have them, it's about, “Hey, we wanna make sure your software does not contain license X, Y and Z,” so they've made their homework; they know where they stand and why. And that makes business discussions much easier to have, as there is no ideology anymore about open source consumption in the enterprise. It's very factual.

Andre: Do you think that part of the reason for enterprise adoption of open source is because of the flexibility it gives them?

Sacha: Yeah. So it's a number of things. Obviously, flexibility, right? Because open source communities don't necessarily do software for a single market. Anybody contributes. Just look at Linux. It's a good way to look at it because, obviously, it's one of the biggest, if not the biggest, open source project out there. And you have people using Linux in the embedded space. You have people using Linux on massively-parallel clusters. You have people using Linux on desktops or on traditional servers. So, actually, when people think that a piece of software could help them, they go use it, and then start contributing, and so you end up with software that's very flexible. But it's also very robust. What we tend to see is that open source software is very careful about how able it is, how tested it is, and let's not forget that software that has been developed in open source, because it's being consumed in so many environments around the world, all kind of hardware you could not even imagine, you end up with a lot of data points, from a QA standpoint. So I think all of that helps make open source software extremely robust, and, in many cases, for lower layers, infrastructure things that can go down, a lot of organizations will actually perceive extremely positively the fact that it's based on open source software. So, yeah, absolutely.

Andre: So, if we talk about Jenkins for a moment, CloudBees has evolved to become the enterprise Jenkins company. Can you tell us how CloudBees first got involved with the Jenkins project?

Sacha: Yeah, we were – actually, it was in 2009, before we started even CloudBees. I was drafting some business plan, what we wanted to do and so on, and, as part of those discussion, I remember Bob Bickel talking about this and how this would – so Bob has been with us at JBoss, and then he's also a friend of mine. He's part of CloudBees, an investor, a board member, an advisor. So he's been, all along, looking at CloudBees, and he was the first one to say, “You should really look at this project and do something about it.” Obviously, the initial intent was slightly different because CloudBees initially was a Platform as a Service vendor and Jenkins was a core service that was orchestrating continuous delivery on this PaaS, but our roots of the project are very old. And, for the little story – I actually reached out to Kohsuke Kawaguchi, or “KK” as he's called in the community, very early on, before CloudBees was created. And what I did is that I sent him a note on LinkedIn and, you know, we connected. And then I sent him a long note asking that we discuss because I wanted to do something with him and so on, work together. And he never replied, and I got a bit pissed, I have to say. And, one day, I am on the phone with a French guy working at Sun Microsystems – that was Oracle by that time. And I tell him, “Oh, do you know KK, by the way? Because I wrote to him and he never replied.” And he says, “Well, that's very odd because KK's such a nice guy. He would never do that. And, actually, he's just in front of me, so let me ask him.” And KK says, “No, I never received an e-mail from Sacha.” And so, long story short, I had sent my beautiful e-mail at noreply@linkedin.com, so it took us, obviously, much longer to get in touch, and I was slightly pissed for absolutely no good reason outside of me screwing up. So here we go.

Andre: So CloudBees is a commercial entity and the Jenkins open source project is an independent community. How do you manage that distinction between CloudBees, the commercial company versus Jenkins, the open source community?

Sacha: Yeah, that's a good question, and I don't think there is one answer. I mean, not one answer in the sense that I don't wanna say the way we do it is the way and everybody should do it. Different communities can do things in different ways, different companies and so on. What I'm gonna say, though, is based on my experience at JBoss first. JBoss was the name of the project; it was the name of the company. I think it brought us a lot, this name being the same, the brand being the same. It brought a lot to, obviously, prospect knowing about the company, so it's great free marketing. But I would say it also came at a cost, and the cost was that, at some point, when you do that, plus you start hiring a bunch of the contributors to the point that, on some project, it's 99.999 percent of the contributors who are on your payroll, it's different, right? A lot of the benefits we're getting from open source are not the same, and so that's something that always felt like mixed feeling – it gave me mixed feeling. And so things happen differently with Jenkins, it was a community strongly wanted their independence. They wanted to make sure they are – they were born as an open source project more than a decade ago, and they think – it seems like it works fine for them, and so they wanted to stay this way, so we respected that. And I think we had to prove ourselves. We had to prove that we could work very closely to the community, have a lot of contributors on payroll helping the project, but, at the same time, do the right thing. And I don't think this trust comes for free. It's not like, immediately, people think, “Oh, they must be nice guys, so I think they're gonna do the right thing.” And they just say, “Well, we're gonna watch you closely and see how you behave.” And so we've tried to really do our best. Maybe we did some mistakes from time to time, but it was not by design; I think it's part of life. And I can tell you that, anytime we receive – we have new employees at CloudBees, we have what we call a monthly “CloudBees University,” so we send everybody to one of the office and we have a weeklong onboarding process, and, as part of that, I'm doing a presentation about the space we're in, why it's important, where we're going, and so on. And I always finish on this slide where I position, as a company, with the open source community, and I say this is really something that we need to respect, and I talk about this church and state – there're two things – and I always say that we can always score quick wins against the community, if you want. As a company, with lots of money, resources, you can sometimes force things if you want. You could push a decision to be made in your favor and so on – no question about that – but the thing is it's always gonna hold you back. All right? And so, with the project, I really force everybody to always think about it as our best friend, our pride. We should be very pride of the contributions we make to the project. We need to do the right thing for the project. We should always aim for the long term and what's good for the community because what's good for the community, ultimately, is gonna be good for the company. In the short term, sometimes, you might have sales guys say, “Oh, but why don't we do this, this, and that?” But, longer term, you always pay the price, so it's really something we value very high, this church-and-state separation between CloudBees and the Jenkins community.

Andre: And I think that that's borne out by the, actually, the growth of the community. As the Jenkins community is over ten years old now, what are your thoughts on that community and the growth that it's seen?

Sacha: Yeah, so what's amazing about this community and it was probably – well, first, I have to say, Kohsuke's amazing at managing communities. He really cares about people. He really cares about the community, about doing the right thing. It's something that is on him. You know, the fact that this community has been around for so long and so healthy, that just one guy – that's Kohsuke. A lot of people contribute, a lot of people do different things, but you always have one guy which makes the community have a specific culture, and that's KK. And I think one of the great thing he did – I'm not sure he realized that when he did it, but Jenkins has a lot of extensions, so the concept of plugins, as they call those extension, is all over the place. And, today, Jenkins integrates with pretty much anything on the market because it has more than 1,300 plugins. And what this leads to is that, essentially, a lot of those plugins, at least the ones that are maybe bigger than average, are true independent communities, right? They have their own people, their own way of thinking about problems, and so on. And I think it leads to a community with a pretty impressive velocity, first, but also critical mass, right? It's not like you have one massive community working on different aspects. You have Jenkins core – that's a pretty important community, obviously – but then you have dozens and dozens of smaller communities around, focusing on specific topics. Could be pipeline; it could be Docker integration; it could be the next-generation user experience, and so on. And that gives a pretty amazing and unique feel to that community.

Andre: Pretty amazing. So let's switch to talk about continuous delivery and DevOps for a moment. So a lot's happened in the transformation over the last few years, as organizations look to move from continuous integration to continuous delivery and transforming their organizations to DevOps. How do you see this from your perspective within enterprises? And what do you see happening next?

Sacha: Yeah. We just talked about open source, and there is an analogy I'd like to make. I remember, back in the 2000s, open source sometimes was called – you know, they were talking about the “sandal brigade.” Open source guys were almost perceived as a bunch of punks by enterprises, and they didn't get operations, they didn't get how enterprises work, and so on. And fast forward, and Microsoft, as I said, is a big open source guy, contributor, contributing to open source projects, consuming a lot of open source projects, and so on; actually sponsoring the Jenkins project heavily in the community. And so open source has won that war, and what was, one day, an open source sandal brigade became the official thing, the things that you can trust and that's rock solid. And I think that the same is true with the Agile movement that started 15, 20 years ago. Initially, it was just almost a funny way to release your software and test and do continuous testing and so on. It was really new and a lot of organizations would say that it's really fun for small projects, but, clearly, it's never gonna work for the average enterprise project. And you look at things today, and the same thing happened, right? The Agile sandal brigade won the war, and every company that today is disrupting the market is using Agile concept, is using continuous delivery, is using infrastructure as code, and all of that is really the fruits of those initial Agile movement that started. So where is this going? Well, I think it's just the start. A lot of companies are talking about it, but, when you actually look and open the box, you realize that they're, for a lot of companies, still proof of concept, specific teams that have been successful, that pushed things for their own product because they wanted to win. And now organizations are starting to look at this and say, “Oh, my God, they've made such improvements and their productivity's so high. We need to look at how we can industrialize this process across the organization.” But, yeah, it has been this amazing evolution, and now we're at the tipping point when enterprises really have to do it.

Andre: So how do you think that Jenkins has evolved to meet the evolving shift to continuous delivery and DevOps?

Sacha: Yes. That's also very interesting because, initially, Jenkins was made for continuous integration, and what that means is that it was really done by developers for developers, so CI, continuous integration, is really the first step of the life cycle, right? You build your code in a continuous fashion. You're maybe gonna do some unit tests and some packaging. Maybe you're gonna do some static code analysis with SonarSource or whatever, but that's pretty much it, right? And typical usage was “Let's use those old machines that nobody is using anymore. We're gonna put them under the desk and use that.” And it's part of the success of Jenkins, right? It was so easy to deploy on anything, and, because of the concept of plugins, it started being good at doing anything. And so what happened when DevOps started to take place is that a number of developers and ops people started to realize that there was a benefit to go further to the right, right? Further toward deployment. And Jenkins, almost by accident, I would say, because it had so many existing integrations, because it was so easy to implement additional integration with third-party software, that it became kind of the de facto tool to integrate with a full chain of software that leads to production. And now we're in a situation where Jenkins pretty much has an unfair advantage on the market because any company that comes and say, “We are providing a new feature, a new product, that can help companies develop software faster, better,” well, first thing they do is they provide integration with Jenkins, right? So there is a self – an acceleration mechanism here. And so, for a while, that's how Jenkins was able to capture that market and that type of use cases. About two, three years ago, people started to realize that it was not enough, right? It was not just about integration. Integration is important, but it's also about “How do you capture that process?” Because doing a few things, like build a source code, a static code analysis or something like that – that's relatively trivial. But, once you start implementing a complete life cycle, it can have dozens and dozens of steps with branches, parallel branches, and conditions and so on. And Jenkins wasn't fit anymore for that; it was making things too complicated. So, to the credit of the community, amazing work has been done, and CloudBees has been extensively investing in the community through engineers working, at CloudBees, to make that happen. And we worked on pipeline features, so a lot of work has been done so that pipelines are first-class citizen on Jenkins. It's so important that Jenkins really is Jenkins 2.0, so, after more than a decade of Jenkins 1.X releases every week – I think it was released 500 or 600; I don't know how far it went.

Andre: 651.

Sacha: How much?

Andre: 651.

Sacha: Wow. 651. They said, “Well, this shift is so important to the project that this is really Jenkins 2.0,” and Jenkins 2.0 is not just for CI; it's for the full life cycle. It's 2.0-ish, you know? It's 2.0 material here we're talking about. And a lot of work is being done. A lot of views specific to continuous deliveries. Docker integration, extensive Docker integration, with pipeline and so on, has been achieved. Things like declarative pipeline was just released a few weeks back to make it trivial for anybody to create their first pipeline in no time. We're gonna see a new graphical editor come in a few weeks, that you don't even need to know anything about languages or anything; you just drag-and-drop and create your pipelines. It's pretty amazing.

Andre: That's gonna bring more members of DevOps teams into the Jenkins fold, right? Because they won't need the programming skills that most Jenkins users require.

Sacha: Yeah, absolutely. So it's – when the Jenkins community started working on those pipelines, what they wanted to do, first and foremost, is create the strongest and most flexible engine for pipeline, right? It had to support all kind of semantic and sophisticated semantic and so on, and it was all based on Groovy, so extremely flexible, extremely robust, but, hey, you had to learn a language to do it and a few things, so the learning curve was not great, from that standpoint, so – if you were willing to invest time because that was – maybe you had a super sophisticated project to do, so it's totally worth it. But we were also seeing more and more teams who just wanted maybe a six-steps process, with a number of parallel steps and testing, and, yeah, down the road, they would get to a very sophisticated concept and so on, but the learning curve was too high and they wanted to get started right now. So the team took a great decision, I think, which is they didn't try to recreate a parallel environment, right – like the baby edition and the adult edition of pipeline. What they did, they said, “No, the foundation are sound and solid. All integrations, all extension for pipeline are here – they're very solid – so let's keep that. But, instead, let's add a layer next to – essentially, the Groovy language, we're gonna create another block that leverages everything we have and that's called Declarative Pipeline. And, on top of that, since it's a declarative language, we can create, two ways, a graphical editor, but, again, it leverages everything that has been done in the past few years. If organization had implemented, for example, libraries, script libraries, to have specific things they wanted to provide to their developers across the organization, they can have a few declarative projects start and, boom, they get to leverage everything that has been developed in the last few years. So it's a very nice architecture there.

Andre: So you mentioned this graphical editor that's now gonna become part of Jenkins, to interact with pipelines. So one of the big knocks that Jenkins always has had is on its user interface, so this graphical editor is a big departure for Jenkins, isn't it?

Sacha: Yes, it's pretty massive. And, you know, that's where I like to think that the relationship between CloudBees and the Jenkins community can be extremely successful because starting from scratch a UX project, which it's not just about making the buttons more like 2017 and the logo more polished, right? We're talking here about a complete departure away from the old way of representing things, which was very much a table of things, a generic table, and you would move across concept to concept. Here, we're talking about a UX that's really focused on use cases, what people do when they do continuous delivery. What do they wanna see? What do they care about? It's a complete departure away from that. And, as a lead of that project, James Dumay has been amazing on that project. He's been working, obviously, with a lot of people – you know, Michael Neale has been part of that. A lot of people have been working on this. But it's a kind of project where it's very hard to make progress when you work on it two hours a night or during the weekend; it's more than a full-time job for a complete team. And that's where I think the relationship with CloudBees and the community is great, right? We've been investing extensively. This new UX is pretty amazing. It should be released in a few weeks only. Today, by the way, is James Dumay's 30th anniversary, so it's almost on time with this very big anniversary for James – and it includes concept like you can visualize your pipeline; you can see in real time where it stands; you can graphically modify your pipeline and add steps, remove steps, configure those. It has a complete round-tripping from GitHub to Jenkins back to GitHub, for example, or other repositories, so you can very easily do those transformation. And, yeah, it's – I mean, you have to try it. You have to try it. A lot of people think that this new UX is just gonna be different bells and whistles, but it's just the same engine, different UX completely.

Andre: So this work that James has been leading is – what's the name of that sub-project?

Sacha: It's Blue Ocean.

Andre: And how did that name come about?

Sacha: I think he told me once, but I have no idea. But I just love it.

Andre: So we talked about Jenkins and the continuous delivery and DevOps aspects. What's happening at CloudBees, with respect to continuous delivery and DevOps? And what are we adding to what people can do with Jenkins?

Sacha: Yeah, so we're really focusing on a number of things. What we're seeing is that organizations that wanna do continuous delivery seriously, typically want to manage it at scale, right? We're not talking about a team doing something nice with continuous delivery; we're talking about what happens after one or more of those teams have been successful. What happens for that organization? Do they just tell the other teams, “Hey, look at this team. They did something great. You should try on your own”? But that's not the way it works, right? They need to centralize this; they need to standardize it. And if you don't – and, you know, the centralized – this tendency to centralize DevOps, and sometimes it's a team they set up to manage this, and that's what we see a lot. I think it's a good way to avoid what I would call this Frankenstein-ization of DevOps, right, where each and every team has a slightly different way to do things. But the problem with this is, as an organization, you're not just trying to make one team be good. I think what you're trying to do is have a unified view of how your factory – your idea factory, essentially, right, where you transform idea into great software – happens. And so, for this, you need to have this unified uses, unified dashboard, that gives you the performance of your, quote unquote, “factory.” Right? In a good sense, factory, not in a derogatory sense, but really because we produced a quality software based on those idea. And, if we don't have the centralized team, I think it's a bit like if you were asking a squad or section in the military to build their own weapon, like, “Oh, I'm sure you know better how to build your what you need as weapons, so, squad here, do your thing, and, squad here, do your thing.” No, that's not how it works. There is a critical mass and you have in most organization, and sometimes it's a lot of the initial minds behind those proof of concept, right? The guys who had the vision for the organization, they create what should be the best-of-breed implementation, for the organization, to apply CD and DevOps at scale. So that team, when they start a new project, they don't have to create their own religion about what's best. No, they can leverage what has been defined, get started fast. Doesn't mean they can't customize things or improve, but at least they get a starting point immediately. It can go on the war field and be efficient right now. And that's a lot of what CloudBees has been focused on, so we just released a CloudBees Jenkins Enterprise, and CloudBees Jenkins Enterprise is just this: you can deploy it on AWS, on Linux, on VMware, on OpenStack. It's gonna essentially take ownership of some infrastructure and provide a complete self-service Jenkins cluster, so you don't need to spend time asking for a new Jenkins instance for a new team. It's all completely automated. It's completely elastic. We share resources. You can apply security rules from the top, update your clusters centrally. So, from a very simple environment, you can really manage this complexity and make sure that your team, your DevOps team, your centralized DevOps team, are not spending their time setting up your Jenkins, new tools, and looking at whether they have enough infrastructure, how the teams are performing. A lot of what we do today is help those centralized DevOps organization be efficient and enable the organization to win on the market.

Andre: Excellent. And, as you interact with enterprises, what are some of the key things you hear them talk about that they'd like in the future, with respect to DevOps?

Sacha: So I think what they're asking for, initially, is it's kind of the – sometimes, the problem with new technology – and open source also has this problem sometimes – is it's very generic, right? It's supposed to serve all purpose. And, when a new technology comes up, it can be adapted to do many, many things. And what those companies are telling us, for the most part, is, “Okay, we get that, but we don't want to invent the next new thing,” right? “We're not gonna do a Ph.D. on how to do DevOps better. We just want to get going because we understand that, from market competitiveness, it's time for us to wake up, so tell us how to do it.” So they want guidance. They want an opinionated view on how to do things. So we're seeing this pop up a lot, this request for guidance. What they're also asking is for visibility into how they're performing, right? So the investibility into continuous delivery, on tools and so on. Okay, fine. Now what's the ROI of this? What benefit do we have out of using this? Can we state that somehow? So a lot of that is around accelerating and proving the value of continuous delivery. It's not so much what we used to do a few years back – explaining DevOps or explaining continuous delivery. I think that's beyond.

Andre: Right. So, Sacha, as we close out the session today, is there anything else that you'd like to talk about?

Sacha: So I think what's – yeah, there's a thing I would like to end on is – well, first, you need to try Blue Ocean, you need to try pipeline and so on, because it's truly amazing. So, once it get out, please do so. It's really worth your time. But what I wanna say is what I see, talking to companies, and I wanna say not – you know, the traditional companies, the, quote unquote, “real” companies that own the market today – it can be in the automative industry; it can be in the technology industry, in the banking industry, any industry – all of the established companies, essentially – they should stop comparing themselves against their legacy competitors, the good, old competition, because I see that, again and again, those companies base their investment on how far or how fast is their competition doing. And what they don't realize is that their competition is not who they think. Actually, I suspect that their old competition is probably their best buddy today because they're exactly in the same boat, and they need to move fast; they need to wake up; they need to change a lot of things. And so I've seen that many times. Again, when you talk to those companies, they, in many case, don't even see who the new competition is. Either it feels like too small, too new – it's never gonna grow; it's not enterprisey enough – so they kind of make fun of it. They dismiss this. Or they think it's not competition because, “Well, they're so small. There's no way they can compete against us, and they do things so differently,” right? “They're purely online; they're purely automated. That's not who we are.” Or maybe they're positioned differently in the value chain, right? They're maybe removing some intermediation or they are after the value chain or something like that, where it feels like, “Well, it's not quite competition.” But, if you look at things and try to fast forward, you realize that, actually, those companies are most likely your competition, your new competition. So it's really what I wanna say. Stop looking at competition as being your old competition, but open your eye, widen your spectrum, and maybe you're gonna spot your next-generation competition.

Andre: Well, Sacha, I think that's very insightful for a lot of companies, and I just want to say thank you for joining us today and thanks for the discussion.

Sacha: Thanks a lot, Andre. Have a good one.

Andre: Thanks, Sacha.