Interview with Kevin Kluge

Interviewers: Scott Swigart and Sean Campbell

Interviewee: Kevin Kluge

In this interview we talk with Kevin Kluge from Zimbra. In specific, we talk about:

Sean Campbell: Kevin, would you tell us about your background and your role at Zimbra?

Kevin Kluge: At Zimbra, I’ve had a variety of engineering management positions since I started in September of 2004. The company was about nine months old then, and we hadn’t shipped any products at that time, and we hadn’t decided to go open source. I’ve managed various parts of development, QA, and support.

Prior to Zimbra, I worked in the messaging space at a variety of companies, including Onebox.com, Phone.com, and Openwave, as well as Corvigo, which was an anti-spam company, also doing mostly engineering management..

Sean: Tell me a little bit about the history of Zimbra. What’s the big picture history, going way back past the Yahoo acquisition?

Kevin: The original concept for Zimbra was for an email archiving appliance. This was prior to when I joined. When they guys started talking to potential customers, most of them were satisfied with their archiving solution, but they were dissatisfied with their mail system. So the guys had implemented some early Ajax technology around archiving, and they were able to repurpose it into a mail system.

And so the original concept morphed, and we were going after larger customers who needed a small set of functionality, but they weren’t really ISPs–it was more companies like airlines, banks, and so on, that had a large number of boundary workers that they wanted to put on the mail system.

We shipped the first product release in about April or so of 2005, and we started getting real customers in late 2005.

Sean: Was some of the drive to have Zimbra constructed the way it is an effort to make the back-end mail server integrate with a lot of front-end points, all the way to MAPI integration with Outlook, high-end version?

It’s a fairly full-featured suite, and I find that technology stacks generally have a little bit of a blind spot. I had a Mac for the last year, and there were certain things in that platform that I loved, like the add-in chat client was probably the best chat client I’ve ever seen on any platform. But at the same time, Exchange back-end integration if you really wanted a shared calendar was lacking.

The open source communities always had a little bit of a gap there, and I wondered if that was an intentional thing Zimbra was trying to shoot for–to reach out at a multi-platform level via a web interface with a really robust shared calendaring solution.

Kevin: There were two things where we thought there were real opportunities in the marketplace. Certainly calendaring was one. Even the commercial calendaring products weren’t that great, and the open source ones were even more lacking. That was certainly a large opportunity that we saw and, after doing the basic mail application and address book, that was the first thing we went after.

We’ve also done a couple of other strategic things, because we noticed that a lot of the open source groupware was very difficult to install. We decided from day one that we would have a strategy of using existing open source components where possible and we would bundle them into our download, assuming that the licensing allows us to do so.

We wrote an installation mechanism that wrapped all the different components and then we also wrote an admin interface and management tools. These allow administrators to change one thing and have it propagate to two, three, four different open source components that need to know about it. We think that this enabled people to download and use Zimbra who wouldn’t have been able to if they had to download it and compile it or download it and 10 other packages, each of which had to be a particular version.

You’re also right that we did go after a cross-platform environment. We wanted to be the best desktop neutral solution for collaboration. We didn’t want to be a Linux desktop solution or a Windows desktop solution or a Mac desktop solution or a mobile solution. We wanted to allow people to choose whatever client they wanted, from the beginning. It took us a while to implement some of the features, but that was definitely the strategy, and I think it has been very helpful in getting both community adoption and commercial customers.

Sean: It sounds a bit like what Ubuntu’s doing with desktop distributions–they keep trying to make the process more and more elegant for installs, even with the integration of Ruby and so on. They want to make it increasingly, progressively easier to get the distro down on metal.

It sounds like you want to give someone a collaboration messaging solution that’s fairly easy to just get down under the metal and have a decent set of features.

Kevin: Exactly. Our target market is the IT administrator more than the developer, which is a different skill set.

Sean: On a different topic, since you were acquired by a “for-profit” company, what’s it been like to live inside that bubble? Depending on who’s talking about the MySQL acquisition, for instance, there’s either a massive amount of consternation, fud, or benefit.

You guys have lived in that situation since September, so what’s that been like?

Kevin: Certainly for us, it has been positive. Yahoo is a great company with a lot of resources and a lot of technology in-house that we now have access to, as well as resources in things like the hosted offerings we’re now working on. We’re able to do it with a speed and a scale that we would not have been able to do if we were a stand-alone company.

In terms of the commercial side of it, that’s been helpful as well, because Yahoo has more mature sales operations facilities than what Zimbra had, so we’re working to take advantage of those. But in terms of the product strategy and how we do support for our customers and how we interact with the community, it really hasn’t brought much change.

Mostly, Yahoo’s instructions to us have been to keep doing what we’re doing. The one thing that we are doing aggressively right now that we weren’t doing before is to build out a hosted offering. You can imagine, given how Yahoo runs its data center, that would be a priority. We’re working to put up a hosted ZCS offering. And we’re going to go after a wide variety of target markets with hosted Zimbra.

Scott Swigart: Let me ask a question in a little bit of a different area, in terms of some of the prominent old-school open source projects; like Linux and Apache.

The Apache Foundation has a way of doing things, where the project has to have at least three different committers who are not part of the same company, and things like that. But a lot of the kind of vibrant open source that you hear about–SQL, Alfresco, Zimbra, Zend did their work around PHP, XenSource and their work around the Xen hypervisor. There seems to be an open source project that has a primarily–if not exclusively–for-profit wrapped around it.

How do you view the open source landscape, and what do you view as advantages and disadvantages of some of the possible models? I’m thinking of the range between the one that’s basically “community” or at least no central corporate sponsor, one where there’s a primary sponsor, and then all the way over to proprietary software where there’s a primary sponsor and the code isn’t even available.

Kevin: I can tell you a little bit about our experiences, and where we’ve arrived in trying to navigate those three different options. When we were initially discussing whether or not we wanted to go open source, there was quite a bit of concern that we’d give away all this value, and then how would we make money?

The answer that we kept coming back to that had been proven in the market is that you can charge for support and people will pay for it. That lets you give something back to the community that’s a great piece of software, but as long as you can keep your development costs under control, you can still have a very successful business model. That’s where I think a lot of the older, more established companies had ended up.

We recognized that there was an opportunity to create a great product that gives a lot of value to the community. At the same time, we saw that we could also create a little bit more profit for ourselves by adding a few additional features that we believe that enterprises or large ISPs would want, and that they would be willing to pay money for.

When we started talking about that, and looking at what we wanted to get built in the next few years, we started to identify features that we could leave out of the community edition and still have a spectacular community product, and then potentially get a little bit more profit for the company by putting it in the commercial version.

Those discussions were very lively, and very animated. We really did debate almost every single feature, and try to decide which bucket to put it in. We have been able to do that successfully, so we do have maybe five or 10 features that are available only in the commercial edition. So even though we don’t give away everything, we still do give away enough so that people can be very successful running a collaboration system.

The community is extremely helpful on two separate fronts–one is the product management front, and the other is the quality front. In terms of product management, we have a Bugzilla system that’s open to the world, and then we also maintain what we call the “PM Portal.” Basically, it’s a website where people can go and view what features we’ve had, and what releases, and what we’re thinking about for the next major release.

When we make product management decisions, we look quite a bit at the data in Bugzilla. We look at what people are voting on, and we look at the comments they’re making about the features, and the use cases that they have for those features. That plays very significantly in our decisions about what features we’re going to go do in what releases. On the quality front, we get feedback primarily from Bugzilla, and then also of course the forums. The community has really been invaluable in helping us get new releases up to a stable point quickly.

We’ve done quite a bit of learning there–initially we did beta releases, both of the Community version and the Network version, for the 3.0 and 4.0 releases. For version 4.5.0, we did not do a major beta release, and the quality of the 4.5.0 release was below where we wanted it to be. I think that was directly because we didn’t do a good beta cycle. Then for the 5.0 release, we did a beta with the community, but we only did the commercial beta toward the very end of the cycle.

We think this was the best compromise between the different needs. It allowed the early adopters in the community to get the software, and install it, and give us feedback as early as they wanted to. At the same time, it didn’t put software out there for our commercial customers to install and then potentially have trouble with it.

The community’s involvement both in helping to define the product, and then helping to refine it has been tremendous. Without the community, if you’re in a proprietary commercial situation, you have to run these large-scale beta programs. I don’t think you get feedback as quickly, and I think it’s more expensive for you as a company to get that feedback.

Scott: Does the community actually submit patches, or is their role just posting bugs that they find, or posting issues that they find, and then you task your engineers with making fixes?

Kevin: That’s an area where we really weren’t sure what we were going to get when we made the decision to go open source. In total, I think we’ve had far fewer community code contributions than we expected, and my suspicion is that’s because Zimbra is primarily a product for the IT administrator and not for the developer.

We do have a process set up to accept code contributions from the community. The few code contributions we’ve gotten have been great, but it really hasn’t had a major impact on the product, aside from the fact that we’re bundling all these other open source components. I’ve been a little bit surprised by that.

The community has contributed a number of localizations for us that have helped spread ZCS to users that probably wouldn’t have run it otherwise. That was really helpful, since we were a start-up with no internal localization team.

Scott: What feedback do you get from customers about the value of making the source code available? Could you talk a little bit about the value that you think customers get, and the value that Zimbra gets back?

Kevin: The number of people who attempt to make use of the source code is fairly small–certainly with our commercial customers, it’s a very small percentage.

But for those who do, and who have the skill set to do that, they can make custom changes that they can reapply on releases, or potentially some of them will actually go in and make bug fixes for their own personal versions, because they can’t or don’t want to wait for the next maintenance release where we would address the bug. So, it definitely creates some value there.

That’s also helped some customers to be less concerned about the Yahoo acquisition, because they know that no matter what happens with any acquisition of the Zimbra technology, the source code has been released under a licensing agreement that can’t be changed.

So it’s definitely been helpful to some extent in the sales cycle there, as well as giving customers a little bit more of a piece of mind. We wanted to see the browser continue to evolve as a platform for applications, and we felt that we were pushing the limits of what could be done with browser-based technologies in our Ajax application. By putting the source code out there, we hoped that other people would take a look at what we had done and learn from it, and go do things as good or better than we had done with other Ajax applications.

The last part that we have been working on creating is a community around Zimlets–our mechanism for extending the functionality of the web app. We do have to define Zimlet APIs, and people could write code to the Zimlet API without looking at the underlying source code. But having the source code available certainly is helpful, when you’re trying to figure out why your Zimlet doesn’t work or when you want to implement some particular feature in it.

Scott: When Sean and I were at OSCON last year, people kept starting off their presentations with almost an apology for being a for-profit company.

How do you balance between your commitment to the community and the need to be profitable? As you work through decisions about what to offer as open and free versus what to put only in the enterprise version, how do you communicate with the community about those issues?

Kevin: We’ve given a fair amount of attention to that. Others at Zimbra might answer this differently, but from my perspective, I’ve always remained focused on what it was that we were giving to the community, and to creating a fantastic open source Collaboration Suite. We think we have done that with the constraints that we’ve put on in it, in terms of not handing out five or 10 additional features.

A key consideration for me has been that, while we may choose to limit the distribution of some features, doing that should not prohibit someone from being successful with the open source version.

Sean: Since your customer base tends more toward IT admins and less toward developers, that must inhibit the standard open source model of people contributing the features they want directly.

So what’s the filtration mechanism in terms of your average IT guy saying, “I don’t like the way you built this interface, ” or, “My users are complaining about the way the web email looks, ” and that kind of thing? How do you filter those requests to get them into the product; I find that for some open source projects, that’s a little bit of a struggle.

Kevin: I’ll make a couple of comments on that, and the first is that, even without the contributions of the community, there are a lot of people in Zimbra who are passionate about usability and the interface. They’ve done a lot of thinking and work and really had some tremendous ideas in order to enable us to create the application that we have. That’s definitely been a part of our success there.

The other part where the community has been very helpful has been interacting with us via Bugzilla. And we have built forums that we spend a fair amount of time on, but ultimately for us, for something to get done, there needs to be an entry in Bugzilla.

We’ve tried to steer the community folks into putting their ideas into Bugzilla, and we also have a couple of guys on staff whose primary job is to work with the community. Part of that is going through the forums and trying to figure out what people are complaining about, or else where someone has a great idea. We make sure we get that into Bugzilla so we can evaluate it.

The other part that has helped us is that pretty much everybody knows how to use email, so we’re not developing an esoteric product. We’re developing something that all of us use every single day. Of course, we run Zimbra internally, and have for several years now, and that has helped us work on usability as well.

Scott: Would you like to close off with something?

Kevin: To me, the most educational part of this process has been learning how to work effectively with the community, and how to integrate their input into the product management process. Then how to also work with them to give them something that, in terms of the beta cycle, gives the community something that’s good enough to be useful, yet immature enough to still give them an opportunity to really impact the quality and the feature set before it got released.

We’ve spent a lot of time working with folks in the forums, and we’ve built tools around Bugzilla to let us view the data that gets in there from the community. We had to set up some processes for when the community does file a bug, what we do with it. How do we make sure that all the information we need is in there? How do we make sure that we can reproduce it, and that we know exactly what the problem statement is before it goes to development?

Certainly, the community adds a lot of value. But you don’t want your development team to turn into a support staff for the community, at least not if you’re going to scale to a very large community base, which we certainly want to see happen with Zimbra. To me, that’s been an engineering management challenge, and it’s been a lot of fun too; the end reward is really great. I’m sure we wouldn’t be where we are today with the feature set and the quality that we have, if we didn’t have the community helping us.

We’re also really excited about the future. We continue to add big features to the product, the most recent being Zimbra Desktop and our support for BlackBerry devices with Zimbra Connector for BES. We’ll keep bringing the Zimbra experience and data to new platforms. And we’re going to launch a hosted Zimbra offering shortly that will make it even easier for admins to provide their users with the Zimbra experience. The community keeps growing, too, and we’re excited to see that continue in 2008.

Scott: It’s really been great talking to you.

Kevin: Thank you.

Bookmark this: