In the trenches with...Kevin Henrikson of Zimbra

We next go "In the Trenches" with Kevin Henrikson of Zimbra. Zimbra wasn't the first to build a slick email system with a strong AJAX feel, but it has clearly taken the lead among its peers. The backbone of that position is its engineering team, with Kevin at the heart of the organization.

As it turns out, regardless of all the "sex appeal" that Zimbra has in the market (and it has plenty), Kevin's comments reveal that it's community feedback that makes the company tick. Community feedback and an active engineering team that solicits and acts on that feedback, often in real-time. This is the heart of a successful open source business, and Kevin shows us how it's done.

Name, company, title, and what you actually do

Kevin Henrikson, director of Engineering, Zimbra. I currently manage our client engineering team which develops the Zimbra Advanced Client (AJAX based) and Standard Client (JSP/HTML based), the latter being Zimbra's answer to accessibility (screen readers), low-bandwidth, and older PCs. Along with John Holder, I am also responsible for Zimbra's open source community touch points (forums, wiki, blog, etc). I've also had a chance to speak at several conferences on many related topics including AJAX optimization, AJAX offline, and building large scale messaging systems.

Do you work remotely or in an office with co-workers?

I work in Zimbra's San Mateo, CA headquarters. I sit in an cubicle surrounded by the rest of Zimbra's management team. At Zimbra, offices are reserved for the most senior engineers.

If you've had a similar role in a proprietary software company, how does your current role compare? Similarities? Differences?

I've been an engineer and/or in engineering management for my past couple positions. Both were proprietary software companies one with shipping software and the other an ASP/SaaS model.

Zimbra, like my past experience in shipping software, goes through various development cycles. We define a release, write the new code, QA the software, and finally release it. However, some of those steps are vastly different in an open source model. The release, rather than defined by a few product managers, is compiled from open feedback from Zimbra's customers and community. A real-time view of this feedback is available at all times on our Product Management Portal. It lists the top issues sorted by votes from our community. We have an internal view of the same data with a slightly different weighting based on customer feedback. This ensures that our customers are given more weight in the new release planning.

As we develop the software it is released in real-time to SVN where anyone can grab a snapshot. Periodically we release developer beta or milestone builds intended to give early adopters the ability to run the entire application. This promotes an active dialog of feedback and bug reports with a much wider set of environments than Zimbra could possibly test on in house. This quick feedback lets developers work more efficiently, since we can identify big problems fast and track down hard to spot issues quickly. Once we enter the release candidate phase we can be pretty sure of the quality due to all the testing our community has helped with.

Open source is in many ways similar to the ASP or SaaS model in that you can release quickly and often. However, the SaaS environment alone doesn't promote the active dialog or feedback loop you get with a strong open source community. For example, I remember days we'd push a new release of our hosted application and even though we had millions of users on the system in might be days before engineering got any indication of how it went, in part due to the layers of support but also due to the lack of a public forum or blog where people were notified immediately that a new release was available.

At Zimbra we have the first success/failure reports show up in our forums within the first hour of a new release. As an engineering team the quicker we respond to these issues the faster our community will react next time. So it's a win-win that we are able to find issues or add new features quickly and our community gets to benefit from the free software we provide.

How familiar were you with open source before you joined your current company?

I was pretty familiar with the model and the way open source software was developed. I used several open source components in my previous positions, and also submitted patches and participated on mailing lists of projects like Jakarta, Apache, Struts, PHP, etc. I'd also been a casual Linux and LAMP stack user for many years.

Why did you join an open source vendor?

To be honest, it was the people. I'd known the Zimbra founding team and core engineers from before they started Zimbra. Having the opportunity to work with them again was convincing enough, but the ability to be part of the open source launch intrigued me. From my past run in with open source I really enjoyed feeling close to the code by being able to test the results of an accepted patch just minutes after it was submitted, unlike my job at the time where code I committed might not show up in a customer's lab for months or years. (It was carrier software which by its very nature had very long development and deployment cycles.)

How long did it take you to adjust to an open source operational mode?

When I joined Zimbra it was still in stealth mode and had not yet launched the company publicly. My first position at Zimbra was to bootstrap our community. Looking at leading open source companies at the time, like MySQL and Red Hat, we got a few ideas. We started with forums and a blog, then later expanded with a wiki. So my adjustment from a closed source mentality to a open source happened as Zimbra publicly launched in late 2005.

Even though we had always intended to release Zimbra as an open source project, there was some transition and learning, including routine tactical issues like creating developer documentation and publishing the source code. There were, however, also some surprises like requests for rare operating system ports or our first Slashdot which hit a network configuration issue on our firewall taking out our website for a couple hours.

And, of course, it would be fair to say that I'm still learning. Every day I see a comment on our blog or a post in the forums that causes me to rethink an assumption. Having a diverse and international community forces us to never stop learning and keeps us focused on what our community and customers think is important. There's nothing like nearly 10,000 forum members and thousands of customers serving millions of end user mailboxes all with open channels to email or post comments when they love or hate something we've recently released.

What do you think open source companies could learn from proprietary vendors?

[Matt's note: Kevin answered this from the perspective of what proprietary companies can learn from open source. I agree with what he says, so I'll let it slide.... :-) ]

Open source companies put lots of focus on providing open feedback loops and transparency in everything they do. Proprietary software vendors could provide ways for open and public feedback loops. Creating a forum or blog with engineers monitoring and responding is just a start. They could also open up new release plans for critique and voting by customers and users, or release a toolkit or developer toolset like Yahoo has done with YUI or Google with GWT. These allow you to keep your core business and software closed yet allow options for feedback and to grow a passionate community. We've taken a similar extension of this and will soon make Zimbra Desktop available for anybody to use as a POP/IMAP and calendaring client without the need for a Zimbra server.

Perfect, Kevin. I especially liked hearing about how Zimbra consumes and digests the feedback it gets from its community. Any company - proprietary or open source - could benefit from taking that lesson to heart.