Open Source Product Management: How do features get into Zimbra?

One of the great advantages of being an Open Source company is having a community and customer base that can help guide and shape the evolution of the product. Our community and customers use Zimbra in a wide variety of deployment scenarios from the single individual, to small and medium business, to hosted services and large Internet service providers. Such diversity naturally breeds some excellent ideas around product features and improvements. In many ways we think of our community and customers as product managers whose ideas and experiences can really help improve the Zimbra Collaboration Suite (ZCS). In order to fully leverage such a wonderful resource, it is important to provide the right set of tools and process to easily enable communicating ideas and suggestions to us. It is equally important that folks can track the progress of their suggestions.

We have a product management process and website that we have been using internally for quite some time; today, we are making the process and a version of the website public. Let’s first understand how enhancements make it into the ZCS.

As far as new enhancement requests (RFEs) are concerned, the center of our world is our issue tracking system (currently a modified version of Bugzilla). This system is open to the world and folk are free to add, edit, and browse issues at will. In fact, all RFEs are filed in it, and just about all of them (with the exception of those containing customer specific or sensitive information) are visible to the community. Typically, an RFE consists of a description, input from the community customers and Zimbrians, votes, and code “putback” comments from the engineers working on the feature. In fact, we have an internal website, built around the data in the issue tracking system, that we use to make product decisions – much more on that a little later.

How we decide what ends up in a release:

There are several criteria that we look at when deciding on which enhancements to include in a release. These criteria include:

• The number of votes an enhancement has received from the community;
• The number of support cases (i.e. requests from paying customers);
• The number of potential sales blocked by the RFE;
• The innovation/strategic impact the RFE may have.

As part of release planning, we gather a list of requirements that have the largest intersection of the above requirements and then make a quick level of effort estimate (a.k.a guess) on how long it would take to get the feature implemented. Based on this we adjust the feature set for the release. At the end of the exercise, we end up with a set of features falling into three buckets:

• P1 – RFEs that are hard requirements, i.e. those which we are willing to slip the release date in order to get completed.
• P2 – RFEs are lower priority enhancements that we will attempt to get completed;
• P3 – RFEs which are the lowest priority.

Generally P2 and P3 enhancements are either low hanging fruit, or features which may get completed for the release, but may slip out of it. I think an important point to keep in mind is that our planning process is both iterative and dynamic. That is, we don’t pretend that we can lock the feature set for a release, we realize that there are many factors that can change – sometimes frequently – causing us to have to regularly re-evaluate what is in the release. Such factors include technical discovery that impacts the time cost of a feature and changing market criteria (i.e. community, existing, and new customers input). Bottom line is that we try our best to hold firm to what we consider the “defining” features for a release, while at the same time realizing that as a company we have to be nimble and flexible.

One of the tools that is essential to our product planning and management is an internal website that we call PMWeb. PMWeb provides key information about past, current, and future releases, as well as important views into the issue tracking system. Almost of all of PMWeb is driven by the data in the issue tracking system. The home page of the site consists of a dashboard that shows:

• The list of top 20 most voted upon RFEs
• The list of top 20 RFEs with the most support cases
• The list of RFEs that are blocking sales
• The list of top 20 most voted on bugs
• The list of top 20 bugs with the most support cases
• The list of bugs that are blocking sales
• A list of bugs with critical and above severity
• A summary of past, current and future releases
• A summary of the number of bugs across priorities and severities
• Key statistical graphs such as find-to-fix ratio and find-to-fix rates

Every week we review the above data and make sure that key RFEs and bugs are assigned appropriately; we also review new inbound RFEs and execute an initial triage by slotting them in the current or one of the future releases. In addition, PMWeb provides detailed information on each product release and patches to released products such as:

• The RFEs slated for the release and their status (i.e. whether the RFE is uncommitted, targeted, completed, at risk, or at high risk)
• The bugs slated for the release
• The bugs fixed in the release
• The dates for the release
• Links to patches and future patches slated for the release (once the release has been… released

To help them in their role of product manager, we thought it would be useful for our community and customers to have access to this information and so we have made a public version of PMWeb available here.

There is obviously a lot more that goes into building a product release (and even patches to existing releases) that could fill many written pages; however this hopefully provides you with an insight into how we do things at Zimbra.