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.