Interview with Marco Palladino, Co-founder and CTO of Kong

Transcript

Ledge: Hey, Marco, great to have you on. Thanks for joining.

Marco: Thanks, Ledge. Thanks for the opportunity.

Ledge: Could you give a couple of minute intro – yourself, your work. I know you have an interesting story. I would like to get the audience to get to know you a little bit.

Marco: Sounds good. My name is Marco Palladino. I’m the CTO and co-founder of Kong. Before being the CTO and co-founder of Kong, I was the co-founder of another company called Mashape.

I did Mashape for a while, for a few years, then we had to pivot the organization into a different product, into a different direction. You know that happens all the time. So Kong was the result of that pivot.

Since then, Kong took off and so we’re now building the company and the business.

Ledge: All right. A lot to unpack there. So, talk about arrival at pivot. You talked about off mike that building a company, different country, raising money, now you’re in San Francisco. There’s got to be a story there. I mean, that’s not a thing that everybody does.

What was that like? Walk through just getting there.

Marco: It’s a very long story. It starts 10 years ago. Kong was released in 2015 but they’d been hearing this in San Francisco in the United States since 2009/2010. Everybody asks me, okay, but wait a second. If Kong was born in 2015, what did you do the prior five years to that?

The reality is that me and my co-founder were Italians, so we’re immigrants. We moved to San Francisco to start Mashape. Like every immigrant, we had to deal with the bureaucracy of visas, being able to stay here, and being a little bit of outsiders. So building a network was very important for us – and all of these things require a long time.

Finally, in 2012 we were able to release Mashape, the API marketplace, which ended up being the largest API marketplace in the world. We kept on improving Mashape until 2015 when basically we looked at each other and we realized that the product was great, there was lots of users coming in on the platform, but the business model was flawed. In short, we were making no money whatsoever. Which, as you know, is kind of problem when you’re trying to build a business and you raise money for building the business and so on.

So, in 2015 we decided, okay, this is not going anywhere, we’re running out of money, we have to find something else to do.

You know, as an immigrant, I felt that it was very hard for me and for my co-founder to kind of give up and start something new. Ideally, five years after trying to build something and it doesn’t work people just take some time off and they think carefully about what to build next, and then they just go ahead and do it. We couldn’t do that because our visas are tied to the organization. Basically, we cannot give up.

So we decided, okay, we have to do something here. How about we take our technology in the marketplace? The things that was running on our server that nobody could access, standalone , how about we take that and we open source it?

That was in 2015 when containers were out, microservices were a thing, Kubernetes was already out, and so on.

We took our technology, this API platform that was running all of these requests in the marketplace, and we decided to make it available on GitHub for everybody to download and use.

Since 2015, Kong found really a good niche in the market, a good product market fit, and just took off from there. It first took off in the open source space. Lots of downloads, lots of people, lots of contributors. Then it took off in the enterprise space.

It’s open core. We have like Elasticsearch, like Mongo, we have an enterprise version of Kong. So enterprise organizations that perhaps start with the open source version, they can then upgrade to the enterprise version if they need enterprise features.

Since then, we grew not only the open source adoption but the enterprise business as well. It’s been quite a journey and to be at this point it basically took 10 years.

Ledge: Yeah. It’s an overnight success, right?

Marco: Right.

Ledge: That journey that you discovered organically, were you able to draw off the experience of other open source companies who discovered the open core, but then sell the ecosystem of enterprise tools around it?

Obviously, everybody could point to Red Hat as the first company that probably did that really well. Who were the corollaries or other companies that you looked to to try to get your head around that? That’s a big leap to pivot there. You were building an entirely different organization.

Marco: That’s correct.

Ledge: I wonder, what did you think about there?

Marco: You’re right. In 2015 when we open sourced Kong there weren’t many examples of open source or open core companies creating a great business. I mean, there was Red Hat like you say, but that was kind of a one-off – and there were some new up and comers like Elasticsearch, Confluent, Kafka and so on.

You know, something happened in 2014/2013 in the industry, and that is the importance of open source as an enabler to a new way of building software.

When we’re looking at microservices, and we look at Docker, when we look at Kubernetes, when we look at all of the CNCF foundation and the landscape, we notice that the majority of those projects of those logos are available as an open source product.

Open source became the baseline for this innovation. The reason for that is that developers within the organizations which used to develop software in a top-down way, from a top-down motion that came from the directors, from the central IT perhaps, have broken their chains, so to speak, and now they are picking the right technologies for their products and they’re pushing them in production themselves.

It’s a bottom-up disruption. It’s a bottom-up adoption.

When we look at ecosystems like CNCF, what really that is is it’s a self-service ecosystem. That developers working in teams, close to the end customer, that have to create products, that have to deliver business value today, those are open source projects that these developers can just pick and choose and deploy in production by themselves.

This fundamentally really changed the way software is built because the center of excellence which used to be this platform team, this central IT team, it’s still there but now they’re playing catch-up. They are catching up to all the decisions the teams have made in the actual products. It’s the other way around. It’s bottom-up disruption.

Ledge: Sure. You have this sort of organizing combination of your DevOps toolchain types of efficiency mechanisms to make development work better because it’s been so democratized. There’s different centralization.

Then you’ve got your product functions which are organized around customer and develop… What are you going to build that people will actually pay for? You’re right. It flipped the basis of where the choices and autonomy are coming from, and organizations need to reimagine how they organize that, I guess is the way to put it there.

It’s the kind of thing where I think a lot of people feel good about this approach and business model. It’s probably not as easy to do as you would hope, because you only see the successful cases.

What advice would you have there for anyone who is setting out and saying, hey, that’s our business model. I think it’s a thing you can step into because necessity is the mother of invention, but without having had that pivot experience you maybe wouldn’t have done the things that you did.

Can you unpack that a little bit?

Marco: Yes. In 2015 when we open sourced Kong, all of this was already happening since a year or two. So we thought open source can be much bigger than what it used to be.

Red Hat, maybe it’s not a one-off. Maybe that can be replicated. Companies like Mongo, like I said, Elastic and Confluent, demonstrated that.

What I found really interesting back then was the human aspect of open source. You know, open source is not just about code, it’s about people. It’s about setting expectations with a community. It’s about creating a highway that allows the organizations or the maintainers to give back to the community, but also listen to the community. Create a highway that allows the community to be successful within the open source project.

This human aspect of open source, it’s so important because then it becomes a matter of expectations. As long as the expectations are set between the maintainers and the communities – like with life with friends or with a significant others, the human aspect is there. Then as long as those expectations are met, everything goes well.

When those expectations start to break down, because now we’re going to be closing source something that we always said is going to be open source, for example. Or we’re not going to be accepting contributions because that does not match our strategic vision, blah, blah, blah. That’s when the open source project becomes less open, and open source becomes like marketing checkbox. We’re open source because you can see the code, but not open source intended as there’s a two-way relationship here between us and the community.

Ledge: That’s a very careful line to walk. I have talked to developer representatives from all different types of companies that have said, yeah, there was this time that we made a decision and we really pissed off our core contributors, and we lost some of them.

I think that’s a thing that is terrifying in this model, but sometimes the community isn’t aligned to what… You do have a business mandate. You need to pay some people. You need to make some money. It’s not always a line there.

What things have you had to do to stay aligned with the community, keep that ethos, but also make choices that sometimes you need to say no?

Marco: That’s fine, as long as the ‘no’ happens within a context of integrity and honesty.

Ledge: What is that? How do you make a high integrity no?

Marco: I believe that even the open source users or open source contributors and maintainers, everybody in the open source space really understands that open source may be free to use, but it’s not free to build. So that’s an important consideration to be made.

But, for example, once something is open sourced, taking it back and away from the community – which is what many companies have done in the past because now they realize they open sourced something they shouldn’t really have open sourced – well, that’s a big no in my book. That breaks the expectations that what’s open source is already open source. It destroys that honestly and that relationship between the maintainers and the contributors.

Really, it’s about being plain honest, or perhaps involving them in the decision. “Hey, guys. In order to be able to continue the project, we were thinking of doing X, Y, Z. What do you think? What’s the best way of doing this?” Try to engage with the community.

If the decisions are being made in one room without those inputs, without the input of the stakeholders, of all of these people that are making the project successful in the first place, well that’s a unilateral decision. Therefore, the community has all the right to be upset about it.

Ledge: How do you weight the contributions of all the stakeholders? Some people’s opinion needs to rise to the top more than some other people. What’s the system or heuristic you use to value inputs and add weight to them?

Marco: Every contribution has to be evaluated from different perspectives. One, it’s the technical integrity of the actual contribution. What’s the strategic vision of the project and if the contribution matches that vision.

Really, having a highway between the maintainers and the contributors really should fix most of these problems. Assuming that, for example, somebody wants to contribute something that doesn’t necessarily match the vision or the technical aspects of the project. A conversation should start and a fix should follow up to that initial contribution in order to bring that specific PR, for example, up to the standards that the project expects.

I also believe that open source maintainers should not accept contributions out of the blue, just like that. They should first open up an issue; discuss if that’s even something that the project and the community would consider; and then, only then, start the contributions. Otherwise, yes, you end up in this situation when people spend lots of time creating code and the code is never merged, and then this creates friction.

As a rule of thumb, it’s always better to always discuss. Again, this is not something that’s unique to open source software, this is really our human relationships. We don’t make decisions, or we don’t just put people in front of a fact. We try to conversate with them and we make a decision together and then we move forward, and somebody who’s responsible and accountable to move that forward.

Ledge: How do you actually facilitate those conversations? This becomes really like a management/leadership discussion. How do you facilitate great conversations with… What do you have? There are thousands of stakeholders. It could consume easily all your time.

How do you manage the actual process of that so that it doesn’t completely consume you? It sounds terrifying. You could take feedback forever and never do any work.

Marco: The sole purpose of an open source project is to listen. Listen to the community, listen to what they have, and provide an avenue for them, a forum for them to be able to express themselves.

Every time somebody opens up an issue or writes a comment, says something in the chat – we have an open source chat – I really don’t think of that as a distraction. The sole purpose why I’m doing what I’m doing is for people to download our work, our software, run it and then being able to express feedback.

Really, in open source 50%, if not more, should be spent in listening to every single user and understanding if there is a pattern. If it becomes too noisy, then perhaps what’s missing is a rule set that would allow people to contribute and communicate more efficiently or in a more precise way. So perhaps the problem is in, what is the process and the highway that the contributors are choosing to adopt to express their feelings or feedback or their improvements to you?

I mean, it’s a never-ending job, so how can we listen to everybody in an efficient manner but never regretting for anybody writing to us or communicating to us.

Ledge: Right. I guess as the leader you really have to think about that efficiency factor and how everybody is spending their time being good listeners. At least to be efficient listeners, like you said. It could consume all the resources of the company listening forever.

There’s a line between listening and then action, and it sounds like you designed a good process around that. Was that home-grown, or did you take a lot of lessons from the community or the open source industry at large?

Marco: There are good leaders in the open source space that I believe do the right thing. Then also, building an organization that grows from the original founders to over a hundred people. We’re still small, but in that range from zero to a hundred many things are happening over the years. There is no way of building any organization without being able to listen, without being able to collect feedback in an efficient manner and then act upon it.

So really if we take a step back, maintaining an open source project and maintaining an healthy community is not any different than maintaining a healthy organization, or not any different than maintaining healthy friendships.

I mean, the human aspect it’s really the element here that all of these different activities have in common. So somebody who’s bad to listen in real life, I would assume he would be a bad listener even in a community. So it’s really about improving our skills – our own personal skills.

Ledge: What have you done? What is your personal path to improve your listening and leadership skills that way?

Marco: The biggest lesson for me, as the company grew, was to give trust. When you give trust, then you also have to listen because you have to listen to what everybody has to say.

The reason why we have to release control and give trust is because we don’t scale if we are the bottleneck for every decision.

So, in an organization, eventually you really have… When you’re starting a company and you’re starting a product, you’re in charge of everything. It’s very hard, because of human nature, to release something that you have because it’s an instinct. If you’re in a jungle, the more rocks and sticks you have the better. If somebody asks you for a stick or for a rock, well you don’t want to give it to them. It’s kind of a natural instinct.

Humans are not very good at releasing. We really have to make a conscious effort in releasing that power and giving trust so we can avoid being the bottleneck and now we can listen to what other people have to say.

There is always a balance, of course. I’m also not a big fan of having too many chefs in the room because consensus doesn’t scale either. We cannot be possibly having everybody on board, but we have to listen to everybody. After we have listened to everybody, we can make a decision of going on a different path or not.

But, giving the trust, listening to people while building the organization really helped me and improved me as an individual. Not just in the open source community, but in my own life I would say.

Ledge: Absolutely. Great feedback. Yeah, I agree. That’s critically important.

So, tell the audience about Kong, maybe how to get involved. We have a lot of audience members who are open source contributors and also a lot of people here who might be your clients. Please, give us information about the product and how to get involved and things that you want the audience to know, before we wrap up.

Marco: Yeah. It’s a very simple product. If you have an API, either an API that other teams within the organization have to use or APIs that you want other people to adopt and start consuming, well you have to secure those APIs. You have to protect them. You have to monitor them. You have to version them. You have to document them. You have to do all sorts of things that are far away from the actual business logic of the API itself.

So, our mission is; developers, focus on building the actual business logic and let Kong do the rest so that we do not waste time implementing and reinventing the wheel when it comes to connecting, securing and extending those APIs.

Kong as a platform can work in a north-south capacity – so as a traditional API gateway – or can work on an east-west capacity as well – so microservices and service mesh.

We’re working from small, individual developers to large, top Fortune 50 organizations. We help them connecting, securing, protecting and making their software, their architectures, viable in order to, at the end of the day, deliver business value.

We are building APIs, we are choosing different architectures, we are doing all the things that we are doing because there is a driver to that – and the driver is always the business. So, how can we, for example, support more world regions? How can we connect with more partners? How can we support different mobile apps? How can we scale our team?

Usually, the answer to those questions is, okay, we have to change our software with microservices, or use APIs or do X, Y, Z. So, how can Kong help technically connect all of that from a technical standpoint, but at the end of the day how can Kong help create business value to what is the original driver to that transformation?

Ledge: Well said. I’ll let everybody else chime in after that.

So, Marco, thank you. Thanks for sharing your story and your insights. Really good to have you on.

Marco: Thank you very much, Ledge.