Open Source Underdogs

Open Source Underdogs

By Open Source UnderdogsBusiness
Download on the App Store

Open Source Underdogs episodes

  • Episode 50: DataStax NoSQL solutions built on Apache Cassandra with Kathryn Erickson, Open Source and Ecosystem Strategy
    Intro


    Mike Schwartz: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 50 with Kathryn Erickson who helps lead open-source strategy at DataStax. Founded in 2010 and currently employing about 500 people, DataStax was one of the first and most successful companies in the Apache Cassandra big data Ecosystem.


    Kathryn has an engineering background. You can listen to some of her great deep dives into the tech on the DataStax website. In her role on the strategy team, she’s helping to lead the company into its next phase of growth and community engagement. I hope you’ll enjoy this episode. And if you do, don’t forget to share a link on social media. You can find all the episodes on opensourceunderdogs.com, or you can retweet our announcement by following us on Twitter. Our handle is @fosspodcast. So, without further ado, let’s carry on with the interview.

    DataStax Origin

    Mike Schwartz: Kathryn, thank you for joining us today.

    Kathryn Erickson: Sure, of course, thank you.

    Mike Schwartz: Most of our listeners probably know about Apache Cassandra, one of the most popular databases for big data, but how did DataStax evolved in relation to the Cassandra project.

    Kathryn Erickson: DataStax was founded by Jonathan Ellis and Matt Pfeil, both employees of Rackspace. Jonathan, being contributor to Apache Cassandra and Project Share as well, was considering leaving Rackspace, and Matt Pfeil went to talk to him and say, “Hey, there’s some really cool stuff going on here, you should really consider staying.” And by the end of the conversation, they were founding a company together.

    And so DataStax was founded to support Apache Cassandra. Over time, we began adding Enterprise features and selling an Enterprise distribution of the database with these features added, and then, of course, more recently, the cloud platform as a service offering as well.

    Evolution Of Support Offering

    Mike Schwartz: Actually, I didn’t realize that you started out providing support. Because when I first ran into DataStax, I guess I had just known it as a distribution of Cassandra. And now, I see that you’re also providing support for the open-source distribution. Can you talk a little bit about how that’s evolved over time? Has it always been there or has there been a focus on for or against doing that?

    Kathryn Erickson: It hasn’t always been there. When DataStax was founded 10 years ago, there wasn’t really a playbook for how to build and run a successful open-source company.
    We were founded around the premise of providing support and consulting for Apache Cassandra. Over time, we did, all for the Enterprise Edition, but what you see with most Enterprises is that they have a mix of the Enterprise version and open source. For some customers, that’s dependent on the criticality of the data, and for other customers, it’s dependent on the features or the distribution, being the as-a-service offering or self-installed on-prem.

    And so, what we saw in the last year was that there were some obvious things that we weren’t doing, and our customers needed support and consulting around open-source Cassandra. We are beginning to open-source a lot more of the features that would build Cassandra abundance, and so, it made sense to bring those offerings back.

    Astra – DataStax Cloud Offering

    Mike Schwartz: Okay, and you mentioned that DataStax launched a new hosted service called Astra. Do you see that product as a driver for revenue, or is it just an easier path for customers to test drive the product?

    Kathryn Erickson: I think that will evolve over time. I think at launch, it is the easiest way to learn Apache Cassandra. And I think as we launched the hybrid option, I believe that’s later this year, that would become a more significant line of revenue.

    Pricing

    Mike Schwartz: Most of the revenue today I guess is from the license Enterprise product, so focusing on that, a lot of open-source businesses are moving towards consumption-based pricing. And I’m wondering, what kind of metrics do you use to determine what is consumption?

    Kathryn Erickson: You know, a cloud-based offering consumption is based on

    capacity. And with our licensed product and with Luna, the open-source support
    offering, our focus this year has been around simplification of the pricing
    model. And we revisit that each year.

    With the Enterprise product, we previously charged for the Enterprise license, and then, an optional additional fee for advanced workloads, like Spark analytics and graph. That’s confusing for the customer, they just want a simple pricing mechanism. So, we collapse that pricing. And then, of course, for larger deals ,we would have ELAs, or special terms to accommodate those customers.


    Mike Schwartz: That consumption is based on, like, per CPU, per server, or how do you actually figure out what is the size?

    Kathryn Erickson: It’s true capacity-based, the size of the data set being stored. And as we move to Astra hybrid, which will be that offering on-prem, I think we’ll consider that pricing option there as well.

    Market Segmentation

    Mike Schwartz: Data persistence is like the most horizontal market on the planet. Every company basically needs to store data. When you can sell to everyone, it’s sort of a blessing and a curse. Do you segment the market at all vertically or by use case, or do you just not segment the market?


    Kathryn Erickson: It’s hard to segment when you’re serving a pretty broad market. What we try to do is have as easy of an on-ramp for the different verticals as possible. We see data models look similar between IoT use cases, inventory and messaging data models would be similar.
    So, we don’t segment the market for go-to-market strategies, but we try to find places of repeatable consulting efforts to speed up the successes for those customers.

    Partnerships

    Mike Schwartz: When you took on the role of director of strategic Pprtnerships, you probably did a survey of the range of partnerships that exist. Can you talk about like what is the partner landscape look like at DataStax?

    Kathryn Erickson: I ran our technology partner program, and there’s two other sides of that, SI partners and the cloud partners. On the technology side, you want to make it easy as possible for customers to consume your product.

    So, in a technology partner program, you want to

    understand the user journey to get to your product, and make sure that those
    adjacent technologies have the simplest most repeatable easy to build, easy to
    test integrations as possible over time. If you want to think about specific
    companies and integrations, every database needs an ODBC and JDBC connector.
    And customers want those for BI, for reporting, for simple ways to move data in
    and out of the system, but in the last few years, most customers also want to
    see Kafka connectors and more high-speed ingest Pub/Sub integrations.  So, we want to accommodate those as well.

    Mike Schwartz: Coming on the System Integrator side, you know, at Gluu, we found

    that those have been essential for us, to be able to focus on innovating the
    product versus getting involved in specific projects. But there’s such a broad
    range when you’re serving a global market of the System Integrators. Do you
    consider them channel partners or integration partners?


    Kathryn Erickson: We usually consider them strategic partners when we take those types of partnerships on. And the goal is usually to help us penetrate markets that we don’t currently have field team in, or packaged, or cookie-cutter solutions. If you look at some of the stuff that we’ve done with VMware and with partnerships at Dell, we want to assert that the product stack works as recommended for customers that are used to seeing these reference architectures from these larger integrators and technology companies.

    Most Important Partnerships For Driving Revenues

    Mike Schwartz:  Which partnerships, do you

    think are the most important for actually driving growth?

    Kathryn Erickson:  Deloitte’s been in a role to our federal business, they know that space better than any startup could hope. VMware for helping to modernize Enterprise platforms. Enterprises that are looking at Cassandra and looking at DataStax are usually going through some type of digital transformation. And the product that they already have in place is VMware. So, everything that we could do to make that migration to know SQL smooth was helpful to those customers. VMware has been a pretty big partner in my journey.

    Open Source Strategy

    Mike Schwartz: Some of the companies

    we’ve interviewed are moving to a 100% open-source strategy, specifically Chef
    and Cloudera. In the past, the value property DataStax, it had improved
    distribution of Cassandra.But do you see DataStax maybe moving more in
    the direction of open-sourcing its platforms and some of that technology it’s
    developed?

    Kathryn Erickson: We are open-sourcing a lot more. We try to stick to simple rules for open sourcing, simple rule is, it’s a Harvard Business review article, simple rules for a complex world.
    And so, simple rules for open source, if it increases adoption Cassandra, it should be open-sourced. And if it’s Enterprise feature that’s more specific to Enterprise customers, like security features or advanced replication options, then that would be kept proprietary.

    And then, where should something be open-sourced? Well, if it makes a change to the core of Cassandra, of course it should go to the Apache project. And if it increases abundance, but it’s not impactful to the core of the project, then it still should be open-sourced, but maybe able to exist in a DataStax repo or different foundation.

    Does Open Source Help?

    Mike Schwartz: Do you think the wider open-source community A Cassandra

    helps DataStax too?

    Kathryn Erickson: Of course, open source is all about positive sum games. I think it was Thomas Jefferson that said, “If use my light to light your torch, then we both have light.” And that’s how open-source works. The more communities and more companies that you can move from being other to being self, the larger the positive sum game that you’re playing. So, it’s open source, and open-source abundance is absolutely essential to the success of any open-source company.

    Thoughts About Open Source Foundations?



    Mike Schwartz: Any thoughts about Cassandra being hosted at the Apache Foundation versus perhaps Linux Foundation or the CMSF?

    Kathryn Erickson:  I don’t have any opinions on the other foundations, but I think that Apache Cassandra will always be at home with the ASF. They have their simple rules for what it means to protect the open-source nature of a project, and they don’t waiver. And for a vendor backing an open-source project, that can be like a Northern Light, you can lose your way, and you can always look back up and reorient towards the community.

    But you know, there’s nice things when you see CNCF, you know, the marketing wing, and the power of the CloudNative messaging that’s there. But there’s no reason that projects can’t have pieces that exist in different foundations either.

    We see ourselves and others that build communities operators or management APIs or drivers is an example, they should live in a project, but management tooling that exists that the maintainers of the project wouldn’t want entry. So, something like that maybe should live in a CNCF type of foundation that’s focused on CloudNative. But no Apache Cassandra will remain Apache, and that’s a tome.

    Industry Changes In The Last 10 Years

    Mike Schwartz: So, DataStax is one of more mature, well-established companies in the open-source ecosystem today. What are some of the challenges you think that you are looking at now that were different than when you got started?

    Kathryn Erickson: When I started a DataStax, it didn’t always feel like we had a lot of competition. And I think as other good distributed databases emerged, we adjusted to having competition. I think the obvious answer that most people would expect is pressure from the public Cloud vendors. But if you stay oriented on the positive sum nature of open source, then that becomes easy to embrace as well.

    So, there’s changes in understanding the virtuous cycles of open-source, understanding how to build software as-a-service more quickly as Kubernetes has matured that’s become a lot easier. So, I think the ecosystem around us has matured a lot, the playbooks around how to build a company around open source have matured. And there are more senior projects that kind of exist in our ecosystem that we can work with and learn from as well.

    Is Open Source Table Stakes For Databases?

    Mike Schwartz: You know, most of the databases that have been released in

    the last, let’s say five to eight years or so, have been open source. Is being
    open source basically like table stakes now? So, is it a non-differentiator in
    the database market?

    Kathryn Erickson: I think that if you’re moving from a proprietary relational system, and moving towards NoSQL, then you’re obviously moving into an open-source world. And if you can choose something that has a security life, security blanket that you know will outlive any vendor behind it, then you should consider those options first.

    I think that it would be hard to start proprietary databases without the support of the community and of these foundations. I think Snowflake has done an exceptional job and is kind of the exception to the open-source game. But, you know, they were disruptive in a much different way. NoSQL in general is an open-source family.

    Data Platform Trends

    Mike Schwartz: Just a general database question about the database market. So, we’ve interviewed a probably more database companies on this podcast than any other type of company, but have you ever seen a real shift in the way that customers think about databases.

    In the old days, I think you just used to get one database and hope it did everything, but have you seen a sort of on the technology side a shift in the way that companies are thinking about data and databases now, with more SaaS hosted offerings and more database offerings, like in general.

    Kathryn Erickson: Yes. I think I think this is definitely the age of data platforms. With Cassandra, we see customers considering NoSQL when they’re using the relational system. And it can’t support the throughput that they need anymore, or they need to replicate more geographies, or exist in a multi-cloud or hybrid environment.

    And so, that’s when you consider Cassandra. If you look at when you might consider Mongo, you want to get quick start with a developer friendly environment that’s great for mobile. What you start to see is that there’s a certain fit for purpose that the different NoSQL databases have. We’ve started to see an emergence of multi-model systems that move forward. And consolidating those capabilities, we have that with our Enterprise products and their integrations for graph analytics and search, we want to help customers build high-growth applications, high-speed transactional applications are the sweet spot of any Cassandra deployment.

    Advice For Startup

    Mike Schwartz: This is a question, a sort of a generic question for

    entrepreneurs who want to launch a business around an open-source product. I’m
    wondering if you have any advice, for let’s say, startups? And it could be
    general and it could be about partnerships.

    Kathryn Erickson: You don’t have to invent a path to success, you can listen to the A16 podcast, you can look at other companies that are out there. You can go through so many success stories on podcasts like this, you can listen to Cockroach, and there are Open Source Underdogs podcast talk about how they’re thinking about licensing other companies. You know, having similar conversations, really understand what has made other companies successful, and don’t try to invent that yourself.

    How To Improve Tech Diversity?


    Mike Schwartz: Last question. As you’ve might noticed, there aren’t enough women in the tech business, including there haven’t been enough women on my podcast, so thank you for joining. What can we do to reverse that trend?

    Kathryn Erickson: I think there’s a lot that we can do. as You are on the side of making mistakes, just try things, and if it’s not the right thing or if it doesn’t work, try something else. We’re going to do a program at DataStax, you know, Jumpstart, if you’re a woman or a person of color, and you want to learn Cassandra, and you don’t know where to start, just hit the button, sign up. Somebody from the team will meet with you for 30 minutes and help you get started. That might work, that might fall flat, but we’re going to just start trying stuff. And I think everyone should just start trying the ideas that they have, and we should all tell each other what’s working.

    How’D You Get Started?

    Mike Schwartz: How did you get started in the tech industry?

    Kathryn Erickson: Well, my dad taught Computer Science, Community College, and I was going to be a DNA researcher. And I just wasn’t very good at it, and I thought, “You know what dad’s over Computer Science, we’ve been playing with computers all of our lives.” That sounds more like playing then working, it’s been that way ever since. It feels more like playing than working every day,

    Mike Schwartz: That’s great. Thank you so much for joining us today, Kathryn, and sharing your insights. And best of luck at DataStax.

    Kathryn Erickson: Sure. Thank you.

    Closing

    Mike Schwartz: Thanks to the DataStax PR team for helping us to schedule

    some time with Kathryn.

    Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics by Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

    Next episode we’re excited to have Cornelia Davis, author of Cloud Native Patterns, a Manning book that needs to be on every software architect’s bookshelf. She’s also the CTO of Weaveworks. She was fantastic, so don’t miss it. Until next time, thanks for listening, and stay safe.

    The post Episode 50: DataStax NoSQL solutions built on Apache Cassandra with Kathryn Erickson, Open Source and Ecosystem Strategy first appeared on Open Source Underdogs.

    0 min
  • Episode 49: Open Source API Management with Martin Buhr, Founder / CEO of Tyk
    Intro


    Mike Schwartz: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 49 with Martin Buhr, CEO of Tyk. API Management is a hyper-competitive market–there are commercial, open-source and SaaS products from which to choose. This makes Tyk’s success even more impressive. I think they’ve done a lot of basic things right: keep it simple, provide great support, make sure customers are happy. That’s enabled Tyk to grow organically, with a relatively small amount of outside investment.

    This interview, it’s a little bit on a long side, so, let’s just get on with it. Here we go!

    Mike Schwartz: Martin, thank you so much for joining today.

    Martin Buhr: Hi, yeah, Mike, thanks for having me.

    Origin

    Mike Schwartz: In 2016, the API Gateway and Management market was already pretty well-saturated, you could say, with existing well-funded competitors. Why were you crazy enough to jump into this shark tank?

    Martin Buhr: Well, the origin story, it’s a bit of a Cinderella story actually. I needed to make a gateway for the platform I was running as a side business, besides my regular job. And the existing solutions that were around were either large enterprise monoliths, SaaS platforms or open-source platforms – there was one or two – but they were getting really, really big. There wasn’t anything small and tactical to just use — I mean, I could use like NginX or something as a proxy, but I needed more than that.

    I had just rebuilt my existing services with API first, and the platform itself, I didn’t want to write my own authentication code and I thought, “Well, that’s what API gateway’s for.” And I couldn’t find one, and I thought, “Well, what the heck, why don’t I just build one?”, which is probably a stupid thing to do, but it turned out okay.

    So, that’s why I ended up with the Gateway. It was really small tactical at first. Work with my platform was really meant to sort of easy to inject into other ecosystems, without having too much deep integration. And I kind of built on it, to get more metrics out of it and understand how people were using my service. Until eventually, I realized that the side business I was running was awful. It was just costing me more money than it was fun to run.


    So, I closed that down and open-sourced the Gateway because I thought why not, it is a pretty decent piece of software. And that’s how I ended up in a market, it was almost accidental. And at the start, I had this dashboard which was the UI for the system, and also gave me some analytics. And I thought, “Okay, I will close-source that and I’ll sell it.” The Gateway itself will be open-source, and I’ll sell them, the dashboard.

    I sold the initial

    version of the dashboard for something like 400£ for a lifetime license because
    I wanted to take my wife to – I was living in London at the time – I wanted to
    take my wife to Gordon Ramsey in London, which is this super restaurant.

    And their average meal per head is 400£, that’s how the meal cost, which is a stupid amount of money, but it’s a very good food, and anyway. So, I wouldn’t say that I started with a great business model – I just wanted to take my wife to lunch.

    Origins Continued

    Mike Schwartz: The open-source project started before the company. At what point did you say, well, I think we can really scale this, and what was your plan for sort of scaling the business?

    Martin Buhr: After that initial sort of launch phase and sticking up the project on Hacker News with the small website, it got a lot of attraction, lots of people were interested, and loads and loads of different companies came along and emailed me, amongst which some of them were — we had Home Depot, Viacom, and a couple others. Some Fortune 500 sort of emailed me saying, “Oh, hi, yeah. We’d love to try your platform out, can you tell me more, can we get a call?”

    But I was having those conversations at six o’clock in the morning because I was in the UK and they were in the US. And there I was in my pajamas, trying to convince them to spend some money with me, and they would tell me, “Well, how does your support work, and how are you going to scale this business, and how is this going to work long-term, why should we onboard this?”

    It was the first spur to say, “Well maybe there’s a bit of a traction in this, and maybe I need some help. You know, I’m quite technical, but I’ve not run a business successfully, and marketed it and sold it properly, you know.”
    Once we got the initial traction, and I saw a lot of interest, I managed to talk to an old friend of mine, I used to work with, into joining. And he came on – his name’s James – he came on as a CEO, commercial guy, and sort of helped me shape the whole thing. He shaped the business, he shaped the product offering and the marketing, and I shaped the product.


    And that was a good team, because we used to work together at the agency, and we were project managers together, so he was very much on the commercial side of things and the operation side, and I was very much on the technical side of things, but we pitched together a lot.

    So, we kind of knew each other’s flow, so when it

    came to — I think one of the first people we had to pitch to was Eurostar in
    London, which is the link between Britain and France, the train that goes up
    through the channel tunnel. And when we went there, it was our first real pitch
    as a company. And that’s sort of how it moved from being an open-source project
    that had some interest to being something viable. I think one of the things I’d
    really came back that they sort of told me that we were annoying people or, you
    know, poking them in the eye with this project was when one of our competitors,
    and they are not the only ones actually, three of our competitors offered to
    buy us or acquire us.

    And this happened early on, when they came along

    and said, “Oh, don’t you want to work in Silicon Valley? Don’t you want to do this,
    don’t you want to do that?” And that kind of thing tells you quite a lot about
    the business having viability. So, at that point, we thought, “You know, let’s
    do this.”

    Our first real sort of tangible money spending

    client wasn’t even a client, it was a company in the US in Texas that wanted to
    try us out, and James sort of talked them into doing an onboarding and training
    session with, so that we could try it out, and so we could do the integration
    for them.

    So, they paid for the tickets in the per diem

    for us to go visit Dallas, spent a week there, I learned how to two-step. It
    was pretty cool, a far too much Tex-Mex food. And we actually never got the
    client, they changed teams halfway through, so we never actually got the deal, but
    we did get this real validation. And it was on that trip, where James turned
    around to me, and he said, “When I get home, I’m going to quit my job.”,
    because we both had day jobs at the time. And that was it. He was employee zero.

    So, that’s kind of the way that panned out. We kind

    of stumbled into it, and then went into it full-on once we felt we had real
    traction. It was something there that showed growth. We had people who were
    actually willing to spend money on the product and spend money on us, so, yes.
    Does that answer your question?

    Mike Schwartz: Yeah, definitely.

    Value Prop / Open-Source Strategy

    Mike Schwartz: So, today, what would you say is the most important value

    proposition for your customers?

    Martin Buhr: When people come to us for API Management, there’s multiple

    outcomes they come to us for. They might be breaking down a monolith into a
    microservice architecture, they might be adopting Kubernetes, they might be looking
    at functions as a service, or they might be looking at the old-school API
    economy stuff. So, you know when you said earlier how the market was saturated
    with solutions, those solutions are built on the premise that users wanted to
    sell their back office.

    So, they had existing service that they wanted to monetize them. That was the API economy. And all those business premises were on that, where it’s actually — I feel like API management now is much, much more than that. It is all about managing internal services usage, external service usage, integration – it goes all over the place in terms of the actual market. You know, sometimes we have customers going to us for integration problems, which aren’t API Management problems.

    We also get a lot of folks that are just moving vendors, but the main value proposition for us is, Tyk is small, lean, really efficient. I mean, we get benchmarked against NginX and OpenResty all the time. So, you know, latency matters a lot when it comes to high-volume APIs. So, all of those boxes are ticked. Being an open-source product, we’re not open core, we’re open source. It’s just a big distinction between those two things.


    So, we spent a lot of time, effort and money on engineering team working on the open-source project, to make sure that it has all the features you need to get the job done. Most open-core products will just give you an empty shell and then sell you the bits you need. We don’t do that, we don’t hide the ball. That’s a big change for us, and I think one of the largest pieces for us is that when folks come to us we have a really unique way of engaging with customers. You know, James and I are from the agency world, and it’s slightly different in terms of how you handle your customers to have a normal B2B sales works.


    And I think our customers see that, and it’s created this — we have this amazing reputation for customer support. We’re always rated best of the best in Forrester and Gartner every single time. Our customers are extremely satisfied with dealing with us as a company. We are extremely good handling our customers and handling our relationship. And that’s a great value proposition, because it means, once they meet us, they go, “Oh, this is a bit different.” And then they look at the product, and they go, “Oh, this product actually says what it does on the tin.” And that’s a big differentiator for us.

    We were also – and this is slightly different aspect, but when we entered this market, one of the main things we did was say, when somebody wants to install a critical infrastructure, like an API Gateway, they do not want to worry about security concerns, that software phoning home, worrying about external access to it, or external access to those laws.


    So, right from the back, our software does not phone home, our licensing system doesn’t check on whether your license is valid – it’s all cryptographically done. And that puts us at a bit of a risk. It puts us at risk to make sure that we are selling something that will not bring us any income revenue, but at the same time, it gives our customers that satisfaction that they can actually create their infrastructure behind the firewall, lock it in the cave somewhere, and it will still keep ticking over. And that’s really important, especially when you go into heavily-regulated markets like healthcare, banking, insurance, and things like that.

    Because these organizations, they need to be

    able to file out their solutions, and make sure that they have full control.
    So, we kind of revived this on-premise business model, where everybody’s moving
    to SaaS, we said, “No, no, go on-prem.”, because a lot of organizations need
    this, especially B2Bs.

    You know, for the smaller stuff, we see a lot of

    companies coming to us for our SaaS, and we were one of the first companies to
    offer a hybrid SaaS solution, so you could go into our cloud, you could run
    your traffic via our cloud or, you could run your gateway locally and localize
    your traffic, but have all of the management infrastructure, which is the more
    expensive part of the infrastructure sitting in our cloud. And that was a bit
    of a big deal at the time.

    And we took that capability, and we made that

    into a product, and now that became our Enterprise product. We called it rather
    imaginatively multi-data center bridge. It doesn’t really roll out of the
    tongue, but that piece of software is our big, big ticket item. And it’s
    closed-source. But all it really does is it enables the user to manage their
    API ecosystem and their gateway fleets across multiple data centers, firewalls,
    regions, without having to worry about latency uptime of connectivity, they can
    fail independently, and they scale it independently, and that’s all built into a
    base platform.

    So, it’s quite powerful. When you get out of the

    box, it’s super powerful. And then, if you add all value-add that we have,
    that’s closed-source on top of it, it’s worth the money.  So, when it comes to open source, a lot of
    people try to monetize open source through support, and that’s when it’s hard
    to scale. You know, when you scale support, you’re scaling the margin you have
    and your time.

    So, your customer base gets bigger, and you’ll

    look at your own, let’s say, your customer base comes in, they join in, the
    organization, they’re trying to integrate your number of support calls and the
    usage of SLA peaks over let’s say maybe six weeks. So, they’re getting their
    money’s worth on what they pay for support.

    But then, once everything’s working, and they got the hang of the product, that tails off again. And that’s great because, obviously, it frees you up to do more support work, but it also means that the value they’re getting out of it, goes down. And then, it becomes more of an insurance policy, and expensive insurance policy, which means, it’s one of the first things that gets caught, especially when your software works really well. You know, as you grow, you then hire more support engineers to help you make sure you can manage SLA.

    But as that support tails off, where your business stops growing so quickly, those margins you’re making on someone’s time, just aren’t sustainable, and they scale really badly. Whereas selling a product, so selling a physical thing, you know, the old school put it in a box and sell it to the end-user – that has a huge margin, because you sell a thing, you’re dealing with unit economics. And that’s much, much easier business to run.


    So, when we came to the open-source conclusion, we said, “Okay, so we’re going to hamstring ourselves by giving away a free product that’s incredibly powerful. And then, we’re going to have all these value-add products that sit on top of it that are geared towards the enterprise. But those will be closed-source. And that is what we will sell. But it’s worked for us, because the thing is the value-add stuff that large organizations want to pay for is the kind of stuff that gives them those insurance policies.

    Most engineers don’t want user interfaces, they

    don’t want human intervention, but their managers do. That VP of marketing
    wants to be able to go in and look at a chart. And they need that full back
    control, where they can manually intervene, without having to worry about a
    DevOps pipeline, or something like that.

    And then, there’s that piece, obviously

    analytics is a very big piece. And then, last but not least is simple things
    that all businesses want, single sign-on, role-based access control
    multi-tenancy. Those are the kind of things that large enterprises just
    salivate over. And if you can take that, bundle that into your enterprise
    value-proposition, that’s the bit you sell. And you’ll see actually, if you
    look at most open-source solutions these days, you’ll see that there’s an
    open-source product. And then all of those businessy things are the bits they
    sell for an extortion amount of money.

    Is Tyk Open Core?

    Mike Schwartz: Actually, I wanted to roll back a little bit to something

    that you said. You mentioned that you’re open source, you’re not open core,
    would you say that there’s a core product, or let’s say, that’s open source, and
    then, there are additional components which are commercially licensed – how
    does it work?

    Martin Buhr: The bit that does all the heavy lifting is the gateway. It’s a

    proxy, traffic goes in, gets managed, traffic goes out the back end. And that’s
    where all the hard work happens. So, not only does it move the traffic, but
    also it applies things like rate limits, quotas, it gathers analytics, it might
    transform the request in some way, it might run some plug-in middleware – all
    kinds of transformational or validation elements that you need to do to your
    traffic. That’s where your authentication lives, where your authorization
    layers live.

    That component is sort of the key bit, that’s

    what you want. That’s the thing that you want to put in front of you, into your
    DMZ, in front of your traffic to secure your services. That part is completely
    open source, and all of the components you need, all the features you need, to
    manage your traffic, is part of that component.

    If I went out and I said, “Okay, I am large business A, and I want to spend no money on my traffic management, my API gateway and my API management.” I could do all of that, with our gateway. The only difference is, there’s no UI, you have to do it all programmatically, with our API, and with files, and all that kind of good standard, you know, unixy way. So, that’s fully functional. We don’t hobble our product at all. But then, we have the components that go on top of that that are the value-adds. So, there’s a separate service called our Tyk dashboard. That’s the management UI. It’s also the management API.

    So, the dashboard is a single-page web app. It consumes the dashboard API, the dashboard API is much larger and granular, it’s multi-tenanted, you can have users, RBAC, and all of that good stuff. It also has a developer portal, which you can expose to let your developers that self-serve access to various services in the organization or even externally.

    And so, that part, that whole application is

    closed-source, and that takes a license key. And that license key is
    essentially a cryptographically signed object, we use a private key to sign it,
    the public key is embedded in the binary, so all we need to do is validate the
    signature. If the signature is valid, we can trust the claims inside it, and
    that then says what you’re allowed to do with the dashboard.

    And it has an expiry set, so we know that, let’s

    say, it’s a one-year license, and then the software will lock you out after one
    year because that’s expired.

    Good thing about that is, it doesn’t need to call home, we don’t need to actually validate the license because all that stuff happens in the software in quite a safe way. It’s hard to break unless we lose our private key obviously. So, that’s one component, and then the second component that I talked about, this multi-data center bridge, also has a license with a separate key because it’s an add-on. So, you can kind of build out your ecosystem with Tyk. You can start with the gateway, which is open source. “Okay, this is great. I like this, but I actually want a UI, and I want all this cool RBAC functionality.”


    So, you buy the dashboard, and you just tell the gateway to be managed by the dashboard. So, now, you extended out your installation. And now, I actually need gateways in six different locations or six different networks. Okay, I can’t do that with one dashboard because of latency problems, database problems and things like that, so I’ll buy the multi-data center bridge. It’s an add-on, you point the bridge at your dashboard, and you point your gateways at the bridge. And it then takes care of handling your fleet.

    So, we basically license those components, and

    within the dashboard, there are feature flags, you know, for role-based access
    control, multi-tenancy, things like that, single sign-on. Those are feature
    flags we can switch on and off in the license, so we can start with a base
    license, and then build up on the pricing tiers from there. And we leave that
    up to – it’s not a software decision, that usually goes to the commercial team.
    They’ll sort of know what levers they see coming out of the interactions with
    potential customers and saying, “Okay, well, these are the things that people
    want. Let’s figure out how we can price those.”

    So, there’s always this evolution in how we

    price our software, but that’s essentially how we manage it. It basically means
    that somebody could go along, they go to our dashboard installation, they run
    that for a year, and they’re like, “Okay, we can’t afford this anymore.” They
    don’t actually have to take away this out – they just simply have to take the
    configurations out, put them into the open-source system and take away the
    dashboard, and they can keep running. That’s the important bit.

    Whereas with an open-core system, the core thing, doing all the work is hobbled. Because, if you no longer own the components that are doing the work, like your rate limiting, or managing open ID connect, or something like that, then actually, the whole thing is broken. So, you can’t continue, you have to shift.

    Products

    Mike Schwartz: So, of the pre-products that you mentioned, there’s the

    self-managed, the enterprise, and the SaaS. From a revenue perspective, which
    of those is the most important today?

    Martin Buhr: At the moment, on-prem, the self-managed is the one with the best

    margin, because we don’t take on any of the costs of running the software. SaaS
    is a tricky business, you have to run it, you have to put a margin on top, and
    you scale accordingly. So, there’s quite a lot of cost of just getting
    everything running.

    We’re about to launch the brand new version of

    our SaaS, which basically takes all of the stuff you get with the on-prem
    version, all the good stuff, like our plug-in capability and things like that,
    and makes it into a multi-region SaaS, so you can say, “Oh, I want to have my
    dashboards in…”, but that’s mainly on data sovereignty because we operate in
    Europe, and we operate in Australia and Singapore. You find these data
    sovereignty levels get more and more and more strict. And that’s why on-prem is
    really popular.

    But the first thing that gets cut during

    recession is your DevOps team. So, the last thing you really want to do is
    manage people that manage software, so they all go for SaaS. But then, if your
    SaaS offering is enough to scratch, you lose them at that point. So, we’re
    building our SaaS to basically be just as competitive as our on-prem solution,
    and just as capable in terms of where you locate it, where you run it, and
    doing it all by a managed controller, to make that work. But essentially, to
    answer the question, yeah, the wholly-owned system is the one with the biggest
    margin, and the one we currently see the most interesting.

    Sales Motion

    Michael Schwartz: So, on your website, I didn’t see any particular vertical,

    marketing focus. Are the sales opportunities primarily inbound, like i.e people
    find the open source and then, they reach out to Tyk?

    Martin Buhr: It’s a bit of a mix, mostly inbound, yes. People do reach out to

    us, we don’t necessarily have to go banging on doors, which is good. The way
    people find us are a few. Yeah, there’s google looking for the open-source
    software, trying that out. But actually, interesting, a lot of stuff that
    drives us is, whenever there is a comparison, we’re always in the mix these
    days with our largest competitors.

    And Gartner and Forrester run reports on full

    lifecycle API management. And we were lucky enough, six months into launch of
    the company, to be featured in both. I think we were an honorary mention in the
    first Forrester because we didn’t quite have the revenue they needed for open
    source, but we did manage to get in there.

    So, we’ve been on the radar for a while.

    Nowadays, it’s more about when people look for, you know, they’re looking to do
    a proof of concept or some kind of RFP that will hit us off just by default.
    And then, they reach out to us and say, “Tell us more about your software.”

    You know, the other sort of big inbound market

    is – especially in Asia actually – is partner marketing. So, we have a whole
    bunch of integration partners out there since our business is mainly the use
    case for an API Management solution is ultimately an integration problem.

    So, we have all these systems integrators that will look to us to provide a solution. And they might be more vertical focused. So, you’ll have NSI that’s healthcare, or you know, government, or things like that. And they’ll specialize in that sector for us. They’ll build on top of our platform.

    Partner Development

    Mike Schwartz: Did you actively recruit and identify the system integration

    partners, or did they find you?


    Martin Buhr: We hired a really, really good sales guy in Singapore, and he knew how that market worked out there. So, he courted them initially, it was a bit of a mix of inbound and courtship, and usually what happens is, it’s a bit more opportunistic. The problem with legacy providers at the moment is they already have all these partner relationships set up, but they’re also extremely expensive. So, when it comes down to trying to cut costs or trying to streamline things like government spending, looking at the value, those solutions add, becomes problematic for most, especially if they’re closed-source. The open-source model always feels cheaper, so that tends to be a big driver as well.

    I’m not saying that open source is cheaper, but

    open source is perceived as less costly because it doesn’t come with the
    overhead of training and a sales cycle that comes with it. Because you go and
    try and get a trial of a large enterprise piece of software, you have to go
    through three layers of account managers, sales peoples and technical
    representatives before you can get your hands on the software. And that’s bad
    accessibility can be a real problem, buying off the back of a data sheet.

    Is It Worth It To Serve Smaller Customers?

    Mike Schwartz: I’m gathering that enterprise customers are most important from a

    revenue standpoint, but have you found a way to serve small organizations, i.e
    through the SaaS? And is serving those smaller organizations actually like
    materials of the business? Is it worth the effort?


    Martin Buhr: It’s definitely worth the effort. I mean, we started off as a community business, still are. The people that pay our bills are the large Enterprise customers. Those are the ones we really try and court, but those are six-month, twelve-month deals. You know, selling into the enterprise takes forever, not just from just getting in the door, but also just getting contract signed and making sure that the invoicing is correct, and going through all their procurement coops. So, that’s all well and good.

    That’s the bit that sustains you, but at the end, it’s the smaller engineer, the side project, the hacker that drives interest, that pushes the platform a bit, that actually will probably contribute back. Especially in the open-source place world, and so we do. I mean, as our SaaS version is relatively less costly than the on-prem version, and we do obviously offer discounts for charities or small businesses and things like that.

    So, we do have ways in to use the software

    without paying us a fortune. And we do sometimes say, “Here, you have the
    dashboard to be filtered free.” But most importantly, what I said is, “If
    you’re working with a smaller customer, is we can enable them through our
    community support or through discounting, to make sure that they get what they
    need.

    We don’t actively go after those customers.

    Instead, actually, almost every single time, you engage in a sale, especially
    in our market, it’s an integration sale. There’s a lot of expertise required –
    they’ll have their own identity provider, they’ll have their own databases they
    want to use, they’ll have different service types that they want to use,
    they’ll have specific integration problems that they need to solve, and they
    need your help with.

    You know, that’s the old fight of how good is

    your documentation versus how much help do you want to give on a personal
    level. In this case, that person’s time is really expensive, so we have to be
    very careful where we spend that time, but we do make sure that all of our
    engineers, for example, are on our community forum and are actively engaged in
    helping the community, make sure that they can do what they need to do and work
    with the software. We’re not exclusively focused on the enterprise, we just
    can’t spend a huge amount of time on customers that don’t sustain us.

    We do ultimately have bills to pay, and

    developers got to eat. We have something like 74 people on staff now, in 22
    different countries. And, well, it’s lovely to be able to offer an open-source
    piece of software to the community, and take the position that we will never
    hide the ball. And you know, it’ll be a fully functioning piece of software
    forever. The bits that are the value-add, we do need to charge for, and we just
    need to make sure we can keep the doors open.

    One of the things I think that really puts a lot of people off of starting an open-source project is, there’s a lot of entitlement that comes with folks that use open-source software that they don’t quite understand. You know, the person building it is doing this out of love or, you know, because they enjoy it. It’s rare that an open-source project becomes a business. And once it becomes a business, your viewpoint has to change. So, it’s a sort of double-edged sword of how much do you put up with users that feel like you owe them something versus trying to run a business profitably.

    Hybrid Cloud Pricing

    Mike Schwartz: Hybrid cloud API proxies are hard to price. Some companies are pricing

    per transaction, but transaction value varies widely based on the line of
    business per server. And CPU models are tough because in the Cloud Native world
    with auto scaling, compute can be a moving target. I heard MuleSoft has a
    pricing model based on per container hour gig of RAM. So, I’m wondering, have
    you figured out what are the gates you’re using to figure out how do you price
    for this type of service in the enterprise space?

    Martin Buhr: Hybrid’s

    tough because you’re not actually running the traffic either. So, if you’re
    telling a user, “Oh, no, you run all the infrastructure, and we’ll charge you
    for the traffic.” It’s problematic at best. So, what we do is, for us, when
    somebody comes along and says, “Okay, we want to use the hybrid.”, they are
    basically using — you have to remember that everybody that uses our software,
    no matter the large enterprise to the smallest user are all using the same
    open-source gateway.

    So, if you use our hybrid offering, you’re

    actually using our open-source gateway in the configuration, so it works with
    our hybrid cloud. So, the nice thing is, we can basically say, “Look, here’s
    the container, it’s public, do what you want with it. Just make sure you
    configure it this way. And the way we price is pretty straightforward – you
    basically pay us for your account. It’s a monthly subscription, and that
    subscription comes with data retention limits. So, that’s the most expensive
    part.

    We don’t run any of the traffic. The traffic is

    going through hybrid gateway, so we are just collecting and storing and
    processing analytics, and that IS expensive.

    So, we say, okay, so per gig, per — we actually

    do it by number of days we store it for. You know, you get seven days, or 30
    days, or 100 days, plus the additional features in the dashboard because all
    the value-add stuff, so single sign-on, role-based access control – all that
    stuff that lives in the cloud bit, whereas the hybrid gateway itself is fully
    featured, so they just simply need to configure it.

    So, actually the way we offer is just a subscription model, where we don’t charge by scale. If they want to run 100 gateways, that’s absolutely fine. I mean, admittedly it’s a bit of a surprise to us when people do it, but we have had it before where we had one Malaysian customer who was — they were a huge ecommerce provider out there. So, big sort of eshop, mobile shop. And they were running millions of requests today, through our hybrid infrastructure. And they must have had 100 or 150 gateways spun up in their architecture. I think they were using mesosphere.

    Yeah, it just sort of, it stood up, as long as we didn’t have to store it, it was okay. So, for our hybrid instead, we’ve actually parceled it as part of our overall SaaS solution. So, if you pay our cloud price, we throw hybrid in, just as part of it, because it’s meant to be a flexible proposition – it shouldn’t be either/or.

    Self-Hosted Pricing

    Mike Schwartz: I see, what about on the self-managed piece, how do you price

    that?

    Martin Buhr: Well, if it scales according to how many gateways the dashboard

    has to manage. So, you could for example, have 10 gateways running open source
    – fine, no problem. But as soon as you introduce the dashboard, we limit that
    down to how many things can actually connect to it. So, customers come to us
    and say, “Okay, I have this much traffic, I have this kind of size of server,
    these are my requirements for a high availability and failover.” And we can
    then put a package together for them saying, “Okay, well, you need two
    gateways, or you need five gateways, or you need ten gateways to manage that.”
    And then the license is built accordingly.

    So, they then install the license, and it allows

    ten gateways to connect. If you try to add an eleventh, the one that rejects
    the connection, that gateway doesn’t boot basically.

    What Is Tyk Doing To Grow The Community?

    Mike Schwartz: It sounded, like you were

    saying, that you actually had good community interactions on the support
    forums. Are you planning to foster growth of the open-source community and
    ecosystem, and how are you planning to do that?

    Martin Buhr: Yeah, we just hired a full-blown community manager – I think he came to us from Mozilla to help us build out our open-source offering. So, it’s one of those things that gets neglected as you get bigger. You kind of go, “We’re making money, uuu, let’s focus on that.” And then, you sort of forget about all these free users that are sitting there, giving you all this free feedback on what your product needs.

    So, we do a couple of things. One, we have an open-source community forum, and all of our engineers are on there, all of our consulting engineers, so these are kind of like post-sales technical architects are on there, plus our support managers are on there to make sure that there is coverage. So, you do actually get access to the staff, it’s not just the community helping itself. So, we do actively do that. It’s obviously a bit slower than our SLA approach, but, nonetheless, it is there.

    And then, as a sort of a community manager is

    focusing quite heavily on what we can do better in Github, managing tickets,
    managing visibility of the roadmap, managing pull requests, and also in
    general, figuring out how we can shift from being an open-source project that
    we mainly drive to becoming more of a platform that people can build on top of.

    We are currently investigating ways of doing that to make that really work, because as I said, you know, systems integrators and partners, they will have large companies like Accenture or Tata Consulting, or Capgemini, you know, they do have industry vertical professionals. And those guys will go in there with the product that they’ve got internally around HIPAA compliance or HR compliance, or open banking, or whatever. And they’ll want to build products around that.

    So, the more customizable your solution is, to handle an industry, handle a vertical, the better, because they can build products out of your platform, and both people win. You win because you sell a license, they win because they’ve now cornered a vertical with this particular solution that happens to be based on yours. So, that’s sort of where I’d like to see it go.

    And we’ve seen it here and there, you know, it’s hard to track them because as I said, we don’t call home, so we don’t actually know where any of these open-source gateways are running. But when they do pop up, you do find some really interesting stuff.


    We had a customer in Thailand that said, “Okay.”, that the guys they brought it into the company, they eventually left, and they started their own thing. And they just recently shared with us like, “Oh, look, we’ve done all this extra work, and now it integrates with this, and we have all these plugins.” And they’re literally running a business off of that. And I love to see that, it’s amazing. They’re doing this all open-source work, and we’ve seen a couple of integrators, partners, individual open-source contributors, just taking the product a little bit further. And that’s wonderful to see. So, I actually like to see more of that and have more visibility of it.

    As we said, we don’t at the moment, because we don’t really force it to call home, so we can’t really just sort of poke a user and say, “What are you doing?”

    Open Source Ecosystem Duplicating Enterprise Features?

    Mike Schwartz: How would you feel if somebody took the open source, or some

    company took the open source and built a sort of platform around it, and there
    was some overlap, maybe with some of the features that you were offering? Would
    you see that as a positive or negative for the company?


    Martin Buhr: It depends. If they’re taking business away from us. It’s a positive most of the time because they’re doing something with it that we can’t do. If they’re doing full-blown overlap, like they’re taking our dashboard and copying it and adding services on top, and then saying, “Okay, this is a cheaper version of the version you can get from the vendor.” I would be a little bit irritated because it’d be reverse engineering, some APIs we’ve got. BUT, it is the price you pay for being an open-source market, for being an open-source product. It is part of the risk.

    You see a lot of people moving into the business

    source license, and we considered that for a while to think, “Okay, well how do
    we stop people trying to edge into our market.” And at the moment, it’s not so
    serious. I mean, if you were a database, like Mongo or Redis, it’s a much
    bigger problem because your footprint is much bigger, in terms of usage. And
    it’s this whole thing, it’s sort of API theft, or Driver theft.

    And you can see it in some businesses as well

    that they are API based, where, all of a sudden, they’ll go, “Oh, we support
    the Uber API for our car service.”, which means, you can just point at a
    different endpoint, and your SDKs will continue to work, or all your
    integrations will continue to work. Or, you can just drop in a new driver, you
    can use the same Redis driver to connect to ElasticCache as you can to run fast.
    That’s just mean.

    It’s really taking advantage of interfaces, and

    I think it’s part of the open-source problem, it’s a real issue if you become
    very successful in open source. You know, you become a kind of standard, I
    mean, we don’t have that yet. I would love that, but we don’t have it yet. But,
    it’s like MySQL, or Redis is a great example, they have this wire protocol, if
    somebody wants to launch a competing product, they just need to implement this wire
    protocol because it’s open source. And all of a sudden, they can say, “Oh, no, we’re
    driver compatible.”

    Cockroach Labs, for example, is driver

    compatible with Postgres, let’s interface that.” It’s just a way of acquiring
    users through somebody else’s hard work, which is — it’s a risk, it’s a real,
    real risk. And that’s why things like the business source license exist. But I
    think the only time you need to look at something like that is when you do
    actually have people building out large-scale, high-visibility platforms that
    are competing with yours.

    Most of the time, there should be enough space in the market for you both to coexist, so it’s a bit tricky. There is no answer I think. I’m not sure if that answers your question.

    Advice For Startups

    Mike Schwartz: So, last question. Any advice for entrepreneurs who are launching

    a business around an open-source product?

    Martin Buhr: The first thing is, try and figure out what are the bits that are

    valuable in your product, because that’s the thing you’re going to need to protect
    and monetize. A great example actually is the Caddy Project, a really, really
    good web server with some really strange monetization options. And they changed
    their tune several times, from enabling access to a built server, to removing
    headers, to doing all kinds of stuff with their proprietary version. And it’s
    because the entire product was open source.

    What you need to kind of figure out, if you look

    at like Kibana or even NginX, you kind of want to say, “Well, if you’re going
    to try and monetize an open-source project, you can’t monetize the actual open-source
    piece because that’s always going to be free and open, and you don’t really
    want to be hobbling your own open-source software.

    So, you have two choices: you have the choice of

    either forking and creating a second branch that has all the value-add stuff
    that you want to sell, or going open core, where you then sell the plugins and
    things like that. Or maybe go like us, where you say, “We have an open-source
    offering, we’re going to continue providing that, it’s fully functional.” But, if
    you’re a big business, you’re going to want all this extra stuff. That’s the
    stuff that’s instead of baking it into the core, we’ve created different separate
    services for it, and we charged for those. That makes it more sustainable.

    The other thing is, I guess, if you’re starting

    an open-source business, you need to really figure out who you want to sell to,
    because mass market is hard. If you’re looking at investment, mass market is great.
    So, if you’ve got something that’s got really high penetration – a good example
    might be, like Postman or Visual Studio Code, that gets a lot of adoption, it
    gets a lot of adoptions. It means you have access to millions of users. And
    that’s really valuable because you can eventually monetize that and mine it for
    that 10-20% that’ll actually pay you some money.

    When you’re going mass market, you have to go

    for as much penetration as possible. If you’re going B2B, and you want to go
    into the enterprise layer, and you want to start charging those big bucks, you
    need to really start thinking about your sales process. I think most startups,
    when they get into the B2B industry, even if it’s open source or not, selling
    to a business is hard, it takes forever. If you don’t have the experience of
    working in that environment and dealing with the red tape, the context, the
    process, and the flow, you’re going to have a really hard time to break it.

    So, that’s the second thing, it’s probably

    easier for an open-source product to go from mass appeal rather than B2B, but B2B
    is where all the money is. With the mass appeal product, if you’re going to
    say, “Okay, I’ve got a new code editor, or a driver, or a really cool data
    stitching API or whatever, if you get a lot of users for that, that’s great, but
    you’ll need to monetize them down the line.

    And one, that means you have to alienate your

    community, two, it means that actually your value will be in that network, which
    means you’re going to be trying to sell on that network. And open-source
    business is that we are relying on a network need funding. So, eventually,
    you’re going to have to get funding in order to monetize the network, in order
    to get to a point, where you’re profitable.

    At Tyk, we were really, really lucky because we managed to build the business really organically from the start. We started with zero employees, then one, then two, then three, then seven, and that was off of the back of a little bit of Angel money and actual real deals. We were making cash, and we were in the black. And then we grew slowly.

    We only took funding last year, but that was so that we could go aggressively into the American market and open an office there because that costs a fortune. You know, you can’t build that organically. So, you kind of need to really figure out where you want to go with your project if you’re going with open source. That’s a lot of weird advice, I guess.

    Mike Schwartz: That’s great. Martin, thank you so much for spending all the time

    with us today, and congratulations, and best of luck.

    Martin Buhr: Thanks, Mike.

    Mike Schwartz: And thanks to the whole Tyk team for collaborating on this

    podcast. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool
    graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie
    and Lee Rosevere.

    Don’t forget to follow us on Twitter. The handle is @fosspodcast. You can also follow me personally on LinkedIn. I always post a link to the episodes, and you can share it from there too. Next episode we have Kathryn Erickson from DataStax, one of the leaders in the Cassandra ecosystem. Hope you enjoyed this episode. Until next time, thanks for listening.

    The post Episode 49: Open Source API Management with Martin Buhr, Founder / CEO of Tyk first appeared on Open Source Underdogs.

    0 min
  • Episode 48: Zero Trust Security and Packaging with Ev Kontsevoy, CEO of Gravitational
    Intro


    Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 48 with Ev Kontsevoy, CEO of Gravitational.
    This episode, it’s a little longer than most, clocking in closer to 45 minutes. That’s definitely because Ev has such a broad breadth of technical and business experience, we probably could have gone on another hour.
    If you want to hear a little bit more about the tech stack, watch The FLOSS Weekly, episode 529. I’ll put in a link on the episode website.
    Gravitational has two very interesting products, and they are somewhat related but also a little different. It must have been a tough marketing challenge to come up with a unified message, but apparently they did it, because the company’s been super successful by all measures.

    So, without further ado,

    let’s cut to the tape. And after you listened to this podcast, I’m sure you’ll
    want to check out Gravitational’s website for more info.

    Ev, thank you so much

    for joining today.

    Ev Kontsevoy: Thank you for having me, Mike.

    Story Of Mailgun

    Michael Schwartz: Before we talk about Gravitational,

    can you talk a little bit about your previous startup called Mailgun and your
    experience at Rackspace, and how that led you to identify the business
    opportunity for a Gravitational?

    Ev Kontsevoy: Mailgun was interesting, and for those who don’t know, Mailgun is an API platform to send and receive emails programmatically, so it’s email for developers. If you need to send a password recovery email, or if you need to send newsletters to your customers, you just use Mailgun API to send those messages and collect responses.

    That company was interesting to me because of two things. First, it was founded in the middle of financial collapse. I moved to New York City around 2009, right when the economy was self-collapsing, I guess. And it’s also when AWS was beginning to happen, which is always interesting, like, which means that when everything is crushing around you, there is always some positives. And I thought, well, if Jeff Bezos can sell APIs to servers, I could probably sell APIs to emails.

    And the reason for that is that if you’re moving to the cloud, you cannot really take your things with you, so whatever email delivery appliance you used to have, like you need to have a virtual replacement for it, that’s how Mailgun really got started. It was really tough, raising money back then for a project like this, because most investors didn’t understand what an API was. I would do a presentation, and then an investor will pull out a Blackberry. And he said, “All right. So, I got my Blackberry here out, so how do I use you API?” At that moment, you know that you lost, that this is not going anywhere.

    But then, an interesting

    thing happened. A Twilio got funded. And everyone paid attention because Twilio
    said, “Oh, we are API for developers to do, like, SMS.” They started saying
    that Mailgun is simply a Twilio, like Twilio, but for email. And it helped
    tremendously.

    So, we got accepted into Y Combinator, in 2011 actually, and went from there. I ran the company for a couple of years and eventually got acquired by Rackspace, by one of the cloud providers.
    So, the interesting thing I learned from that experience – well, it was my first company, so you’ll obviously learn a ton if you do that – but as a technologist, I wasn’t prepared to be exposed to so much…let’s just say crime. That’s what it is really. Because email is a really dark world, so many shady things happen via email. You know, fishing, and viruses, and spam, and I would say that 80% of my attention was consumed by those problems, as we were running that company, which is unfortunate, because you actually want your real users, engineers, developers to enjoy, the product, you want their experience to be great, you want performance to be great, you want documentation to be amazing. And you constantly have to deal with spammers, fishers, and all parts of bad, bad internet.

    So, that was my Mailgun experience. And the reason we, I guess, decided to sell that company to Rackspace, is because Rackspace at the time had very compelling vision, for using open source and open standards to free the world from AWS dominance.That was kind of resonating with me because I started my career as a software developer during Windows dominance. And I just remember how boring and bleak everything felt, just operating within constraints of what Microsoft thinks you should be doing. And, yeah, so that was the story of Mailgun.

    Technical Origins Of Gravitational

    Michael Schwartz: You know, it’s a

    totally different answer than I was expecting.

    Ev Kontsevoy: What did you expect?

    Michael Schwartz: I was listening to another episode, or another interview with you, and you spoke for some time about some of the interesting technical challenges around how complex Mailgun was, and how you were considering replicating it on a different cloud, and how completely, like just, it seemed like such a big challenge. And I was wondering if that sort of gave you some technical ideas that might have led to the development of the Gravitational, like, technology stack?

    Ev Kontsevoy: Oh, so, that’s more interesting question – how did I go from being an email person to effectively ending up almost in the security space. So, what do you think happens right after an acquisition, when one technical company acquires another technical company? It happened with us, and maybe, like, when Facebook acquired Instagram, there was probably something similar there, the first thing they ask you to do is, start planning to migrate all your stuff into their own infrastructure.

    Especially for Rackspace. Rackspace’s a cloud provider. It would be really strange for them to have an email service that’s not using their own cloud. And at the time, we were using SoftLayer, which is now part of IBM – old-school, bare-metal servers, and migrating to a public cloud on Rackspace, which was virtualized and had all these fancy infrastructures as code capabilities. It took us a long time, I don’t remember exactly how long it took, but let’s just say if I say 6 months, it’s not going to be an exaggeration.

    And I remember having a conversation with someone in my family, maybe it was even my wife, where someone asked me like, “So, what are you doing – like, now, post-acquisition – like what are you building?” And I said, “We’re not building anything, we’re just moving from SoftLayer data center to Rackspace data center.” And that person wasn’t technical, and she said, “Isn’t that, like, copying files over the internet??” “Why is it taking six months?” Like, “You have that many files??”

    And I laughed. But at the same time, it was kind of illuminating. Like, normal people think that copying software from one data center to another, it’s something that happens within few seconds.
    Wouldn’t you probably feel the same, like, what is software, is it just some files, you have software on your laptop, I have software on my laptop, like, it’s just copying things around, but apparently, when it comes to data center software, to what we call cloud software today, everything takes months.

    And, at the time, I just kind of took this for granted, like you’re sure it’s a complex problem.
    We have completely different security here, we’re going to have that over there, over here we are using this kind of load balancing, over there is going to be different kind of load balancing, and the code needs to be updated, and so on and so forth.

    But then, when I became a “racker” – that’s how Rackspace employees called themselves, I was a proud Racker by the way, I love that culture – so, once I became a racker, I got exposed to vast representation of cloud users out there, companies who use cloud computing. And I was talking to them usually trying to understand how can we improve, how we can make our cloud offering better.

    And I was amazed how frequently they will bring this problem that I had with Mailgun. It’s like, “Hey, we’ve built this application, and it’s running on AWS, and now we’re trying to run it on Rackspace, and it’s really challenging. Can you help us?”

    Or they would say, “We want to use Rackspace, or AWS, or Azure, some kind of cloud provider to build applications, the development environment, but for whatever reason, we need to actually run it in Luxembourg, like in the data center that is supposedly compliant with whatever regulations there are under.

    So, how do we have staging environment in one place and identical production in a completely different place? And they kept coming to us looking for advice. And sometimes, we would be able to sell them something, you know, like DevOps as a service, or security as a service. But generally, I just saw this trend is that people feel like they’re chained to their cloud environment.
    It doesn’t even matter how amazing that environment is.

    But not being able to just take your production and have like, I don’t know, a hundred copies of it running all over the world – it’s extremely frustrating. And it’s limiting to a lot of use cases. You know, latency is important. Because the laws of physics, they don’t really change. So, you have to be able to run your code, close to where your data sets are. Data sets are distributed, which means that code needs to be distributed.

    And that’s what I became deeply dissatisfied with SaaS model, in general. I don’t think there is anything wrong with Software-as-a-Service, but there is definitely something wrong with software-as-a-service running in a single place.

    And as I was talking to more and more companies, I realized that some of them – check this out – they can’t even recreate their production environment in a different Amazon account. Those are companies based in Silicon Valley by the way.

    So, let me just kind of

    zoom into this use case: you have an application running in an AWS account that
    you have – you control that. Go ahead and create another AWS account from
    scratch, also yours, so you have full, you know, God permissions for both
    accounts. And then, have a full replica of what you have in one account and
    another. And a surprising amount of companies don’t know how to do that.

    They just overtime kind

    of lose institutional knowledge of what would it take to recreate everything
    from scratch. And as an engineer, you probably understand why that is
    happening, because you know, when you start building your application, like in the
    early days, not a single line of code is written, but you’d know that you need
    some environment.

    You’re going to go and

    click some buttons in that AWS panel, maybe you’ll write some terraform, or
    cloud formation, but not always, maybe use Ansible, so, you kind of start
    manually creating first layer of your future environment. Then you start adding
    things on top, then you start deploying your code, maybe manually at first,
    maybe SCP. And then, you move to something, I don’t know, maybe like Ansible,
    or Chef, or Puppet.

    So, things happen over time, and not everything is documented. Some scripts, they run daily, maybe they are part of your CICD pipeline. Other scripts you ran three years ago, and maybe the person who did it is no longer with the company. So, the point is, almost any cloud environment today, it’s built with many layers that are created over time by different people.

    And that’s the reason why they’re not reproducible. And a company needs to have, you know, we need to have seven regions all over the world instead of one. Or we need to run our software inside of someone else’s AWS account. Or we need to deploy into GovCloud because government wants to use our software. They run into all these issues that they’re chained to one specific environment. And that’s why Gravitational was born. That’s the company that a bunch of ex Mailgunners started. So, that’s maybe a different answer to your original question.

    Products

    Michael Schwartz: So, let me drill down a little bit more, Gravitational has

    two products, Teleport and Gravity. Which was the first product? Or were they
    both coming at the same time?

    Ev Kontsevoy: It’s basically a packaging question. We initially built a solution, so if you want to run your software in many different places, you have to solve many different issues for that. You need to separate your application dependencies from infrastructure. You need to solve remote access problem, you need to solve compliance problem – because a lot of these companies, like the reason they needed to be in the different place is because of compliance requirements.

    And we had – what I would just call a code base,

    a bunch of GitHub repositories. We have this culture internally that we create
    GitHub repository per library. So, we break everything we built into these
    libraries. Each library has its own repository, and then we compile the
    software, and then, we produce solution.

    So, originally, everything we built was just a collection of these repositories. And we started to sell the solution called Gravity, and Gravity includes everything we do. Gravity is a complete platform. With Gravity, you can take your AWS account – technically, it’s a Kubernetes cluster, but let’s put that aside for now – and you could save it all into a single file. That’s your image, we call it “cluster image”.

    Think about like doing a snapshot – it’s not a snapshot, but I think it’s a helpful analogy – and then you can move that file somewhere else, and you can create exact replica. So, you take this image that contains the full copy of your production environment, and you can copy/paste it all over the world, and you can have thousands of identical environments created from that image.

    So, the question then becomes, how do you keep them up-to-date, how do you push software updates, how do you fix the vulnerabilities, how do you troubleshoot problems that happen remotely. So, you do need to have some kind of remote access to those environments. Interesting analogy that I like is software updates built into operating systems.

    If you have a Mac, it somehow updates itself, it downloads things from Apple, it applies these updates at reboots, and all of this kind of is just working automatically. So, think about it, from Apple’s perspective, how is that different from running a massive software deployment to hundreds of millions of servers running on untrusted network all over the world, with unreliable internet connectivity. For a typical data center person, that is a Star Wars level tech. And that is what Gravity tries to do with data centers, with your cloud account.

    And this component that allows you to securely download and apply updates, that is what Teleport is. It is basically a part of Gravity that enables this world-class security into this restricted, regulated, remote environments, where Gravity is usually running.

    And at some point, we thought, why don’t we make open source available for people to use as their own software update mechanism in their own kind of applications. And we open-source that, we put documentation in a separate place. And what we discovered very quickly is that people realize that it’s a much better way to do SSH than open SSH oftentimes is. Which was completely unintentional, but it was kind of nice for us because suddenly people started to discover Teleport, and download, and use it more. And basically, it’s a really good way to access infrastructure right now.

    So, whatever you’re using to SSH into your servers, or to access your Kubernetes cluster, you’re probably using something worse, so I highly encourage everyone to check Teleport out. It’s free, open-source, Apache license. So, that’s how it happened – everything was built at the same time, but Teleport, just by accident, developed its own fan base, so to speak.

    Revenues By Product

    Michael Schwartz: In terms of revenues, which product is more important?

    Ev Kontsevoy: It’s hard to say. I think both of them are doing really well, and Teleport is definitely not as expensive as Gravity is because it’s not as foundational to company’s business. Because we have Gravity customers who basically run massive, they sell a lot of software into these remote locations and deliver it with Gravity. So, Teleport, it’s usually part of a platform, it’s not the whole platform. So, it’s cheaper per deal, but we do close a lot more Teleport deals.

    Marketing Message

    Michael Schwartz: Have there been some challenges around finding the right marketing message for this platform?

    Ev Kontsevoy: Absolutely, absolutely. I do think we’re still searching for the right way to describe what we do to the world. There are people out there who believe that Gravitational is a company that helps you take your SaaS application and sell it as a kind of on-premise environment. And it’s fine. Yes, we can do that, and we can do it better than anyone else.

    But to me, that’s not really the reason why I decided to spend significant, you know, invest a portion of my life into this company. We want to enable a completely different software distribution model. Think about it like push versus pull.

    We believe that the reliance of DevOps team needs to be reduced. The fact that most companies today have to set up and maintain these complex environments, with so many moving parts, and have these massive DevOps teams that constantly struggle with this ever-increasing complexity of this environment – it just feels temporary to me. It’s got to be simpler.

    The typical DevOps picture at a company, like average company today, reminds me of what you would read in a history book about early computing.

    Remember those stories about old electromechanical computers that would take up the whole room in the building, and you had cockroaches and bugs crawling in, and you had special people called debuggers kicking them out with broomsticks and replacing vacuum tubes and relays, computing was like a manual job, you had to have people walk around and constantly do that.

    That reminds me a little bit about like a typical cloud environment today. I think it should be sealed, fully automated with zero human presence. So, if you walk into a data center today, you’re actually not going to see that many people, probably you’re not going to see anybody at all. There’s going to be some security at the entrance, but inside, it’s going to be quiet, no people.

    So, I want that to be true for virtual access as well. Even though there are no physical people in that data center, but you could be assured that there are probably hundreds, if not thousands of DevOps engineers, maintaining those machines basically manually. And the purpose of like the goal for Gravitational is to make it not so. We want this all to be completely automated, similar to how millions of Apple laptops download software from Apple, apply patches, and keep running. I see no reason why a typical cloud environment for a typical company should be very different from a MacBook.

    Value Prop

    Michael Schwartz: How do you convert that into like business peak? You know,

    because it’s sort of, like, what you’re saying is almost like a kind of “sale to
    the guy with the hands on the keyboard”. Is there a way to convert that into
    like actual value proposition for the business customers?

    Ev Kontsevoy: Well, first of all, let’s be honest with ourselves – can we do this today? Let’s just take a random company that have nothing to do with, let’s say –

    Michael Schwartz: – eBay.

    Ev Kontsevoy:  eBay. Can they make all of

    eBay run similar to a MacBook, with no DevOps team or server today? No, I
    can’t. There’s so many problems. Like, it’s a complex challenge. So, it’s going
    to take us many years to actually solve all of these challenges. But what you
    can do, you can start looking into where DevOps teams are overloaded today and
    start pushing that needle.

    So, for example, if you try to run the same application, let’s say in a hundred different places, you will quickly realize that secure access is a huge problem. Because all these different cloud environments, they have their own tools for accessing infrastructure. And then, you have this like open-source ecosystem that all these components need to be integrated and everything used to be secure. And it begins with SSH, and it ends with Kubernetes access, and then you have, like, internal things, like Jenkins, maybe how do you secure access to Jenkins – all of these problems, they become extremely complex if you try to run more than one production environment.

    So,okay, now we have a security problem, we have this access problem – that’s what Teleport solves. So, maybe I cannot promise you that your DevOps team will have nothing to do, but I can promise you that your secure access will be taken care of. You no longer need to have a competent team of infrastructure security people.

    Or, if you have one, from now on, they can focus on other things, we will take your security problem away. And it doesn’t matter if you have a single cloud environment or 56,000. So, think about any like retail business, like McDonald’s or Taco Bell, they have tens of thousands of restaurants all over the world, each of those is actually a small data center. They have computers in the back, but can you dream about updating software and those locations, using like regular open SSH and let’s say Ansible? That would be quite, let’s say, inconvenient.

    So, here’s the problem that we already solved for them. I do think that our strategy will be to just declare that going from 0, which is where we are today into this bright future, where all software runs by itself magically everywhere, we need to solve 57 problems.

    Alright. So, let’s outline what those problems are. I think it actually helps because maybe some other startups will help us. Maybe they will solve disaster recovery or backup problems, but we will concentrate on security first. So, that’s how Gravitational is executing today.

    Both Teleport and Gravity, they are very much security and compliance oriented. Because, if you want your code to run globally, you have to take care of that first as basically problem zero. That’s why we focus on it for now.

    Free V. Commercial Offering

    Michael Schwartz: So, a lot of open-source companies, they open-source a funnel for

    customers who might want to engage commercially. What does the sales motion
    look like at Gravitational? Is it try by fly, and what’s the effort to bring on
    these large customer accounts who probably pay the bills?

    Ev Kontsevoy: Look, I’m going to be honest with you. We don’t really have a clearly defined strategy that’s documented for example internally, like how do we upsell open-source users. We simply try to — I think we have a following approach, we want to make sure that if you are an individual, like a developer who is curious about where technology is going, someone who has a home lab in their apartment, or a couple of Raspberry Pi’s that they’re running a little toys on – we want to have something for you.

    We want you to get access to Gravitational vision, we want you to find our projects interesting. So, we’re going to have something for you. Yes, it’s going to be free, yes it’s going to be open source. We’re not going to sell you anything because you don’t really have problems that we solve at commercial level.
    So, then if you are a small team, let’s say about three, two, 20 people, and you are working on some young project, let’s say your startup, we want to have something for you as well.

    Then finally, if you’re a large enterprise, let’s say you’re IBM, and you have some problem, we are going to have something for you as well. Every time, we look at the capability that we are introducing into one of our products, we will always have one of those three use cases in mind, simply the size of the team. One-person small team, and then giant team. And it just so happens naturally that things that giant teams want, they are willing to pay for them.

    And things that hobbyist would want, I think trying to charge money for it – it is just ridiculous. At least for us. And that’s how we naturally end up in the split, what is a commercial offering and what is free and open-source offering.

    Is Gravitational Open Core?

    Michael Schwartz: Would you say that Gravitational is open core?

    Ev Kontsevoy: I would say no, we are open source, like we are open-product company. Everything we make is open source. We have a tiny bit of proprietary magic dust that we apply to our open-source products, but that dust just happens to be critical for large companies. In other words – let’s talk about a simple use case – you want your engineers to SSH into their machines, in the most convenient way possible. You don’t want to like annoy anybody with additional stuff.

    But you also want this to work across all kinds of cloud environments, you want this to work with, you know, IoT devices out there in the field, you want this to be compliant with all these different regulations that your customers want you to be compliant with.

    You basically want the best in-class security

    and compliance, but you don’t want developers to be inconvenience.

    Okay, which means you have to use identity-based

    system. In other words, if a developer, who wants to access something, they
    need to go through some SSO process, once a day, nothing crazy.
    And, usually, if you look at small teams, what do they use, everyone uses like Google
    Apps and maybe GitHub, which is naturally what are open-source products for. But
    if you look into what giant enterprises use, you will start discovering
    products you’ve never heard of. Like, I think SalePoint, and you obviously want
    Teleport to support those things. And that’s what we’re going to charge you
    for.

    Another thing too is, if you are a giant enterprise,

    you are going to have all these different teams and different groups, you might
    have infrastructure developers, or like NetSec team, or you’re going to have
    like some auditors. So, in other words, the composition of your teams is
    complicated. And you need highly granular role-based access control.

    So, this extra granularity that only large companies require, that’s another proprietary thing, like from our perspective. So, we basically try to attach – we try to draw the line between open source and enterprise offering, basically based on a company size. Because large companies, they need things that are not even obvious to startups.

    SaaS Gravitational?

    Michael Schwartz: A lot of open-source entrepreneurs, they love the SaaS business

    model. I’m sure you’ve kicked around some SaaS ideas. Is there a SaaS Gravitational
    offering, or are you thinking about one?

    Ev Kontsevoy: It definitely makes sense. Yes, we do run into accounts every once in a while who simply say, like, “We love your tools, this is unbelievable, but believe it or not, we right now have zero engineers available to set everything up, to get up and running. “Can you just do it for us, can you run it for us?” And we listen, and we, let’s just say we’re considering it.

    Pricing

    Michael Schwartz: Most of the companies in this space are using a per-user metric for gating. I’m wondering if you’re using that strategy, has it worked for you, is it a good proxy for value and a good way to land and expand?

    Ev Kontsevoy: I just told you what our internal motivation is, what we’re actually building – completely autonomous unmanned, operational model. So, it would be strange for us to charge you based per on number of users if we believe that software needs to run without humans standing around.

    Difficulty here comes from the fact that we’re not there yet, so yes, you do need DevOps engineers SSHing into boxes every once in a while. But I believe, if we succeed over time, like the need for that will disappear. So, if we, for example, adopt a business model that we’re going to charge you based on how many SSH users are manually accessing servers, that pricing model will not be compatible with our long-term vision.

    Even today, I would argue, without even Gravitational technology, if you have a well-running operations, but you are a Cloud environment, you should not be giving SSH access to your production environment, to all of your engineering team.

    Ideally, very few people should be able to do that, and ideally, there should be no need. Especially if you’re running on a modern cloud, you can simply like kill things that misbehave and recreate them from scratch very quickly.

    Michael Schwartz: So, what gates do you use?

    Ev Kontsevoy: It’s based on your footprint. If you’re running large applications, you’re processing tons of data, you’re present in many data centers all over the world, you have tens of thousands of services based on that, we will charge you more for our solutions.

    How To Gauge Deployment Size?

    Michael Schwartz: In the Kubernetes world, servers are so ephemeral. You get

    a lot of servers when there’s a big demand and less servers when there’s less
    demand. It seems like all those per server, per CPU models are so challenged in
    the new Cloud Native world – how do you gauge the size of a deployment today?


    Ev Kontsevoy: Well, I would argue that per server, per CPU, per RAM pricing, it’s not getting obsolete. If anything, it’s getting more and more popular with – like, look, AWS themselves. That’s what they charge you for. Yes, it is more challenging to accurately meter usage, but generally I would say that usage-based billing is the future for almost everything we use in a data center today.
    So, for Teleport SSH access specifically, we look at how many servers we’re using. And for different companies, we offer different options there because there are different business models, and that’s the reason why we do custom quotes for every account.
    For Gravity though, I do believe that the value we provide is based on how many environments you’re going to be running. Let’s say, if today, you have a single-production environment, then tomorrow, you’re going to be in a hundred production environment – it’s the environment. Like, the number of environments, that’s the value that we give you. So, then we’re going to charge you based on how many environments you have. We don’t really care about how many servers you have in each.
    And environments, they rarely jump too quickly. So, it’s kind of slower moving targets. And that’s how our pricing is built on for Gravity site.

    Does Open Source Help The Business?

    Michael Schwartz: Has open-sourcing the software really materially helped the business?

    Ev Kontsevoy: Absolutely. Because it’s the best form of marketing you can do in our market. We are all dreamers. I believe the technical founders and companies that are started by engineers, they almost always have this dream component attached to it.

    And you want to find people who agree with you that future is going to look different, the future is going to be moving this direction and not that direction. And that person is probably also technical. And the best way to communicate with that person – and it has always been like this – is to show me the code, let me play with it. Because that’s how we collectively dream together, by downloading each other code, installing it, playing it, and then communicating, and sending each other pull requests and criticism. That’s just the best way for, I think, mankind just collaborate and move the progress forward.

    And if you don’t do that, if you use proprietary kind of code in the cave mode, then you’re basically guessing. You’re saying, “Hey, I’m going to go and work on this problem for a year.”, and then I present you with the solution. If solution works for you, you’re going to buy it. And if solution doesn’t work for you, you’re just going to ignore me. And that’s just a much slower way, to get to this optimal state of offering something that the world truly needs.

    So, it’s really hard for me to even think differently right now. You see, with Mailgun, it was different because the problem was so obvious. The problem was basically this: the world needs to send and receive email. And there are solutions for it already, and you have them in your data center.

    And now, you’re going to go be in the cloud, so you cannot take your solutions with you. So, you need to have a cloud version of it. All right, sure, here’s one. But Gravitational is much more visionary company that we just want to change the way how cloud software runs. And if you’re going to start working on that problem, doing it in the open, it’s the only way I see how it could even be accomplished.

    Portability Of Startup Experience?

    Michael Schwartz: This is an unusual question that I haven’t asked before, but

    you sort of backed the question a little bit. You know, I’ve actually started
    more than one business – Gluu’s my fourth business – and one of the challenges
    I found in starting the second business was I applied a lot of the lessons from
    the first business to the second business. And it turned out that the second
    business was so completely different that actually like I shouldn’t have.

    And I’m wondering, are there any cases where – I mean, certainly you learned a lot in the first business, that helps – but was there any like things that you feel like maybe the first experience led you to something to take longer to figure out?

    Ev Kontsevoy: Actually, the Gravitational in many ways is anti-Mailgun. So, Mailgun was proprietary code-based SaaS. Gravitational is open-source software that you can download and run. So, from the beginning we knew that our ability to borrow from Mailgun experience is going to be limited.

    So, that allowed us to bypass a lot of these potential problems that you’re referring to. However, what was helpful and applicable is just the mechanics of starting and running the company. You know, raising money, incorporating, setting up like basic processes. So, a lot of that you could just fly without even thinking and do exact same things, simply because a lot of early-stage startups are surprisingly similar. So, copy/pasting that experience into your present, I think it’s totally applicable.

    Why Leverage An Incubator For A Second Company?

    Michael Schwartz: You chose to go to Y Combinator and raise seed funding and go a pretty traditional startup route. But you didn’t have to go that way, you could have probably bootstrapped it. I’m wondering, why did you think going the traditional route made sense, given that you probably had some capital and some experience and maybe could have done without it?

    Ev Kontsevoy: Because it worked previous time. You see, I’m a technologist, I’m not a professional entrepreneur. Like, incorporating, raising money, doing all these things – it’s boring stuff. So, it worked wonderfully for us at MailGun, going through this traditional sequence, through Y Combinator seed stage, and so on and so forth. We just did the exact same thing, we would concentrate and spend my time on actually building interesting products and solving problems, because that’s really the reason you’re doing it. Everything else feels almost like distraction.

    Yes, you have to do these things, but at the end of the day, they’re not differentiating, they’re not going to define if you’re going to be successful or not – it’s simply getting resources, and office space, and processes, and 401k plan, whatever, just getting it done as soon as possible and moving forward – that was the goal. And look, Y Combinator, they’re very incredibly efficient at getting all of their startups through this early stage, so I highly recommend it.

    Team

    Michael Schwartz: So, you’re currently in the Bay Area, are you planning to

    recruit most of the team in the Bay Area? Maybe you’ve already, like,
    diversified quite a bit – what are your thoughts about building the team in the
    next couple of years?

    Ev Kontsevoy: If you’re asking me, like, what I recommend – I don’t recommend anything. I think it always depends on founders and company culture. There is always this popular question, like, “Shall I go 100% remote, or should I have an office?” I don’t know the answer to that question, there are pros and cons, but what we’ve decided to do is that we want – there are smart people all over the world –we don’t want to discriminate based on either they are in Bay area or not. We want them to be involved, we want them to join the company. And we quickly realized that Seattle actually is the capital of cloud computing of the world. It’s not Bay area.

    If you want to recruit engineers who understand

    what kernel variables are, who understand differences between file systems, who
    can troubleshoot lost packets in the network, you will have a much better time
    finding that talent in Seattle because every single public cloud provider is
    there. You know, Azure, AWS, GCP, it’s all sale companies, even smaller clouds,
    like former CenturyLink Cloud, in the Oracle Cloud, original team was based
    there.

    So, Seattle, it’s the highest concentration of cloud computing experts. And for that reason, our engineering is actually based in Seattle, even though the company is headquartered in Oakland Bay Area. But we’re also open to hiring people all over the world. We have a small office in Toronto, we have remote people on the east coast, and Germany and Italy. So, we’re constantly evolving in our views on what kind of culture we want to have. It is challenging, it’s not easy.

    How To Scale Beyond Startup Phase?

    Michael Schwartz: So, you’re in an interesting stage in the company’s

    development, where you’ve had quite a bit of success, and you’re sort of scaling
    to the next level. Any advice for entrepreneurs who find themselves in that
    situation, in terms of, like, how to adjust to this new sort of focus on sales
    and marketing, especially for technical founders.

    Ev Kontsevoy: You just gave them advice – do not ignore sales and marketing. Think seriously about sales and marketing. Something that I learned in my journey, going from engineer to entrepreneur, was that building a sales team, building a marketing team, is absolutely similar to building a product.

    So, just like you have an engineering team with your processes, you know, for example, no one can commit to master directly, you have to do your own branch, and a pull request with a code review. And all good engineering teams, they have processes, and then the coding style, and like which programming languages we allow, which ones we do not allow – building this takes experience, building this takes a lot of brains, and doing it well requires a lot of energy and discipline. It’s really tough. So, this is why top technologists are so expensive. And that is absolutely true to yourselves and marketing teams.

    Doing marketing and having a marketing machine that’s operating properly also takes a lot of brains. No, it’s not obvious, no, you can’t just read a couple of Golden Books and go do it yourself. And then, the same thing with sales.

    So, underestimating the effort and sophistication of sales and marketing activities I think is quite common amongst engineers. So, simply building and expecting that the users will come – it rarely happens. You have to just approach those problems with, I would say, seriousness, and everything else will come from there. Because if you’re not stupid, if you do have engineering approach to everything, simply putting yourself into that frame of kind of mind, will help you solve sales and marketing challenges.

    Advice For Entrepreneurs

    Michael Schwartz: Last question, any advice for new entrepreneurs launching a business around an open-source software project or product?

    Ev Kontsevoy: Yes. I would just say, forget about that word, don’t call yourself entrepreneur – that’s a distraction. Think of yourself as a product person who tries to solve someone’s problem, and just focus on that until you have overwhelming evidence that it is indeed happening. Because at the end of the day, company is just like a vehicle for allocating and distributing resources. This is what it is. It’s deeply secondary to what you actually trying to do. So, if you want to change the way how backups are done, just focus on that and just forget about incorporation, what kind of company you want, what kind of investors you want – all of that, it’s not primary to your success.


    You have to understand what your solution is going to be, how it’s going to be different, how it’s going to be better, who is going to like it, who’s going to not like it – solving all of these problems and just focusing on that before you even begin to think about entrepreneurship is probably key.
    Because one common thing I see in “entrepreneurial circles” is that people basically start with this, “I want to have a company.”, and then, they start looking for problems to solve. It just feels very unnatural to me.

    Closing

    Michael Schwartz: Ev, thank you so much for going over a little bit on time and for sharing all your experience, and best of luck with Gravitational.

    Ev Kontsevoy: Thank you very much! Thanks for having me, Mike.

    Michael Schwartz: Great job by Ev, isn’t it? Editing by Ines Cetenji. Transcription

    by Marina Andjelkovic. Cool graphics from Kamal Bhattacharjee.

    Music from Broke For Free, Chris Zabriskie and Lee Rosevere. The podcast Twitter handle is @fosspodcast. Follow us. Retweet the episodes, help us get the word out.

    Next episode German-British-Kiwi, Martin Buhr from Tyk, one of the coolest open-source API Management companies around.

    Stay safe everyone. Until next time, thanks for listening.

    The post Episode 48: Zero Trust Security and Packaging with Ev Kontsevoy, CEO of Gravitational first appeared on Open Source Underdogs.

    0 min
  • Episode 47: Jenkins Software Delivery Automation and Management with Tracy Miranda, Director of Open Source Community CloudBees
    Intro

    Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Michael

    Schwartz, and this is episode 47 with Tracy Miranda, Director of Open-Source
    Community at CloudBees.

    CloudBees is a company behind Jenkins, the famed

    project, which is used to automate building, testing and deploying software.

    Many commercial and open-source projects use

    Jenkins as part of their continuous integration and delivery infrastructure,
    including my company Gluu.

    Jenkins was forked from a project called Hudson,

    started by Sun Microsystems in 2005. After Oracle acquired Sun, Hudson was forked
    and rebranded as Jenkins.

    Tracy has been an entrepreneur, a developer, a

    technologist for around 20 years. She was active in the Eclipse community, serving
    on the board of directors. She’s also one of the founders of the Continuous Delivery
    Foundation, which operates under the Linux Foundation.

    Hopefully that gives you a little background, so

    let’s get on with it. Here’s Tracy. Thank you so much for joining today.

    Tracy Miranda: Thanks, Mike. It is my pleasure to be here today.

    Joining CloudBees

    Michael Schwartz: For 10 years, you founded and ran your own consultancy,

    specializing in Eclipse development – how did you end up getting involved in CloudBees?

    Tracy Miranda: Yes. I think the
    common thread there is definitely open source. So, I think that’s something
    early on in my career I’ve always been drawn to, especially because of the innovation
    that you find with open-source communities. And it came at a time I was looking
    to just make a change in the career and focus a bit more on some of the
    community building aspects.

    And as I was talking to people out in the industry, I got introduced to Kohsuke Kawaguchi, who’s the creator of Jenkins, and at the time was the CTO of CloudBees. And the more he talked about the next stage of CloudBees, and what he wanted to do with Jenkins, the more exciting it sounded to me, so I could not resist the opportunity to join his team and lead the open-source team and try that future direction.

    History of CloudBees

    Michael Schwartz: So, for the non-geeks in the audience, can you talk a little bit about the history of Jenkins, and how that impacted the development of CloudBees?

    Tracy Miranda: Yes, yes. So, Jenkins is a built automation server. It is most

    commonly used for continuous integration and continuous delivery, which are big
    parts of delivering software. So, it’s a tool that’s been around for 15 years.
    Many might know it originally in its first incarnation as Hudson, but it
    evolved over the years and became Jenkins and became very rapidly adopted by
    developers and focused on delivering software everywhere, just because it gave
    you a lot of flexibility.

    And it was the first tool that sort of helped

    you integrate and build your software. And it was really what we’d say is the start
    of this whole field of developer productivity engineering.

    And around it, so companies like CloudBees

    emerged, offering more Enterprise version. So, when it came to scaling or
    features around governance and securities, and CloudBees would offer Enterprise
    Jenkins. And that’s just sort of evolved and evolved, and now the whole space is
    currently really doing very well as we deliver more and more software every
    day.

    CloudBees Products

    Michael Schwartz: So, CloudBees has a number

    of products and services. For 2020, what are the most important products,
    with regard to revenue, and what are the most important projects for your
    future growth?

    Tracy Miranda:  In 2020, well – let me talk about the direction

    we’re going first of all, and then I can bring that back to the present – so,
    we see just everybody’s delivering a lot more software, and software has become
    critical to every industry. So, you know, whether it’s a bank or a travel
    company or insurance company – you name it – software’s a differentiator for
    them. So, the more software we have, the more we kind of start to talk about
    like software factories. And you can use the factory metaphor as well to apply
    it to this.

    So, in that model, we

    talk about Software Delivery Automation, and Software Delivery Management
    automation is just – the name says it all – it’s everything you need to do to
    get the software delivered, pretty much like a factory. And then, the Software
    Delivery Management, or SDM, is the part where you have the business
    intelligence coming in, how do you make the decisions, what to release when, and
    to who. So, that’s the direction we’re headed in, and we’re building out all
    the different parts that contribute to integrating all the tools.

    Today, what a lot of companies have is basically focused on continuous integration and continuous delivery, so, tooling around tools like Jenkins, we also have SaaS versions of CICD tools, and then, any tools that help you deliver faster. So, we’ve got a whole kind of portfolio, depending on your flexibility and what you’re trying to achieve.

    Market Segmentation

    Michael Schwartz: CloudBees is in a very horizontal market. As you mentioned,

    you are serving customers in basically every industry. Given that, does
    CloudBees segment solutions or the marketing effort, either vertically, or by
    use case, or in any other way?

    Tracy Miranda: I think probably the most clear segmentation, which we will kind

    of see, is whether people want to manage it and have things kind of on-premise
    themselves, or whether they want software-as-a-service. So, that tends to be a
    key differentiator.

    And oftentimes, it will depend on the industry. So, certain industries might have very strict compliance or governance around it. So, perhaps, it always has to be an in-house solution. But then, perhaps some new startups, so, in different segments can afford to go with much more as a service model, where they don’t really want to deal with the nuts and bolts, and the upgrades and the security patches – they’re just happy to focus on what they need to do to get their software out the door.

    Why Open Source

    Michael Schwartz: Without open source, there probably would be no Jenkins, at

    least as it currently exists.  And
    therefore, I guess perhaps no CloudBees. But going forward, why does continuing
    to invest and contributing to an open-source community materially help the
    business?

    Tracy Miranda: This is my key
    role at CloudBees is, it’s kind of overseeing the whole open-source strategy.
    So, you’re absolutely right, CloudBees is based on this massive open-source
    project, and as we grow and continuing to evolve, we’re going to do a lot more
    in open source and in different ways.

    I think there’s lots of different benefits we

    see to open source, so, on one side, if you take kind of just the engineering
    side, there’s obvious benefits from working with the community – you’d get fast
    feedback, you’d get people contributing.

    A lot of the developers we hired in the early

    days would come from open-source communities, and then they’d even have the
    advantage of they are already up-to-speed with the processes and the ways of
    working and the code base.

    But then, there’s also other kind of strategic

    science to open source as well. Open-source projects tend to spread like
    wildfire, I had someone using the term, kind of the open-source tsunami. And
    they have a tendency to change the direction of industries, to take something
    like Kubernetes, which caused a big shift in the whole sort of cloud
    infrastructure.

    So, in that way, we also kind of look at technologies for them to be open and for them to drive the future direction of the industry and help us to get to an innovative place. So, we always want to be involved with open source and find ways to just create those kind of win-win situations for both the community and the company.

    Open V. Commercial Features

    Michael Schwartz: You mentioned previously that it was an Enterprise version of Jenkins, and I’m wondering about, today, is there still software that’s non open source, and if so, how do you decide what to open-source and what to keep private?

    Tracy Miranda: Yes. I know that’s a key thing, and it’s constantly evolving. So,

    we have an internal process, and we’ll kind of look at the way things are
    evolving in the market. In general, like you take something like Jenkins, and
    we have a lot of plugins added by different groups and different individuals in
    some cases.

    One thing that CloudBees do is, for the software

    like CloudBees Core, or CloudBees CI built on top of Jenkins, is we also offer
    kind of tiers of plugin, so we know which ones meet a certain level and meet
    the requirements for Enterprise type customers.

    So, this is focused specifically on things like security and governance and running things at scale. So, typically features in those areas, or verifying plugins, will be the areas we’ll tend to kind of have as the more closed source. And anything developers tend to use, this tends to be pretty open.

    Open Source Strip Mining

    Michael Schwartz: I’m sure you’ve heard this term “open source strip mining”, where large companies take open-source software projects and commercialize them. You know, you have a SaaS, you are offering themselves, but is this something that you’re concerned about, or any thoughts about this sort of phenomenon?

    Tracy Miranda: I’ve definitely heard the term, yeah, it’s a pretty controversial one. But I think it is something that is always a consideration. So, you take something like Jenkins X, which is a new open-source project. It’s not related to Jenkins, as the name might indicate, but it’s actually a complete new CICD tool based on Kubernetes. And it’s one of the best ways to do Cloud Native CICD.

    So, a lot of Jenkins X is open source, and you

    could conceivably imagine another company taking it and wrapping it up and
    delivering it in a specific way, but I think the reality is that open source is
    always evolving. And it’s more about kind of the vision in the direction it’s
    going. And the key thing I guess from CloudBees’ perspective is, we have a lot
    of the people who are driving that direction working for CloudBees.

    So, I guess that the people, at the end of the day, are a secret source. So, even if other people want to come and extend it or do it in a different way, I think we’re always kind of focused on what’s the vision, how is this going to evolve, how we’re going to keep pushing the industry forward. It’s a concern, but we try not to spend too much time focused on that, just more time focused on what do the users want and where are we headed.

    SaaS V. License?

    Michael Schwartz: In terms of monetization strategy, is the Enterprise license the majority of the revenues, or is SaaS the biggest part of the revenue stream?

    Tracy Miranda: Yes. Enterprise licenses are definitely the main focus. I think that will evolve over the next set of years, but, for now, that’s certainly the case.

    Pricing

    Michael Schwartz:  Few questions about pricing, which is hard for a lot of startup entrepreneurs. Many organizations are using Jenkins for free – is it hard to move these customers to a paid offering? What type of gates do you define? Is it per developer? And is pricing still evolving with new offerings, or have you achieved some stability in the pricing area?

    Tracy Miranda: Yeah. No, I think this is an area constantly evolving. You know,

    Jenkins is a great tool, and a lot of people can do a lot of things with that
    anyway. So, we’re always looking to add value on top of that. So, we find a lot
    of the customers who see the value of CloudBees, they’re focused on what they
    need to do as a business, they don’t really want to be messing around CICD is
    not their value add, so they want kind of the complete package. And that
    includes the ability to get support and the ability to know things are going to
    work for them.

    When you are sort of doing things in open source

    by yourself, you tend to run the risks yourself. You can pick up plugins and
    you have to decide, are these going to work for me, are they going to have the
    security patches attached. And what happens if something goes wrong? You know,
    you can’t pick up a phone and kind of call up the open-source community and ask
    them to fix your thing in a timely manner. That being said, it is a constantly
    evolving space.

    So, I think kind of the offerings and the bundling and the way that works is always evolving. And like we will do things as well, like offer kind of more analytics on top of that, which give people sort of more insights in what they can do with their systems, and yeah, that’s just constantly growing,

    Partnerships

    Michael Schwartz: What have been some of the more important partnerships for CloudBees in terms of specially impacting the business?

    Tracy Miranda: In today’s world, I think you really can’t succeed as a company

    on your own – we had a recent kind of partnership program, which I think we’ve
    got a whole bunch of companies who we were working with. My
    main tendency is to be on the open source and on the
    Continuous Delivery Foundation – it’s not partnerships in the traditional sense,
    but a lot of companies on the open-source side we’re working with closely.

    And the other big one today is the partnerships with the cloud providers, and with those we have really strong relationships. I think every cloud provider has a marketplace out there, and you can easily access all CloudBees products very easily from the cloud marketplaces. I think this year we’ve also named the Google Cloud partner of the year, so, yeah, a lot of strong relationships, especially towards a whole Cloud space.

    Project Governance

    Michael Schwartz: You have a lot of experience in this area, so I can’t resist asking, but companies can host their own open source and build their own governance infrastructure around their project, or they can move to a foundation that can help maybe attract a larger community. What’s the strategy of CloudBees there, and how’s that evolved over the years?

    Tracy Miranda: Yeah, a great question. So, Jenkins itself pretty much had its own governance, and that worked well and served the community really well for the first kind of ten, fifteen years. You know, it is very alike with model software in the public interest, it provides some great services.  But, eventually, it got to a point where there was some kind of sticking points in the community. These were things sort of shared widely with the community.

    Some key things like just having a business

    entity so that we could get signing certificates, having a more kind of ability
    to hire for roles that want developers, but other kind of things that are key
    to software projects, but you don’t necessarily get contributions for. And
    again, the ability to build a bigger community.

    So, these are kind of some of the limitations

    that we hit. So, Jenkins got to a scale, where it needed to grow past that and
    to get companies interested and understanding it, they needed a really kind of
    known model, which is why it then looked at setting up Jenkins in an
    open-source foundation. And that led eventually to the Continuous Delivery
    Foundation forming, which is, as the more we talked to folks, the more it made
    sense, not just to have a single project foundation but to have something where
    a bunch of folks could come together and work towards a bigger vision.

    So, that’s been the key thing. The creation of the Continuous Delivery Foundation is what have helped launch over the last year. And that’s been a major kind of change, both for Jenkins and for CloudBees as a business.

    Fostering Diversity at CloudBees

    Michael Schwartz: You have been an advocate for a

    diversity. And I am wondering have you been able to have an impact on how
    CloudBees builds the team?

    Tracy Miranda: Yeah, I think diversity is super important for all sorts of

    reasons, but especially for business ones. I am very lucky in my position, I
    head up the open-source team, I’m a hiring manager, so, in a great position to
    kind of influence that at CloudBees.

    So, I have a great team, and I’m happy to say

    very diverse on kind of multiple accesses. You know, gender and age, and from
    where we are across the world. So, that’s been really nice.

    We also have lots of initiatives at CloudBees. One of the things I’m pleased to say is, there’s a lot of people doing things like CloudBees, and kind of constantly changing the status quo, which is nice, because it’s not always something I have to do, and then I can just kind of focus on my main job. But, yeah, a lot of great folks pushing things in the right direction.

    Pandemic Impact On Diversity?

    Michael Schwartz: We’re recording this episode in May of 2020, so the pandemic

    is on everyone’s mind. It’s easy to look at all the negatives, but being an
    entrepreneur, I think I’m inclined to look at positives. Is there any way we
    can spin the pandemic as a positive around creating more diverse teams?

    Tracy Miranda: That’s really interesting. But I think by moving online and by a

    lot of companies had this almost artificial limit on, where people can be hired
    from and all having to live in specific areas, which are often cities, which
    often have big barriers to entry in some cases. I think by going virtual, you
    do remove some barriers, you do make it easier for people to be hired from
    wherever they are, and all of a sudden, that does open up the field for people
    you can hire from. So, I think, in that way, it can be very positive.

    How To Catalyze Gender Diversity In Tech?

    Michael Schwartz: Just speaking from my

    own personal experience, my company is very globally distributed in terms of
    team members, we have team members from like every continent, except
    Antarctica. So, we are doing an okay job in terms of diversity, but in terms of
    getting more women on the team, we’ve faced some challenges.

    I know you’ve talked a little bit about this topic, but maybe you can share why do you think there aren’t more women in tech, and what are some of the challenges that women face? And how can we maybe help more women get into the tech business?

    Tracy Miranda: I spent a lot of time over the last three or four years trying to

    understand for myself, because I think at the beginning of my career, I took it
    a bit for granted. I thought this is just the status quo, this is how it is, but
    I think it is down to kind of a number of factors all coming together. And you
    know, unconscious bias tends to be a big feature.

    We’ve got just a ton of research that shows how lots

    of different things have compounded things over the year. I think there’s a
    great NPR Podcast as well, which talked about the times of women started
    dropping out of computer science courses. And it was almost because computers
    in general were marketed towards boys. And it was very difficult for them to
    sort of coming disadvantages to the
    courses, and there was not a lot of empathy for that. So, I think that that’s
    kind of one factor, but there’s a lot of other things in general that play out,
    just networks and how people bring people into companies.

    So, the good news is I think we have more

    awareness than ever before of what it takes. And then, there’s a number of
    things we can do. The bad news is, you almost have to keep at it constantly,
    and things change very, very slowly. But we know, for instance, just
    representation matters hugely. So, having more women voices, having more women
    in higher position kind of modeling — I think there’s a great expression “You
    can’t be what you can’t see.”

    And then, just having more not just mentors for women but sponsors who are ready to kind of pull them up in the right channels, help them to get and meet their goals much faster. And I think we’re getting a lot more systematic approaches in place to do this. And actually, I was really glad to see with your podcast, you have a lot of the recent guests have been some very frankly incredible and awesome women. And I think that’s places you start, just having that representation, having those people talking and telling their story.

    Advice For Open Source Startups

    Michael Schwartz: Thank you. We are doing our best. So, last question, you run

    your own company for a decade, and you’ve been around open source for a long
    time, so I’m sure you’ve seen some successes and failures of entrepreneurs who
    have tried to use open source as part of their business model. If you were
    starting out from fresh today, you wanted to use open source and build a
    business around it, do you have any advice for that person about how they
    should go about it?

    Tracy Miranda: I think there’s a lot that gets said about kind of open source

    and the relationship with business models. I think I completely buy into it.
    Building off open source has so many efficiencies and so much kind of leads to
    a lot of serendipity.

    I think you see a lot of startups today embracing

    open source and understanding that it’s not just open source in the sense of
    code, but what you’re really doing when you embrace open source is building out
    a community. And I think people understand more than ever how key developers
    are to any product and how key that community is.

    So, not that open source is the only way to do it, but it’s such a great way to do it, and I think the main advice would be: if you’re doing it, you have to commit to it completely. You can’t kind of be half-hearted about open source, you have to commit to the vision and to the community and constantly growing it and tending to it like garden. And then, it will play huge dividends. And we have seen the companies who have done really, really well off open source. It’s just kind of really sort of impressive.

    Closing

    Michael Schwartz: Tracy, thank you so much for spending some time with us

    today. And best of luck with CloudBees and with the Continuous Delivery
    Foundation.

    Tracy Miranda: Thanks very much for having me. It’s been great.

    Michael Schwartz:  Thanks to the CloudBees team for helping us to promote this episode on social media. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics by Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

    The podcast Twitter handle is @fosspodcast.

    Next week we talk to Ev Kontsevoy, founder and CEO of Gravitational. Stay safe everyone. And until next time, thanks for listening.

    The post Episode 47: Jenkins Software Delivery Automation and Management with Tracy Miranda, Director of Open Source Community CloudBees first appeared on Open Source Underdogs.

    0 min
  • Episode 46: Create, Deploy, and Manage Modern Cloud Software – Pulumi, with Joe Duffy, Founder / CEO
    Intro


    Mike Schwartz: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 46 with Joe Duffy, Founder and CEO of Pulumi.

    Pulumi is a platform that lets organizations

    manage infrastructure in the cloud of their choice, using the coding platform
    of their choice. It’s delivered as either a cloud service or a software. Joe’s
    doing a fantastic job executing the Pulumi business plan. No point spoiling the
    show for you – let’s just dive right in. Joe, thank you so much for joining the
    podcast today.

    Joe Duffy: Hey, Mike. I’m glad to be here, thanks for having me.

    Pulumi Products

    Mike Schwartz: In one of your past interviews, you described Pulumi as the name of the band, the name of the album, and the name of the song. We’ll take more into the business later, but can you describe the current Pulumi product offerings or maybe I should say super powers?

    Joe Duffy: Yes, superpowers, yes. We just launched that sort of as a new

    marketing theme for ourselves. We started Pulumi because we really have this belief
    that everybody should be able to leverage the full capabilities of the cloud. The
    cloud is kind of changing everything about how we build software, and yet, we
    found that for most developers, the cloud was still sort of an afterthought,
    which harkens back to the days of virtual machines and N-tier applications.

    And on the other side, we found infrastructure teams that are, well, frankly using not-so-great tools, and really what we thought what Pulumi is, “Hey, we can bring decades of programming language innovation, and great tools, and developer platforms, and apply that to the cloud infrastructure space, and really supercharge people’s ability to use the cloud in how they build software. We’re also breaking down some of these barriers between the different sides of the organization.

    So that’s our focus, you know, open source was super important to us from day one. And we offer a SaaS for teams and Enterprises that are adopting that open source.

    Seismic Changes In Programming From 2004 To Today?

    Mike Schwartz: You started at Microsoft in 2004 as a developer and went on to lead teams as a director of engineering. Looking back, what are some of the most fundamental changes in software development that you’ve seen over the years, or what would utterly shock the 2004 Joe Duffy?

    Joe Duffy: I think you know a lot has surprisingly remained the same, but the cloud really is the biggest change – it changes everything about what we can do. It’s incredible when I look back, I think at 2004 even, and I was a developer before that, but really back then, like multi-core, multiprocessor systems wasn’t even a thing. And I spent actually a good deal in 2000 working on that.

    The fact that every piece of software is a distributed application now, every piece of software has access to infinitely scalable compute and data, and AI, machine learning – all of these capabilities are just an arm’s length away.

    Whereas, back then, I mean, we couldn’t even dream of using anything close to those sorts of capabilities. And I think that’s partially why we started Pulumi – we were excited about supercharging people’s applications with those capabilities.

    Insights From Microsoft?

    Mike Schwartz: From a business perspective, what would you say are some of

    the most important things that you learned in your 12+ years at Microsoft, or
    what was most helpful to you to lead Pulumi?

    Joe Duffy: It’s definitely interesting, I did not plan on being there that

    long. I was about to do my own startup before going to Microsoft, but I actually
    went in part because I knew it was kind of like an extended MBA program for how
    to build an Enterprise software company.

    I think it sounds just, like seeing that sort of

    innovation at scale, seeing how you keep existing customers happy while still
    innovating and pushing the boundaries of what your platform can do was really
    fascinating to see that at Microsoft, and to see how you can effectively
    innovate and do research while you’re also doing product development. I think
    that’s a really key thing to be able to do.

    Also, a lesson learned over the years was, it was really hard to figure out kind of like what business units actually made money, how did they make money, and how did the money get redistributed across the company. I spent a fair bit of time just reading the PNL breakdowns, and all the investor statements, and trying to figure out, okay, what’s actually making money.

    And the funny thing is, there’s a lot of lost leaders in a company like that. In fact, a lot of the open-source investments, frankly, are sort of lost leaders for the real money-makers, used to be Windows, now it’s more Azure at Microsoft specifically. But you see the same pattern, you know, AWS, Google, Cloud, other major players in the cloud, where a lot of the developer tools are really just there to get you to use and pay for their computing storage, and that was an interesting thing to see from the inside at that scale.

    Marketing

    Mike Schwartz: Pulumi is still a relatively new venture. The marketing team is probably trying to catch up with a momentum of product and engineering – what have been some of the challenges with messaging and extremely complex IT offering?

    Joe Duffy: Marketing has been the one part of the company that is constantly changing. I think the product – we’ve really had a very product-led approach in everything we do. The community is everything for us, and so, we lead with the community and everything we do. Even revenue, we only started focusing on last year, and we’re finding that a very inbound-oriented model with open source and SaaS, being a great combination, is working well for us.

    So, the challenge really is, how do we find the right people – and that is, the people for which Pulumi is a great solution – and tell them the right story at the right time. Because you can’t be constantly changing your cloud platform every day, so there are particular times we need to find people.

    I think that’s been a bit of a challenge. You know, in the early days, it’s probably very common, we tried to tell a more exciting sort of long-term story than the product truth. Especially with the open source, I think you got to get the product truth story nailed first. And we got a little ahead of ourselves. Thankfully, we course-corrected after talking to a lot of end-users. And frankly, I just got out there and went to as many conferences and talked to people as possible – that helped to hone that product truth messaging.

    And then, over time, I think you got to be patient. You’ll get there for the longer-term messaging, and it’s important that people know what your DNA and what your company stands for. But even more important than that, on day one, especially with open source, is to understand, what does this product do, why do I care. Especially in the cloud space, where it’s like, there’s a new open-source project every week, if not more frequently than that. And it’s a lot to stay on top of.

    Value Prop

    Mike Schwartz: So, that leads into my next question, which is, what are the most important value propositions for your customers today?

    Joe Duffy: Yeah. We started out thinking they were all technical, and it turns out actually the cultural sort of human component is turning to be important for us. I think the first is, our two main customers, are practitioners, are infrastructure teams, dealing with complexity.

    Modern cloud transformation is complex. I

    mentioned it’s a difficult space to navigate, there’s so many options – many of
    them don’t work at scale. So, Pulumi, for them, helps them tame the complexity
    of modern cloud architectures, multi-cloud architectures, modern, even single-cloud
    but increasingly multi-cloud. So, on the infrastructure team, that’s the thing
    that’s really helping.

    For developers, increasingly developers want to

    use the cloud in their software. They don’t want to go learn this completely
    foreign, frankly not as good toolchain. They’d rather just use the tools and
    techniques that they know and love, and really start incorporating the cloud
    more into their software. So, it’s great for them.

    And then, if you look at the organization, it really helps those two sets of people collaborate and work together. And that’s the cultural part that’s actually fueling most of the growth within our existing customers.

    Market Segmentation

    Mike Schwartz: Do you segment the market at all? I heard in a previous interview, where you said at the time, you weren’t looking at vertical segmenting, but what about other ways, like size of customers, or how do you look at the market or break it down into something manageable or tackable?

    Joe Duffy: This is something we’re learning over time. I think it’s naturally segmenting itself. We have an even spread of customers across SMB mid-market and Enterprise customers. And you know, the takeaway is, like, everybody’s doing cloud. So, everybody is a potential customer for us.

    Honestly, running a company, it kind of makes it difficult sometimes to prioritize. The Enterprise needs are not always aligned with the community needs. And so, I think we’ve done a good job of balancing those. For example, we did SAML SSO identity integration very early on, which really was an enabler for us to add more Enterprise value-add features. So, we did a lot of the foundational work that helped us to cater to this broad spectrum.

    I’ll also say, we see some verticals, just naturally emerging. And, again, they sort of fall along the same lines of what I was mentioning earlier. You know, folks that are doing modern cloud initiatives. And in certain industries, there’s more of that, like connected cars for example, we’ve got a number of customers in the connected cars vertical that we didn’t plan it that way, but it’s a great partnership with them.

    I’d say that the number one thing though is, we listen to our customers, we listen to our community, and we try to let them take us where they need us to go.

    Customer Interaction

    Mike Schwartz: Interacting with different size customers can be a challenge. Large customers expect one level of support or integration and small customers another – have you seen a big delta there? Or, how do you manage the expectations for some of the larger customers who want more?

    Joe Duffy: There’s definitely a very big difference in the engagement model. And I think for us, the key thing was community first for everything. So, we wanted to build a community, nurture the community, build a great community that has bodies or values and is a warm and welcoming place. And what that’s led to is, the community helps the community. And that helps actually, I mentioned this inbound model, where we’re really focusing on open source plus SaaS.

    Our goal is that people can get up and running without needing a human to intervene, like they don’t actually need to talk to a sales person. They can download the open-source to get up and running very quickly. People tell us that getting and starting flow is one of the easiest they’ve ever experienced, and we spent a lot of time making sure that was the case.

    We’ve got a community Slack, where literally thousands of people are helping each other, and the whole team is encouraged to participate. And so, that takes care of sort of that inbound transactional sort of customer and actually frees up our internal folks on customer pre-sales engineering and post-sales engineering, along with our sales force, to really focus more on those higher target accounts that do want a little bit more white glove service, might want to do a proof of concept, might want some more training and advice as part of the evaluation.

    Monetization

    Mike Schwartz: Let’s talk a little bit about monetization. Previously, I guess, you had a consumption-based model, where you were pricing based on number of services, but you’ve moved to a per developer pricing model. I’m actually curious, why didn’t the consumption-based approach work?


    Joe Duffy: We thought long and hard about this, and we started designing the system so that the open source and SaaS work naturally with one another. So, we have a very high attach rate for people who download the open source. 80% of the people that do that actually use our SaaS, which is great, we have a free tier as well for unlimited individual use. And so, it’s only when you get to a team that you start paying, or Enterprise.

    We invented this concept, basically pay-per-project

    was the previous model. What we found was a few things. And honestly, our hearts
    were in the right place. We really avoided per user for as long as we could
    because we want the whole organization to be able to use it freely, we don’t
    want to stop growing within a group, land and expand is important. But what we
    found with per project is, no two projects are alike.

    Especially in a world of microservices, it’s very

    common to have mega-projects sitting alongside thousands of little tiny projects.
    And we didn’t want folks to feel like their architectures were influenced by
    the pricing model. That felt like an anti-pattern to us, and that was sort of
    some of the feedback we got on that pricing model.

    Although we really did want it to be, “Hey, you pay for what you use.”, and the idea was, “Hey, if you’re using more, you’re seeing more success, and so, you would expect to be paying more.” Per user was just easier for people to model out, easier for people to kind of gauge how much they expect to be spending today versus tomorrow. And frankly, it’s just a familiar model for anybody who’s using a lot of other SaaS products that our customers are using, whether that’s PagerDuty, or Gitlab, or GitHub, or a lot of those other sorts of systems.

    I’m not saying per user is perfect, it certainly isn’t, but it’s kind of the least bad that we found today.

    SaaS V. Software Revenue

    Mike Schwartz: Is most of the revenue from the SaaS platform or from the Enterprise software product?

    Joe Duffy: It’s actually a good breakdown, you know. Honestly, it’s about

    50/50. Now, it’s importantly, our Enterprise product is actually sold as a
    SaaS, as an option. So, you can either run, you can use the SaaS as the online
    hosted version, or you can use a self-host, on-premise version of that.

    I’ve been pleasantly surprised at how many people are willing to use the online SaaS because the COGS for us to deliver that service are just so much lower than having to do on-prem support, and installation, and upgrades. And I think my takeaway there is, people now, even more so than even two, or three, or especially five years ago, they are used to depending on cloud services, whether that’s GitHub, or AWS itself, or pick your favorite SaaS.

    I think these organizations are getting more

    comfortable with that sort of dependency. We also architected the system, so
    that you don’t need to share PII, or Cloud credentials, or anything like that
    with our SaaS. So, when we go through a security review with one of these
    Enterprises, they almost always walk away comfortable with where we’ve drawn
    those boundaries.

    Single Versus Multi-Tenant

    Mike Schwartz: In your SaaS offering, would you say it’s a single-tenant design,

    where, each customer has their own sort of database and infrastructure, or is
    it a shared multi-tenant type of platform?

    Joe Duffy: It’s primarily multi-tenant. There are some resources that are per organization, things like, we have a Secrets Management element to the product, and each organization gets their own dedicated hardware encryption key for example. But for the most part, it’s a multi-tenant architecture, unless you use the self-host version, in which case, it doesn’t talk to any shared resources, it can run entirely behind your firewall, it never phones home, so kind of have those two basic models.

    Is Pulumi Open Core?

    Mike Schwartz: Would you say that Pulumi is open core?

    Joe Duffy: I don’t say that, and although some people tell me I shouldn’t be

    so pedantic on this point because it’s a familiar model to people, but we don’t
    hold things back from the open-source platform. So, the way I see it is, the
    entire Pulumi platform is open source.

    So, you can use Pulumi entirely offline, and you’re not missing out on any features that are in the platform itself. It’s just that we have a SaaS product that you can choose to use. And that service itself is not open source. So, it’s almost like sort of GitHub. GitHub, you get the Git tool, Git is 100% open source. And then, you’ve got GitHub, and GitHub is a SaaS that you can choose to use or not when you’re using Git, often it’s the easiest way to go.

    But that thing is not actually open source. So, that’s the model that we have adopted, where the SaaS, and importantly, the SaaS provides value. And that’s the other thing, where I kind of have some qualms about, where we’re not artificially hampering your experience. The SaaS is there, and you might pay for it because it actually provides significant value that’s worth the money. It’s not that you’re forced to pay for it. So, that’s I think a key distinction as well.

    Has Open Source Materially Helped The Business

    Mike Schwartz: SaaS provides a lot of the features of a try by fly. So, has

    open-sourcing really materially helped the business?

    Joe Duffy: Yes. I would say especially in the space that we’re in. And I

    think it would be different for different SaaS products. Like, if you look at
    PagerDuty, there was something where everything is about the SaaS, and there
    might be some ancillary tools around it – we’re sort of the inverse of that.

    I think it’s table stakes for our space, for

    developers to change the way they’re writing code, for infrastructure teams to
    bet their whole organization on this – they need to have something where they
    have confidence that they’re always in the driver’s seat. And if they need to
    take things and go, they can do that. So, that was important to us.

    The community I mentioned, everything is about community

    for us. Because of the bet on real programming languages that we made, we allow
    people to share and reuse packages and contribute to the ecosystem – we have
    tons of extensibility points. So, if you want to — we’ve had community members
    bring up, integration with Datadog for example, great, you can do that sort of
    extension.

    If you want to integrate with Spinnaker – we just did a Hackathon with Armory a couple weeks ago, where, if it wasn’t open source, that vibrant ecosystem around it just would have never come to be, and that is essential not only today for how we scale the business, but the long-term sustainability and differentiation of the company itself in large part depends on that.

    Foundation?

    Mike Schwartz: I was reading today about Google, looking at different foundations, where they might contribute Estio. And I’m wondering, when you have an open-source product, and you’re also hosting it, it’s sort of like enlightened despotism. You know, you’re controlling the roadmap, and you’re making the code open source, but that could always change. We’ve seen a change in some companies.

    What are your thoughts about a long-term – does

    Pulumi ever move to a different governance model, where the roadmap almost becomes
    part of the community too?

    Joe Duffy: I think, never say never. It’s not something that we’re looking at now. I would say if the community takes us in that direction and it’s important to the community, we would definitely go in that direction.

    There are a few things. Like, one, we are open in our planning process, we are open with our roadmaps, we are very community-oriented, and how we do all of that. And so, I think, because of that, our end-users feel like they’re part of that process, probably even more so than if it was in a foundation, frankly.

    Because a lot of times, in foundations, there

    are special interests. They’re just not as visible. I think Google definitely
    has some influence in the CNCF, and so, it’s not a bad thing. You kind of have
    sponsors, you can have people in the driver’s seat, but I’m just saying it’s
    not, like, in one model you have no influence, in the other model you do have
    corporate influence – in all the models you have that level of influence. And I
    think, really, our community trusts us, and our task now is to make sure we
    preserve that trust and nurture that trust.

    But if there are strategic alignment in projects, I think we would be more interested in partnering up with a foundation. But it’s not something that’s on the immediate radar.

    Team

    Mike Schwartz: Switching tracks a little bit, is most of the team in Seattle?

    Joe Duffy: Yeah, we’re about one-third distributed as far as Europe, East Coast, sort of all over the world, but the two-thirds of the team is here in Seattle.

    Mike Schwartz: What are your thoughts about growing the team in the future?

    Joe Duffy: The situation, at least at the time of the recording, with the

    Covid situation, we’re all getting really good at working remote. And that foundation
    of starting with a third of the team being remote, I think instilled a lot of
    the foundation we needed to be successful in this new environment.

    I wouldn’t say we’re actually suffering too much from it. And I think, if anything, it’s actually helped with our existing remote employees feel like they’re more included in the daily dialogue, we’ve introduced a lot of new practices.

    So, in terms of growing the team in the future, I think we’re going to be a lot more flexible in terms of, I don’t know, if we’ll go 100% all remote, you know. I think some people have said they actually enjoy working with people in person, but I think we’re definitely going to be a lot more remote going forward.

    And frankly, from here, most of our focus on growth is in the go-to-market side of things. We’re Series A- funded company, we’re looking to that Series B in the not-too-distant future. And really, as we start to build more scalable and repeatable go-to-market motions, we’re going to scale up marketing, we’re going to scale up sales, and so that’s really the focus for us, at least for the next 18 months.

    Partnerships

    Mike Schwartz: Are there partnerships right now that are critical to Pulumi

    as business model?

    Joe Duffy: I would say all partnerships have been essential. And we’ve done

    a fair bit of partnering. And that’s an area that, as we look to repeatability,
    I think one of the challenges is, sometimes I say, “Hey, we’re really good at
    standing on the top of our own roof, shouting into a megaphone in our own
    neighborhood, like writing blog posts and tweeting to our existing followers,
    and nurturing our existing users and helping them be successful – you got to do
    that. That’s super important.

    But what we’re starting to get better at now is leveraging those partnerships to, you know, get into adjacent channels, where there’s actually natural synergy between them. I think that it’s a tough thing to do, you got to nurture those relationships over the long term, but then, some of them start to pay off.

    So, the major cloud providers have been great partners with us, but we’ve intentionally built our system to integrate with a lot of other systems, whether those are source control systems, CICD systems, cloud infrastructure providers – in each one of those is a partnership opportunity that we’re just now starting to learn how to leverage to basically grow top of the funnel, while also giving customers a more complete solution because each of these is just really one piece of the puzzle.

    Pandemic Impact On Open Source

    Mike Schwartz: As you mentioned, we’re recording this episode in April 2020, in the midst of this unprecedented global pandemic. Is there a scenario where the new world that’s emerging will somehow be more fruitful for open-source startups?

    Joe Duffy: I think we’re learning to flex a bunch of new muscles, especially when it comes to marketing, more online digital campaigns, events were huge for us in the past. And I think in open-source generally, QCon, it’s great to connect with your colleagues and learn what they’re up to, see how you can incorporate their ideas into what you’re doing. 

    DevOpsDays, a great conference that’s very open source oriented, that I personally went to almost a dozen of them last year – those things aren’t happening now. They’re all moving online, and I’ll say it’s a little bit of a stark contrast. It’s not quite the same watercooler kind of informal conversation, it’s kind of hard to have these large group settings, connecting over Zoom, where it’s 30 people on a screen, taking turns, talking to each other.

    I think we’re going to invent tools, we’re going to invent new ways of basically moving that conversation online. I think we’re going to come out much better afterwards in that dimension. And that will benefit marketing, that will benefit open source because open source really is about that community dialogue. So, yeah, I think we’ll come out stronger afterwards.

    Advice For Open Source Entrepreneurs

    Mike Schwartz: Any advice for new entrepreneurs who are launching a business with open source as part of their business model?

    Joe Duffy: I would say, we thought long and hard about the monetization strategy. I think the temptation is to launch the open-source project as soon as possible. And frankly, that is a good strategy, you always want to get out there sooner, so you can start getting that sort of virtuous cycle of customer feedback and community building. But it’s really tough to get in a situation where you’ve launched an open-source project is growing vibrantly, but you have no idea how to monetize.

    For me, I wanted to build a product company, I didn’t want to build a services organization. That’s a very different playbook. It’s low-margin, lots of people, very expensive to get to scale. You really want to focus on selling product. And if you’re going to do that, it requires really thinking deeply about where that boundary is between what’s free and what something people would pay for.

    And my advice is, the thing that people pay for has to be something of value that they want to pay for. You can’t trick somebody into paying for something – it really needs to be valued. And that means you can’t necessarily open source 100% of your value.

    Closing

    Mike Schwartz: Joe, thank you so much for sharing all these insights today,

    and thanks for your time.

    Joe Duffy: Thanks, Mike. I had a good time. I appreciate the chat.

    Mike Schwartz: Special thanks to the Pulumi team for wrangling Joe onto the podcast. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics by Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere. The podcast. Our Twitter handle is @fosspodcast.

    Next episode we talk to Tracy Miranda, Director of Open Source community at CloudBees, the company is behind Jenkins. Stay safe everyone. Until next time, thanks for listening.

    The post Episode 46: Create, Deploy, and Manage Modern Cloud Software – Pulumi, with Joe Duffy, Founder / CEO first appeared on Open Source Underdogs.

    0 min
  • Episode 45: Continuous Deployment with Tracy Ragan, Creator and CEO of DeployHub
    Intro

    Mike Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 45 with Tracy Ragan, Founder and CEO of DeployHub. Tracy is exactly the kind of entrepreneur we’re looking to interview. She is deeply experienced in open source. For example, she served on the board of the Eclipse Foundation. She’s a serial entrepreneur, and she has a plan to succeed that will adapt to whatever the market throws at her.

    If you want to learn more about Tracy, she was a guest on two episodes of The Daily Drive. I try not to repeat too much of the content from those podcasts. I’ll put links on the episode page so you can check them out. The Daily Drive is hosted by Ken Knorr to provide entrepreneurs, marketers and sales people with news, information, inspiration and tools to drive success – it’s a fun show. Well, enough of my blabbering, let’s get on with the interview. Here we go.

    Tracy, thank you so much for joining the podcast

    today.

    Tracy Ragan: Hello, and it’s my pleasure.

    What Is Continuous Deployment?

    Mike Schwartz: This isn’t really a tech podcast, but sometimes the background is helpful. So, I’m wondering if, in a nutshell, you could help us understand what is the Continuous Deployment Market, and what are some of the adjacent markets, like, how would you compare to a Puppet or a Chef?

    Tracy Ragan: I think the best way to describe it first is to define it around Continuous Delivery. Continuous delivery is the engineering process that says, “Hey, let’s get new innovation out to end-users as quickly as possible.” And that means a change has to go through sort of an assembly line from tracking the change request, to creating the binary, to testing the binary and installing it at different locations, from dev to test or production. That’s what Continuous Deployment is.

    So, when you think about companies like Chef and Puppet, they are at a lower level, they are worried more about the configuration and the deployment of the infrastructure itself, so, do I have a cloud image or a physical machine that I am ready to deploy to. So, they are at the lower level. So, Continuous Delivery and Continuous Deployment generally sits at a higher level and worries about the application level.

    How Is DeployHub Democratizing Continuous Deployment?

    Mike Schwartz: In a previous interview, you mentioned that DeployHub is democratizing Application-Release Automation – what exactly does that mean?

    Tracy Ragan: I have been in this business for quite a long time, and I get frustrated when I see so many companies still relying on scripts to do the heavy lifting of the Continuous Deployment piece. It can be a real showstopper for a lot of companies because they can’t do updates as frequently as they would like to.

    Now, they can go out and buy a product, but some

    of these products are really expensive. Some of them are based on endpoint. So,
    if you’re going out to a few thousand servers, you’ve got to buy an agent for
    every server.

    And when we built out DeployHub, I really, really wanted to provide an open-source solution to many companies and developers who didn’t have what I call Budget Authority, so that they could move away from this scripted process, and instead, do something that’s truly automated, and do it from an open-source standpoint. And that’s what I always mean when I say we’ve democratized it.

    Because it’s not just the person at the CTO-level or a director-level, making a decision that everybody in the company is going to use this particular solution, and it’s going to cost hundreds of thousands of dollars. Instead, the developer, who’s already building out that CD pipeline, can say, “This is a good practice for us to use, and I can afford to take advantage of it.”

    Differentiators

    Mike Schwartz: You mentioned that in your market, competitors are selling expensive enterprise software platforms, how is DeployHub different, not just from a price perspective, but what are your other differentiators?

    Tracy Ragan:  When we built out DeployHub – and our open-source solution we call Ortelius, by the way. Abraham Ortelius was the first map-maker, he created the first world atlas – we saw the problem from a microservices standpoint, there’s several really solid ARA, Application-Release Automation tools on the market. But they are monolithic-driven, they don’t think about an application in terms of its pieces and parts.

    When we built out DeployHub, we put it back inversion engine on it – just like you would inversion source code – so that we could independently deploy the pieces and parts of an application as opposed to an entire monolithic.

    Now, that’s critical in the microservices world. And it’s basically a mapping exercise. What we’re really doing is what I often call Automated Configuration Management from microservices. And as you push the microservices across the continuous delivery pipeline, we’re tracking the changes and building a map.

    So, if you think about, if you ever go, “This is a fun exercise.”, if you ever go and Google search on the Netflix Death Star, you’ll begin seeing the kind of world that we’re putting together with microservice, and it’s massive. I think Netflix runs around 4,000 plus microservices. So, what we’re doing is part of the deployment is versioning the Death Star.

    Now, in the beginning, we have companies who come to us, and they start hitting a bottleneck at six or seven microservices. That may not sound a lot, but if you put that, and then you add versions, even a version for DEV, TEST and PROD, and then the next version coming, or the version three months from now, you end up with a lot of microservice really, really quickly.

    So, what we focus on is creating that map, and

    that’s what the open source project is all about. Because, in order to be
    successful with a Kubernetes microservice implementation, you must have a way
    to organize the microservices in the same way that you had to organize APIs
    when we first started doing API management.

    Community?

    Mike Schwartz: So, as I understand it, the monetization strategy for DeployHub is Software-as-a-Service. And I’m wondering, is there a community collaborating to build the software that you run as a service?

    Tracy Ragan: We’ve been working on that. When we first started Ortelius, we

    had a few really important folks show up to help us out. One individual’s name
    is Doug Orr. He actually designed Kubernetes
    for Google, he was one of the directing engineers that built Kubernetes out.

    We also had a local company called Descartes Labs step in and start looking at what we were doing with mapping and give us some real strong direction on where they thought the product should go.

    And now, that’s been a year ago, when we first released the product, and we first brought the community in. We now have Netflix and Google, who have joined our Technology Oversight Committee. And we’d have those board meetings about — we try to do them three times a year, to really build out the roadmap.

    So, we’re pretty excited to have some really

    strong players in the market that’s helping us what our roadmap will look like
    for the mapping of microservices in a cluster.

    Has Open Source Materially Benefitted the Business?

    Michael Schwartz: Would you say that open-sourcing the software has materially helped the business?

    Tracy Ragan: Not yet. It hasn’t. There are simple reasons why you would open-source. For example, there’s always this term that a lot of companies use, and you’ve probably heard it before, “vendor lock-in”, and there’s also this thing called patents.

    We open-sourced it originally under the Affero License, which it currently exists under, and what that does is, it exposes the code to all of our customers, so they don’t have this concerned about vendor lock-in. If they want to enhance it for their own environment, they can, but nobody at this point can take it and monetize it.

    Now, on the patent front, it’s a real problem to

    try to patent software. Everybody says, “You know, if you want to get
    investment, you should go do that.” When you release something under the Affero
    License, you’re patenting it. Because anybody who goes to use it, has to use it
    under that license. They could reuse it internally again, but they can’t
    monetize it.

    Now, as we have grown, we are inviting more folks in, like Netflix and Google, because we need now their expertise. And their expertise comes from having these massive Kubernetes clustered environment. We can’t get that without an open-source tool.

    So as we move along, we’re hoping that we will

    move that Affero License and change it to something that’s a little more
    liberal license, so that we can include that as part of the CD Foundation, and
    then other companies can monetize on the mapping.

    It’s yet to be determined if we’re going to get a financial gain out of it, but we certainly have become thought leaders because of it. There’s not too many companies talking about this microservice configuration management issue. The more we can be out there as a thought leader and the more input we can get from these big companies, the stronger our tool will be. And the only way to do that is through an open-source project.

    How Do You Decide What Is Open Source?

    Mike Schwartz: So, you probably don’t open-source absolutely everything, and there’s always this balance between what do you open-source and how do you prioritize R&D, and open-source, or, let’s say, your proprietary. And I’m wondering how do you handle that conflict?

    Tracy Ragan: Yes. So, we looked at the product, and we talked to the folks who were using it from an Enterprise perspective, and we asked them what’s the most important part of the tool that they really, really, really love. A lot of that had to do with what we call our Domains.

    So, in microservices, you really need to

    establish what’s called a Domain-Driven Design. I like to equate it to, you
    know, everybody has a junk drawer at home, and if you don’t know where something
    goes, you kind of throw it in the junk drawer. And then, if something’s missing,
    you kind of dig through the junk drawer to hope it’s in there. Oftentimes,
    right now, microservices are being kind of treated that way.

    They’re checked into a repository, but that doesn’t mean there is a domain-driven, logical hierarchy of where to find these microservices and to share them. So, when we looked at the Pro version, what we call our pro version, we have what we call Divisional Domains. And that’s important to an Enterprise, but it may not be important to a project team. And then, on top of that, what’s important to the Enterprise is – the feedback they gave us – is the ability to put security around those domains.

    So, if you have a group of API developers, they want to be able to share their microservices, but they don’t want anybody to edit or change the way they’re deployed, and some of that information is what we versioned. We, in the open-source version, we took all of that, the Divisional Domain, and all of the security out of it. And that’s generally what the Enterprise wants, but it’s not critical for a project team.

    So, a project team can go ahead and move forward

    with it. And if they really needed to put security around it, they can do so
    around their CICD. So, CircleCI, for example, has approvals that move authority
    it built inside of it. They can actually build security around it without using
    ours.

    Is SaaS The Main Monetization Strategy?

    Mike Schwartz: Did I get the monetization strategy right? I was under the impression that you were a SaaS, or that there was a SaaS version of the open source. But other revenue streams besides the SaaS?

    Tracy Ragan: No, that’s it. Well, of course, we have our consulting arm, so we help companies with implementing these microservice structures and organization. We do what we can to help anyone who comes to us and says, “We’re struggling with managing our domains – how can we do it?” But there is a – just as a point of clarification – there are some companies who don’t want to use the SaaS. We have a registered container at RedHat, and we’ll be adding one to the AWS marketplace that they can create an on-prem version.

    Market Segmentation

    Mike Schwartz: Deployment is a very horizontal market, do you segment the market vertically, or any other way, when you’re thinking about the marketing strategy?

    Tracy Ragan: We actually do. If you take the financial market for example, they have a very different perception of deployments than somebody that might be in Telecom for example. The financial market is really super highly-regulated. They have serious audit requirements. Now, Telecom does as well, but not at the level that the financial markets would. They take separation of duty still very serious.

    When we’re talking to somebody in the financial market, we may be having a conversation that’s stronger around audit, as opposed to somebody who may be in another industry, where it’s stronger around Continuous Deployment. I know it sounds crazy that the financial market may not want the Continuous Deployment. They want Continuous Deployment with a strong audit trail.

    The other markets may want to solve microservices. So, we do have a message specific to some of these industries, medical’s the same way. And then, there’s embedded — you talk to embedded folks, and that’s a whole different story for them because they have a whole different set of challenges.

    Sales Motion

    Mike Schwartz: What does the sales process look like for DeployHub? I know for a lot of SaaS, there’s this philosophy of try by fly. You are a little different, it’s a complicated product sold to Enterprises, and I’m just wondering, like, what does the sales process look like?

    Tracy Ragan: We’re still figuring that out. We still believe some of our best sales has come through a self-service model. So, what we did is we took the open-source version Ortelius, and we built it into a SaaS offering so we could call it freemium. It’s free to use, and we have about 150 users out there using a product, many of them are small project teams.

    What we find are these bigger companies who want to be able to do a POC and never talk to a customer. We have been successful in closing deals based on that model. So, while they use the free version, they understand some of the problems with implementing of the free version into an Enterprise because of the security, the lack of security on the free version, so then, they reach out to us.


    We’re focusing now that we’re kind of low here with the current economy, and we’re focusing right now all of our efforts in making the front end of the product as easy to use as possible. It is a complicated set of problems to solve, it’s our job to make it an easy problem to solve.

    So, the sales model is going to rely on our ability

    to provide a self-service SaaS product. The teams can get excited about and
    start implementing on a very, very short schedule. We’re talking two or three
    days at the most.

    Pricing

    Mike Schwartz: Your business is still sort of new. I think you were formed maybe two years back. But one of the questions I like to dig into a little bit is pricing, which I find is really hard. And the difficulty is really underestimated by a lot of entrepreneurs. Do you have any advice for how do you find the right gates, how do you find the right price, and how has your thinking evolved maybe since you first got started?

    Tracy Ragan: When we first launched DeployHub, the company, I reached out to a few CPAs and said, “I need to make these decisions on real data.” And I put together a monster of an Excel spreadsheet. A monster that said, “This is what we want to do. This is the number of freemium customers that we want. This is what we want to do to convert them. This is where we need to get to, and this is what it’s going to cost.”

    And from there, I backed in the price. So, looking at how much money we wanted to make off of it, we this time – and pricing is really tricky – we said, “This is what we would have to price the product at in order to get to a certain growth in dollar amounts, and to be able to support the product, and do the development that we need to, and do all the selling that we need to do around it.”

    So, that’s how we did it this time. We did it much more scientifically than hunch. You know, I got a hunch that this will work. So, the way we priced it is, we have something we call a “project”. So, if you’re a bank, you have a teller application, that would be a single project. And we price it at $2,500 per year per project, or it comes out to, I think, $300 a month per project, which is a really low price point, but it is a project by project implementation, as opposed to going out and saying, “We want to sell you an Enterprise deal at a 100K with a 30,000 a year maintenance contract.

    And the way we’ve done it, a project team can make the decision to say, “I’m going to go ahead and buy the Pro version. And I’m going to go ahead and implement it because we control our continuous delivery pipeline, and I don’t have to get everybody involved to make this decision.”

    To say we’re really practical about it, I spent the first six months – when we first started DeployHub – with my head in financials and talking to CPAs and really working out the model.

    How To Manage Customer Interactions At Low Price Point?

    Mike Schwartz: So, your price point, I think managing customer relationships correctly is really critical to scale. So, what are the different channels that you have in place to communicate with customers?

    Tracy Ragan: We try to keep in touch with most of our customers by reaching out and calling. And we have a sales rep, I guess you could call him a sales rep, but he really is a customer service person who reaches out on a regular basis. And we have regular training that we reach out, to help them move from one step of the product to the next and make sure they understand all the features.

    But, you know, GitHub is a great resource for that, because, we have on the open source side, we have a GitHub repository, where people go and open up issues. And that creates a really nice conversation, not just amongst us internally, but as well our other customers who are seeing some of the same problems.

    So, we have a GitHub repository for the open source, and then we have one that’s private for what we call the Pro and Enterprise versions, but for most part, most of the tickets are opened up under the open source, which creates a really great platform for that.

    Partnerships

    Mike Schwartz: As we mentioned, the business is still kind of young, but I’d like to ask questions about partnerships. What kind of partnerships does DeployHub have today, and what types of partnerships are you looking to develop in the future?

    Tracy Ragan: I would say two of our best partners is CircleCI, they have really embraced what we do around deployments, especially around the management of microservices. We also work pretty closely with the CloudBees folks. They have what I would call a competing tool, but they still want to provide their customers options. So, CloudBees and CircleCI have been great to work with.

    Now, we also are working with Plutora. Plutora

    is a company that manages what we often call Value Stream. And not a lot of
    companies are thinking about Value Stream Management for microservices. So, we’re
    doing some integration as some joint customers with Plutora.

    When it comes to a broader community, I’m on the board of the Continuous Delivery Foundation, and so I’ve built quite a few relationships with those folks. And I’m currently working on building out a partnership with Gitlab.

    Advice For Open Source Entrepreneurs

    Mike Schwartz: I ask this question to all the guests – do you have any advice for entrepreneurs who are launching a business around an open-source software product?

    Tracy Ragan: You know, I think one of the smartest things I ever did was work on that, build out that Excel spreadsheet. It was painful, it was not fun, it hurt, it really did hurt. Some days, I just feel, like, I just have to go, you know, strap on a drool cup and watch TV for a while.

    It’s not an easy practice, to sit down, and visualize, and think through your company for a five-year projection. But, if you take the time to do it, I believe that you will see if your company is viable or not. And you can get the pricing down, and you can really understand what you need to do to achieve success.

    That was one of the best things that I that I ever did because I know now, I have marching orders that I have to live by. And it’s in that Excel spreadsheet. I know what I have to achieve on a quarterly basis, and I know when I need to increase the price of the product. So, that was really important.

    The other thing that I

    did that was right was, I got involved in the bigger open-source community. Getting
    involved in the Linux foundation, even if you’re a young company, that’s a
    fairly inexpensive entry point, to join the Linux foundation, and then join one
    of those sub-foundations like the CNCF or the CDF, because it really does give
    you a broader community to talk to and develop partnership within your community.

    So, I probably wouldn’t have the friendships that I have now with folks that are at Gitlab or CircleCi, or CloudBees, for that matter without it. So, those are the two things I believe I did right. I worked on that spreadsheet really, really hard. I worked on building getting my name out there, making sure people knew me from a community perspective.

    I’d already worked out to get Eclipse Foundation, so I understood how important that was. And when we started DeployHub, I went back into doing a lot of volunteer work for the community that I love. And anybody who’s starting a company, an entrepreneur of any type should do that. You have to give back even if it’s hard.

    Advice For Building The Team?

    Mike Schwartz: I just looked through my notes, and I realized I missed a question. And I want to make sure I ask this one. In one of your previous interviews I listened to, you talked about recruiting new team members, and how sometimes, you don’t necessarily look for deep technical know-how, you’re looking for a certain type of person. And could you go into that a little bit deeper, like, how do you know who to recruit?

    Tracy Ragan: I learned this when I was running OpenMake Software in the early days. You know, we were small, we needed to expand our ability to recruit without having to pay a lot of money, to be quite honest. And one day, I was sitting at a coffee shop – it was like Caribou Coffee shop – and I was watching this guy work, and he was able to do like — I don’t know, he was making four coffees at the same time, running the register, he just was able to do multitask.

    So, I started talking to him, and he had graduated from Boston University, and he was a filmmaker, and I asked him, “Have you ever thought about doing anything with technology?” And he said, “Oh, I’ve done some programming.”, and I continued questioning him, and I ended up hiring him about three days later.

    He was one of our most valuable employees at the time. He not only could put a story together for us, he really understood how to build a broader picture, and he could code. Had I not been thinking to kind of open up my mind to how to recruit folks, I probably would have never sat there and looked for somebody who was like, “Wow, he’s multitasking really well – I wonder what else he’s talented at?”

    The other thing is, there are a lot of older folks that have a lot to bring to the table, may want to change jobs. We hired an individual most recently who had done some testing, and he had done some deployment work. He was older and he had gone to our community college and taken programming. And we brought him on, and he was fabulous, really, really hard-working. I could rely on him for – and I still do – rely on him for anything that I need. But had I been just looking in the normal channels, I probably wouldn’t have found him.

    Advice for Women Entrepreneurs

    Mike Schwartz: If you look at our podcast, you’ll see that the male to female ratio for our guest is like 50:1, although we’re trying to improve that this year. Given the fewer number of chances I get to talk to them, and I want to ask you one specific question about, do you have any advice specific for women entrepreneurs?

    Tracy Ragan: This is hard for women entrepreneurs. You know, 2% of the funding

    goes to women. 2%. So, I don’t have a lot of advice except reach out to me,
    reach out to other women entrepreneurs, get involved in women in technology,
    consider going to some of these women in technology conferences, because we
    need to build our network.

    When I first got into computers, there were a lot of women. And they’re not a lot now, and there’s even fewer at the top. And that is a problem, it’s a very big problem. And I’ve spoken in high schools and encouraged young women to go into the business of STEM, in particular Computer Science. And I reminded all those boys out there that if they don’t encourage their friends, who are female, to get involved, they’re going to have a really boring life because they’re just going to work with men all the time.

    So, we really need to build our own network, and

    I do everything I can to reach down, when I see somebody really talented, to
    help them in any way. I do have a couple of ladies that I’ve mentored through
    the process. And that’s what other women, who have already gone through and have
    some understanding of how to move from step A to step B, we need to help each
    other. That’s the best thing I can say.

    And I’m hoping that there’s going to be more women, who are investors, who want to start reaching out and bringing women up to the top. I know we have to look at, like, LaunchDarkly, she was great at being an example of what a woman entrepreneur can do. She worked her butt off to get funding now. It’s not easy, and it’s just the reality.

    Closing

    Mike Schwartz: Congratulations on all your success. And thank you so much for making a couple of minutes to talk with us today, and best of luck in the future.

    Tracy Ragan: Mike, thank you so much. It was a pleasure, and I look forward to hearing it.

    Mike Schwartz: Special thanks to the DeployHub team for making Tracy available for the interview.

    Editing by Ines Cetenji. Transcription by Marina Andjelkovic. You know all those cool graphics on the website? Special thanks to Kamal Bhattacharjee for making them. He’s done a great job for 45 episodes, so, thanks, Kamal.

    Music from Broke For Free, Chris Zabriskie and Lee Rosevere. The podcast Twitter handle is @fosspodcast. Next episode, we talk to Joe Duffy from Pulumy. Stay safe, everyone. Until next time, thanks for listening.

    The post Episode 45: Continuous Deployment with Tracy Ragan, Creator and CEO of DeployHub first appeared on Open Source Underdogs.

    0 min
  • Episode 44: Devops, Security, & Cloud Automation Puppet with Yvonne Wassenaar, Chief Executive Officer
    Intro


    Mike: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 44 with Yvonne Wassenaar, CEO of Puppet. Yvonne is the third CEO of Puppet. Luke Kanies was the founder, we interviewed him in the episode 22.


    Sanjay Mirchandani succeeded him, and Yvonne took over from Sanjay in January of 2019, about a year before we recorded this episode. A CEO who takes over a company like Puppet needs a different skill set than your typical founder. Whereas the founder needs deep domain knowledge, usually a hands-on approach to business development, CEOs for companies, in later stages of growth, need this intangible corporate leadership ability. It’s hard to say what it is, but you know what it is when you see it. Yvonne has it, and she also has the values and an understanding of the culture that complements where Puppet is in its corporate life cycle. I don’t want to spoil any of the content, so I hope you enjoy this interview. Here we go.

    Why Take On The CEO Role At Puppet?

    Mike: Yvonne, thank you so much for joining us today.

    Yvonne: Absolutely. It’s great to be here, Mike.

    Mike: When you joined Puppet early last year, as CEO, why did you want to take on this enormous responsibility, steering the ship with hundreds of employees and thousands of customers?

    Yvonne: You frame Puppet so well in terms of, it is a large employee base. We do have a lot of customers, and I’d extend it even further into we’ve got a massive community around the globe. And I did think really long and hard around was I the right person to take on the responsibility to bring Puppet and the impact of Puppet, the company, in the community to the next level.

    And the reason I said yes to that that question, to myself and to the board, is, as I thought about the opportunity, Puppet to me represented a perfect place for my step, next step in my journey, for the following reasons.

    One, the values that are represented by Puppet, and the Puppet community aligned really well with my own, in the sense that we are really focused around – you know, being open-source core kind of the democratization of technology diversity and inclusion, having impact at the practitioner level, and really making a difference in the world around us.

    And to me, I feel life’s very short, and having

    strong value alignment is really important. And what Puppet represented
    resonated very much with me.

    The second thing is really around the technology and the problem that we solve. I deeply believe that Puppet and the technology that we build and work, standing upon with the community and with our own team, makes a difference in the world around us, makes a difference not only in eliminating soul-crushing work, which is what Luke started with, but makes a difference in terms of enabling companies to achieve the agility that they want, in a secure and scalable way.

    And as an ex CIO, the risk of cyber security I

    think sometimes is underestimated, and it’s really beholding upon all of us to
    think about not only how do we leverage technology to make the world a great
    place, but how do we do it in a safe way.

    So, to me, if I think about the values, and I think about the actual product and offerings that we’re bringing to market through the community and with our commercial offerings, that resonated really well. So, the third component was, “Can I personally make a difference?”
     
    Given my experience across companies like New Relic, VMware, and my time in Accenture, I felt I had a good breath of experience that I could, not necessarily bring the answer, but ask the right questions and bring the right team on board to really deliver our true potential as a company.

    So, those three things combined, all aligned up, and having been here a year, it was definitely the right decision. It’s been a great ride, I think we’re doing amazing stuff, and I can’t wait for what’s yet to come.

    Why Expand Product Surface Area from Configuration Management?

    Mike: In the past, I might have described Puppet as being a Configuration Management Platform, but today, Puppet’s moving into areas like continuous compliance, incident remediation, and continuous delivery – why expand the product surface area? And I’m also wondering, how do you evaluate the risks that come along with that expansion?

    Yvonne: Puppet as a Configuration Management Platform, I’d even say tool, has been the market perception of who we are. And that very much is grounded on where we started.

    To me, the fascinating part of your question really comes down to the fact that the big shift that Puppet made in this last year was going from talking about what I would call “feature functionality”, which what Puppet does, is, really, we automate infrastructure in really, really powerful ways, to talking about the use cases and the business problems that we solve.


    So, what’s interesting is, from a technology standpoint, what Puppet has built out over the years is going from a declarative approach to infrastructure automation, which is where we started, which is, we’re turning environment to a known, good state, to extending that into both declarative and task-based automation, which we leverage our open-source project, Bolt, to support and drive. And Bolt integrates with Puppet enterprise. So, it’s both declarative and task-based, both agent and agentless. Now, we are extending even further into workflow, event-based automation.

    The tool has gotten more robust in terms of the types of things that people can do with it, but the real shift, I think, from an impact standpoint, is, we’ve started to really be able to harvest from our customers, what do they use that tool in capability for. So, you know, certainly some people are using Puppet truly to manage the configurations in their environments, and that’s the main driver. They’re looking for that efficiency and scalability of what they’re doing.

    We also found, however, that some people are

    deeply dependent on Puppet for compliance. And that understanding that that’s
    the business use for the tool, or one of the business uses for it, allows us to
    better serve up and meet those needs.

    And interestingly, from an incident remediation standpoint, again, there’s a lot Puppet does from a declarative model standpoint that was always kind of remediating your environments in some way, shape or form, if you think about it. But it’s a very simple extension into integration with security scanners like Tenable, Qualys and Rapid7, to really start to go, having a scan, and then, manual process, and sorting through PDFs and Excel files, to get to business impact to saying, “Hey, I can ingest that information, make it contextually aware in the environment, and allow people to act on it in a much automated way.” Which not only reduces the work effort, but very importantly, to my earlier comment on cybersecurity, reduces the time to remediation of a known vulnerability, which improves your security profile.

    So, the big shift, I think Puppet for a while has been making the tool or the platform more robust, but the shift that I think you’ve seen in the marketplace perspective is more around how we characterize what our technology can do in the context of business problems and business outcomes.

    Priorities After Joining as CEO

    Mike: In your first few months as CEO, what were your priorities, and did you feel like you needed to pivot the business after coming in after the founder? And I’m wondering, was there really a pivot needed? Or did you see that it was more of a requirement to incrementally improve what Puppet was doing?

    Yvonne: Yes, it’s always challenging when you take a company over as CEO, in part because there’s a huge piece of the culture and the connection with the people that comes with that top job that you have to be sensitive to.

    When I look at the journey of Puppet – Luke actually ran the company for the first many, many years very successfully, and the creation of this new market, and the proliferation of the technology at that practitioner level, there was actually another gentleman, Sanjay Mirchandani, who took over from Luke and ran Puppet for three years. And what Sanjay focused on was really selling higher up into the enterprise, and kind of, to your previous question, looking at going beyond configuration management, what was important in the marketplace.

    As I took Puppet over a year ago, the key things

    that I noticed, one was that we were very much on the right trajectory, and it
    was more some fine tuning and focus that we had to drive to the business. And
    my real time and attention in the first year, first and foremost, was on
    appreciating that a CEO change, no matter how great I may or I may not be, is
    an experience that you need to work through with your employees and with your
    community.

    So, my first focus was on the team and the community

    and really aligning around purpose. And kind of your first question, why was I
    even there, did I care about the same things they did, were my values aligned, how
    are we going to come together as a team and really drive the next level of the
    journey – I think that’s important advice for anybody taking on a senior level
    role.

    Start with the people, and then, really, from a

    business perspective, looking at how could we get the biggest impact with these
    things that we have, how can we simplify and focus what we are doing to those
    that would make the biggest difference.

    So, we did trim the product portfolio a little

    bit, we doubled down on areas where we felt we had differentiated capability, we
    started to focus a lot more on the engagement with the community, we had
    drifted a little bit away from that which happens sometime.

    So, really looking at, we did our first ever in person contributor summit, looking at how could we really nurture both, the community who has gotten us to really where we are, as well as being in meaningful service to our enterprise customers, who, at the end of the day, are a critical part of the business model as well, and scaling what is now a relatively large company that has a strong open-source base, and also has a sustainable, monetary business model to care as well for.

    Puppet Value Proposition

    Mike: What would you say the value proposition is for Puppet today?

    Yvonne: I believe that Puppet has gone from being a kind of a practitioner tool that eliminates soul-crushing work, which is a really, really important thing that we have extended a prawn, that value proposition, to being a platform that enables business agility in a safe and secure way. And the way that I see us, really bringing this to market is, if you think about the modern enterprise and open-source projects, they are here to service to everybody. We really focus our commercial efforts on what I would call the Global 1000. And in that segment, those companies are going to be in a hybrid, or multi-cloud world for many years, if not decades, to come.

    And Puppet is uniquely positioned to, in some regards, be their automation everywhere platform, be it in the data center or into the cloud, and increasingly across the Internet of Things. And we’re able to do that because we have a portfolio of automation capabilities, so different types of automation are actually required for different types of use cases in needs.

    And so, whereas before, the world was a little black and white, you know, it’s either declarative or it’s imperative, and there were religious battles, it’s like now we realize that many different types of automation are needed when you operate at that scale. And we offer all of them in a coherent way. And we’re starting to build out the intelligence from that practitioner level up through the executive level, and helping people do things, all the way from, get the work done, to create the reports and the insights that the auditors need to get you through that compliance check.

    So, for me, the real value proposition for Puppet in the commercial space is being that automation everywhere platform that gives you the action that makes things like your ServiceNow and Splunk implementations complete, because they might be able to tell you what to do or where the problems are.

    But it’s really when they integrate with Puppet, that you get that completion of that loop, that everybody needs to truly get the business impact.

    Market Segmentation

    Mike: So, Global 1000 is still a very horizontal market with all sorts of different vertical segments. I’m wondering, from tactical sales and marketing perspective, when you’re trying to convey business value to these different segments, do you have to change the marketing a little bit? Or is there any vertical marketing or segmentation going on, and how you look at the customers, and how to sell to them?

    Yvonne: Yeah, absolutely. I love the question that you asked because there are so many horizontal technologies in the world, and I work with many companies, back in the day, BEA, and VMware, all very horizontal in terms of a capability. What’s interesting, however, is the importance that you highlight, which is differentiating how a product is built versus how a product is bought and consumed.

    And that’s when you do benefit I think from taking a more vertical or use case approach to a technology. And, for us, for example, we do a lot in highly-regulated industries, and financial services is a great callout.

    So, even though the Puppet product offerings are the same, whether in service to retail, or financial services, or tech, or government, how we speak about the technology can start to vary in terms of those segments.

    And at the enterprise level, referential buying is a real thing. You know, if I’m a large bank, I’m greatly comforted if I know five other large banks also use that same technology. And you can start to help them understand the financial services banking problems that you can solve, and as I mentioned, compliance or certain compliance requirements in those industries.

    So, you can start to make it much easier for your customers to get value out of your technology and to trust your technology, when you can speak in their language, and when you can connect them with their peers, who are in a similar way using your technology to solve problems.

    So, what we have done – to answer your question from a segmentation standpoint – one is, recognized where are our open-source solutions most relevant and valued, and continuing to feed and nurture those. And then, being really thoughtful on where our commercial offerings are most valuable, and drive the greatest impact.

    And on the commercial side then, further sub-segmenting into vertical industry, and then, as we talked about use case, are you looking to solve problems around incident remediation and reduce time to vulnerability remediation, are you more interested in compliance reporting.

    At the end of the day, I like to kind of joke, Puppet is a Swiss army knife, they can do a lot of things. That’s a blessing and a curse. And when you work with large enterprise, then, more specific you can be on the problem you solve – I kind of use the analogy of an IKEA furniture – at the enterprise level, they really don’t want the big box of IKEA furniture showing up in a bunch of little pieces, without an instruction manual they have to solve it themselves.

    Some people like that and get a lot of joy. It’s

    usually not my customers, they want to have a simple easy way to get to
    business outcome. So, we’ve really done a lot to make that clear and easier for
    them.

    How To Balance Open Source Investment

    Mike: I thought it was interesting how you mentioned that you were, let’s say, investing a little bit in the open-source community, for example, an event for contributors. I’m wondering if you could talk about how do you prioritize investments in the commercial product versus the open-source product?

    Yvonne: I think about open source a lot. For me, personally, I think we are where we are in terms of the rapid technological advancement because of open source, and how that’s really proliferated around the globe in so many ways. And I do believe that it is a great way to democratize access and contribution to technological development, particularly with underrepresented groups in countries and locations, where they may not have otherwise been able to participate at that highest level.

    So, I’m a big believer in the whole concept, and I’m really proud to work at a company that appreciates and celebrates that, and invests in it. What I think is really important in the seat that I sit in is appreciating the fact that open source has in our case almost moral and principle value, but it’s also a critical component of our strategy. It is not the business model itself, but it’s a key part of our strategy.

    And I think of open-source in a couple different components. We have open source tools, Puppet open-source Bolts, those are tools that our community members can contribute to and benefit from. We have open-source content, which, in our case lives on the forge, which makes the tools even richer. And we have some people who only contribute to content, and some who only contribute to the tool, and some who contribute to both. And then we have the users of that open-source content.

    And to me, it’s important when I think about the open-source community, I think about all those constituencies because they’re all critical players even though they’re playing in different roles. And I’m very proud to say we have over 75% of our commits still coming from the community. We have a very active community.

    For me, what’s important is that we are continuing to nurture the creativity, the innovation, the access, in what I would call that “ground level of capability”, and that we’re allowing people, who have interest in ownership and institutions that we’ve built, to be able to contribute and get the benefits over time.

    So, we do a lot of things, from – we did a contributor summit in Budapest last year, we are doing Puppet camps again, so we’ve reinvested in that, more currently, in the process, we’re making them virtual just because of the environmental challenges, this coronavirus. But we are looking for ways that we can help people who are part of the Puppet community be able to have a platform to speak about, what they’re doing with the technology, the impact it’s having, and help others.

    We have obviously community managers, we’ve got

    slack channels, we’ve got some interesting ways that we’re looking at engaging
    with the community from the support perspective. So, there are many different
    aspects to it.

    And to me, one of the beautiful things is I think open source has evolved a lot in the last decade. And I like to think of Puppet as one of the folks who are leading through that evolution, and how you continue to give back, and you know, garner benefit in a very, very productive way. So, super-excited about what we’ve done. I’m sure we’re looking to evolve, but I do think it’s part of what makes Puppet special.

    Evolution of Sales Motion

    Mike: So, originally, I’m sure open source was one of the primary let’s say distribution channels for finding customers who are going to engage with you commercially. But I’m sure that the sales, you know, processes, and motion has gotten very mature as a company has grown. How does it work today? Would you say that the open source still really is a driver for business? And, if it’s changed, like, how have you adapted to that change?


    Yvonne: The go-to-market side of Puppet has evolved a lot. And open source has, as you suggested, played a critical role, and I believe it still does, but it’s shifted.

    In the beginning, a lot of people who bought the

    Puppet commercial products came from the community, and they were the
    practitioners who were bringing that technology into that environment.

    Many of the open-source users never felt the need to actually go and buy commercial products, they scaled up, and they built their own UIs and their own ways of advancing the open-source project in their company.

    And so, we did go through a phase, where, in the early days, there was a lot of inbound. And what I would say is, now, the two things that have shifted, one is, as our ability to drive impact across an enterprise has increased, as the maturity of our solutions have increased, we’re actually selling to higher-level individuals in a company.

    So, what I’d like to say is, we’re not just selling to the hands-on keyboard people, we’re selling to people who may never actually touch Puppet, the technology themselves. And yet, the fact that there are Puppet practitioners in their company is super important. So, I think one open source serves us today because it keeps a rich set of talents in the marketplace that can work on, and scale and execute the technologies that we’re bringing to the enterprise customers.


    The other thing that we found is, many of our enterprise customers have in some way, shape, or form, or division, used, or are using, open source. And they have just set a point where it’s no longer differentiating for them to do all the work around, upgrading the open-source and everything else, to do it that way. And they rather move to the commercial version, take advantage of the incremental feature functionality, have a simpler upgrade process, have 24/7 support.

    So, for us, I would say, in some regard, open source is still the land, people are using it, and then they’re starting to realize open source isn’t free. You’re just making different choices, do you want to have the engineering talent work on, keeping your open-source implementation healthy and current, and to build around it.

    That’s the right choice for some. For others they are saying, “Hey, open source was a great way to get something started. Now it’s starting to run a critical component of my business. Maybe I’m better off, from an opportunity cost perspective, to engage with Puppet, to have Puppet provide me those services of incremental feature functionality, and reporting and support. And I can spend my valuable engineering talents time on other things that might differentiate me as a retailer, or manufacturer, or a bank.”

    Is Puppet Open Core?

    Mike: Would you say that Puppet is open core?

    Yvonne: What I would say is, Puppet has – and I think this has been the big shift in terms of how we think as a company – certainly Puppet open source is a very mature, very impactful projects that many people can build on top of, frankly, around globe, which is wonderful to see.

    What I would say is, as we think about the broader Puppet, what we are looking at is, how do we create open-source capabilities that people can stitch together in different ways to self-problems. And we don’t just look anymore at, we have to be the sponsor of those open-source projects, we absolutely contribute upstream to other projects, we leverage other open-source solutions in some of what we do. For example, Terraform and Puppet work great together, there’s actually some great webinars on how you leverage Bolt and Terraform to drive provisioning, and configuration and actioning on that.

    So, we’ve really taken a much more open-minded approach, and thought about open source, almost from a component or an ingredient standpoint, that can be stitched together into whatever solution that you need. And some of those solutions we stitched together in a commercial way for our large complex enterprise customers. And others were providing the componentry that companies can stitch together in the way that they need if they want to do something all open source, or put their own secret sauce magic to it.

    Pricing

    Mike: Pricing is I think really hard for every company, surprisingly difficult. And it seems like the impact and the value of Puppet is so enormous to organizations – how do you find the rate gate to figure out or to find the right strategy for pricing? And you’ve only been there for a year, but have you seen that change? Do you think that the pricing model that you’ve figured out is going to be stable?

    Yvonne: Pricing is an incredibly challenging topic I think to your point for pretty much everybody, and to me, what I learned early on, back in my consulting days, is one of the best ways to think about what the right pricing model is, for your company is, to start with the value chain of what you’re bringing to your customers.

    If I take an early-day example of like an eBay, you know, market place, you are bringing value creating community. You’re making value by letting people sell through that community, you’re making value by letting people buy through that community. You are making value by providing different ways to attract attention.


    You can kind of map out all the different value points, and then, you can make decisions on where do you want to price to be able to get a return on the value you’re creating. So, eBay for example, could have chosen to say, “Hey, you’ve got to pay to get in, and then everything else is free.” Or, you can get in for free, “There’s value in there, but let me give you that for free, and you’re going to pay these other steps.”

    So, I think every company needs to go through that process and figure out where the value is, their driving for their audience that’s worth having an exchange. The interesting thing is, it can easily become way too complex. So, simplicity is an important rule of pricing in my experience, and then longevity.

    Particularly if you’re in the enterprise space, you

    don’t want to be changing pricing all the time, and it runs through your
    systems. So, I feel Puppet, in terms of where we’ve come from, that we have a
    pricing model that has worked well for us and for our customer base, on where
    we’re at. Are there opportunities to fine tune it and evolve over time? I’m
    confident there are. I’ve never seen a company that hasn’t at some point in
    time started to shift and think differently about their pricing.

    But, to me, whatever you do with pricing, it has to center around what is the value that you’re bringing your customers, and can you come up with something that’s simple and easier for them to understand that will scale out for a meaningful period of time. Because a hard thing to do is change your pricing all the time. That’s an easy way to upset your customers, and make a lot of enemies in procurement. And nobody wants to do that.

    How to Encourage More Women in Open Source Business?

    Mike: Yvonne, you might have noticed that the male to female ratio in Open Source Underdogs is currently 41:2. And we’re trying to improve that ratio this year, but it does reflect the reality of the tech market, which is that men are overrepresented, especially at the C-level. What can we do as an industry, or even more tactically, what can I do, as a founder of a software company, to improve that ratio?


    Yvonne: I love that you’re asking the question, what can you do to improve the ratio, because I believe at the end of the day, it has to start with individual ownership in action. And we can talk about really lofty things we could do, but at the end of the day, we need to create the future reality that we want. And we all have a role in it, whether we’re male and female, different types of necessities and so forth, if we want a diverse world, we have to create the opportunities for that, or diverse roles in leadership I should say.

    And what I believe you could do, first and foremost, I appreciate this opportunity, just showcasing Puppet and myself, and having different types of role models in your podcast. I’ve had numerous women come up to me and tell me that they aspire to be a CEO, and in part, they aspire to be a CEO because they see me doing it. That’s incredibly humbling, but it’s also a great reminder that, for many people, if you can’t see it, you can’t believe it.


    So, I think, first and foremost, showcasing different types of role models, that it’s not just one type that a successful leader looks like, but there’s many. The second thing is sponsoring and encouraging people to step up to that next level.

    What I have found working with underrepresented folks is that – myself included – we can often tend to be much risk-averse. So, encouraging people to retire to build that confidence that they can go to that next level. Sometimes to give them that nice gentle push, maybe not so gentle sometimes, as I had in my career. Sometimes, you just need that.

    So, I think creating the models, I think giving the pushes. And then giving the opportunities, take a risk on somebody. You’ll be amazed at what they’ll do with the right sponsorship and support. So, I think there’s a lot we can do across the board, but those are three tactical things that, at an individual level we can engage in, things that I try to do all the time.

    Advice for Founders

    Mike: Last question, any advice for entrepreneurs who are looking to use open source as part of their business?

    Yvonne: Absolutely. I live in Silicon Valley, and I run into a lot of people who get really confused on open source, and – when I say “get confused on open source”, they confuse perhaps a desire and a belief around the power of open source as a way to democratize technology and bring important solutions into the hands of everybody, with the fact that somehow you’re going to have to figure out how you’re going to make money.


    And so, to me, it’s really important to understand you can get both, I think Puppet does both, but you have to be really thoughtful what is the role that open source is going to play in your business model, because it is not a business model into itself. That’s kind of a rule number one.


    The second thing that I would say is, community, community, community. I don’t think that you’re going to get a lot of benefit out of just open-source thing, the technology you build if you’re the only one building it. Certainly people might use it, they’re not going to pay you for it, they might benefit from it, they might like that it’s open source, but I think part of what’s made Puppet powerful from an open-source perspective is the community engagement, and the fact that we’re collaboratively building these different open-source projects, and that we are collaboratively building content – that is what I think truly makes open-source most powerful.

    So, I really think if you’re going to do an open-source solution or have that be part of your solution model, how are you going to invest in, and engage, and nurture, and grow, and sponsor, and give a voice to your community, so that you keep them engaged, so that it truly is really executing open source at what I think is the most powerful level and form.

    Closing

    Mike: Yvonne, thank you so much for your time and sharing your great insights today.

    Yvonne: Great. Mike, thank you, it’s been wonderful. And, again, I really appreciate the opportunity.

    Mike: Special thanks to the Puppet team for helping to coordinate this episode. Audio editing by Ines Cetenji. Transcription by Marina Andjelkovic. Music from Broke for Free, Chris Zabriskie and Lee Rosevere.The podcast Twitter handle is @fosspodcast.
    Please, tweet at us if you have any comments on this episode. Next time, we talk to Tracy Regan from DeployHub, a great technologists and founder CEO.

    Stay safe everyone. Until next, time thanks for listening.

    The post Episode 44: Devops, Security, & Cloud Automation Puppet with Yvonne Wassenaar, Chief Executive Officer first appeared on Open Source Underdogs.

    0 min
  • Episode 43: Native-Cloud Visibility and Security With Kris Nova, Chief Open Source Advocate at Sysdig
    Intro

    Mike: Hello, and welcome to Open Source Underdogs, the first podcast recorded in 2020. I’m your host Mike Schwartz, and this is episode 43 with Kris Nova, a Chief Open-Source Advocate at Sysdig.

    Kris, who also goes by Nova, has contributed to Kubernetes and several other open-source successful software projects and startups. She’s currently a leader in the Falco project, a next-gen intrusion detection tool that is an “incubating” project at the Cloud Native Computing Foundation also known as CNCF.
    My mission this year is to interview more women who are open-source business leader, so when the opportunity presented itself to interview Nova, I couldn’t resist. But this podcast was a bit of a challenge for me. I interviewed Loris Degionni, the CEO of Sysdig, a few episodes back, so I wanted to stray little from my normal business model format.

    It was also really tough not going down the Cloud Native rabbit hole, although I think ultimately I couldn’t resist. So, it’s slightly more tacky than normal, but I hope you enjoy it. Personally, I found Nova’s perspective really

    thought-provoking, but you didn’t tune in to hear me, so without further ado,
    here we go. Nova, thank you so much for joining us today.

    Nova: Yeah, thanks for having me.

    Mike: So, how did you end up at Sysdig?


    Nova: Well, I had come out of my third startup that had gone through an acquisition, and, you know, I took some time off from work, I did some traveling, and just kind of — it was the first time in my life and in my career, where I was able to take several months off of work and just kind of mentally reset. And I started to evaluate the industry I was working in, and I wanted to stay working closely with Cloud, and Cloud Native infrastructure, and Kubernetes, but I wanted to pivot a little bit.

    And I started looking at the available spaces or sub departments of the industry. And one of the things that really stood out to me was the security. I felt like security was one of those things that you kind of look at it always as an afterthought.

    You don’t really ever wake up and design new software on day one to be the most secure implementation. So, I felt like we were finally there with Cloud Native, and started having more involved security conversations. I felt like there was just a lot of room for innovation in a field that I already knew a lot about starting off, with a new spin on it, which was getting involved with security. And then, Sysdig reached out, and here I am.

    What Is Falco?

    Mike: Sysdig makes a ton of data available from the kernel, as I understand it. And Falco, the project that you’re working on, tries to filter that data to make some actionable security information, maybe about intrusion detection.

    Nova: The definition that kind of really made it sing in my mind and resonated with me was, when Loris, our founder, I think you might have already spoken with him, the way he explained it to me was, basically we take the kernel as the new source of truth. Traditionally, if you look at how you would be auditing or attempting to observe a system, the network was usually kind of the most fundamental element you could get down to and, the thesis behind that was, if it’s happening at the network layer, we know it’s true, and we can trust it.

    And as we moved into Cloud Native, we realized that TCP packets were not the smallest element anymore. So, we took it even down later further than the network, which is where the kernel comes into play.

    I think you said it best yourself, we take a lot of information coming out of the kernel, and then we try to turn that into something meaningful for a human or a team. And that’s really what Falco does. It tries to be that connection point, that adapter between what would otherwise be an unreasonable amount of information coming out of the kernel, and then actually, trying to give you something that can help you tell a story.

    Has Falco Been Good For Business?

    Mike: Falco looks like a pretty impressive tool, and I’m wondering, has it been able to drive business opportunities for a Sysdig, the company?

    Nova: I think if you look at open source, and what that means to anybody doing open source in any industry, it’s got a new way of thinking about how you engage with other people in the industry, other organizations in the industry, other folks in the enterprise.

    And I think the easiest way that I can describe,

    the success I’ve seen with open source is, just looking at it as there’s fundamentally
    a difference between building a solution for someone and building a solution
    with someone. And I think open source is the latter of the two, is it gives you,
    and it gives your organization an opportunity to collaborate with other folks
    in the industry. And that’s where we’re seeing a lot of these hybrid solutions.

    You know, we could have open-source software called Kubernetes running in a public cloud provider, using a CNI implementation from a startup in San Francisco, all of which being secured with Sysdig. So, we’re seeing these multi-level, multi cardinal solutions because people are building an open source, and realizing that it’s actually more effective to build a small tool that is easily consumable than it is to try to build this monolithic solution to every problem under the sun.

    Has CNCF Been The Right Home For Falco?

    Mike: Falco has been incubated at the CNCF. And I’m wondering if you have some thoughts about whether CNCF was the right home for the project?

    Nova: I’ve been involved with the CNCF for years now. Like I mentioned earlier, I’ve worked at a few startups, we’ve donated, and built, and contributed to a handful of projects that ultimately ended up in the CNCF. And I think if you look at open source in the enterprise, and having a neutral third-party organization such as the CNCF, that can just help with things like governance, and infrastructure, and supporting the projects. And doing it in such a way that it’s neutral and unbiased for the project itself, ultimately just makes for a healthier project in a more wholesome experience for the maintainers and the end-users.

    I think the CNCF does a really great job at embracing this idea that ultimately in open source the end-user is the new customer. They’re the new consumers of the open-source project, and giving them that customer-like experience is something that you really see with the CNCF, and I think really drives healthy communities.

    Introducing Governance For Falco

    Mike: So, one of your goals I guess, when you joined Sysdig, was to help build the governance infrastructure for the Falco project. Have there been any challenges along the way for making that happen?

    Nova: I feel like when I joined, Falco was already on a trajectory to being a first-class security solution in Cloud Native that is open source. And I think I was able to come in with, you know, like I said, I’ve done this a few times, I’ve been involved with the CNCF for years, I’ve been working on other more household projects such as Kubernetes, or Helm, or Envoy. And I think I was able to come in and bring everybody together and kind of double down on our approach to open source.

    I think there’s a lot of work that we had to do, that we have yet to do, but ultimately, it all comes down to this idea that, at the end of the day, Falco belongs to everyone. It’s not Sysdig’s tool, it’s a tool that was originally started by Sysdig and has already started to grow and be used in new and exciting ways.

    We have end-users who are using Falco for things that we never even dreamed of originally. I think having that open-source governance, that open-source model of “We’re going to make our decisions in the public, and we’re going to give the broader community an opportunity to get involved with these decisions as we’re making them.”, has been a really big part of the direction that we needed to take the project over the past maybe six months or so.

    Falco Ecosystem

    Mike: In addition to end-users, have there been any other vendors who joined the Falco ecosystem? Maybe who are looking to commercialize Falco as part of their product or make an offering?

    Nova: I mean, that’s something that we’ve tossed around with at Sysdig. And I think any time you have successful open source, somebody’s going to automatically go to, “Okay, how do we wrap this up and stick an SLA on it, and then start offering some sort of first-class support for a project.

    And in my mind, once an open-source project reaches that stage, like that’s a sign of success. That’s ultimately where you want to end up. I think Falco is right on the cusp of us getting to more of an enterprise open-source solution.

    I’m excited to see both, how my company Sysdig is able to take these new ideas and run with them, and potentially see other organizations and other companies in the industry do the same thing as well. So, I feel like we’re on that horizon of this finally happening for the project, which is pretty rad.

    Trade-off Of Moving To A Foundation

    Mike: I guess moving your project to a foundation, it’s a lot of bull thing to do for the governance of the project, but not all open-source companies do that. What are some of the trade-offs that you have to make when you decide to move your project to a foundation, and to move the governance to sort of a more open process?

    Nova: In Falco, we always talk about exchanging of velocity for altitude. And I feel like in open source, we have that same paradigm of, as you go either more on the foundation side of things or more on the agile side of things, you’re going to be exchanging enterprise opportunity with the ability to be agile.

    In other words, if we, as a company, had an open-source project, and we didn’t have open-source governance and open community around it, we would ultimately be able to iterate much quicker, and it would be a much more simpler and less complicated process for us to drive features, and to deal with debt, and to build a new functionality. But we would be sacrificing this ability to build with other folks in the ecosystem.

    If you look at Kubernetes, if you look at a lot

    of the sub-projects of Kubernetes, they do operate at a less agile speed or
    less agile velocity, but ultimately, that has empowered many different
    companies in the enterprise to come together and start working on building
    holistic solutions for everyone.

    I think a great example here is, there’s an infrastructure project called Cluster API, I had helped start this project, I think two years ago now, when I was at Microsoft, and the whole point of the project was, for us to come together and start to standardize how folks install and manage Kubernetes. And it’s taken two years for us to get where we are today, so it’s happened a little bit slower than most people might be used to.

    But, we now have a standardized holistic API that anyone in the ecosystem can use. And we’ve actually seen large Cloud providers, VMware, Microsoft, Google, they’ve all come together, and they’ve actually started building to this new interface. So, again we’re exchanging that velocity for that ability to be collaborative.

    Coalescing Ecosystem

    Mike: Remember, when I interviewed Matt Mullenweg from WordPress, he mentioned something very similar how we could build it faster if we just build it ourselves, but the community slowed us down, but we ended up with better software.
    And one of the other things I remember from that podcast was, well, just thinking about it, WordPress is really such a central part of so many ecosystems. They’re not monetizing Automattic, the company behind WordPress isn’t monetizing every user of WordPress. There’s companies that do WordPress hosting and WordPress development, so there’s this big ecosystem around WordPress, which is really impressive.

    And I’m wondering, do you see the Falco project

    as coalescing that kind of ecosystem? And how do you get there? Or, is that
    even desirable?

    Nova: I think the CNCF enables this type of collaboration. If you look at the projects, this is something that is baked into the governance model. When we were proposing Falco to move from the Sandbox, which is the most introductory level a project can be at, to incubation, which is where we are now, there is an entire section and an entire conversation around this concept of vendor independence, which is effectively this idea that if one vendor, who is working on a project, decided to take a step back, or take a break, or pull resources back, would the project still be able to grow, and prosper, and be healthy in the same way it is now?
    And that’s a fundamental philosophy in the CNCF. So, I think you’re going to see that with every project. I think us doubling down this for Falco was really critical to us getting where we are with Falco.

    Surprising Falco Use Cases?

    Mike: So, you alluded to some of the interesting business use cases that maybe you didn’t anticipate when you designed the product. I’m wondering if you could share with us what some of those are? Because I was also wondering, it seems super interesting, but how do people actually use it?

    Nova: I did a presentation of KubeCon in San Diego, with a gentleman named Abhinav from a company called Frame.io, and he went into a lot of detail about how they’re using Falco in a very limited way, which is funny, because I spend the first half of the presentation talking about how Falco can audit the entire kernel, and how we can start to process and assert various signals in the kernel that go for every system call that would potentially be running in Linux. And then Abhinav walks on the stage and says, “Oh, we only use it for three.”

    And it was just kind of this funny moment, where it’s like, if that’s what they needed in their pipeline, which if you go, and you watch the video, you can see the use case, and why they were only interested in a subset of these metrics here.

    You can actually see that Falco is dynamic and configurable enough for them to use it very concretely in a very small, but very precise way for exactly what they needed. So, I think you see that in a lot of different open source, but especially in Falco.

    Can Falco Consume Non-Kernel Data?

    Mike: Can Falco consume information from other sources, other than the kernel, and make sense of it in sort of the same way?

    Nova: Yeah, absolutely. One of the things that we’ve been circulating in the Falco community, and I think this is a great example of us not being able to move as quickly as we wanted, but in exchange, we’re getting feedback and insight from the community is, we’re working on a long-term supported release called Falco 1.0.

    And one of the things that we learned pre 1.0

    was that there was actually a lot of value in taking other input sources other
    than just the kernel and enriching the Kernel information with these other
    input streams.

    So, a big feature of 1.0 is going to be making secondary input streams much more dynamic and much more configurable, so that folks can start to plug other information into Falco when it comes time to building that story or that alerting system that they’re looking for, when it comes to detection, and anomaly detection, and insecurity.

    Is There A Marketing Strategy At Sysdig For Falco?

    Mike: Is there a marketing strategy at Sysdig for Falco?

    Nova: Yes and no. So, we obviously have our corporate marketing strategy, we have an entire department here. And we have a lot of similar goals, but I feel like they’re implemented in different ways. I think the easiest example here is Sysdig targets customers and users of our platform, whereas Falco targets end-users, which effectively are customers, but the relationship is a little more like, “We’ll give you a foundation in the scaffolding to come and build with us.” And you’ll be able to do that effectively for free, but you’re not going to be getting a lot of the first-class features that you would be as like a commercial partner, or a commercial consumer of what Sysdig has to offer.

    So, again, depending on your use case and what

    you’re looking for, it kind of gives us an opportunity for folks to get
    involved with — it’s going to cost more, but it’s going to be easier and more
    resilient, more reliable and more powerful. Or you can take the free
    open-source approach, which is going to require rolling up your sleeves and getting
    involved in the community.

    And I think what’s really interesting from a business perspective is watching as different implementations change from one side to the other over time. And seeing how 2019, it was a commercial user, and then moving forward, they moved over to open source. Or flipping that around and going from open source to commercial.
    So, it’s exciting to have that flexibility, as departments grow, or their organizations, as their needs change, as their systems change, what they might be looking for from us – it could potentially change. And having sort of an array of opportunity and avenues for them to get involved has been really powerful for us.

    Difference Between End-User / Customer

    Mike: What is the difference between an end-user and a customer?

    Nova: I think the easiest way to say “This is an end-user.” is someone who takes advantage of open-source software in its most raw form, whereas a customer is an exchange for goods and services, where we’re willing to provide some sort of monetary compensation.

    So, again, we’ll use Kubernetes here. Kubernetes is open source. If you or me wanted to go and go to github.com/kubernetes, we could potentially download Kubernetes and install it on some servers, and then try to go sell those servers that have a working version of Kubernetes running on it, with some sort of service agreement. But there’s nothing that’s really preventing us from doing this.

    And in the same way, other folks who have been contributing to Kubernetes for years and maybe even were, like Google, the original creators of Kubernetes, they have both the open-source avenue as well as the more commercial avenue. And I think you see that with tools like how GKE is Google’s Enterprise version of the open-source software that you could go download for free.

    Who Ideally Would Join the Falco Community?

    Mike: So, if you could see more partners join the ecosystem, what kind of partners would you like to see join the Falco community?

    Nova: Honestly, I would like to see the security industry come together and start working together as a community more and more. Like I mentioned earlier in the interview, moving to security, I had to relearn a lot of things. One of the things that hadn’t really been in my career up until recently, after joining a security company, was this concept of very strict competition, and this concept of, if I have some piece of intellectual information, I’m going to kind of withhold that. And that becomes part of our IP and what we have to offer. And I think we saw the same paradigm infrastructure in Cloud

    And, ultimately, if you look at the security

    industry, following applications, following infrastructure, following DevOps, it’s
    ultimately in my mind going to end up in the same way, which is the industry
    coming together and realizing that it actually makes more sense for us to work
    together on something that it is for us to fight each other.

    I would love for more folks, whether their security vendors, or security consumers, or even just users of security tooling, at the end of the day, to come together and start exploring different ways of securing systems, and open-sourcing, and collaborate on that.

    Is Open Source Security a Trend?

    Mike: I think that’s actually true. I remember speaking with Michael Howard from MariaDB, and he mentioned to me that – I don’t know if it was on the interviewer or after – security software is not inherently open source that normally it would be commercial, proprietary, licensed, all the above, to keep it closed. And so, I do think it’s the idea of, there aren’t tons of open-source security tools, so, are there other open-source security tools that maybe you can identify that you can think of this as a trend, or is Falco really at the forefront of this?

    Nova: I think – and if I get too often with ranting about security, please, please feel free to stop me – but I think if you look at security, having a holistic approach to two main categories is really what you want to see, when it comes time to taking security seriously and fully locking down a system.

    So, I think to give a really simple example of

    this. If we look at solutions like Kubernetes RBAC, which is role-based access
    control, just describing who can do what, and when, and how they can do whatever
    it is they’re trying to do. And potentially rejecting requests if they do not
    meet whatever criteria you set forth.

    But we also see this in Linux with things like Seccomp

    and SELinux. And it’s this idea of, we’re going to try to prevent somebody from
    doing something if they’re violating some sort of policy we have in place. So,
    there’s other CNCF tools like open policy agent as a great example here. There’s
    an open-source tool from Microsoft called Gatekeeper. That is an implementation,
    a concrete implementation of open policy agent. That attempts to effectively do
    the same thing pod security policies do, and Kubernetes, but from concrete
    implementation of OPA or open policy agent.

    But, again, we’re in the situation where these solutions,

    everything I just mentioned, all attempt to prevent somebody from doing
    something that they shouldn’t be able to do. Or to prevent some application
    from doing something that it shouldn’t be able to do. But if you look at the
    history of security, that’s only part of the story. One of the things I’ve been
    saying that I really feel like it’s a powerful statement is, at the end of the
    day, there’s no such thing as perfect software.

    Even Linux, the most well-known open-source operating system in the world, the largest open source project in the world, we still get CVEs, there’s still exploits. There was Heartbleed, there was a handful of critical CVEs that have happened in my lifetime. And those are fundamentally never going to stop. And anomalies and things that you aren’t expecting are fundamentally never going to stop.

    So, I think having this preventative side of things that you see with tools like access control and policy enforcement, running those in concert with tools like Falco that are more of a detective side of things really gives you like your kind of coming at the problem from two different fundamental perspectives, which kind of I wish you to double down on your security approach.

    So, short answer, yes, we see a lot of other tools, but we don’t really see anything that’s as focused on runtime detection, has to do with something say like Falco, or maybe even Wireshark, which was Loris’s original project.

    How Can Companies Adopt Cloud Native?

    Mike: So, you’re the author of an O’Reilly book on Cloud Native infrastructure, which I just ordered?

    Nova: Thank you. You should buy several copies of it, for all of your friends and all of your family.

    Mike: Makes a good Christmas present. But this is a very new knowledge domain for enterprise IT staff, and reading your book is a good place to start. But I’m wondering if you have any more thoughts on how companies can get up to speed on Cloud Native infrastructure?

    Nova: I think the book is a good starting point, but more importantly one of the things that I really want to stress with folks, to really have an understanding of what this phrase “Cloud Native” even means. And you can go to cncf.io, and they actually have like an entire essay that was put together that attempts to define what Cloud Native means to them.

    But I feel like it’s kind of like a personal choice or a personal journey you have to go on. It’s like buying a car. Ultimately, at the end of the day, you’re going to buy the car with the features that you need, that you like, but that whole process starts with, doing test driving things, and doing research, talking to people, and going to look at cars, and spending time understanding why this car may be better in this situation or might be better in this situation.

    And I think Cloud Native infrastructure follows the same paradigm of, you have to look at the ecosystem as a group of resources. And you can take these raw resources that are available in the ecosystem, my book included, and those raw resources become part of what you would use to potentially build out your finalized system.

    What To Look For If You Want To Join an Open Source Project?

    Mike: A couple last questions about your experiences as a veteran of being a part of open-source startups. If you’re looking to join an open-source startup, what would be some of the things you would look for that would be good signs that this company knows how to use open-source as part of their business model?

    Nova: I guess there’s two answers here, coming at this from somebody who’s — I’m in a very senior, very high visibility role, here at Sysdig, so I almost wanted to join a company that needed some guidance and needed some help. If I was to join a company that was perfect and open-source was already solved. You know, they were already doing everything “by the book”, it wouldn’t be very interesting or exciting for me, and I would hope that they would not be as interested in having somebody like me come in. And for lack of a better term, do what I do best, which is helping to drive open-source adoption and collaboration.

    For me, I wanted to find something that had

    opportunity to grow, and had opportunity and potential for us to move into
    really, really great things. And I felt like Sysdig was that perfect
    intersection of high potential with the right place at the right time with
    security.

    Now, if somebody isn’t as insane as I am, looking to get involved with something that’s going to be a lot of work and a lot of effort, I would say the first thing I always look for is, how are decisions made, both at the company, both on your team and both with open-source projects. And another thing that I always kind of view as a red flag is this concept of open-source announcements.

    If you think about it, an open-source project by design should be open to the community, you should be able to go, and read, or watch, or listen to the decisions that are made, the features that are driven, the choices that the community is deciding on. And you should be able to at the very least observe these, and if not, potentially shape and govern these things.

    So, anytime I see somebody doing some sort of open-source announcement, to me, that’s just evidence that it wasn’t an open-source project to begin with. That it was built behind closed doors, and then ultimately, hand it over for the sake of publicity, and not originally built in open source, as you would see with a lot of the other CNCF projects, like Kubernetes, like Hellman, like OPA, like Falco.

    Advice For Open Source Entrepreneurs?

    Mike: Last question about open-source entrepreneurship. So, if you were in the shoes of an entrepreneur who wanted to use open source as part of their business model, do you have any advice for that entrepreneur?

    Nova: Get in there and roll your sleeves up. At the end of the day, open source is, you’re not going to have that first-class experience of, “Click here, put in your credit card number, and then poof.” Everything works like it’s going to take understanding what’s going on, it’s going to take contributing to the code, contributing to the project. And you’re really going to have to accept the fact that you are just as responsible as the open-source project as everyone else working on it.

    Mike: Nova, thank you so much for joining us today – first guest of 20/20, yay! Thank you so much.

    Nova: Thank you. It’s been really nice talking with you.

    Closing

    Mike: Special thanks to the Sysdig team and Amanda McKinney, 280blue, for helping to coordinate the episode.

    The link to the presentation that Nova mentioned can be found on

    the episode webpage on opensourceunderdogs.com. Transcription by Marina Andjelkovic.

    Music from Brooke for Free, Chris Zabriskie and Lee Rosevere. The

    podcast Twitter handle is #fosspodcast.

    I have a big announcement: I just found out that my talk about the

    podcast was accepted to OSCON in July. If that happens, I’m really looking
    forward to sharing some of my thoughts on what all these episodes mean.

    The next episode features the current CEO of Puppet, Yvonne Wassenaar,

    who brings us up-to-date on Puppet success in business models. Don’t miss it.

    Until next time, thanks for listening.



    The post Episode 43: Native-Cloud Visibility and Security With Kris Nova, Chief Open Source Advocate at Sysdig first appeared on Open Source Underdogs.

    0 min
  • Episode 42: EnterpriseDB, Collaborating with the community to make Postgres enterprise ready, with Ed Boyajian, CEO

    Ed Boyajian, CEO joined EnterpriseDB and helped it pivot from a small organization, to one of the leading Postgres database companies. The company has figured out how to run a profitable business, while embracing and respecting the community and open development process that has formed around Postres for more then two decades.

    Intro


    Michael Schwartz:  Hello, and welcome to the first episode of Open Source Underdogs in 2020. I’m your host Mike Schwartz, and this is episode 42 with Ed Boyajian, CEO of EnterpriseDB.

    This episode was

    recorded last year, it took me a while to get it out due to some technical
    challenges. Let’s just say the internet Gods conspired against me the day I
    recorded this episode, and I had to finish recording on Zoom, which is
    fantastic for meetings but not ideal for podcast. So, if you hear a slight
    audio quality difference towards the end, that’s the reason.

    After the episode, I

    have an announcement about what you can expect this year from The Underdogs podcast.
    We have a new challenge, but I think you’ll be excited to hear about it.

    So, make sure you tune

    in after the main event.

    Ed is definitely one of the superstars of open source business. I got a lot of great insights from this interview. And I feel like I only scratched the surface, we might have to have him back for a follow-up.

    But, without further ado, here we go. Ed, thank

    you so much for joining the podcast today.

    Ed Boyajian:  Hi, Mike, I’m glad to be here.

    First Priorities

    Michael Schwartz:  What was the EnterpriseDB product when you joined a CEO, and

    what were your first priority to transform the business?

    Ed Boyajian: I came to EDP in 2018, and the company had been founded a few

    years before that, in 2005. The original thesis for the company was centered on
    helping customers solve problems they were having with Oracle. And even then,
    there was well-known pain around locking that was associated with Oracle and EDB,
    that is origination, and had developed some technology to make compatibility
    with Oracle, kind of the flagship technology, such that it was easy to migrate
    applications, written to run on Oracle, to run those on a Postgres database.

    So, when I joined the company, that was kind of the center point of the business. And a company at that time was more prominently known as the Oracle compatible database company. My focus when I joined was to really shift that and center it much more squarely on it, being a Postgres database company.

    Pivoting Challenges

    Michael Schwartz: What were some of the biggest challenges you faced when you joined

    a CEO to pivot the business?

    Ed Boyajian:  I think, like many companies

    that have to face change, the core engineering focus of the business, being on
    Oracle compatibility more so than Postgres, meant that there had to be a shift
    in mindset, and to get people to really reorient around prioritizing Postgres
    and our competencies in the database platform itself, as the priority for the
    company.

    And having come from Red Hat, I’ve been there for almost seven years and had some experience obviously around open-source projects, and working with open-source communities, I think that was an important change for the company to really think about what it meant to be participants and contributors to a project like Postgres.

    Relationship with Postgres Community

    Michael Schwartz: Did the Postgres community welcome EnterpriseDB? How would you describe

    your relationship with the community?

    Ed Boyajian:  I think that the Postgres

    community was and is very welcoming of contributions from outside, and to that
    end, and at that time, very, very welcoming to EDB in our contributions.

    I think the company had done work with Postgres

    previously, but in the intervening time, we’ve invested in a number of people,
    who’ve come to the company, that are key contributors to the community. So
    that’s been a real strength.

    Postgres, like Linux, as you may know, is an

    independent open-source community. It’s not one that’s controlled by a company.
    I think that’s inherently the strength of the community. And I think, given the
    longevity of the Postgres community and the nature of governance, the Postgres is
    governed by a core team of folks that manage the whole project – there’s no
    single individual who’s responsible. I think that is also structurally aligned well
    to encourage contributions from companies like EDB.

    Open Source V. Open Core?

    Michael Schwartz:  Cloudera and Chef recently went from open core

    to 100% open source. Of course, you’re familiar with Red Hat that has a similar
    model – do you think that open-source vendors are moving away from open core?

    Ed Boyajian:  I see generally that being

    true, although many companies, including EDB, do work on the periphery, around
    the core, open-source project. We do that in the form of tools and extensions
    that aren’t specifically in the database server itself, and we do those
    projects outside of the core community.

    I think a lot of companies, including Red Hat,

    do work in similar fashion, but generally speaking, I think there’s a great
    advantage to being prominent, an active contributor to project. And I think
    most of the commercial companies associated with open-source projects have
    recognized that value.

    EDB Value Prop

    Michael Schwartz: Speaking of value, what are some of the most important value propositions for EnterpriseDB?

    Ed Boyajian: I think there really a

    couple that we focus on, and I think that means most to our customers. The
    first is around customer obsession, but it’s customer obsession set entirely in
    the context of Postgres.

    And to kind of put

    another lens on it, I think it would be fair to say Postgres One. That enterprises
    and governments all over the world have made Postgres a standard database
    that’s now part of their strategy.

    EDB was central in

    creating that when in the market, and because of that I think, we’re uniquely
    positioned, with our exclusive focus on Postgres, to provide a level of care
    for customers that no one else in the market can do at this stage. I think
    that’s one.

    The second is Postgres

    technical differentiation. And for EDB that manifests in a couple of ways.
    Primarily in our contributions to the community, where we’ve led advancements
    in the core Postgres database platform for many of our customers, parallel
    query, projects like zheap, and other projects, where there’s a meaningful
    amount of heavy lifting, we’ve been the primary contributors to much of that
    work.

    The second area where we

    create technical distinction is what I mentioned earlier in the enhancements,
    that we make kind of around the database server itself. And some of them touch
    the database server like Oracle compatibility, which many of our customers
    still value from EDB, but beyond that, doing work in the areas that enable Postgres
    to be deployed at scale have been really important.

    You can think about that in the context of replication, or failover, enterprise-class management, and monitoring – all the things that any enterprise would need to run a database at scale.

    EDB Products

    Michael Schwartz: How many EnterpriseDB products are there today? And which

    are most important from a revenue perspective?

    Ed Boyajian: So, predominately, we think of it as essentially being one

    primary product we called the EDB Postgres platform. Within that, there are two
    database server options: one is the pure community edition, the second is that
    version of the database server that’s enhanced with the work we’ve done in
    Oracle compatibility, and in a few other areas.

    We bundle with the tools that I described earlier, such that our customers don’t have to pay for a separate skewer line item for the pieces and parts they need to make the database run. And that’s notably different than the traditional enterprise vendors in the market.

    Pricing

    Michael Schwartz: Ed, pricing is really

    hard for startups – do you have any advice on how to find the right gates, or
    how to set the right price, or how to evolve pricing as the business
    environment changes?

    Ed Boyajian: That’s a great question. It is a part of the strategy that’s

    evolved over time. In the early stages, as we started to develop some of those
    capabilities around the database server itself, we attempted to monetize those
    as parts.

    And we found that that was particularly

    complicated largely because customers were turning, the Posgres were turning
    away from complex, contractual arrangements and complex, buying systems they
    have with Oracle and other commercial vendors.

    So, I think our first attempt at that we got

    wrong, by putting that into a bundle, it also created the dilemma of figuring
    out how to price that sufficiently, such that we didn’t over-price. Because we
    had a lot of extra development, and IP, and value-add on the one hand, but on
    the other hand, kept things simple.

    We, over the years, have been really tuned in

    kind of creating price points that are appropriate for customers. And I would
    say, it’s evolved even more recently as we’ve done more extensive work in areas
    of the product, particularly with replication for example, where that alone has
    become valuable. Some of our customers want that almost exclusively.

    So, we’re starting to rethink how we approach that pricing modeling, and looking at stratification of our product line. And I think what we will see going forward is some additional skews that allows to kind of address different levels in the market.

    Market Segmentation

    Michael Schwartz: Data persistence is a horizontal market – do you segment the

    market at all?

    Ed Boyajian: Generally speaking, we don’t. And I think if you look at

    database, and just recognize a database is an infrastructure software, it is
    incredibly prolific across enterprise environments. I think if you look a
    little more closely in on database, if you look at the database like Postgres, which
    is a true, general purpose, transactional database, it has even broader horizontal
    applicability enterprise.

    It is compared to some of the specialty database

    technologies that are in the market today. So, given that nature that it
    touches every application, it touches every department, it touches every
    developer, you know, we’re mindful that our opportunity is equally distributed,
    both in terms of within an organization, and then across industries and
    segments.

    Now, having said that, we’ve seen centers

    massive for the business that have been prominent. And, so, we do some
    specialized marketing to those categories, and the ones that are most
    significant infotech, which is software and hardware technology. We have a
    biggest sub segment of our business government is much as a quarter of our business
    today, financial services, another really important vertical for the company,
    and then media, and telecom.

    Those four segments would represent 90% of our

    business. We do Orion, some of our messaging and solutioning around those
    segments. And then split it other way, we are a global company with more than
    half of our business coming from outside the United States.

    Interestingly, that split about 30% in APJ, 20% Amia, and the rest in North America. So, we also, in that context, do segmentation that is more geo-oriented.

    Partner Strategy

    Michael Schwartz: I’ve noticed that EnterpriseDB has really great partner network – what are the different types of partnerships that are important for EnterpriseDB?

    Ed Boyajian: Yeah, it’s been an important part of our growth strategy. and I

    can only put it in context, we’ve had now 39 consecutive quarters of subscription
    revenue growth. And if you looked inside of that, that’s come largely because
    of a diverse network of go-to-market strategy than partnerships.

    About 65% of our business comes through indirect

    channels, and so, we categorize that in the kind of classic form, distributor, reseller
    market, which is probably clearly the most prominent go- to-market route for us
    outside of North America.

    We rely heavily on distributors and resellers,

    in both of Amia amd APJ, so, that’s a particularly mature and growing part of
    the business, in one that we prioritize.

    Beyond that, we look at a network of partners

    who provide some other form of value out. We may try to call them, coin them OEM
    – they are not literally OEM partners, in one form or another. Or technology
    partners that bring EDB products to market, somewhat different than a
    distributor.

    A notable one that we just announced this past

    year, late in the year, was our partnership with IBM, in close alignment with
    their data and AI teams, and where we bring our products to market. In close
    alignment with IBM Solutions, particularly around their cloud pack for data,
    for example.

    So, that’s an example of a prominent partner

    that brings us to market. We see other examples of that, where we’ve developed
    strong alliances.

    I think another notable one is Infosys, where, again, particularly in their new application development practice bring EDB and Postgres to their clients, as they do, to work there.

    Partnership Prioritization

    Michael Schwartz: Over the years, have you developed any rules of thumb, as to

    which partnerships to develop?

    Ed Boyajian: I think there are partners who have a clear vision and agenda

    that relates to open source, and then, to go a step further, have gone beyond
    that and really defined Postgres as a part of that strategy.

    Those, not surprisingly, are high-priority

    partner targets for us. And that actually exists across the continuum we’ve
    seen in the distributor and reseller world. We’ve seen partnerships evolve and emerge
    that were specifically focused with a partner specifically focused on bringing
    Postgres solution to market.

    Even our recent partnership with IBM, for example, or our partnership with Infosys, our partnership that we announced last year with Ali Baba – all were centered on their vision to bring a Postgres solution to market.

    Sales Organization

    Michael Schwartz: Building a global sales organization is a huge challenge – how

    did you go about transforming the sales organization when you joined
    EnterpriseDB?

    Ed Boyajian: It was a really interesting challenge because I had just come

    from Red Hat, where when I joined Red Hat, the company was maybe 50 million, and
    I ran the North America business at the time of my departure, which was
    approaching a 250-300-million-dollar business. So, I had the opportunity to live
    through an extraordinary amount of growth in a sales model around open source.

    When I came to EDB, the company was tiny by

    comparison, and there wasn’t a firmly establish sales pattern. So, one of the
    things that we started to do was, really focus on being efficient in acquiring
    customers. And I think it’s an important distinction, especially for this
    audience, rather than plow big money into what I think of is high-end enterprise
    raps, we started with inside sales motion that toggled around software downloads
    and incrementing sales spend at a relatively small rate, until we got to higher
    levels of a value with customers. And really built from what I consider really
    basic selling model out.

    And that proved to be incredibly powerful because we got quite good at addressing customers. Frankly, in the way that I think they prefer inner set companies nowadays.

    Modern Sales Strategy

    Michael Schwartz:  The enterprise software markets changed a lot in the last 15 years – can you talk about how you think vendors of open-source software should adjust their sales strategy for 2020?

    Ed Boyajian: I think you have to look first at what’s changed in the landscape

    of IT consumption, and how buyers are forming inside companies. If you look in a
    little closer, first I think the commoditization of compute has allowed users
    across the enterprise to emerge, and you couple that with the way development is
    happening now more outside of IT, and more in the business unit.

    The pattern of adoption for technologies has

    changed, its not centered on IT. So, I think the old strategies that we used to
    use in growing a global sales organization, to bring in relatively expensive
    high-end sellers, to engage with a relatively finite number of buyers has
    fundamentally changed.

    The other thing that’s changed alongside that is,

    customers and users consume a tremendous amount of information on their
    journey. In fact, they’re heavily in self-service mode in their learning about technology
    or company.

    And, here, again, I think an easy mistake to make

    in a go-to-market model, in an inefficient, go-to-market model is to think that
    you need to fill that blank in with staff, or we might think of it as high-end
    salespeople, but rather to build the systems that allow users and prospective
    customers to self-serve as far as possible, which is their preferred method of
    engagement nowadays.

    So, my view of that has changed radically over

    the course of the past 20 years, in terms of how to build and structure the
    right kind of selling motions and sales organization.

    Impact Of Cloud Computing

    Michael Schwartz: As you know, enterprises are moving to the Cloud for many

    services, but as an enterprise software vendor, on-premise, or hybrid cloud, is
    still critical for growth. Is the move to the cloud accelerating? Has it
    peaked? And any advice for open-source software vendors on how to align with this
    trend?

    Ed Boyajian:  Well, I would say that the

    move to Cloud is accelerating. It’s hard to argue that, but I think, at least
    from what we see now, companies are starting to kind of settle in on enterprise
    strategies for how they deployed technologies.

    Cloud is another important deployment platform,

    just as traditional on-prem deployments are an important deployment platform. And
    I think it’s easy to get caught in this kind of notion that there will be no tech
    deployed in what we may think of today as traditional contacts – we just don’t
    see that as a reality.

    I think the difference for companies that are

    building businesses to think about what are the key technology capabilities
    that you have to develop to enable your customers to deploy in any environment
    of their choice – that’s how we’re focusing on this change. And we can’t avoid
    the reality that 70%, 80% of our customers deploy in traditional on-prem
    environments.

    Now, those environments are becoming more cloud-like

    in the way they’re being deployed on containers, certainly in virtualized environments.

    But, at the end of the day, our customers’ view, and we with them, view Cloud as a another very important deployment platform, but it’s just another deployment platform.

    Cloud Strip Mining

    Michael Schwartz:  Amazon and other mega

    clouds are offering RDBMS as a service, and many in the industry are
    understandably concerned about Mega Cloud providers moving up in the
    applications stack. As someone who’s experienced this firsthand, do you think
    it’s a good or bad for your business?

    Ed Boyajian: Look, we have many of our customers deploy databases in the

    Cloud, so they have to separate maybe two things. I think it’s very valuable to
    have Cloud computing as a utility and as a deployment platform for enterprise
    customers that makes compute more accessible.

    I think it gives a lot of businesses, a lot of flexibility

    that they can’t get in traditional deployments. In that context, I think that the
    deployment of databases in Cloud is healthy for enterprises.

    I think this question of whether or not Amazon

    being prominent in offering as a prime vendor of those database services, it
    intersects that, but I think most broadly speaking, I think the availability of
    Cloud services is a good thing, for companies like EDB, and for other open-source
    companies.

    Advice For Entrepreneurs

    Michael Schwartz: Last question, any advice for new entrepreneurs who are launching

    a business around an open-source software product?

    Ed Boyajian: I guess I’d give maybe a couple of thoughts. One is, make sure

    that what you’re thinking about is where you want to take your business that
    you have – a credible, commercial vision for what you intend to do with the
    technology.

    And I think that starts with really being

    clear-minded about the needs that are being served, and defining that in the
    context of target markets, and being thoughtful about the kind of business
    model you designed to serve that market.

    I think it’s easy in open-source technologies to,

    at some level, get caught up in the enthusiasm that goes along with the
    projects. But I think building a business around that takes surprisingly a
    remarkable amount of thoughtfulness and discipline.

    Michael Schwartz:  Ed, thank you so much

    for making time to talk to us today.

    Ed Boyajian:  It was my pleasure – thank

    you.

    Michael Schwartz:  And thank you to the EDB team for logistical support.

    Closing

    Michael Schwartz: Transcription and episode audio can be found on opensourceunderdog.com. Music from Broke For Free and Chris Zabriskie. Transcription by Marina Andjelkovic.

    Now, as promised, a special announcement time:

    for those of you who’ve listened to all the podcast, you might have noticed a
    preponderance of male voices. In fact, the male to female guest ratio is 42:1. The
    only female guest we scheduled was Jamie Thompson, way back in episode 2.

    So, this year, we’re going to hear from more

    women who are leading pure-play, open-source startups. After this episode in
    fact, for the rest of 2020, it’s going to be all women.

    To start things off, we have Deborah Bryant, Senior Director of the Open Source Program Office at Red Hat.

    I had heard her given a presentation at the Open

    Core Summit last year, and I’m still repeating some of those things that she
    said. We’re filling out the schedule. If you know of any great open-source business
    leaders who are women, please let us know.

    You can tweet at us using @fosspodcast, or you can send me a message on LinkedIn. Just mention that you’re a listener, and I’ll be happy to accept your connection.

    The next episode will be out towards the end of

    February, and then you can expect episodes about once a month this year.

    So, thanks for listening, and best of luck with

    your open-source business models in 2020.


    The post Episode 42: EnterpriseDB, Collaborating with the community to make Postgres enterprise ready, with Ed Boyajian, CEO first appeared on Open Source Underdogs.

    0 min
  • Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder

    Geoff Schmidt, CEO and Co-Founder of Apollo GraphQL, says you don’t get to pick your business model, you get to pick your problem. As part of the team who authored one of the most popular monolithic JavaScript rapid application development frameworks, MeteorJS, Geoff describes how they applied their experience to address an even bigger challenge–how to build more flexible backend data services.

    Intro

    Michael Schwartz: Welcome back, Underdogs. I’m your host, Mike Schwartz, and this is ep isode 41, with Geoff Schmidt, Co-founder and CEO of Apollo GraphQL. Geoff and his team have a gift for looking at the same problems we’re all looking at, and coming up with inspired solutions. After developing Meteor JS in 2011, they developed the Apollo GraphQL platform, which has coalesced and expanded its community in just a few years.

    Geoff has some tactical advice on how to engage

    with your community to build an amazing business. Apology in advance if there
    are a few audio blips on this episode.

    If you like the podcast, please help us get the word out. Like it on iTunes, or even tweet at a link on opensourceunderdogs.com. Our handle is @fosspodcast. Enough shameless self-promotion, let’s get on with the interview.

    Thank you so much for joining the podcast today.

    Geoff Schmidt: Of course, it’s a real pleasure.

    What Is GraphQL?

    Michael Schwartz:  What is GraphQL, and how does it relate to the Apollo GraphQL platform?

    Geoff Schmidt: GraphQL is kind of like a query language for the cloud. We’re in an interesting situation right now, where, if you go back 5 or 10 years, the way we built apps was really different. You might have a web server and a web server might connect to a database or two. And then, on the front end, you might have a web browser, maybe even a mobile app.

    But now, we’re in this situation that is a lot

    more complicated, where people are expecting more and more from applications. The
    applications have a lot more of a richer interactive experience, they do a lot
    more, they’re also available on more platforms, and at the same time the
    services in the cloud that back those apps got a lot more complicated too. It’s
    not just a web server and application server, it’s a whole bunch of different
    micro-services typically.

    And so, you’ve got this problem of, how do you

    connect all of those devices, all those apps and all that sophisticated
    functionality to all those services that exist in the cloud. And the old way of
    doing this was with REST APIs. REST APIs require that you write a bunch of
    custom code basically for every screen in your app, probably a new REST
    endpoint for every use case.

    And with GraphQL, it’s a flexible query language,

    so an app developer can ask for any combination of data that they need out of
    the cloud, and you don’t have to write custom code anymore, like you would with
    a REST API.

    So, one way of looking at it, it’s a better way for app developers to be able to query all the day that exist in the cloud, it’s a much better experience for the developer. Another way of looking at it is, it’s a way that an organization can build a connected map of all their data and services in the cloud, so you can have one central organizational source of truth of all those resources.

    And I think another way to look at it is, it’s almost like an abstraction layer for the cloud. It’s a way that you can, even as you are writing your applications, even as you are building your micro-services, you can keep like one consistent stable map, so that really gives you the ability to write a lot more apps, build a lot more cloud services, and evolve your all infrastructure really, in a flexible and more principled way, now that every app has an API inside of it.

    Origins

    Michael Schwartz: Can you walk us back to 2011. Meteor development is founded – where were you then, and how did you develop that into Apollo GraphQL?

    Geoff Schmidt: Sure. This whole journey started for us back in 2011, we were in one of the early Y Combinator batches back in summer 2011, and I was meeting a couple friends, and we had a lot of different ideas, but what we wanted to do is, when we got into Y Combinator, we discovered that all of the people in our Y Combinator batch were really struggling to solve the problems of modern app development.

    2011 was kind of a tipping point, when the world

    went free on rails with PHP as enough, to “Wait a second, now people have
    bigger expectations about the user experience, where they were trying to
    deliver that user experience.”

    So, what we decided to do is, me and my co-founders, Matt Debergalis and Nick Martin, we’d work on a variety of other projects together, each has been trying to build a different combination of apps, or open-source projects, or SaaS products, and we thought, “Can we take everything that we know about building modern applications and put it into a reusable framework?” That would help people build apps faster.
    That gave birth to Meteor JS, which we launched in early 2012. And it grew over the next couple of years to become one of the top 10 most startup projects on GitHub.

    When we launched Meteor 1.0 there were local media

    meetups, I think 134 cities around the world on the same day. So, we had big
    success with this monolithic JavaScript open-source app development framework. And
    we were able to build a profitable business on top of Meteor JS with Galaxy,
    which was a hosting platform for Meteor.

    But what we started to realize, as we got toward

    the end of 2015, there was a bigger opportunity, because we were finding that
    people wanted to connect Meteor, not just a MongoDB – which was the database that
    came in the box with Meteor – but they wanted to connect it to all sorts of
    different sources of data and services in the cloud.

    We also found that people wanted to build app

    experiences that were not just JavaScript in the web browser, but across any
    number of different mobile platforms, and increasingly, like all kinds of new
    stuff, these IoT platforms, all these things were happening.

    And we really said, “If we could take the technology

    inside Meteor or the ideas, architectural ideas inside Meteor, and put that in
    a form where you can use it not just for new applications like Meteor for any
    app, and you can connect it to any source of data in the cloud, not just a
    particular database, and you can push into many platforms, not like just one
    front-end, written in JavaScript, then, it would have an even broader
    applicability.

    The other thing we saw was that Enterprises were

    starting to adopt Meteor JS, and we were getting much more familiar with the
    needs that you see when you are building highly-scaled applications of
    Enterprises, not to scale in terms of how far the technology scales, but scale
    in terms of how you have larger code bases, larger teams. And so, that led to
    us starting to research like what would Meteor 2.0 would look like, what would
    the component to that be. We’d also seen the rise of react.

    And we’d seen that something like react, that’s

    incrementally adoptable, where instead of having to build a new application,
    you can add it to an existing application, quickly get up and run it, and
    quickly get some proof points – we saw how powerful that was for growth. So, we
    thought, “Can we build a new data layer for Meteor that takes everything we learn
    from the whole experience with Meteor that is a very powerful open-source
    project?”

    Everything we learned from Enterprise customers,

    everything we learned about the proliferation of back-end services in the cloud
    and new front-end that people wanted to use, and put it in an incrementally
    adoptable form. And that’s the end of 2015 I guess.

    And that’s when we heard about GraphQL. GraphQL

    was just what we needed to work on this new project, which is what we were calling
    the Apollo project, because Meteor has been so tied to MongoDB, whereas
    GraphQL, this whole idea is, it’s this database agnostic abstraction that lets
    you talk to any number of different databases or cloud services.

    We set it to take some of the core ideas or learnings from Meteor, make it speak GraphQL as a query language, build something that is very easy for people to drop into existing applications. And then, we started launching the first Apollo open-source component in early 2016, and it’s been really amazing couple of years as more and more people adopted this technology. I think it’s really exceeded any expectation we had for it back in 2016.

    Sales

    Michael Schwartz: Can you talk a little bit about how your sales processes have evolved, because I would imagine initially there was a lot of organic inbound Enterprises saying, “Okay, we want to use this software, but over time, how has that changed and adapted to the demand?”

    Geoff Schmidt: I think we have seen a trajectory that’s pretty typical in the sense, yeah, to your point. Some of our first customers were people that were already very sophisticated users, very sophisticated early adopters, who were using Apollo at scale in the Enterprise, as well as people maybe who were small, midsized businesses but had a strong vision for what they wanted to do, and they wanted to get a technology partner for their vision.

    Some of those first customers, there were

    various things that we helped them with, but in a lot of cases, it was the
    relationship with us, maybe some code development on the open source, us carrying
    the pager for their assistance maybe.

    There’s a couple of different ways those things were

    structured, but what happened was, more and more of our businesses shifted
    toward the additional tools and services that we were able to provide around
    the core Apollo Client, Apollo Server open-source offering.

    We have a product called Apollo Graph Manager.

    Graph Manager is essentially the control plane for a data graph, so, we have Apollo
    Client, Apollo Server. It’s basically the date plane, it’s the stuff that goes
    in your data center to answer queries, the stuff that can’t go down, stuff that
    handles all of your personal data, all your sensitive business data.

    But what we found is both as companies scaled the Graph, they go from just a couple developers to 10 developers, to 100 developers, to 1000 developers. There is a lot of additional management tool that you want. There’s also a bunch of architectural best practices that are really helpful. It’s really helpful to put your Graph schema in a schema server, have a central source of truth for the structure of your Graph, how it is changing over time, build workflows, and processes, and governments around that.


    At the same time, one of the best parts of the Graph tool is the tooling that’s possible around it. And that tooling is super valuable very early in the development process as well. And so, the SaaS services we built that are essentially souped-up set of developer tools, and even more so, a control plane for a scaled enterprise data graph.

    That’s all packaged up in a SaaS service we call

    Graph Manager. More and more of our business now is Graph Manager. And what
    we’ve done is, we’ve created both an Enterprise offering around Graph Manager
    that comes with the full 24/7/365 SLA for the whole Apollo platform, covering
    all the open source, all the SaaS, as well as our support and expertise. As
    well as some like in Enterprise Edition of Graph Manager that has features like
    single sign-on, some of the things that are Enterprise specific requirements.

    As well as having, we go all the way down to a $49

    per seat per month offering that anyone can buy online with a credit card
    because you want the support through the whole development cycle.

    And we also have a freemium offering. If you

    just want the developer tools for the earliest stage of development process, you
    can use it for free. We’ve really tried to understand what the entire user
    journey is from the moment you write the first line of code and start exploring
    GraphQL, all the way through to when you have a scaled graph in an Enterprise –
    it’s the strategic asset.

    We tried to understand how people want to buy and how people want to partner with us at each of those stages. And it’s an ongoing process, but we’re building our packaging around that user journey to try to accommodate each stage in the journey.

    Revenue
    Streams

    Michael Schwartz: What would you say the current breakdown is of SaaS vs. license revenue? Which part of the business is more important today from a revenue perspective?

    Geoff Schmidt: I think there’s some open-source companies where the service offering is a bolt-on, like maybe it’s a nice to have. But it’s not really that critical. Or, in some cases, something was included primarily just to drive renewals. That’s not the case for us. We find that the Graph Manager, the SaaS tools are very important to people as they scale, and also are something that people really value early in the process.

    I would say that almost every customer is using some form of the SaaS tools. Now, in terms of what’s the breakdown of revenue versus people are purchasing online versus people are purchasing more Enterprise subscriptions, Enterprise subscriptions are a big part of the revenue. Right now, from a customer count point of view, it is more online purchases, but most people are using some form of the Graph Manager, though there are exceptions to that.

    How To Align With The JavaScript World?

    Michael Schwartz: JavaScript is the largest community. Do you have any insights on how other open-source companies can align with the JavaScript world?

    Geoff Schmidt: JavaScript is really about the rise of app developers, and it’s about the rise of accessible app development. It’s one of the easiest languages to learn, and there is a huge amount of demand for more sophisticated websites built in JavaScript. A lot of what drives the rise in the JavaScript is, there’s this whole world of apps that are written on kind of this LAMP stack derivative frameworks that date back to, in some case, the nineties, like PHP, Ruby on Rails, ASP. Net, Spring. Like the LAMP stack approach to building applications.

    And what’s going on right now is, a lot of these apps that were written on those frameworks are getting re-platformed onto a more modern app data stack that includes React Apollo, some of these other components are going to be building a modern experience. I think that the way to think about how you align with JavaScript is to think about how you align without movement toward like modern app development. The thing is, most of the time when a company is going through that transition with a re-platforming, it’s part of a larger modernization effort.

    They are often evaluating other technologies too,

    and they are thinking about, “Hey, is this a time for bringing Kubernetes?” Or,
    “Is this a time for bringing a different version of mobile development?” Is
    this a time to go to different platforms?” I think like every offering’s going
    to be different, you either have an axis with modern app development, or you
    don’t. If you do have an axis with modern app development.

    I think it’s really important to understand like the JavaScript constituency is going to be one of your biggest users if you can understand really what their pain points are.

    It’s very driven by community. I think front-end app developers, by nature, they value design, they value community, there’s a really great community there, they are collaborative and positive, community that is more diverse than Symantec, it’s more accessible than Symantec.

    Making an investment in how you meet that

    community where it is, understand what the values of that community are, and maybe
    build some relationships with the leaders in that community, I think can really
    help you reach those app developers.

    The other thing that’s important is to

    understand that it’s a community that cares a whole lot about user experience,
    maybe more so than some other communities. It’s what you do every day is an app
    developer, you think about how you deliver great user experience to users. It
    tends to be people that value good user experience.

    I think those are some of the values of the community that can help you get more mindshare more quickly if you do have a product that is related to modern app development.

    Benefits Of Open Source

    Michael Schwartz: Has the open-sourcing of the code materially benefited the company?

    Pricing

    Geoff Schmidt: Absolutely. Apollo would not exist today if we were not open-source. I don’t think there would have been anyone to do this, other than as permissively licensed set of open-source libraries.

    Michael Schwartz: You were mentioning pricing before, and actually I think pricing is really hard for Enterprise startups. In your industry, it sounded like you had a logical gating mechanism, like you mentioned number of developers. Do you have any advice – going from 2011 to today – any advice on how do you find the right price and the right gates for your software?

    Geoff Schmidt: Well, it was a journey for us to get here. We originally priced based on query volume, so the number of operations that you performed on your graph. And the reason we went that direction is, we thought of it as utility, like AWS. And we thought, “How cool it would be if you had a very predictable, very simple way of understanding, “Hey, here’s what my costs are going to be.” If you told like electricity, or water or cloud computing. And we thought that was a model that everyone was really familiar with, that would feel like a natural way to purchase infrastructure like a data graph platform.

    What we learned was that query volume pricing

    wasn’t very well aligned, either with how people wanted to buy and budget for
    technology in this case. And also that wasn’t very well aligned with the value
    that we were providing.

    We had customers that were doing maybe billions

    of queries a month with a small team, and we had customers that were doing maybe
    millions of queries a month with a much larger team, for like maybe an even
    more valuable line of business.

    Like the business I associate with the query is

    so different across maybe a B2C app that is like mostly freemium, versus an
    internal line of business application. So, that lack of value alignment, which
    kind of manifested it as the platform would get way too expensive, way too
    quickly for some people, whereas other people that were driving a lot of revenue
    from the product and getting a lot of value were very happy with, they might
    only be paying $2 a month.

    It manifested as a churn of some of our largest

    customers as the query volume pricing just got unaffordable. It manifested as a
    lot of people who had to contact sales to better understand the pricing. It
    also manifested as longer sales cycles because it meant that we were forcing
    people to predict their usage of the Graph far into the future, because if
    you’re going to adopt this like core piece of infrastructure, you really want
    to have a good way to understand what your costs are going to be.

    If you are looking at this thing and you are

    thinking, “Man, this is probably going to expand to be all of my app
    development and all of my traffic.” And especially if it’s a new technology,
    where you don’t necessarily know the estimate, how many queries are going to be
    doing, like how many react components might use this, how many queries might
    each one do, that’s really scary, and it slows adoption and lengthens the sale
    cycle.

    So, what we did was, we listened to customers to

    understand what’s the most easy and natural way for them to buy what just feels
    like a great experience for them. And what we found was, at the early stage of
    the journey, especially if you’re doing a self-service purchase online, or if
    you are an internal manager that is just buying it for your team, thinking
    about it as developer productivity, see pricing is A very natural and easy way
    to understand it because it’s proportional to the investment you’re making and
    developing your application proportional to your team size.

    It’s also pretty easy to predict and plan, and you

    could plan it alongside your other cost. And as we get into some of the enterprise
    tiers, there’s a platform fee as well, which is based on sort of the overall
    intensity of use of the graph, which is a couple of axes.

    Query Volume is an axis there, but it’s only one

    of several axes that we used to understand, like, “Hey is this an individual
    team?” Maybe it’s a whole business unit, maybe it’s a whole much larger company
    that’s all family different brands. We found it really startling with an
    understanding of how people want to buy and aiming to serve the customer,
    rather than saying, “What do we think our users might want?” Or saying, “What’s
    the easiest way to plan our business?” was really, I think for us the master
    key in fighting the right pricing.

    Pricing Process

    Michael Schwartz: To get you to your new pricing model – did you appoint somebody who is heading up that task, and who made the final decision around what to charge?

    Geoff Schmidt: It was my co-founder who’s also our head of product. It was a process that involved many people in our team, many customer conversations, listening to what we were hearing from the sales team, listening to what we were hearing on the developer relations on open-source side. A lot of conversation inside the team, and ultimately, it’s one of the decisions that is hard to change, that you don’t want to be constantly changing your pricing, at least your pricing axes. At some point, you have to gather information you can, and make a decision to commit to it, and take it from there.

    Open Core?

    Michael Schwartz: Would you say that you are open core?

    Geoff Schmidt: I would describe us as a complementary product model, so we have our open source. And right now, we don’t hold anything back on the open source. Could there be open core Enterprise features in the future? Yeah, maybe. And we’ve heard some requests that it might be a good fit for that model.

    But currently, open source is just open source,

    but what we offer is a SaaS service on top of that. I think of it as a
    complementary product. The way I think about that from a business point of view,
    if I think about advice I give open-source entrepreneurs, I think your business
    model as an open-source company is not necessarily something you can force. Like,
    I don’t think you get to pick your business model, I think it’s more like you
    get to pick your problems, like pick what you are building. And then, that will
    have a natural business model associated with it.

    I think that there are some things that are open

    source that are just really hard to monetize. There’s a lot of things that are
    100% in a view layer on the front-end, there’s just not a natural way to
    monetize that. These things, their ultimate destiny, at least I think for the
    foreseeable future, and in a lot of cases, they are just going to be open-source
    libraries.

    There’s other things that can really naturally

    be monetized by selling supportive services from day one. There’s other things,
    like get offering in an open-core model.

    There’s other things that very naturally can be

    monetized by saying, “Hey, I have some open source.”, but any using this open
    source, many of them will want the SaaS service. I think Git and GitHub is a
    great example of that.

    I think you have to start with what the natural

    structure of your solution is, and ask, “What are the pieces of this that your
    users would like to be commercial?” And, “What are the pieces of this that your
    users would like to be open source?”

    And follow what really does right for the user in order to find out that right model. I think if you try to go the other way and say, “I’m going to try to force particular business model on this because that’s my strategy.”, I think you’ll end up creating worse experience for the user. And I just think that the world we are in with dev tools and the internet today, there are so many opportunities. I think you’re going to see competition that correctly shapes product, I think it is going to win with the correctly shaped business model.

    Is There Amazon GraphQL?

    Michael Schwartz: Is there an Amazon GraphQL hosted service similar to what you’re offering?

    Geoff Schmidt: Amazon does have a GraphQL offering called App Sync. App Sync is more focused on mobile development, and it’s more focused on getting mobile developers a great way to access all the data and resources they have inside Amazon. It’s a little bit more of a back-end as a service. Maybe that’s not a quite right way to study because it can do so much more inside Amazon.

    That’s different from what Apollo is, which is

    focused on integrating many different data sources in the cloud as some of you
    can incrementally adopt. You can add Apollo to any existing application or
    stack, whereas App Sync is designed a little bit more for new application
    development typically, so they’re actually complementary.

    It makes a lot of sense to say, “Apollo is my

    data graph integration layer, and then maybe I could have App Sync with some of
    my back-end services. With technology like Apollo Federation, they are good
    frameworks for how we can think about federating multiple GraphQL services
    together to build one graph.

    Some of the details that are still being worked out because a lot of this is a new technology. But, conceptually, I see them as complementary products rather than competitive.

    Would Amazon GraphQL Be Good Or Bad?

    Michael Schwartz:  Let’s just say that Amazon takes the Apollo open-source server and lunches Amazon Apollo server service – would you view that as a positive or a negative?

    Geoff Schmidt: I think the more the merrier. I would love to see more people running Apollo server on Amazon. And if Amazon helps them out, that’s great. We’re focused more on how you scale the graph, and that has a lot more to do with workflows, and the control plane, and a schema registry, a bunch of other things that are like really different from a SaaS offering, and really different from Apollo Server and Apollo Client.

    I think the more people are building services on top of GraphQL, and the more GraphQL grows, the more people are going to need solutions for managing large GraphQL, like Apollo Graph Manager. But I think it’s a positive for us potentially.

    Open Source V. Commercial

    Michael Schwartz:  Do you ever feel any friction between, when you’re introducing a new tool, and between should this be open source, or should this be commercial? And how do you decide which way to go?

    Geoff Schmidt: For us, we have a pretty bright-line. We start with, “Does this naturally exist inside the SaaS offering or does it just naturally exist inside the open source?” And I think that’s been a really reliable benchmark for us.

    On some level, that’s just a technological fact,

    like where to go, where to live, in our case, because we have a SaaS model
    instead of being open core currently, but I think there’s some things that we
    learn along the way that I can talk about.

    I think one of the core ideas is, companies who

    want to own their data graph, this is a very important investment for them. And
    they don’t want to feel beholden to an outside vendor, just for the continued
    existence of that, and maintenance of that thing.

    At the same time, they also want to see strong

    vendors with viable business models because they want to know if there’s going
    to be somebody there to support them. I think your challenge as a vendor is
    helping craft that right relationship with your customer, so they feel comfortable
    and secure.

    And they trust both of it, you’re not going to be in a position with too much power over them, but at the same time that they trust that you’re going to be around. It’s very rational considerations that customers have when they’re selecting a solution like this. And downstream from that, focus on customer trust, and just really trying to understand what would you want if you were that Enterprise that was purchasing the software, or adopting that solution whether it’s open-source or commercial.

    I think that some of the principles we found are

    what’s inside owning your graph, controlling your graph, it’s important that
    people own the entire data plane, so everything from when the request comes in
    all the way through to when it’s answered by your services and the responses stitched
    together and sent back down to the client.

    You want to feel like you’re in control of the

    uptime of that. You want to feel like you’re in control of the security and the
    privacy associated with that. You want to feel like if there’s ever an issue,
    you can look under the hood, read the code, understand what’s going on, and fix
    it without necessarily waiting for round trip from vendor, at the same time, as
    you want to have the vendor on a 24/7/365 pager rotation for you.

    So, when we think about the features that relate to keeping your system secure, and private, and up, to me those are the things that have to be open source. When you think about the things that relate to how we manage the workflows and processes around it, where maybe it is tolerable for some of those aspects to exist inside of a SaaS platform, and maybe it’s even better. Because you have a supplier that’s constantly keeping that up-to-date data adding new features.


    And it’s delivered as a managed service to you. Those are the places where I feel like the SaaS stuff fits really naturally. And so there’s some nuance and complexity there about how we’ve been sharing that. So, for example, one of the things that Graph Manager can do is, it can manage the deployment of your Apollo gateway instances. If you are using Apollo Federation to manage the whole constellation or fleet of these different GraphQL back-end services in a federated architecture.

    So, to do that, what we do is we push Graph Manager

    push the configuration that those Apollo gateway servers are going to need to pick
    up into a highly-available, global distributed CDN.

    That way, we are doing the analysis of how is

    this going to affect my uptime to have this dependency on this other component.

    You can see even if Graph Manager goes down for 30 seconds, it’s not going to affect my ability to scale up and down my servers, because we’ve found a solution like the CDN to ensure really high uptime for our services.

    GraphQL Foundation

    Michael Schwartz:  Last year, you announced the GraphQL foundation, I’m wondering is that self-sustaining, and what role the foundation is playing in the ecosystem?

    Geoff Schmidt: The GraphQL foundation, that was put together by us together with Facebook, and the Linux foundation, and a few other great founding partners coming from Facebook, the folks that originally wrote the GraphQL stack and created the GraphQL language.

    The foundation is self-sustaining, it is one of

    the auspices of the Linux Foundation. The way I see foundations, they are the
    keepers of the specification. It’s really important that a technology like
    GraphQL that we have a way in industry to evolve, going forward, while
    maintaining interoperability.

    I think in the early days of GraphQL, there were

    a lot of questions about the relationship between GraphQL and Facebook. There’s
    a lot of positives there because there’s a proof point about how GraphQL has
    powered applications at massive scale at Facebook for years. And I guess people
    have a lot of confidence that it’s a good, technological direction.

    At the same time, too much control by Facebook that isn’t the developer tools company I think was a little bit of a concern for some folks. And now that we have a foundation that can be the custodian to stack, I think that’s a development that’s given folks a lot of comfort and confidence.

    Changes In Enterprise Software Market?

    Michael Schwartz: The Enterprise software market has changed a lot in the last 10 to 20 years – can you talk about how you think vendors of open-source software should think about their strategy today?

    Geoff Schmidt: I think the key thing to understand first is, to the extent, how you are thinking about how you monetize your open source, who is the buyer, is the buyer going to be an end-user, in which case you probably have more of a bottoms-up motion, where it’s probably a product-led motion, where you’re focusing very much on the user’s first moment experience, and what the value proposition is for that first credit card swipe.

    And then maybe after that, thinking about what

    are the layers that drive and upsell the Enterprise possibly as the graph
    grows, and maybe what starts being used by multiple teams, or whatever your
    product is.

    There’s another approach that can also work well

    I think, where, if the buyer is more naturally maybe a leader inside the
    infrastructure team, or maybe another executive where it might make sense to
    enter around the 1500- $50,000 price point, where it’s more like a
    comprehensive Enterprise subscription offering.

    I think the thing to understand is what really is the adoption model of your software inside the customer, and understand is it really driven by end-users that want to purchase easily online, or is it driven more by the need to have a business relationship and a vendor relationship. And I think that ends being, in my point of view, the driver of how you build your go-to-market strategy.

    Advice For Open-Source Entrepreneurs

    Michael Schwartz:  Last question, any advice for new entrepreneurs, like the people who are starting this business around an open-source product, what advice would maybe you give yourself, if you could go back 10 years, or so, 9 years?

    Geoff Schmidt: It’s a good question. I guess I would say they’re not the easiest businesses to start but they’re some of the most rewarding. Because you get to hold an incredible community, and you get to touch a lot of people, you get to do it very quickly at internet scale. And I think one of the idea about doing open source right is, it’s about building a coalition. There are many different models about how you might structure contributions to your products that whether your project is more like a cathedral or more like a bazaar, what I think is very important is it be a coalition.

    In this era, you’re not going to succeed if you

    go at it alone. You’re going to succeed if you understand the larger set of
    communities, the larger set of other projects, and needs and customers and
    entrepreneurs that exist around you, and think, “How can I build a coalition to
    solve a problem that people really care about?”

    I think if you start from that point about the

    community you want to build and the problem you want to solve, it ends up being
    a more powerful starting point than, “Hey, what’s a really cool piece of
    technology I could build?”

    Michael Schwartz: I think that’s a really good advice.

    Geoff Schmidt: The other thing I’d say is, I think, through podcasts like Open Source Underdogs, I think it’s getting easier and easier to start these types of businesses.

    I think if you go back, even not that many years,

    a lot of the ways that you would build a business like this will really expect
    a little bit unknown, and that made things a lot harder.

    For example, can you find executives that

    already understand your business model, are there pre-stablished like marketing
    and sales playbooks that you can run, are there reference points that you can
    look at in terms of pricing and packaging to understand what’s worked and what
    hasn’t worked.

    Or even, is there a community for you as an

    entrepreneur, where you can meet some other folks that have been down this road
    and talk about your experiences – all those things have gotten a lot easier. It’s
    a model that is increasingly well understood. I think it’s not just the future
    but also the present at this point.

    I think it’s been really rewarding, it’s been a great experience for us, I think they can require some patience because in open-source business models, you have to succeed twice: first, you have to build the great open-source project for your technology, a great community around it, and then, you have to build a great business around that.


    But if you have the stamina to do it, not only are they some of the most rewarding business I think, and not only do you have this incredible tailwind behind you with your community and your supporters if you built a good coalition, but additionally, I think they have the potential to be some of the most capital efficient businesses, and have some of the best economics.

    Because if you structure your business right, you

    have some of the best parts of a B2C business on one side, where you able to have
    a big internet community, and a big group of supporters that will have your
    back, but with some of the B2B economics on the back end.

    You just have to do the work to understand what really is the right way to benefit your users and serve the community, because it is a business model, where you have to start from the point of view of stewardship, asking how you build a community, asking how you adopt the perspective of making the best use of the resources and position that has been entrusted to you in the community, but I think that’s really fun for people that are attracted to that.

    Closing

    Michael Schwartz:  I think those are really good advice, so, thank you so much for sharing.

    Geoff Schmidt: Of course.

    Michael Schwartz:  And thanks for the Apollo team for logistical support.

    Transcription and episode audio can be found on opensourceunderdogs.com. Music from Broke For Free and Chris Zabriskie.

    Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from

    William Lowe. Transcription by Marina Andjelkovic.

    The Twitter handle is @fosspodcast.

    Next week, for our final episode of the season, we have one of the true veterans of the industry, Ed Boyajian, CEO of EnterpriseDB. It’s going to be a special episode, so please, don’t miss it.

    Until then, thanks for listening.



    The post Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder first appeared on Open Source Underdogs.

    0 min

About Open Source Underdogs

From the publisher's feed

The podcast for entrepreneurs about open source software.