Sponsored by Reblaze, creators of Curiefense
Justin Dorfman | Tzury Bar Yochay
Hello and welcome to Committing to Cloud Native Podcast! It’s the podcast by Reblaze where we talk about open source maintainers, contributors, sustainers, and their experiences in the Cloud Native space. We are super excited to have as our guest, Alexis Richardson, who is the co-founder and CEO of Weaveworks, the creator of GitOps that unlocks cloud native agility, reliability and scalability. Previously he was the TOC chairman at the CNCF, and co-founded RabbitMQ. Today, Alexis shares his advice on how to build a successful open source community and an open source company. Some key things he talks about if you want to build a successful business around open source are trust, communication, and incentives. Also, we learn more about Weaveworks, the products, and the solutions to make your life easier. Go ahead and download this episode now to learn much more from Alexis!
[00:01:23] Alexis shares with us his history of what he did in the tech industry before he co-founded Weaveworks.
[00:08:12] Tzury asks Alexis if people are preferring open source as sort of an insurance policy to get more confidence with the software they’re using, or are they actually preferring the open source so they can actively contribute and get involved in the development and patch.
[00:10:00] Alexis tells us that open source coincides with two phenomena that they’ve seen that are very important, self-service and agile.
[00:13:40] Alexis shares his thoughts on what an open source company is and how an open source company operates. He talks about Confluent and how they work on Kafka, which is an open source product.
[00:16:34] We learn from Alexis his recommendations if you want to build a successful business around open source.
[00:21:00] Alexis shares his advice on the secret of building a successful community, and he talks about trust, communication, and incentives.
[00:22:52] Justin asks Alexis how it went in terms of relying on the community to come up with those plugins he mentioned.
[00:25:29] We learn more about Weaveworks, the products, and the solutions.
[00:28:44] Alexis shares his opinion of the role of CNCF within the Cloud Native movement and the Cloud Native Open Source.
[00:29:59] We learn who coined GitOps, Alexis tells us why he’s a big fan of Kelsey Hightower, and Tzury asks Alexis how long he thinks it will take Kubernetes to be really simple to use.
[00:34:17] Alexis fills us in on the industry being cyclical, the new buyers, and if technologies are growing that rapidly.
[00:41:41] We end with Alexis saying to buy from Weaveworks and use GitOps to make your life easier.
[00:02:55] “One of the lessons we had learned was that open source software was going to be how people would consume infrastructure, at least at some base level.”
[00:06:05] “Instead, we focused on, you know, solving problems for the cloud generation of apps represented by the Silicon Valley companies.”
[00:12:13] “And if you think about software developers as people, which we do now luckily, then it’s really easy to see that people want to have convenience in their work.”
[00:13:48] “An open source company is a company that primarily works with or produces open source tools in order to engage with customers who are users first because they have a free experience as well as potentially a paid experience.”
[00:15:17] “The question then becomes what is open, and for some companies, the answer has been everything has been open because we sell a complimentary product.”
[00:16:34] “Anyway, today my recommendation would be that you know, you really need to think that if you want to build a business around something open source, number one rule, your open source project has to be successful.”
[00:18:14] “So, you need to be a leader for your project to be successful and people need to be aware that you’re the leader. And for that to be true, you really need to be pretty fully featured.”
[00:20:13] “And obviously everyone knows that engineering the results those are not infinite, and nobody expects you to have all the features that they could possibly imagine, and you should always be prepared to say no.”
[00:21:19] “So the secret of good community is trust and communication, and I think thirdly, incentives.”
[00:21:46] “You can’t be a leader if you’re not actually telling people what’s going on.”
[00:22:30] “You need to find a way to encourage contributors to take ownership so then you can have an ecosystem.”
[00:22:58] “Well you have to seed it yourself. So, you need to go out and be prepared to go and find people to build first ones, and then you create the momentum.”
[00:24:48] “And once you have that, you’ll have enterprise series users coming along and you won’t just have small scale use or people with no money, but also people who actually have real business problems that need solving around operations, and scale and security and governance, automation, BI, AI, everything.”
[00:29:12] ”That is why we put our GitOps application CD tool Flux and our progressive delivery tool Flagger, for example, into the CNCF, so we can co-invest in them with Amazon and Microsoft and Alibaba for example.”
[00:36:22] “But if you’re building a business, it’s a really good chance to find areas where you can solve problems that generate revenue.”
- Executive Produced by Tzury Bar Yochay
- Produced by Justin Dorfman
- Edited by Paul M. Bahr at Peachtree Sound
- Show notes by DeAnn Bahr at Peachtree Sound
- Transcript by Layten Pryce
One of the lessons that we have learned was that Open source software was going to be how people would consume infrastructure, at least at some base level. We weren't sure exactly what the business model was going to be, but we could see it was going to be important. For example, Metalogic in Finland, we've been introduced them all to Martin Micus at mysql and he'd say, yeah, sure I'd be very happy to distribute your app server with my database, but you'll need to make at least some source, we weren't sure what that would mean.
Intro [00:28]: Hello and welcome to committing to cloud-native, the podcast where we talk about the interface between open source and cloud-native. We're super excited about our guests today, can't wait to introduce him. Our panelists today are Justin Dorfman and Dory [Name] and they're going to have an awesome conversation. I really enjoyed listening to it, and I really hope you enjoy this conversation.
Justin [00:52]: How are you doing today, Alexis?
Alexis [00:54]: Very well. Thank you. Nice to be here.
Justin [00:57]: Thank you, Justin. Thank you Alexis for coming out. I'm very excited and the very early days of thinking, considering and planning out to make your [01:07inaudible] as a public officers project. We have a really insightful and effective conversation and some of those great ideas I hope you can elaborate today and repeat them to the benefits of our audience. So Alexis, would you mind sharing with us your professional history before you came about co-founding and running Weaveworks?
Alexis [01:34]: I'll try. I mean, I've been in the tech industry for about 20 years, before that I was in financial services. My first job after leaving university was with Goldman Sachs where I was a derivatives trader for a while, and I had a background in mathematics and computation and things like this and an interest in technology.
[01:55] So when I was working in the city, I became very interested in how technology was affecting, how people made money and did their business. We could see that, increasingly things were getting automated, not just in the single-user XL decision support sense, but just across the whole firm. And decided that it would be fun to sort of get into technology full time. So I left and started the company with friends, which became Metalogic, which was an early-stage technology venture for me in Europe building what we will now call the front office app server, I guess, in Java. And we were one of the first companies that really made an effort to kind of cater to the ordinary developer who didn't want to learn about enterprise APIs and enterprise this, and enterprise that or just write things as if they'd just done a University course.
[02:44] Unfortunately, that was way early and a lot of crazy things about the company meant that we didn't succeed, but after we packed it in, I decided to do another company building on the lessons learned. So one of the lessons that we learned was that open source software was going to be how people would consume infrastructure, at least at some base level. We weren't sure exactly what the business model was going to be, but we could see it was going to be important. For example, at Metalogic in Finland, we've been introduced to Martin Micus at mysql and he'd said, yeah, sure I'd be very happy to distribute your app server with my database, but you'll need to make at least some of it opensource. So we weren't sure what that would mean.
[03:22] So I decided to learn about opensource and in sequence met up with a lot of people, some of whom are still very active in the industry like James [Name] who's now I think it CloudBees doing Jenkins X. He was doing Activemq at the time. Ross Mason, who went on to do MuleSoft, then symphony soft. Rock Johnson who did spring source, which was in phase 21 at the time. And many other similar people and realize that, there was a way to build a company here, but making money was something that we were going to have to figure out. We could all see right hand mysql pioneering, but we weren't sure where that would go either.
[04:00] So I started various companies to try and tackle the problem of open-source support in a world of lots of components that enterprises wanted to consume. And not settle down into building an open-source stack for finance cause that was my background. I got together with a bunch of finance guys and we did a company called cohesive, which became Cohesive Ft because it was financial technology.
[04:24] And Cohesive we soon realized that the way that software was going to be used, wasn't just open source, but also through cloud and virtualization. So we built a tool called elastic server, and then we built a bunch of cloud tools which became somewhat popular. But while we were doing that, I hadn't lost my interest in opensource and was working with JP Morgan as part of my project at Cohesive. And they had launched a new initiative called AMQP, which was supposed to be like HTTP or TCP for networking in the web, but aimed at integration and messaging like MQ from IBM and TIBCO rendezvous, which was 30 or 40% of the typical financial services IT budget.
[05:05] And so they wanted to have a protocol like HTTP that anyone can implement, using different implementations, just like we have many web browsers and web services today. And they all talk to each other despite being made by different people, because the protocol makes it work. So we decided to make a tool called rabbitmq, which would implement [05:23inaudible] and then can do integration and be part of the open-source stack and finance. But actually, I soon realized that would be while a fun thing to do, it would be more relevant to the industry if we took this product, which is opensource and provided it as a tool to Silicon Valley companies, building websites, people like Heroku engineers and others.
[05:45] I mean, this is the time when Gihub, Twilio, everyone was getting started with these big products. So we sort of pivoted our attention towards those companies. And instead of building rabbitmq with a C shop client, receive cost client, so that some finance person could try and put it into that execution engine and then not pay us any money because it was open-source. Instead we focus on solving problems for the cloud generation of apps represented by the Silicon Valley companies.
[06:14] And as a result of this rabbitmq find a niche and the niche was one it could grow from, it became very successful. So we ended up with the company, Rabbit technologies, which I also started alongside Cohisive, getting acquired by VMware. From there, I went on to Pivotol, where I ran spraying [06:31 inaudible] fabric, I was responsible for the generation of spring boot and spring cloud, speaking as a product owner rather than as a tech, I'm not a developer. And then after that, I decided to leave and do Weaveworks because I could see that the application developer and the cloud open-source were going to continue to be the thing, which is driving the market.
[06:52] Today, we've seen this explosion of tools around Docker and Kubernetes, a whole ecosystem of hundreds of tools, which is exactly what we hoped would happen. I think that we're in a new world where finally we can see the potential for a second generation of technology like the internet in the nineties, but for applications and those applications will run anywhere connected by things like 5g networks. So a very exciting time to be in the industry.
Justin [07:20]: You just mentioned so many great tools that all of us are familiar with, many of us have been using or still using. And perhaps we can just hang on those and talk about that exciting era. You mentioned starting Engineyard, Heroku and so on. I do want to ask you though Alexis, before we move forward to weaveworks and talking about Cloud Native, Kubernetes and so on. I do want to hang on this open-source topic for a second. So you said that Finland was, you met it through myqyl guru creator and he said, I'll be happy to distribute your software, but you have to make at least some of it open source.
Alexis [08:05]: That was Martin. Yeah, Martin's view was we can partner, but there will need to be an open source over that.
Justin [08:11]: From your experience over the years, are people preferring open source as a sort of insurance policy to get more confidence with the software they're using or they actually preferring the open source so they can actively contribute and get involved in the development and patch and so on.
Alexis [08:31]: So I think the answer to this question changes at the time. I mean, today, I think people prefer open source because almost all the best infrastructure software is open source. And as a result of this, it has widespread support in the industry, which means that you can choose multiple vendors to get you help. I mean, not always, but mostly. And that means that you get a fair price and you get to compare and make your decisions. And we're also seeing new generation of opensource coming through where the developers at big end-user firms who are not traditional software vendors, but companies like Uber or Lyft or SoundCloud or Spotify.
Justin [09:08]: Netflix and so on.
Alexis [09:10]: All of those folks, the Netflix's of the world are themselves not only consuming, we're producing opensorce. So that's become part of the understanding about how infrastructure software is done today. It's good. Not only because everybody is building it on the vendor side of the fence, but also because everybody is building it on the end-user side of the fence. But originally I would say that wasn't the primary reason why people would use it. And I think that the main reason that I saw that really drove the change to what we see now is when you're trying out software for the first time, it's a lot easier if you don't have to talk to salespeople or pay for things or downloaded limited trial edition or worry about the licensing or really any of that stuff, because this is getting in the way.
[09:58] So I would say opensource coincides with two phenomena that we've seen, but very important, one is Selfservice and the other is Agile. Now I know that Agile today is a little bit of a dirty word and talk about other ways of, dynamic IT and [10:15 inaudible] and so on. But fundamentally moving to a more iterative, faster-moving way of planning and executing with type decision loops or OODA loops some people call them, versus the old way of doing technology in the nineties, where we would set the budget and then spend two years spending it. And then after two years, we'd figure out if we'd got the project right or wrong, which was often wrong, whereas with the iterative method, you're constantly adjusting your plan, like a yacht in a race. And then Selfservice, you know, coincides with the web.
[10:45] It's not an accident that amazon.com was successful. You can go to something that you don't even need to get out of your chair. You can look at a screen which is already in front of you, maybe you're at work and you can do this while you're supposedly working, which has spent hours and hours browsing books and then you can buy one, it gets sent to you and you don't even have to get out of your seat. So you can get it sent to you. Maybe somebody has to collect it from the front door, the doorbell. And this Selfservice makes it just about convenience. And convenience is very important for progress because every time you put something in somebody's way that prevents them, it gives them a chance to say no to something. Then they might not do it and you lose users that you can build a big business if you make things convenient.
[11:26] So Netflix, they talk about the moments of truth or something. The moment of decision. This idea that before a person watches Netflix, they have an opportunity to decide to do something else. Like, go for a walk or make a meal or watch television or play with their dog or talk to their family. And Netflix, you shouldn't do any of those things in the moment of truth, you should have this decision to use Netflix because it will always work, it's always convenient and always comes on with something that you want to see, which if you think about it is a little sinister, but they already put their finger on this idea that people want to make decisions in a convenient way. And self-service is really critical to how users, as we call them how people want to do things.
[12:12] And if you think about software developers as people, which we do now, luckily, then it's really easy to see that people want to have convenience in their work and tools that are familiar. You know, philosophers in the early part of the last century make careers, writing books about the relationship between people work and tools and how it needs to be authentic. And I think that the selfservice iterative way of working in teams that open source lends itself to and SAS as well, is really the right way to work in technology. Otherwise, it becomes [12:46 inaudible].
Justin [12:48]: So you mentioned Opensource company. Some would think this is a contradiction within the same sentence. Open Source mean non-profit but the core idea it's free. A company purpose is to earn revenues to shareholders. So I'm assuming the building, company and organization on top of an open source technology, the small key layers of, I would say operations that you're running has to be a thought. You need to think about each and every aspect of the operation and what should go into the open source to each point or which parts of your solution should be allocated on the premium paid side. And so on. Would you mind share with us your thoughts about this question?
Alexis [13:39]: There are many different answers to this question overtime again, just as with the other question. I think today it's a little different from how it was 5 or 10 years ago, but an open-source company is a company that primarily works with or produces open-source tools in order to engage with customers who are users first, because they have a free experience as well as potentially a paid experience. And we can see a lot of open source companies in the world today. Confluent is a great example. They primarily work on CAFCA, which is an opensource product, but they also make money by selling an enterprise edition.
[14:11] Some years ago you could have argued that a company like Thoughtworks was an open-source company cause they often recommended open-source tools in their consulting. I'm not sure if that's still true, but I've also seen other consulting firms that are primarily opensource focused. But I would say that this is for the benefit of the user or the user that doesn't have lock in or has choice. But often the real reason was developers just want to use those tools and work with them. But from a software product side, it's very clear that it's more of a company like Confluent, whether the product is some kind of support services or enterprise product or SAS, fundamentally you're building a capability where the end-user starts their journey through an opensource experience, almost certainly with an opensource tool. Be a CAFTA or Kubernetes, or Weaveworks.
[15:01] We've been doing a lot of business around flux as well as Kubernetes and flaga, which provide people who github's capability. Other companies are building a business around other things in the CNCF, I think Pessary are building a business around Curifence, which is insecurity. So you'd be an opensource company in that sense. The question then becomes what is open? And for some companies, the answer has been, everything has been open because we sell a complimentary product. Here's a good example of, but isn't even opensource but similar, Norton antivirus, do you remember you'd buy your laptop and it would have windows on it. And for some reason it would also have Norton antivirus on it. And it was really difficult to uninstall it. Then this thing would sit there and it would tell you volubly constantly gregariously and you've got a virus or you haven't got a virus.
[15:47] And if you're a normal person that's [15:48 inaudible], anyway, you can figure out if you've got any sort of tech sense at all, that you need to tell things to keep updating itself otherwise it's going to get out of date and think that everything is evil on your computer and [15:59 inaudible] until the end of time. So what they've done there is they've given you a free product, which contains free intellectual property, which is the virus list. And the patterns they're looking for. And then they forced you to upgrade to a commercial subscription to get that thing updated. Otherwise this thing turns into a hassleware. So that is an opensource business model, par excellence. I think users have pushed back on that now. Thank goodness.
Justin [16:24]: Golo.com and cnn, those days.
Alexis [16:28]: The good old days.
Justin [16:29]: The tool bars, don't mention.
Alexis [16:35]: Anyway, today, my recommendation would be that, you really need to think that if you want to build a business around something opensource, number one rule, your opensource project has to be successful. You can't build a business around an opensource project that nobody uses. You can't make money, if you know, everybody says, well, I'd love to use your opensource project, but I'm actually using Kubernetes. This is ultimately why D2IQ changed from Mesosphere to D2IQ and from Mesos to Kubernetes, because at some point they realized there just aren't enough Mesos users who want to go commercial anymore, and they're all going into Kubernetes. So the other thing that's very important as a consequence of being successful is you have to be seen to be successful, which means that you need to be clear leader in your space.
[17:28] Now, some spaces are very big and have many leaders. Databases is a really good example, within the world of databases you have categories. And in each one you have typically two or three or four good opensource projects. Some are older, some are new, some have different features. I think this is a very healthy situation. And then you have another 200 that generally don't get used. There might be special purpose or a labor of love for somebody working alone or something that you know was somebody's fun project for a few years, then ran out of gas. We saw this with web frameworks in Java in 2000. It was a time when there were 30 or 40 of these and then mobile frameworks, 2010 onwards. Now we just have React and Angular and a couple other things. So you need to be a leader for your project to be successful.
[18:15] And people need to be aware that you the leader and for that to be true, you really need to be pretty fully-feature because trust me if there's more than one company or team or group or whoever it is, whether it's a commercial project or if it's a pure community play really important to remember projects do compete for attention and users can become contributors and they support the projects over time. All of that is a competition in some sense. It can be a friendly competition, but it's still a competition. And for that's to go well, it doesn't help if you choose to remove a critical feature from your projects. If you do, and you have enough opensource users who want that feature, then you have to choose between one of three things. One, you put it in, or your community puts it in two you tell people to use something else with your project.
[19:10] So for example, Kubernetes doesn't have a gooey because there are plenty of other GUIs that you can use. And some of them are opensource. There also commercial gooeys of course, but if nobody had a Kubernetes GUI, I'm sure that Kubernetes would have build [19:22 inaudible] inside the project. And then the third option is just to tell your users to go and f--- themselves. Trust me, it's a really bad idea if you're trying to build a business. Now, if you're not trying to build a business, maybe it doesn't matter. Theere might be all kinds of reasons why the users are happy with the limited feature set. But if there's a critical feature that users want, you shouldn't hold it back. And that's really important when you look at closely governed, opensource projects in a single company around them, which deliberately hold back features they can get into trouble if they end up in competition with that community.
Justin [19:56]: See if I get it right, the foundation of a successful opensource company, is the open source layer, the opensource core, the opensource community, the product, feature set, support, and so on.
Alexis [20:11]: Correct. So then you should provide the features that people need right now, if you can. And obviously everyone knows engineering the results is not infinite, and nobody expects you to have all the features that they could possibly imagine. And you should always be prepared to say no, a really good way to do that is to have some kind of steering committee or project management group, when you are opensource, which can say yes or no to features and produce roadmaps and stuff.
Justin [20:36]: So for this part to be successful, it has to do with, you mentioned being a leader. So to be a leader, you need those who follow you, right? Those that follow you, meaning you got to build a community.
Alexis [20:50]: You got to build a community and you also have to have competitors.
Justin [20:53]: Now Alexis you have been billing thorough communities over the years. I believe you were also a chair of the CNCF for a few years, right? Could you share with us a few great insights of how to build successful community around a tech product?
Alexis [21:10]: So this is obviously one of the kind of million-dollar questions, and you can build a great community and still not make money. So be careful what you do with this advice. So the secret of good community is trust and communication. And then I think thirdly incentives. So, you can establish trust by for example, always responding to users. When I did rabbitmq, we had a rule, anyone who asks a question on the mailing list gets answered within 48 hours of business time. And that created the impression that we were a very responsive community. The communication is really important. You can't be a leader if you're not actually telling people what's going on, they can't trust you either.
[21:50] So you need to have folks writing about the projects, going to conferences, talking about user cases. When you have users who are successful, you need to encourage them to talk about that. So it really helps if you're a natural sort of networking person or a kind of party person is also a good person to have. I think a great example of this done right, is Alex's job without openfast. Alex is kind of tirelessly awake, nonstop, promoting openfast that putting people in touch with each other and helping people along. And then I think a third factor is incentives, where this is where you get scale because you really can't do everything. Not everyone can be Alex.
[22:28] You need to find a way to encourage contributors, to take ownership. So then you can have an ecosystem. And with rabbit, we copied mural, which basically have a load of consideration plugins. So he said, we'll manage the core, which will allow us to have a fairly small engineering team before we can start trying to worry about commercialization. And then we'll have an ecosystem of adaptors plugins so about 250 in the end, which is quite a lot.
[22:55] Justin: How did that go, In terms of relying on the community to come up with those plugins?
[23:00] Alexis: we have to seed it in the [23:01 inaudible] so we need to go out and be prepared to go and find people to build the first one. So then you create momentum. So that was something we did with the CNCF. We knew that the secret was having a CNCF community that was out of control and that would force everybody to jump on board because there would be a sense of unstoppable momentum, but that was much more important than any other kind of marketing in the beginning anyway. So we have this strategy of attaching successful projects. So the CNCF, which meant that we had to go and find those projects and convince them that if they're looking for a foundation, the CNCF was a good choice or that a foundation would make sense for that particular project, which it didn't in every case.
[23:41] And that led us to things like Kubernetes and [23:44 inaudible] and envoy and so on, which meant that by the time you get to [23:47 inaudible] rights of these people realize there's something special happening here. And then you can move into a different phase marketing in a different way, but you know, how do you get good communication and good contribution? You got find contributors. They need to be outside your team. You ideally look for tribal leaders, people who are very well known in the Ruby community or whatever. Sometimes you can have several people. One person does the coding. One person does the evangelism. Another strategy is to tie yourself to platforms so that your project is being used alongside another widely used thing? Now that gives you a platform for success. Those are all strategies for building community.
Justin [24:25]: Thank you because that's what I'm currently doing with curiefence. So this is really great advice. Thank you. Thank you. Thank you.
Alexis [24:32]: Another thing that's really important is if you're think of commercialization, is thinking about users on a journey and for that you need documentation. Good examples of the success stories and integrations and then help them with things like analytics, to start to understand how the project is going. Once you have that, you'll have enterprise serious users coming along and you won't just have small scale use or people with no money, but also people who actually have real business problems that need solving around operations and scale and security and governance, automation, BI, AI, everything. All of those things start to become more and more of a pain point as you grow.
[25:12] And as you grow, you're obviously generating revenue in your business. So then you have a way of paying for features from the vendor. And that's where if you want to build an opensource business, you come back and you say, okay, we are selling you capability that can help you to scale up. So that could be services or it could be enterprise products.
Justin [25:32]: Do you mind elaborating a little more about Weaveworks, the product, the solution?
Alexis [25:41]: So Weaveworks in the light of this conversation can be seen very simply actually. We're fundamentally offering a productivity solution for free to developers in Kubernetes because in Fox and gitbubs, we're making it super easy to deploy applications, undeploy applications, update them, scale and patch them and manage them on Kubernetes clusters. In fact, we're doing that for the whole stack. So we can, through configuration, which is how githubs works, configuration lifts and get. The more you can describe it, the more you can alternate and control.
[26:14] So we enable you through agents to apply your configuration to running systems and automatically verify that everything is converse to the correct state. And then far or less, if it hasn't, which means that you can run thousands and thousands of stacks, even if they're different with just one person, because the operations are automated, if you want. And that means that you can do things like if you're a telco, you can have 5g in all of 40,000 telco towers around the country, without having engineers visit them, to fix things when they go wrong, which is awesome.
[26:46] And you can imagine many out of high-scale user cases, I'm sure by cars and drones and IOT, train, cloud, et cetera. So we are offering a productivity solution because we're making it so that developers can very quickly recycle applications and clusters and stacks, any kind, wherever they like. But then by making people productive, our expectation is that people will then do more. So then we're selling commercially things to protect them if they do, so security, governance, compliance, policy that protects you in a world where all your teams are using the same high productivity tool.
Justin [27:26]: You mentioned githubs, interesting enough. I'm not sure if you're aware of, but within curiefence the entire configuration engine is simply a repository. So we were making a day or a year ago, year and a half ago. We were thinking that that would be probably the best solution. I'm not sure if githubs was a term used at a time, but that was a natural choice from our perspective to say, okay, let's use github. So each branch represent a different platform, QA, production and pre-prod and so on. Then every change that you make within your configuration, every role that you change, basically become a commute that you [28:06 inaudible].
[28:07] So then I find out about githubs, which is a thing and a methodology and a way of life. And I was so excited to see how people coming from different directions, different angles, or actually ending up in pretty much same principles, same concepts. So you mentioned a community, you mentioned principles as I believe the foundation of transparency, communication, leadership. We skip over probably a CNCF, the role of CNCF nowadays, the way you see it within running and moving forward to cloud native. So what is in your opinion, the role of CNCF within the cloud native movement, the cloud native opensource? As a company, if somebody now we're thinking of this idea of opensource project.
Alexis [28:56]: What does it mean for us you mean, for weaveworks? We want as many companies as possible to have the simplest possible time using Kubernetes and cloud native. And therefore we want everybody to be using ideally a very simple, common set of very popular tools. That is why we put our githubs application CD tool flux and our progressive deliveries, farga example, into the CNCF. So we can co-invest in them with Amazon and Microsoft and Alibaba, for example, we are all using these things in production and drive it forward as a common piece of infrastructure across the whole industry.
[29:34] And then enterprises, big companies like HSBC or apple or fidelity, you know, big organizations that are using these open source tools can say, oh, I'm doing continuous deployment or I'm doing progressive delivery. Let me use these tools to do that. And oh I'm also doing githubs, which means I can be secure and also great.
Justin [29:54]: Who coined this githubs term?
Alexis [29:58]: Yeah. I want to know.
Justin [29:58]: Oh, you did. How awesome is it when like Kelsey Hightower talks about it on stage? I mean, that's pretty awesome.
Alexis [30:08]: I'm a very big fan of Kelsey and all of his work. He's the first person to really hone in on how to explain githubs in a really simple way to developers, which, you know, we come from an operations perspective, building a sauce, and Kelsey wanted to rethink it through and he understood that it wasn't actually about git as much as it was about hubs on this idea that you have this reconciliation, but automatically fixes your stack for you every time it goes wrong, which means that you can do deployments and updates and patches and rollbacks all automatically. It's awesome. So, anyway, going back to what's in the CNCF for us, you know, being in a foundation is making a commitment to a community in return for hopefully building your commercial product out of standard tools.
[30:53] And by standard, I don't mean what ISO standards, but just tools that everybody recognizes the use by lots of people, they don't even have to be individually leaders, they could be one of three or four commonly used tools. But when you talk to a customer, they don't say go away because we're using Oracle. They say, please come in and talk to us because we're using the same tools that you've built your business from. Now, if you're a software company, that's a really good thing. Just think about back to the nineties when you know, it was like, oh, piss off you're not Microsoft, or you're not Oracle, or you're not some. It's harder to make yourself stand out. But if you're in the opensource world, the foundation creates a platform, but not only big companies can succeed, but also small companies.
Justin [31:37]: So how long do you think it will take Kubernetes, not to mention eco to be a real simple [31:45 inaudible], like real simple?
Justin [31:48]: While there is such a thing as fundamental complexity, right? You know, like chasing common core of complexity. What is the smallest number of bets that you could write Kubernetes in? And the answer is obviously 10, but you know, the 10 characters that is, what can I say? I mean, Kubenete is fundamentally a bit complicated because fundamentally it's quite richly featured. If you don't use all of Kubernetes, you can have a simpler experience. And there are tools like K3S and trust me, I know a lot of people who've thought about writing their own simpler Kubernetes, but you're taking something out in order to be simpler. So that's the first thing.
[32:24] I think the roots of simplicity is not in a removing cycle, atomic complexity, the code is going to stay, but we can simplify it in other ways. For me as an end-user Android is simple because I had a phone in front of me and I can turn it on and off on. I can install applications and make phone calls. And if there's no fluff in the bottom, I could even charge it. So that's good. I don't need to care about Android version typically, or a lot of things about Android. So in that sense, to me as a user, it is simple. So I'm experiencing the joys of platforms and embedded software now, but I believe that for Kubernetes, people will still think in terms of applications. The cost will be part of the infrastructure you start the application with.
[33:05] Like an app server on demand. So you'll go to the cloud, you'll say, give me my cluster and my stack. You'll say, I want to do machine learning. Okay. Here's a cluster with machine learning stuff on it already, off you go straight away. You're instantly productive where if I'm an independent software vendor, like, you know, say I'm selling a business application, I will bundle that as a set of containers and maybe Kubernetes clusters so that somebody can run it wherever they want to, without the whole installation rigmarole that we used to have in the enterprise.
[33:32] So all of that is good, so everyone operates much more like a kind of enterprise app store. So all of that will mean that things for most users seem simple, even though they will still be some devops people and some platform operations engineers, and some Linux people, and some other people, who are still concerned about how Kubernetes works and what the architecture should be for version three. But the rest of the world's not going to care about just like, you know, I'm quite certain that you can spend hours of your life arguing about [34:02 inaudible] about things on the Linux lists on the days when he's around there. But you know, for the rest of us, it's not relevant. The world is simple enough that we can use Linux through other tools.
Justin [34:15]: One routine is I like to discuss before I'm running out of time, is the new buyers, I would say the decision-makers, the text choice nowadays seems to be made by different audience than it used to be. So do you think this is one of the reasons for the opensource and cloud native and degrade moment that we're experienced in right now, those technologies are growing that rapidly? Or is it the vice versa?
Alexis [34:52]: I think the industry is cyclical, most industries are cyclical imperative creation, expansion, and then a period of structural collapse, which proceeds a new area of construction. And that's often in business associated with things like M&A, consolidation and growth. You know, the internet in the nineties, I think is the best analogy for today's era. And for a while, everybody was building the same stuff on the same tools. And then you get to the end of the nineties, around 2000, you have the Java apps, and it's a more destructive time, but from business point of view, the market is still growing. And then you kind of get to about, I don't know, 2006 or seven, and they started to consolidate.
[35:31] Some people have moved on to a new tool set because they've realized that you can power a big internet sites like Facebook on PHP, and suddenly the world is different. And people are thinking about the rich funds, the mobile apps and much more. So right now, I think we're in a period of expansion and creation. So I guess a Cambrian explosion would be another analogy people like to use that a lot of strange new tools and hope for [35:54 inaudible].
[35:56] And then I think that we'll soon see a period when some of the land mammals emerge and not so many creatures are around maybe a handful. And then there'll be in each category two or three good tools that everyone uses. The real winners out of this will be the people who build business. Well, okay. No, that's not true. The end users will win because they'll have a chance to really drive the industry. The developers will win cause they'll get to work on some sort of stuff. But if you're building a business, it's a really good chance to find areas where you can solve problems that generate revenue, whether it's kind of operations or, you know, governance or something else around the [36:33 inaudible].
Justin [36:35]: Help me understand something, not that I'm anti or God forbid, I'm apart of this, working on this project opensource and cloud native in a low debt. However, to me, it still seems like something that I'm still not getting, the fact is that we talk about infrastructure as code. We talk about automation, talking about continuous integration. It could use deployment and githubs and all those fancy great automated and infrastructure and automation, et cetera, et cetera. However, seems to me that probably it's the middle phase. Like it will evolve over a period of time where it could be a really simple, but right now this is really like the overhead of the devops world, is sometimes takes longer than, let's say in the short term than to benefit immediately, if you understand what I was saying, if I want to put, for example Linux with an [37:36 inaudible]. It should take me know less than a minute to get it done but now if I want to do it through Kubernetes, now I need to go through [37:46 inaudible] and configurations. Like simple stuff get more complicated, even though you would expect this automation will save us time. We're going to work less hours, in fact, working much more, many hours.
Alexis [38:00]: How many hours you work is tied to other factors. I mean, if the tool makes you more productive, often you find yourself doing a lot more with the tool, as far as those, like Jevons paradox about that.
Justin [38:15]: So because you enjoy it you're using it more. So you're spending more time in the computer because you like the technology?
Alexis [38:20]: Well see now that the customer resource is to make them more committed, we'll just use more resources. So the network and cost goes up. Who led to Bitcoin because they are real idiots. I believe that, we haven't moved the barrier to entry out of the way enough. So a lot of the benefits, day two benefits, operational benefits, they all are in production with larger scale systems. But for the ordinary developer, just putting, you know, two Netgear bricks together to make a wall for a demo or a POC or a small app, you don't need all of that stuff. So we don't have a continuous experience between the ordinary developer and the large scale application at the moment. That is a shame. I think that will get solved in time. I think we are still very early in this particular revolution or this particular phase. We haven't, for example, seen, I was saying the analogy is the nineties. If you think back to the nineties, we had Warp at the end of the nineties, which was for five or six years considered to be the future of mobile, along with things like Symbian, all of which turned out to be utterly pointless.
[39:25] We have the Blackberry phone with all the keys to do email, and then we have the iPhone and suddenly everybody knew what the internet was for. The iPhone is that for music, photographs and tools and talking to each other, and now we have all this powerful technology, and we don't know what it's for. So it could be for something that hasn't been seen yet, or it can be for an evolution of something we already use, like a kind of car thing or a home screen saying, I mean, I'm looking on my desktop iMac screen from a few years ago. And I'm thinking, how long will it be before I walk into every home? And there's a wall dedicated to communication, and there's all this kind of future 3D technology that Google was showing at their conference last week, which makes it seem like the person is really standing next to you.
Justin [40:13]: That was awesome.
Alexis [40:14]: It was pretty incredible and combination of computers, bandwidth, connectivity, and compression. Well also, you know, machine learning to iterate outside of the gaps. So many different things that made it seem like a natural experience, so all of these things are becoming possible with this new platform. And eventually people will have some wow moments. And then they'll say, oh, well, you know, I can't remember what it was like before we have, you know, the [40:43 inaudible] or whatever that will be. Early days. And the developers just have to wait through the sludge in the meantime and shave the yacks. Always shave the yacks.
Justin [40:53]: Usually I like to chime in a lot, but I learned so much, especially from the community stuff. And I really appreciate you coming on. I'm an early rabbitmq user when I was at a company called Mahalo. So it was just kind of cool to see that you're like one of the creators. I would say great conversation, Alexis, but you just started talking about the future in visionary. You talk about technology in the future. I really want to have another conversation about this. That seems like another episode. So thank you very much, Alexis, for being with us today and sharing from your experience, how to build a successful open source community and open source company. Is there anything you would like to mention before we conclude?
Alexis [41:39]: We sell absolutely anything you want, please use githubs first of all. It really is about making your life easier and if you do that, then you'll find that there are things that we sell as well that will help you scale.
Justin [41:52]: We'll definitely start using, githubs. We're already githubs, but definitely weaveworks tools.
Alexis [41:59]: Thank you very much.
[42:01] Listener. I hope you enjoyed this one do tune in next time. We're really excited about our lineup of guests. We have super exciting guests next week, as well check out the show notes for this podcast at podcast.Curiefence.io. That's C U R I E F E N S E podcast.curiefence.io for the community cloud native podcast. Thanks again for listening tune in next week.