Reductive Labs Q&A – History & the Road-map

As you might have seen yesterday, one of RedMonk’s clients Reductive Labs was funded yesterday to the tune of $2 million. While they work on and are core members of the popular Puppet project (which we’ve had plenty of interviews around in the podcast if you’d like some background), there hasn’t been a tremendous amount of talk about the company, Reductive Labs itself.

Getting venture funding is, of course, a company-centric event, so I thought it’d be a good idea to ask the “Puppet guys” about Reductive Labs. I emailed out the questions below to Luke Kanies, Andrew Shafer, Teyo Tyree, collecting them below:

Q: How did each of you get involved in working on and then working full time on Puppet at Reductive Labs?

Luke: When I left BladeLogic in 2005, I was frustrated that there was such a clear opportunity to build useful, interesting software in this space but that they weren’t doing it. After a month of thinking about it and negotiating with my wife, I decided that I would take the prototype I’d developed last year and see if I could build a company around turning it into a better automation product.

Andrew: I was a bit of a sounding board and a confidant for Luke when Puppet was just a twinkle in his eye. There were a few code commits early in the project by me and we had phone calls about Luke’s vision of the problems and potential solutions. As the project picked up momentum, I followed the conversation on the mailing list as I was working for startups as a developer in Salt Lake City. There was obviously more work than Luke could do at some point and he asked me to join up. I started helping our part time at first then went all in starting March 2008.

Teyo: Luke and I have worked together at a couple of companies. In particular, we worked together at Caterpillar Financial. At CAT Luke and I implemented an automated infrastructure using available tools, CFengine, ISconf, and LDAP. When Luke started Reductive Labs, I naturally was interested and had experience using these kind of tools in the real world. The timing was right last summer [2008] for me to officially join Reductive Labs. Now I travel around teaching our customers how best to implement Puppet. It is really gratifying to see Puppet changing the way systems can be managed. Back at CAT we struggled to get our ideas adopted and now with Puppet we have a real chance to become the standard tool for automated configuration management.

Q: Puppet is a pretty widely used and known about project, but not as many people have heard about the company you created around it, Reductive Labs. When did you, Luke, decided to form a company, and what was your plans for what the company would do?

Luke: The company was actually formed long before Puppet was, because I transformed my consulting company into a software company. I went full time on Puppet development in March of 2005, and my plan at the time was to build a company whose success or failure depended on its ability to produce software good enough that people would use it and pay for help with it.

There are many open source projects where money isn’t a good way to judge success, but in the IT space, so much money is involved in building and managing data centers that if you can’t get people to pay for something around your software, you probably don’t have very good software. Conversely, if you aren’t being forced to make and then keep promises to customers, then nothing is requiring you to actually keep pace with their needs, which is obviously important.

So, my plans were to build a company dedicated to building the best configuration management solution available, and I chose open source because it would make bootstrapping easier.

Q: How has the role of Reductive Labs to the over-all Puppet community evolved over the years?

Luke: Initially, we provided all of the development and support for the community, and we were also the only people giving talks on Puppet at conferences. Now, however, most appropriate tech conferences have someone giving a Puppet talk at them, and often that person is not employed by Reductive Labs, there are a lot of great, helpful people on both IRC and our user lists, and we are getting quite a bit of outside development help, mostly from users and customers.

So, our role has evolved into something like tier 3 support for the community, where we help resolve the particularly sticky problems, and we do a ton of code review for all incoming code. We also manage what gets accepted as a bug or feature, and, of course, we still do the lion’s share of development of Puppet itself.

Q: Most open source companies offering a pretty set standard of services – support, training, and consulting – all “meat-based,” if you will. Has Reductive Labs fallen along these lines?

Luke: So far, yes, although we do very little, almost none, of what people traditionally think of as consulting. We want to help our customers become Puppet experts – it does us no good to spend hundreds of hours on site with a customer if they then can’t take over managing Puppet internally. So really, all of our services are focused on helping our customers manage Puppet, rather than being outsourced sysadmins or something.

We’ve found that this makes it much easier to scale up the number of customers we can work with, and, of course, it builds a better relationship between us and the customer, because the sysadmins know that we’re trying to make them more effective rather than replace them and the management knows that we’re trying to build internal expertise rather than a dependent relationship.

Teyo: It is important to understand that what we are promoting with Puppet is not really just an opportunity to reduce overhead. It is about quality and agility. The data center is not static. Companies need to be able to change and retool fast. So if you have a staff, developers, sysadmins, and architects that can use Puppet to manifest change, change happens more accurately and more rapidly. With the advent of virtualization, hardware provisioning latency goes away. With Puppet and Virtualization organizations now have a stack that can really provide a truly agile environment.

Yes, we can and do provide consulting services that will automate your network for you, but strategically indoctrination and training really provides the most value to our customers in the long term. This works for us because we are grassroots. Automated minded sysadmins are our biggest advocates. If we can help their organizations succeed with Puppet by consulting, training and providing support, then we are going to be very successful. Think about why Linux has been adopted almost universally in the past 5 years. It is because it is far easier and cost effective to succeed with Linux. We want to be as ubiquitous as Linux and providing services that really enable adoption seem to be the best fit for us currently.

Q: What have been some of the more typical customer engagements and relationships Reductive Labs has had? Do you go to green-field installs, after the fact to “optimize” usage, address bugs, etc.?

Luke: The vast majority of our customer relationships start with what we call a bootstrap, which is on-site focused training of one or two internally designated experts plus setting up their test infrastructure. From there, they get a support contract and we help them build that test infrastructure into a production install over whatever timeframe makes sense for them. We usually do some code audits for them after their first revision of their infrastructure.

Andrew: Yes, we do all of these. The value that we can provide is different depending on the infrastructure needs and background of the organization. We provide greenfield implementations, code and process audits, custom development and training. Customers also have a separate ticket system to escalate issues as well as conversations to discuss best practices and features.

Q: I’ve talked with you guys frequently about the struggle to balance all the activities a small, open source company gets involved in – fixing bugs in the core project, adding in new features, supporting customers (paying and non-paying), evangelizing the project, and so on…and then all of that balanced against working on the commercial offerings (in form of additional products, training, etc.) Reductive Labs sells. Do you think venture funding help address these hassles? How do you think it might change what Reductive Labs does day-to-day?

Luke: We really do think the venture funding will help find that balance. Currently, we all wear so many hats that we lose a lot of efficiency switching between roles, but the funding will allow us to add some people dedicated to at least some of the roles. It’s especially difficult to be an effective developer with long stretches of unbroken time, and we’ll be using the majority of this funding to add engineers to the company. While we will always focus on community, and everyone at the company will be involved in the community to some extent, having engineers who can focus entirely on the code will make a huge difference in productivity.

We’re also excited about having engineers to dedicate to some of the more difficult but important bug fixing. There’s always room for performance optimization, but it’s difficult to find the time necessary to really do analysis when you’re always context-switching.

Beyond engineering, we’ll be able to hire dedicated support people, and they’ll be splitting their time between helping paying customers and the community, and managing things like the wiki and incoming tickets. We think it’ll be a great way to continually be involved in the community while building a ramp for internal people to gain Puppet expertise and work their way into training and consulting roles.

Andrew: Context switching definitely kills efficiency. The capital will help Reductive Labs be a more strategic. The short term impact is we still have plenty of work, plus the need to recruit new Reductive teammates, then get them onboarded, so I don’t see a shortage of context switching for the rest of the year. Once that starts to stabilize, then I like to believe we’ll carve out much more specialized roles.

Teyo: You know, I think the experience of bootstrapping a company and finding out what works has been great. It is good that we have been lean and focussed, but it has limited our ability to push new features and market to executives. With funding, we can be a little more strategy focussed and less tactical. I think this is going to lead to some real acceleration both in adoption of Puppet and in the development of new features and tools that enhance the current product. I wouldn’t expect us to loose our sysadmin focussed approach. We still want everyone to get to the pub early.

Q: In some of our podcast interviews in the past, we’ve talked
obliquely about Reductive Labs building an additional product offering
around Puppet. Can you shed any more light on what your thinking is
along those lines and how it’s shaking out?

Luke: Our primary focus is on a web-based console. Code just doesn’t belong in a GUI, but there are a lot of parts of Puppet that now really should be managed via a GUI rather than a CLI. Our initial product push will be getting some basic graphical tools in place to provide that simpler, better interface in the areas that make sense there.

We’ve got most of the designs worked out, it’s just a question of finding the people and getting it done. Thus, the investment is well-timed, because we can really focus on execution – we don’t need to do a lot of research, we can just get it done.

Disclosure: Reductive Labs is a client, and floated the idea of short interview as the above, the idea which, obviously, I liked.