Luke Kanies is the Founder of Puppet, an open source tool for software configuration management. In this episode, Luke discusses the fundamental challenges of starting, building and running an open source software business.
Transcript
Michael Schwartz: Welcome back to Open Source Underdogs, the podcast where we interview the founders of pure play open source software companies, and hopefully illuminate the business models that power their success.
If you’re not familiar with the Puppet platform, it helped define the market for configuration management as code. They’re also one of the pioneers of the second generation of open source companies, i.e., the company was founded after Red Hat.
Luke Kanies is the founder of Puppet. After serving as CEO for many years, he was elected to lead the board of directors as chairman. He’s working on a new startup, which he talks about in this podcast, and he’s helping entrepreneurs in an advisory capacity.
It was a great honor to interview, Luke. So without further ado, let’s cut to the tape.
Luke, thank you so much for joining us today.
Luke Kanies: Thank you for having me, Mike.
Origin
Michael Schwartz: Can you tell us a little bit about how Puppet got started?
Luke Kanies: Yeah. I think there is only the long version of the story.
I started Puppet around 2005, but I had begun doing the arguing, and research, and community discussions as early as 2002/3. But it was by 2005 that I kind of run out of other options.
I spent some time doing consulting and working at another company, trying to convince other people who had already had the technology that they should build a company. And by 2005, I both had run out of other options for myself to do as a means of making money, and it also concluded that none of the other more obvious people to start a business in the space we were going to.
So, the person who was running the CFEngine was going to start a company, and the person running the config wasn’t going to start the company. So, I basically said “well, if no one else is going to do it.”
There’s this old saying about “if you look around a poker table and you don’t know who the sucker is – it’s you.”
One time I was at the event, I looked around the table, and I couldn’t figure out who the entrepreneur was, so I said “well, I guess it’s me.”
So, I just quit a job making six figures, and didn’t know what else I was going to do. I sat down and I took the prototype that I built last summer, and started building a product around it.
Within about ten months, I had our first paying customer, and bootstrap for four and a half years, so we are run and profitable from about year on, and went from there.
Founders
Michael Schwartz: How many initial partners were there in Puppet Inc.?
Luke Kanies: Just me.
There are two other people who I gave the title of Co-Founder when they joined the company three and a half years later. But by then, we already had a complete product, we had a customer base, we were making multiple hundreds of thousands of large revenue.
I was able to pay them their previous salary when they joined the company, whereas I went without salary for ten months, and I went for two more years, paying myself less than half of what I had been paid previously.
By the time they joined the company, I was desperate, I was expecting twins any day now, so I was in a really, really tough shape. I think they both did good work for the company, but I would say that they were much more employees number 1 and 2, and I just called them founders because I was not making high-quality decisions about titles and things at the time.
Existing Community
Michael Schwartz: The point you started Puppet, there was actually no existing community around Puppet, you started it from scratch.
Luke Kanies: Yeah, that’s one of those rare cases where I started the company and the product about at the same time.
And I, from day one with Puppet, knew that I wanted a company around it.
At the time, we had this community at LISA. So, LISA is this system administration conference, it’s been there for a long time, and there was this smaller config management community within LISA. And I remember at the conference, we did these all-day workshops, and they’ve got maybe about 20 people.
I did a poll, “how many people here have written their own product, their own piece of technology, their own config management tool?” And nearly everyone in the room raised their hands. And then I said, “of all those tools, keep your hand up – is anybody outside of your organization still using it?” And Mark Burgess, who started CFEngine, he was the only one who kept to stand up.
There were already a bunch of other projects out there that existed, were in use, but really weren’t in use by anybody else.
And so, the challenge wasn’t can I build a piece of technology? The challenge was – can I build a piece of technology, specifically with the goal for other people to use it?
And from my perspective, the only way to do that was to say “my ability to eat is depending on your liking my product.” And if I can’t sell something to you, if I can’t build a business around this, then the product is not good enough.
That’s essentially what I focused on, and that’s why it slides in my presentation from 2006. I said, look, if it’s not good enough, I don’t deserve to eat. And that kept me focused on building something people would love, not just building something that I liked.
Initial Revenue Streams
Michael Schwartz: How did you initially monetize? Because that’s a lot of pressure to put on yourself, especially with an open source product. What was the initial monetization strategy?
Luke Kanies: Services. And, thankfully, in a lot of ways it was straightforward, because I had spent almost two years as a consultant before I started Puppet. Well, six months I spent in BladeLogin in-between. I spent almost two years as a consultant, and I mostly focused on doing CFEngine work.
I did two kinds of work with CFEngine. One was, I did training.
So, I would design a CFEngine training class, and had 20 people meet me somewhere – I don’t remember where it was – oh, I know. I flew out to Los Alamos National Labs and taught a class there. I remember I got paid $19,000 in a week for that. Of course, I did a ton of work in prep for that, so it wasn’t a week of work but it was a week on site.
I’ve also done a couple of essentially implementation projects, where I go in, and it’s about 50/50. At the end of the week, you’re going to have a running functional implementation and also at least one person who is highly trained in implementation.
When I started Puppet, I took that same basic model. We’re going to do training classes that cost about $2,000 per person, and we’re going to do like group trainings, and then we’re going to do on-site trainings, where you can pay for the entire company. You can pay for some people, it’s a fixed price for that group. And then, we are going to do implementations. The business model was already in place, built around the project.
When I started Puppet, I basically said, “I don’t know how this works.” I didn’t know how to negotiate pricing, I didn’t know how to think about value. I would just roll those same basic concepts, and do what we do at Puppet.
Ironically, if you look at our average sale price, ten years after I started those services, our average sale price for a downloadable installable software was within a couple of grand of my week-long services engagement that I started in 2005-2006.
So, I did a pretty good job of landing on a reasonable price point and getting to the point where I knew what I was doing, and how I was doing it, why I was doing it, and how much I could charge for it.
And then just for the next ten years, figuring out what else do I need to add to make it work, and how can I provide a better product, and then overtime, how to go from the first installation as $20,000, to a million-dollar installation, and then a ten-million dollar installation.
Initial Bootstrap Phase
Michael Schwartz: We’ll drill down a little bit more on the revenue stream business model stuff later, but I’m still interested in the startup phase. So, did you say it was four years until you actually raised the first round of money for Puppet?
Luke Kanies: Yeah, we were running profitable from 2006 to 2009.
I brought Andrew Shaffer in, Teo in 2008. We got offered a round of funding that year, but it was contingent on me stepping down as CEO, and there were some other things that we didn’t love about the round, so we turned down that term sheet.
I pitched to a few other investors before, not officially pitched but had conversations with. I had found investors who I would have taken money from, and I found investors who probably would have given me money, but I never found investors who were both of those things, who wanted to give me money and whom I would have taken it from.
In 2009, Puneet Agarwal from True Ventures tracked me down at an event, he said, “hey, we’ve been following you, we would like to give you money.” And I said, “well, that doesn’t sound right.”
Most investors, when they say, “we are interested in you,” say, “we should talk again.” And Puneet said – “we should talk again… On Monday.”
On one hand, I was interested in the things that come with raising money, but I’d been at a startup that had gone bankrupt because it raised too much money, and the investors brought in the wrong managers and all kinds of stuff – that was a more complicated picture because of market timing and stuff.
I had seen plenty of the bad examples, and so I was very skeptical. True Ventures was able to convince me that they were going to be a really good partner, and that they weren’t going to make a lot of the short-sighted anti-founder decisions that investors were famous for.
Overall, they’ve been a great partner. We got our first round in 2009, almost four years after Puppet started.
Startup Leadership Challenges
Michael Schwartz: Can you talk about some of the leadership challenges during those initial four years?
Luke Kanies: I mean, there weren’t any because I was the only employer, so essentially, I was the one out there doing all the work.
I was the only person there. I was trying to build a community, I was trying to build a product, and I was trying to build a business – all at the same time.
It’s worth noting, like, I wasn’t the developer when I started Puppet. I had written some small scripts before that, probably 2000-line Perl script before Puppet.
I have never written a line of Ruby until I wrote the prototype for Puppet. And I had never shipped software that anybody else has ever used, when I started Puppet.
So, in addition to trying to figure out how to be an entrepreneur, how to deliver services, and how to sell, I was also trying to figure out how to become a programmer, and how to ship software that doesn’t break, and stuff like that. So that was pretty much just me the whole time.
I did bring in Teo and Andy towards the end of that bootstrapping period, but in the end, by then, most of the questions you needed to ask in business, to figure out that we have a real business here, those questions were already answered.
And the rest of the questions to figure out, essentially, “how do we take what we have and scale it up, how to get the most out of it? How do we turn this from a one-person operation into a functional organization?”
Those kind of traditional scaling questions that I think are super, super important but are really, really different from “what problem are we trying to solve, how do we solve it, how we deliver it.”
Those questions were pretty much solved before I had my first employee.
When to Use Open Source?
Michael Schwartz: When do you think it’s appropriate to use open source as a development methodology, and when do you think you should patent and license your software?
Luke Kanies: That’s an impossible question to answer in the abstract.
It’s worth saying something. It’s not that I don’t believe in patents. For me, I would say patenting and licensing are orthogonal. I could totally see you licensing software that you don’t patent.
I will personally probably never bother to patent software – I’m not saying I absolutely won’t – but in software, I think patenting is primarily an anti-competitive mechanism for suing smaller players into oblivion, rather than the actual mechanism for publishing innovations.
I think it’s mostly the fault of the courts, that have just allowed pretty bad patent behaviors. Maybe someday software patents will be useful, I just don’t see that right now.
In terms of licensing versus open source, I don’t think you can answer that in the abstract. I think that you need to have a very good reason to go open source.
I think that you can name some companies today that have built really good solid businesses on open source software. But for every single one of those you can name, I can name a hundred companies that have built really solid businesses on commercial software.
And it doesn’t mean you should never do open source, but it does mean that the barrier for it being the right answer is much higher than it is for commercial software.
And there’s a trend right now where people say, “oh, well, in this industry, in this part of industry, infrastructure, you have to be open source.”
I would say to every one of those circumstances like, that’s just not the case – Amazon is not open source, AWS is not open source. The vast majority of what we use in our infrastructure is not open source. Cisco is not open source. Right.
There’s a story that you have to be open source, but the reality when we look at the stacks that we have to rely on, there is a lot of open source – but there is a lot of proprietary software. I think you just start with getting rid of the excuses for, “oh, I have to be open source.”
And then, you need to say, “Well, what are some really good reasons to be open source?”
To me, this is the interesting part of the conversation. The first thing is to answer the question “what are great reasons to open source my software?” And then, the next question you have to ask almost immediately is, “can I sustain a business in that case?”
I know there is a ton of really great open source software that has no business around it. And I think a lot of that is really important.
For me, personally, I’m primarily interested in open source entrepreneurship.
So, my fundamental interest is about the business side of any of this stuff. I’m much more of an entrepreneur than I am an open source person. If you had to get rid of one of those, I’d far rather never do open source again than never do entrepreneurship again, if that makes sense.
I do think you have to protect space to build your business as you think about what you are going to open source.
And I know this is going to sound cynical to some people, but I think of open source as primarily a marketing strategy: This is a mechanism for people to become committed to your product, without having to make buying decisions.
Sometimes, that commitment is a technical commitment. I’ve built this piece of your technology into my infrastructure, into my development workflow, into some portion of my life, and I love it so much that I want these other things that go with it.
Sometimes, it’s honestly just – I’ve got brand awareness because everyone knows about Docker, and so I’m going to go figure out whether I can get from Docker some money or not.
But I think that’s the right way to think about, not all, but most open source is, top-of-funnel, getting broad usage everywhere.
It is a fantastic freemium model with the one caveat – that the thing that makes people love your product is the thing that’s also available for free. Which means that building a business on it isn’t impossible, but, in most cases – you look at Splunk.
Splunk has an amazing, fantastic freemium business. But at a certain point, Splunk says, “you’ve got to pay me or you can’t use my software anymore.” And no one goes to Splunk and says, “how dare you ask me to start paying after 500MB?”
But if you had open sourced that, and said the same thing – “by the way, you have 500MB you should pay me.” Then, all the people would say “how dare you ask me to start paying after a certain point?” So, there is this challenge of messaging that a lot of people hear this as a permanent promise that everything will always be free.
That dynamic, and I wrote this article a couple of years ago, about the fundamental challenge of open source is that thing you offer for free has to be sufficiently great that people can succeed with it, but has to leave room for there to be some other thing you charge for.
In many cases, you rely on lightning to strike twice. The thing that’s free is great, AND the thing that’s paid for it is also great. And, as we know, lightning doesn’t usually strike twice.
So, it’s a kind of a pretty challenging conundrum, in my opinion.
Puppet Sans Foss?
Michael Schwartz: Do you think Puppet would have been successful if it wasn’t open source?
Luke Kanies: I think it’s a fantastic question, and it’s one I thoroughly enjoy speculating on.
I think – obviously this is a pure speculation – I’ve no idea. I would guess, that would be far less used, and it would have made far more money. That’s my guess. So, when you say successful, it depends on what you mean, right?
Downsides of Open Source
Michael Schwartz: What are some of the other downsides to open sourcing your software?
Luke Kanies: Honestly, I think one of the hardest ones is the messaging side. Because I recommend founders think about open source as a liability, in a financial sense.
What you’re saying your community is, I’m making the brand promise to you that this software will always be free and always be high-quality.
And that brand promise is expensive.
So, when you open source your software, you’re not just thinking about what can’t I do in the future, and things like that. Google shuts off products all the time. Google has a thousand products, and the average users do not care when Google kills Google Reader or kills Google Glasses.
But if your core product is something, and you go in and say, ahh, you know what – turns out we aren’t able to pay our developers with the business that we built. And so we’re going to have to fundamentally change our developer, or shut our whole project down. Because 99% of developers in this project are paid by my company. So we’re either we’re going to completely reframe our business and start charging basically everybody, or shut the whole thing down.
You’re breaking your brand promise.
And the brand promise was, “we won’t do this.” The brand promise was, “it always will be great and it will always be free.”
At least, it leaves not a lot of wiggle room to help people see, well, “*free” with an asterisk, and “yes, except…” And that conversation is really complicated.
So I think we got lost in the weeds of that conversation all the time. One of the things that happens is, there’s one person in the room that’s screaming all the time about licensing or something.
There’s some part of the open source ecosystem that demands a certain kind of fidelity, or a certain kind of allegiance, or a certain kind of zealotry. And if you refuse to commit to that kind of allegiance, then that person’s going to scream as loudly as they can all the time. And it’s really easy to confuse yourself into thinking, “that person represents the wider community.”
And sometimes they absolutely do. But in a lot of cases, they absolutely don’t.
So, you have to figure out how to have that conversation with your community. By that I mean, people who use your project, the people who contribute to it – and by contribute, I mean people who are on your IRC channels, or helping to ask and answer user questions, or responding to email questions – these are all super important contributions.
You have to be able to have a conversation with those people about, ok, where is this balance between survivability of the company that funds the vast majority of development on this project, and what the community needs to be happy, and things like that.
I think it’s a little bit like the relationship between unions and big companies. If you look at the relationship in Germany. Germany’s had unions for long-time, but Germany unions recognize that if they get too powerful, they can destroy the business. And the business has recognized that if they get too powerful then workers began suffering, and they recognized like this is the dynamic that we have to play with here.
It seems like, at some point in the 20th century in the US, the unions kind of stopped caring about whether the business they were working for was viable, and the dynamic got off. And the businesses stop caring whether the employees that they hired, what situation they were in.
And so, that dynamic is critical to the success of an ecosystem.
And if you were starting an open source business, or even just a project, you’ve got to be willing to sign up to manage that dynamic for the lifetime of your project, because it’s a really, really important part of people being happy.
And so much of it is: Are we meeting your expectations, what did you expect, and are we succeeding in those expectations? It’s not really about what you did, it’s about what you did relative to what they expect.
I think you have to think about that upfront. And you have to be willing to sign up for that work.
Training
Michael Schwartz: You answered one of my questions that I had written. I remember Puppet doing a lot of trainings, and I was going to ask you why, but I think you kind of just explained it.
Luke Kanies: Well, I think training is great for two reasons.
One is, it’s a fantastic revenue source. If there’s a demand for it, it’s an amazing revenue source.
And the second is, people are paying you to become experts in your product.
In my opinion, you should sell as much training as the market can possibly support, because it’s super high profit from a service’s perspective, it’s amazing business! And, again, everyone is now skilled in your product.
To me, there’s no downside and a lot of upside.
Michael Schwartz: Yeah, it’s challenging to build a good training program. We’ve been trying it with Gluu for a long time. And we want to, but it’s actually pretty hard to do it.
Luke Kanies: And especially – it’s one thing to have the intro training class, it’s another thing to have three tiers, and your product for this specific vertical, or for this specific type of user, so yeah, I totally agree.
Scaling Revenues
Michael Schwartz: So, training – it is a great business and it helped you get started. But you alluded to this earlier, to really scaled the business, you needed, maybe, some other way to generate revenue streams. How did you make that transition?
Luke Kanies: In 2010, we launched our first, what I would call commercial product, which was our first attempt at building a licensed product, rather than everything being free, and the only thing we offered were services.
I think as of maybe two years ago, or three years ago, we finally have some idea of how that might work in practice.
So, six years of trying from first released to, “oh, I think I know how to make this work in the long term.”
We were super early when we started, but then I thought “you know, I don’t know exactly how to make money, but I’ll copy one of those great open source businesses that are out there.” Or, at some point, after a few years, I looked up and went, “let’s count the open source businesses.”
And it was like, well, there’s Red Hat. Red Hat went public as a T-shirt and mug company – that’s never going to happen again.” Okay, well, that’s not a good example.
What about MySQL? Well, MySQL is now owned by Oracle. Now, therefore, no one else can ever build that same GPL-based relicensing business again. So that one’s out.
Well, who else was left? There weren’t that many other businesses left that I could use as an example. And so we were breaking far more new ground than I would have liked.
I always recommend founders do as little innovation as possible.
There’s like, part of your business that’s really innovative and risky? Well, don’t, like, invent other risks to other parts to your business.
Like, if you know your software is super risky, don’t be risky in how you think about your hiring practices. Don’t be risky in how you think about whether you are going to have managers or not. There’s just no reason to add more risk to your business.
We didn’t have a business model that we could copy very effectively. And you would probably recall we tried open core, but we tried a ton of different iterations of like, we’re going to have this complete feature be commercial, or we’re going to have the infrastructure components be open source, and the graphical components be commercial.
We were trying a bunch of those different things, and it all kind of ran into this cliff of – because the primary reason to do open source in most cases is: “I want you to become addicted to my product. I want to build the thing that you love.” And some portion of you are going to have a set of problems where my commercial product is a better fit, or you are going to decide for some reason, hopefully for a functional reason, but also for other reasons, to upgrade to my commercial product.
And the challenge becomes – you need to build something that is great enough for the free users that they become successful and happy, but that isn’t a complete solution, such that, at some point, they decide, “oh, we need to start paying them because we’ve hit some sort of barrier.”
That balance is basically where we spent 7, 8 years, trying to find that balance.
And we built a great business – so I don’t mean to say that we failed, or that we didn’t get a lot done, and make a lot of happy customers in the meantime – but from the business strategy perspective, this is something that we were kind of always messing with the throttle. Where do we put this line, how do we think about it.
And to be clear, I am on the board of Puppet, and I’m not directly involved in product strategy or building products, so this is all stuff you can learn from reading our website.
So if you look at our website right now, and you look at the open source projects that we are releasing today, you’ll see that they don’t follow quite the same model of – let’s build an open source engine with a commercial graphical interface on top of it, or a commercial packaging for it. And, in a lot of cases, it’s a different story.
And I think right now, the story will vary depending on the project. If you look at Lyra versus Bolt, the commercial strategy for those are different from each other, I’m pretty sure.
I think the whole industry is learning about how to do this right now, and we certainly have been part of that learning this whole time. Some of it has been quite fun, and enjoyable and educational, and some of it has been really uncomfortable, and at times miserable.
How To Get Customers To Pay?
Michael Schwartz: How did you actually make that balance, or more simply, what did you actually end up charging for?
Luke Kanies: I kind of reject the idea that we have a clear answer to that, or that we can have a clear answer.
I really wanted people to be buying software that made a big difference to them. But then, plenty of cases, people buy software because they thought it was the right thing to do, or people buy software because they really wanted a support contract, but we didn’t offer that separately.
It’s surprisingly hard to figure out what a customer’s motivations are, and obviously, you can figure out per customer, but you can’t go across all of your customer base and say, “I know what all of them are thinking, and I know why all of them are buying,” especially, as you get to a thousand, two thousand, three thousand customers. It becomes fantastically hard to figure out exactly why someone did something.
So, we sold a license to downloadable product that the vast majority of the software inside that product was open source software. But there were key portions of it that were commercial, and there were portions of the commercial that changed over the years, depending on what we built and what we found. This makes a big difference, this doesn’t make a big difference, this needs to be open, and this doesn’t need to be open.
We listen really closely to the market year after year, and change our behavior based on what people said.
In essence, we had quite a few separate open source projects, the biggest one, which was Puppet, and then a commercial downloadable product that combine all that together in one download.
Tools
Michael Schwartz: So, it wasn’t just Puppet, the license, but some of the tools in adjacent markets, let’s say, that you included in this Enterprise subscription?
Luke Kanies: Exactly.
As one simple example, Puppet has always worked for the small utility called Factor. And you can of course download the RPMs to each of those, but we would say, well, in our commercial product, we are going to have Puppet in Factor, and over time, we had to include our own separate Ruby because we couldn’t rely on system installations to Ruby for lots of reasons.
We found especially the way we use certain things competing with the way Rails uses certain things, and so we would have really significant incompatibilities between our Ruby and system Ruby. So, that was one of the things where we found that it was much better experience, from our customers’ perspective, if we distributed the entire stack that we were reliant on.
Over time, Puppet became much more reliant on the JVM. A lot of our core tech, like PuppetDB, which is this whole separate store engine that we built, that’s already in closure but runs on a JVM. That’s another example of, we’re going to deliver a lot more tech as part of that stack, to make sure that we can ensure that you have a positive experience.
That reduced the operating cost of not having to worry about package installation, of not having to worry about software upgrades or compatibility, or, “hey, does this installation of Puppet kind of compete with my production application?”
Those are examples of things that you get with the commercial products that are not technically commercial software, but they’re part of the operating runtime value of the commercial product.
Customers Who Want Commercial License?
Michael Schwartz: Did you find that some customers just didn’t know how to buy open source license, and that they preferred some of the liability, and protection and indemnification that came with a commercial license?
Luke Kanies: I mean, honestly, whatever you might be looking for, we definitely found people with those things.
We found people who were offended that any of our software wasn’t free. We found people that were still scared of open source. We found people that wanted to buy our product and would prefer we’d just never talked about open source. We found people that would buy our product, but then only use the open source versions, and not actually even use the commercial versions.
We found every kind of iteration. And over the years, those different iterations made support costs much, much higher.
You’d say “I’m going to do it my way instead of your way,” but then you call us for support, and it would take us three days to resolve your problem instead of five minutes.
So that’s one of the things that shifted our practices around what we’re delivering and what we expect over time. Because in order for us to make your experience better, and to reduce your problems, and if you have a problem that we can resolve quickly, we had to get a much narrower set of valid installations out there.
Why Transition out of CEO?
Michael Schwartz: So, initially, you rejected some venture capital offers because they came with strings of you not being CEO. But then after eleven years or so, you decided maybe you didn’t want to be CEO. Can you talk a little bit about why the reasoning behind that transition?
Luke Kanies: Yeah, it’s certainly complicated. As of 2014, by the end of that year, it became clear that I was no longer happy in my job.
And I’d say I was unhappy for a few reasons. And, I don’t think I’ll get it all in here, but I might get a little bit. There’s more I could say, but I will tell the high-level version.
Mostly I was burned out, I had been running in the red forever, I had rebuilt my executive team twice. It was clear at that point that some of my key executives were not going to be in the company much longer, either because I didn’t want them to be there, or they didn’t want to be there. And managing people is incredibly, incredibly hard. And success is critical.
I had put everything I could into helping these people be successful, and I didn’t have anything left. The thought of going out, trying to hire replacements was too steep a hill to climb a third time.
So, I said “look, I’ve done it as long as I can, I don’t have anything left to give.” At the same time, it was very clear. I founded Puppet to prove to the world that you can build a general-purpose automation system, that is of real value both to the companies but especially to the employees, the people doing the work, and actually building one and adopting one.
That you can build one where the mechanism for automation is text. Which means you can version control it, you can share it. Things that came before Puppet – this might not be super obvious, and CFEngine had this problem, but like all the previous like, widespread solutions did – if I had something that was great, I couldn’t email it to you. I couldn’t ever put it on GitHub.
In fact, in a lot of cases, I couldn’t even use it from one version to the next. I’d have to recreate all of my installations because they didn’t have this text-based configuration. And I wanted to prove that we could do that. I wanted to prove that it worked, that it was a good idea, and all these things. And we did.
But, when you look at my strategy for the first ten years of Puppet, it was all about getting a beachhead and organization, it was about getting the first 10% of every company in the world automated.
But I also realized the next challenge, the next ten years, it’s about getting the next 90% automated.
Not just the challenge, like, the technical challenges of that, but like the people challenges, and especially the contract management challenges of that, are really, really different from that first ten years, and those first challenges. And more importantly, they are really, really different from what’s near and dear to my heart.
I really respect the job of Enterprise sales, I respect the work of navigating an organization and figuring out how do I get a deal in place that the entire organization buys into enthusiastically; they don’t just write a check, but they actually use the software.
How do we get team after team after team, and exec after exec after exec to buy into this, in a way that they’re successful. And, you know, the company gets paid, the product gets used, the users are happy, the company is happy – that is incredibly, incredibly hard, and it’s not my skill set.
I am really honestly over-focused on the individual human, on the individual user, and I’m not great at thinking about the teams, and especially thinking about teams of teams – and that’s what the company needed.
The company needed somebody who was excited to have a complex, multi-team, multi-organization conversation about how the entire organization can use this product.
I think Puppet has actually scaled organizationally better than anything out there. If you look at, we’ve had companies where 70% of the company is using Puppet. We have companies where hundreds and hundreds of people are using Puppet. And there are a lot of other ways in which it scales organizationally just really, really well.
But from a deal-mechanics perspective, from what it takes for Puppet the organization to scale, I wasn’t the right person to navigate those. And when you find yourself in meetings where, I’m either having the same conversation I’ve had for a long time, because now we’re selling to more conservative systems instead of leading-edge early adopters. But also, I don’t ever want to sell to CIO. I just don’t ever want to do it.
And it’s not that I don’t respect them, it’s because they don’t use the software directly. I am personally interested in users, not buyers, not project managers. And you’ve got to be great at understanding and working with all of them to be great at Enterprise sales.
And I could tell what Puppet needed in the next 10 years was something else. I couldn’t get motivated to do that.
Now, the actual mechanics of how the transition happened were a little more messy than that, and I like to say it was my plan and the board’s execution of the transition. So, it’s been an interesting time.
But with Yvonne Wassenaar over there now, I’m super excited.
I think she’s perfectly positioned, she’s got a ton of strategy experience that every company needs. She was at New Relic when they went through that transition from entirely inside to this mix inside/outside sales. And that’s the stage that Puppet’s at.
So, having somebody who respects the fast initial adoption sale, but also knows how to build out that big large Enterprise sales – that’s the mix of business that we’re going to have in the long-term. And somebody who is excited about that and experienced about that is the right CEO of the Puppet. And that’s not me.
Luke’s New Business Idea!
Michael Schwartz: Do you think you’re going to start another company?
Luke Kanies: I already have.
Just super fast – I’m starting a new relationship management software company, focused on helping you ensure your most important relationships are healthy.
I think contact management is one of those, it’s like, one of the most important problems with the worst tools available today. So I’m hoping there will be some aspects that we’ll release that will be open source, but the core product, in this case, will be commercial.
Michael Schwartz: Will it be a SaaS product?
Luke Kanies: I don’t think it will. Man, this is so complicated. I’m doing like, six things at once, and the largest envelope with all those things is, my next 10-year mission is trying to convince the market that power tools are important, and that they have been under invested in.
And also trying to teach the market where a power tool is. And I think, I don’t know this, but I think it’s much easier to build a power tool when it’s local operations against local data.
So, you can have SaaS components, you can have backend headless services and things like that. But I think in general, a power tool – it’s hard to believe Photoshop could be as great if it was a SaaS product. It is hard to believe that AutoCAD could be as great as if it was a SaaS product – No.
Is it great if you have SaaS components? – Yes. But is the core experience ever going to be as good as if it’s a fat-client app, operating on a powerful computer in front of you? I don’t think it is.
That’s my operating like thesis right now – that we need to build power tools with local operations against local data, and we’re not trying to build it for everybody. I think too many companies are targeting products to be used by everybody – there’s two billion people online! That these should be used by everybody? I don’t want that.
Those two billion people, they’re not all going to pay for the same software, and I want to build a software that makes people more powerful. That means that I will need to build the software that you will need to pay for.
If you are not willing to pay what it costs for a cup of coffee a week on my contact management software, then we are not building anything for you. And that means that for most people, this is not the right tool for you. It’s only for people whose networks matter so much that they’re willing to invest time.
I’m not saying it should be as hard to use, but if your contact management isn’t at least as powerful as your text editor, like you made a mistake somewhere. Content management matters a lot to some people. Relationships matters a lot to some people. And the tools I have for doing it are nowhere near as complex as my compiler, my text editor, my project management software. All my developer tools are way more powerful than I had as a manager, or that I had as a leader, or hirerer, or as a CEO – all those tools were really simplistic. Why?
I think as a CEO, I deserve as complicated and powerful tools as the developer, or the sys admin, but they are not available. So, I want to try to convince the world that everybody deserves powerful tools. That your hotel cleaner deserves powerful tools, that your construction workers deserve powerful software tools, and it’s not just sys admin developers.
Challenges Of Open Source Business?
Michael Schwartz: Wow! Good luck with that. I think that, just as a data point, you’re recording on Audacity did not crash, and my SaaS recording tool did.
Two last questions. One’s about companies and the second one is about people.
The first question is: What do you think are the biggest challenges facing pure play, open source startups today?
Luke Kanies: It’s super easy. You are giving your product for free, why would anyone pay you?
That seems really obvious. There’s no other business where you give away your product for free, and then try to find some other way to pay it, that I know of. I think it’s super hard.
There are models that work, there are proven models. Red Hot got rid of their source RPMs, they made it harder to build a completely new, from-scratch copy of Red Hat.
There are some of those, but all those starting on a presumption that I’m going to get broad enough adoption that a 2% conversion rate, or a 5% conversion rate allows me to build a viable business. I think it’s conceivable, but it’s super hard.
Michael Schwartz: The last question is do you have any advice for the entrepreneur, the person starting the business – and it could be about not just necessarily the business challenges, but some of the personal challenges of starting a business, around open source software?
Luke Kanies: There’s a ton of advice out there, or really a ton of people who are trying to say “this is what entrepreneurship is,” and almost all that framing is “and if you don’t do this, then you’re doing something wrong.”
You know, there is this thread about the most successful people get up at six in the morning. Okay, well what if you are a night owl? Well, I guess you’ll never be successful. Suck it.
I’ve never gotten up at six in the morning, I can’t really speak coherently until at least 9 AM.
So I’d say, for any entrepreneur, it’s really easy to find advice that you will never be able to follow, and become dispirited, and feel like you’ll never be able to succeed as a result. I would focus much more on finding success cases and ignore the failure cases.
The things that you’ll never be like – if you can’t be like, then just ignore them. There are lots and lots of ways to succeed in general, so focus less on whether somebody else’s successes is replicable by you.
There’s a great thread on Twitter today about all these different amazing people who built great business, and how Jeff Bezos’ parents were able to give him $250,000 to start Amazon.
Ok – on one hand, Bezos is a great entrepreneur, but on the other hand, if he didn’t have rich parents, then we wouldn’t know if he could be a great entrepreneur.
It’s really easy to tell yourself a version of reality that makes it so it seems harder for you, but it might actually be literally harder because you don’t have rich parents, or rich friends, or a rich uncle, or whatever that is. And that is just being an entrepreneur. Full stop.
And for me, I would say, be really, really clear about why you’re doing open source. And then make sure that’s the actual thing you do with it.
If you’re doing it entirely for top-of-funnel for usability, for getting broad usage, and then you want to convert people to paying, then that’s a very different business than this small engine needs to be open source because it needs to be distributed everywhere, but the viable broader product doesn’t. That engine, being open source, may not have much implications in terms of your product. That’s what will be different.
Or, my partners really require this to be open source. Each of these point to a different business model, and a different set of constraints on you. And so just saying it all needs to be open source, or I have to be open source, is not really very instructive.
Be really crisp, and be clear, and put walls around it. Then ask yourself “can I build a viable business outside of those walls? Can I build the business that I want to build?” Because I guarantee, whatever it is – you could build a services business making half a million, a million, maybe five, or even ten million dollars a year – but that might not be the business you want.
And if your goal is to go out and raise ten million dollars in venture capital, or a hundred million dollars in venture capital, I know that that’s not the kind of business they want. So, you’ve got to be clear enough about why, and then what’s left, and then what’s left is enough to build the business that you want to build.
Michael Schwartz: Awesome! Luke, thank you so much for your time today and sharing all that with us.
Luke Kanies: Thank you for having me on the show, Mike.
Michael Schwartz: Transcription and episode audio can be found on opensourceunderdogs.com.
Music from Broke For Free and Chris Zabriskie. Our audio editor is Ines Cetenji.
Production assistance and transcription by Natalie Lowe. Operational support from William Lowe.
Follow us on Twitter, our handle is @fosspodcast.
In the next interview, we have Sam Tuke, the CEO of pHplist, an open source platform for email communication management.
Until then, thanks for listening.
