The Business of Open Source

Have you thought about how your OSS license could impact your ability to grow your community and monetize your OSS in the future? Attorney McCoy Smith talks about what to be aware of at the beginning to avoid messy legal issues down the road. Links: McCoy on LinkedIn Lex Pan LawOpsequ.io

27 Tammi 202135min

As an analyst at CCS insight, Bola Rotibi gets a birds-eye view of trends in how industries use software to advance their business goals. We had an incredible conversation about how companies use cloud native technology to meet business goals and how vendors in the cloud native space should pay more attention to the needs of specific industries. Links: https://www.ccsinsight.com/blog/author/bolarotibi/https://www.linkedin.com/in/bolarotibi/https://twitter.com/bolarotibi

20 Tammi 202137min

SaaS companies that handle customers' sensitive data need to worry about how they manage data locality. In this podcast, Canopy CTO and founder talks about how their business would not be possible without the flexibility and ability to easily spin up resources in regions across the world that a cloud native architecture offers. Links: https://www.canopyco.iohttps://www.linkedin.com/in/oransears

15 Tammi 202131min

Here's what I covered in this episode: What positioning and market segmentation is and is notThe specific positioning challenges facing companies in the cloud native ecosystemWhy it's important to identify and talk about the types of application your product benefits the mostThanks for listening, and happy new year!

6 Tammi 202113min

Jim Bugwadia, CEO and co-founder of Nirmata, talks about what has changed (and what has stayed the same) since the company started in 2013. Links:https://www.linkedin.com/in/jimbugwadia/https://nirmata.comhttps://kyverno.io

16 Joulu 202030min

In episode 29 of The Business of Cloud Native, I talked to Krishnan Subramanian of Rishidot Research about trends he sees in how end users use cloud native technologies and how startups in the space can meet end users where they are.  Links: https://rishidot.comhttps://www.linkedin.com/in/krishnansubramanian/https://twitter.com/krishnan

10 Joulu 202032min

This conversation covers:Idit’s role at Solo.io, and what she typically does on a daily basis. Idit also talks about how her job duties have changed over the last two years, and the impact that COVID-19 had on the company.The common business reasons why customers come to Solo.io — and where they typically are in terms of cloud-native maturity. Some things that Idit has learned about customers over the last two years. In addition, Idit talks about her own journey at Solo.io and what she’s had to learn along the way.How Idit’s customers typically benefit from using distributed systems — and some of the top misconceptions that they tend to have about using them.Idit’s thoughts on the market for cloud-native technologies.LinksSolo.ioFollow Idit on TwitterSlackTranscriptEmily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.Emily: Welcome to the Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with Idit Levine of Solo.io. Idit, I want to start out, first of all, by thanking you for joining me. Idit: Oh, thanks so much for having me. Emily: And then, second of all, I wanted you to just start off by introducing yourself: what you do, what your company does, and also a little bit about how that translates into what you do every day, like, what activities you spend your day doing. Idit: Oh, for sure. Okay, so as you said, my name is Idit Levine. And I’m, right now, the founder and the CEO of Solo.io. I started Solo two years ago, and when I started it, my focus was try to solve our [00:01:24 unintelligible] application networking problem that we know that will come up. So, what does it mean? As you guys all know, there was a huge shift in the market between monolithic to microservices and, kind of like, moving from technology of monolithic to microservice stack mean that now we also moved to a distributed application. And it was clear to me that now everything is basically will go on the wire; any communication, small communication, between those two microservices basically will have to go to the network. And I thought that would become a big problem because stuff that we didn't need to take care of when everything was the same binary, now we need to actually figure out how to solve. And basically, I was really passionate, thought that that will be a huge problem in the ecosystem and I was very passionate to actually try to solve that. So, the idea was, how to connect, right? How to connect the application, how to connect everything related to your, eventually, application to the user.Emily: And then tell me a little bit, what do you do every day? When you start, what does an average day actually consist of?Idit: Oh, wow. So, it's really interesting, that I think it's a huge difference between now and what I was doing a year ago. Right now, basically, it's pretty simple. Corona came by and it was influence a lot of companies. I was assume that it will influence also my company, and therefore I basically freeze hiring, freeze everything, and try to do the best I can with the resources that we had. What happened is that actually, not only that we didn't was influenced, we actually over doubled our revenue every quarter. That's basically forced me to immediately grow the team to be able to actually serve all those customers. Right now, basically, the main thing that I'm focusing on is—besides the technology, of course, in the strategic of the company—is basically on growing the team. So, it's hiring, it's interviewing, it's looking for the right people, it's building. You know, basically try to grow the team as much as I can in order to basically, yeah, serve well, the customer that are asking for us to—you know, for our products. That's a lot of my focus this day.Emily: And what do you find are the business reasons? What's the business problems that cause somebody to come to you?Idit: So, as I said, once people basically is moving from monolithic to microservices, there is a lot of simple stuff that before that just natively happened inside of the organization; right now, it's a little bit more complex. So, first of all, they needed to find something to run it on, and this is what Kubernetes so great in this ecosystem is the ability to install, upgrade, and basically orchestrate their microservices. But then, as I said, simple stuff that before that people were baking into the microservices created a lot of issues, like small stuff, like how do two microservices communicate with each other? How do you make sure that they're doing it safely right now? Because as right now, it's all on the wire, so potentially, there's always a third party that could, you know, join the party. So, you really need to be safe and make sure that there is a very secure line between those microservices. And then the last thing is that because there is so many because the idea of microservices was to allow you to scale, the question is how do where the request is actually routed? So, in the [00:04:52 unintelligible], request is coming, and there is a lot of replication of the same microservices, and you have no idea basically where it's coming and where it's landing. And then it will go to the next level of the microservices, and again, not know which instance of it is basically being hit. So, now the question is, how do you get visibility to something like that? How do you know what's going on in your cluster? How do what to look for the logs when now it's distributed all over the place. So, that's a lot of problem that the organization basically started to have. As well as with this—if—before that, there was a technology called [00:05:26 api-get] that was relatively popular, but people somehow—it wasn't a must. Right now, when microservices was adopted specific in environment like Kubernetes, when everything is very cloud-wise, you know, stuff is coming up and coming down, you really wanted to make sure that you have a place that you can actually control the policy, control the [00:05:50 unintelligible], the [00:05:51 unintelligible]. And that's basically where API can help. So, that is basically—how do you manage all this networking, basically, of all these systems and applications, as an edge gateway? It's something that going inside your cluster, as well as what's going on inside the cluster after it. And that's basically, yeah, the main problem that you're solving. So, every traffic to your infrastructure, node to start, we're basically taking care of exactly of everything that you then have traffic between what called East and West, inside your cluster. And that's basically the st...

2 Joulu 202026min

This conversation covers:Mirage’s role as an API mocking library, the value that it offers for developers, and who can benefit from using it.How Mirage empowers front end developers to create production-ready UIs as quickly as possible.How Mirage evolved into an API mocking library How Mirage differs from JSON Server Sam’s relationship to Mirage, and how it fits in with his business. Sam also talks about open source business models, and whether Mirage could work as a SaaS offering.One interesting use case for Mirage, which involves demoing software and driving sales.LinksMirageSam’s teaching siteFollow Sam on TwitterSubscribe to Sam’s YouTube ChannelTranscriptEmily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.Emily: Welcome to the Business of Cloud Native. My name is Emily, I'm your host, and today I'm chatting with Sam Selikoff. Thank you so much for joining us, Sam.Sam: Thanks for having me.Emily: Yeah. So, today, we're going to do something a little bit different, and we're going to talk about positioning for open source projects. A lot of people talk about positioning for companies, which is also really important. And they don't always think about how positioning is important for open source. Open source maintainers often don't like to talk about marketing because you're not selling anything. But you are asking people to give you their time which, at least for some people, is actually more valuable than their money. And that means you have to make a compelling case for why it's worth it to contribute to your project, and also why they should use it, why they should care about it? So, anyway, we're going to talk with Sam, about Mirage. But first, I should let you introduce yourself. Sam, thank you so much for joining me, and can you introduce yourself a little bit?Sam: Sure. My name is Sam Selikoff. These days, I spend most of my time teaching people how to code in the form of videos on my YouTube channel, and my website, embermap.com. Most of it is front end web development focused. So, we focus on JavaScript. I have a business partner who also works with me. And then we also do custom app development, you know, some consulting throughout the year.Emily: Cool. And then tell me a little bit about Mirage.Sam: Yeah, so Mirage is the biggest open source project I've been a part of since falling into web development, I'd say about eight years ago, I got into open source pretty early on in programming, kind of what made me fall in love with web development and JavaScript. So, I was starting to help out and just get involved with existing projects and things that I was using. Eventually, I made my way to TED Talks, the conference company where I was a front end developer, and that's actually where I met my business partner, Ryan. And we were using Ember.js, which is a JavaScript framework, and we had lots of different apps at TED that were helping with various parts of publishing talks, and running conferences, and all that stuff. And we were seeing some common setup code that we were using across all these apps to help us test them, and that's where Mirage came from. There was another project called Pretender, which helped you mock out servers so that you could test your front end against different server states. And we first wrapped that with something called Pretenderify, and then it grew in complexity. So, I was working on it on my learning Wednesdays, renamed it to Mirage, and then I've been working on it basically ever since. And then, the other big step, I guess, in the history is that originally was an Ember only project, and then last year, we worked on generalizing it so that it can be used by React developers, React Native developers, Vue developers, so now it's just a general-purpose JavaScript API mocking library.Emily: So, we would say that the position is an API mocking library. And—does that sound right?Sam: Yeah. If I had to say what it is, I would say it's a mocking library that helps front end developers mock out backend API's so that they can develop and test the user interfaces without having to rely on back end services.Emily: Why does that matter?Sam: It matters because back end services can be very complicated, there can be multiple back end services that need to run in order to support a UI, and if you're a front end developer, and you just want to make a change and see what the shopping cart looks like when it's empty. What does the shopping cart look like when there's one item? What does it look like when there's 100 items, and we have to have multiple pages? All three of those states correspond to different data in some back end service, usually in a database. And so, for a front end developer, or anyone working on the user interface, really, it can be time-consuming and complex to put that actual server in that state that they need to help them develop the UI. That can involve anything from running, like, a Rails server on their computer to getting other API's that other teams manage into the state they need to develop the UI. So, Mirage lets them mock that out and basically have a fake server that they control and they can put into any state they need. So, it’s like a simplified version of back end services that the front end developer can control to help them develop and test the UI.Emily: And when you first started Mirage, did you think of it as an API mocking library?Sam: Not exactly. We used it mostly because of testing. So, in a test, it's usually a best practice to not have your test rely on an actual network. You want to be able to run your test suite of your user interface anywhere, let's say on an airplane or something like that. So, if your user interface relies on live back end services, that's usually where you would bring in a mocking library. And then you would say, okay, when the user visits amazon.com/cart, normally, it would go try to fetch the items in your cart from a real server, but in the test, we're going to say, “Oh, when my app does that, let's just respond with zero items. And then in this next test, when my app does that, let's respond with three items.” So, that's the motivation originally, is in a testing environment, giving the UI developer control over that. And then what happened was that it was so useful, we started using it in development as well, just to help during normal times, just because it was faster than working with the real back end services....

25 Marras 202038min