Puppet Labs' Kanies: 'The Right Resources to the Right Relationships'
"The biggest danger is when an open source company gets confused about what it sells. If you think you are selling open source software, there aren't a lot of buyers for that now," said Puppet Labs Founder and CEO Luke Kanies. "But if you have promises about what you sell, those promises make a very lucrative business. "
05/07/13 5:00 AM PT
Luke Kanies has a passion for the Puppet language he created. He always wanted to start a software company with Puppet as its foundation. The problem he faced was how to make the open source model support his software innovation without getting lost in the process.
After eight years as founder and CEO of Puppet Labs, Kanies has succeeded in avoiding the danger lurking nearby for all open source companies.
Puppet is an open source configuration management tool written in Ruby. It was released as free software under the GPL in 2005 until version 2.7.0 and the Apache 2.0 license after that.
The Puppet language helps sys admins simplify how they manage systems using Puppet. The software provides automation to manage infrastructure throughout its lifecycle -- from provisioning and configuration to patch management and compliance.
Kanies developed Puppet as a model-based approach to IT automation. The user defines the desired state of the system using Puppet's declarative language. Puppet does the heavy lifting to automatically create and then enforce this desired state. This information is stored in files called "Puppet manifests." Puppet discovers the system information and compiles the Puppet manifests into a system-specific catalog containing resources and resource dependency. Puppet applies these manifests to the target systems and then reports the actions it has taken.
Puppet products combine a strong foundation in existing open source code such as MySQL with code the company has added. Some of that code is proprietary. The open source portion handles the setup, configuration and scaling to the user's hardware. The proprietary portion runs on top of that, according to Kanies.
One of the neat things about Puppet's success and the company's growth was Kanies's desire to always be a software company. When he started the Puppet Project, he also started Puppy Labs, the company to support it. A former sys admin who contributed to many tools like CFEngine, his business sense told him he could not succeed with one company without the other.
"Unlike a lot of other open source projects, I didn't spend a few years doing it as a hobby and then realize there was money behind it," Kanies told LinuxInsider. "I really started it in the beginning to build a company to support it. The goal was always to build a scalable company primarily to pay for the programming. That was my number one problem. How do I pay for my programmers?"
In this exclusive interview, Kanies tells LinuxInsider how he grew his open source software project into a thriving commercial enterprise.
LinuxInsider: How does the Puppet language differ from other programming languages?
Luke Kanies: Puppet's language is designed to do one thing -- specify resources. In the Puppet world, a resource is an entity that you want to configure, whether that entity is a package, a user, a group, a service or a file. Any of those things is a resource.
Everything that Puppet comes down to is to get the right resources to the right relationships. So the language is really about specifying those resources, allowing the different parts of the configuration to do the things that those resources need to do, and building and subscribing the relationship using those resources.
LI: Can you give an example of that difference?
Kanies: Puppet was built to handle active resources in the most user-friendly way possible. You don't use language to tell Puppet what work to do. You tell Puppet what state you want the system to be in. So you don't say to Puppet, "Go install package." You say, "I want to make sure this package is installed." So the first time Puppet runs, it finds the package is not installed and goes about installing it. The next time Puppet runs, it is going to check to see if the package is installed and then does not do any work because the system is already configured correctly.
LI: Prior to introducing Puppet, what alternatives were available to deal with system configurations and maintenance?
Kanies: There were generally two ways to go. One was picking a general purpose language, and the other was relatively opaque graphical applications. There was no middle ground between the simplicity and approachability of a GUI and the power of a programming language. Because Puppet is a domain-specific language, it allowed us to really simplify the problems faced without dumbing down the language.
LI: The Puppet Labs documentation describes the Puppet language as much simpler than other programming languages. What makes it simpler and thus easier to learn and use?
Kanies: I have found through our seminars that within one hour, participants decide if they get it or find it too complicated. In practice, we find that most people take about two weeks from deciding, "I'd like to take some time with this" to "I've got it up and running in production doing real work and solving problems with my infrastructure." And that's not two weeks of clock time, spending 80 hours of active work. It's two weeks of calendar time.
Another measure is we have a three-day training class heavily focused on teaching people the language. In those three days we can train the vast majority of people in how to use Puppet.
LI: What factors led to expanding the free version to the commercial version of Puppet software?
Kanies: Prior to the commercial software, we had done a lot of short-term tactical training projects where we would show up, train a team, get Puppet set up, solve some specific problems that they had and then get out as quickly as possible. The biggest reason to switch to the commercial software was to solve that setup problem.
We were finding that spending three to five days on site was generally devoted to setting up peoples' infrastructure. So now with Puppet, that installation service is dead with Puppet Enterprise because in one click you can get the whole thing up and running with as much specification as our services people would take three to five days to do.
LI: Your web site boasts that the development of Puppet skills is one of the top trending jobs in IT. What type of training do you give to certify Puppet skills?
Kanies: Last year we officially launched our Puppet certification class. We are building out our certifications portfolio and will offer three to five certifications over the next year or two. It isn't a rubber stamp process where you show up and pay your US$1,000 and we make you look special. The goal is to provide a challenging certification that demonstrates expertise. We have seen a pretty strong response to that so far.
LI: Since you already expanded the open source version of Puppet to a commercial version with proprietary code, how viable is open source in today's market?
Kanies: You have to be pretty clear on the definition of open source. The entire world runs on open source. Nearly everything you do everywhere relies on open source. Every email you send, I guarantee you, goes through at least one email server that touches open source, and the vast majority of every website you visit is running on an open source stack. And that is all the way from the little Web server you are talking to down to the operating system and the kernel it is running on. In many cases the browser you are using to talk to that system is also based on an open source engine or something like that.
None of those is in danger of going away or becoming obsolete or being supplanted by a commercial replacement. If anything, open source has become more and more pervasive over the last 10 years.
LI: So how critical will the distinction between free and commercial become in the future as a business model?
Kanies: Today open source is generally better software that is more stable, more secure and better maintained. All those things that shouldn't happen because it is open source are absolutely happening. So the question becomes if you are a company trying to grow, how do you do that without open source?
LI: What, if anything, needs to be done to improve or advance the open source model? If you were calling the shots, what would you like to see happen next?
Kanies: I think I am calling the shots! In my opinion open source is not a business model. It is somewhere between a technique and a strategy. Fundamentally, if you want to be viable as a business, you have to sell something that your customers think is valuable that they can't get someplace else or think the overall deal is better with you. That is the only business model that has ever succeeded.
LI: So how did you make that business model work for you?
Kanies: For me there are three categories as a software company. You sell software. You sell promises around open source software. You sell services on the software. We do all three. We have proprietary software on top of open source. We have open source products. But if you buy our commercial products, we make additional promises about that open source software that we don't make to our wider community. And then we sell services around our software also.
The biggest danger is when an open source company gets confused about what it sells. If you think you are selling open source software, there aren't a lot of buyers for that now. But if you have promises about what you sell, those promises make a very lucrative business.