Succeeding with Open Source

Most successful open source projects started out as open source. Zimbra took a different path: We cranked code for nearly two years in stealth mode before making the first public release of the Zimbra Collaboration Suite in open source in August of ’05. Since then, of course, it’s been a wild ride: Zimbra is now arguably the most popular open source technology in its category of messaging and collaboration servers. Zimbra’s success has led to inquiries from the owners of existing closed source software that are considering open source as a means to replicate that success.


All of us in open source land should encourage proprietary software vendors to go open source, but we should also be realistic with them about their chances for success. The Catch 22 is that it is precisely the widely deployed, highly profitable software technologies that have the greatest likelihood of success, but for which the financial risk of open sourcing is the greatest. The software that existing vendors seem most inclined to open source are the ones that have been losers as proprietary software. For them, open source is likely the last hurrah. The open source community is generally tired of such attempts to “put lipstick on the pig”. This is why, I think, the most compelling open source software and innovation comes from projects that have been open and grown with their users and communities from their nascent stages.

In quantifying the hurdles that formerly proprietary software must overcome, it is fair to ask why has Zimbra thrived in open source? Here’s my short list:

(1) Innovation – Zimbra is most known for our client and server Web 2.0 innovations. (Web 2.0 innovations tend to span the client and the server: consider Zimlets/mash-ups, ALE, server-side search, REST, etc.) We have argued elsewhere that if all the open source community does is deliver lower-cost versions of the existing closed source technologies, we will have failed to deliver on the promise of community collaboration. We must instead set our sights on doing new things and on doing the old things dramatically better. Innovation, first and foremost, is what makes the Zimbra Community fun.

(2) Use of Existing Open Source Technologies – Had Zimbra endeavored like most other email efforts before us to build our own blob store (we instead use the Linux/Unix file system with standard MIME format), our own mailbox store (we use MySQL), our own protocol handler (we use Apache), our own MTA (we use Postfix), our own index (we incorporate Lucene), and so on, we would have been unable to win so much community endorsement. (Ask you favorite open source companies which email and calendaring they are using.) Moreover, we would be years from having a viable product. The best news with open source is that the barriers to innovation have never been lower: innovative software ideas can be far more quickly realized via the re-use of open source building blocks and by mashing up existing Internet services.

(3) Modern, modular architecture and code base – Developers tend not to want to spend their smarts and sweat turning fifteen year old, nonmodular, formerly proprietary software into twenty year old, nonmodular, formerly proprietary software. The reality is that both the way we design and build software as well as the stresses we put it under have changed dramatically with the success of the Internet, Service-Oriented Architecture (SOA), managed code, and so on. I think my favorite compliment on Zimbra to date was when one of my WebLogic buddies said he felt he learned something by reading the Zimbra server source code. This generally doesn’t bode well for open sourcing older, proprietary code bases (The only chance is probably to have a really large installed base, such as for, say, Sun Solaris, which nevertheless has an uphill battle in winning open source converts from Linux).

(4) Transparency and ease of participation – Open source shouldn’t just be about access to the source code. Rather it is about enabling the community of developers, administrators, and even endusers to participate in “the sausage factory” of software development: filing bugs, suggesting or contributing new features, enhancing the documentation, developing mash-ups, building new “skins”, localizing to new languages, new authoring modules that support the ALE conventions, and so on. Such an “on ramp” of projects is critical for fostering a vibrant open source community, and it’s easier to make the right decisions when you are getting so much informed help.

(5) Intellectual property (IP) hygiene – We at Zimbra are zealots about protecting the IP “cleanliness” of the Zimbra code base. We are very careful about incorporating third-party contributions and technologies (generally using only state-of-the-art open source projects with compatible licensing) to protect the community and Zimbra customers from any potentially encumbered IP. In fact, I’m convinced there is now less risk of IP contamination (i.e., does your vendor own the IP rights to the software they are delivering to you) with open source than with closed source alternatives, and your investment is better protected to boot.

In closing, software developers most of all want their software to be used, whether that deployment represents a multi-million consumer service provider, a 100,000 seat enterprise, or a 50 employee SMB, we are deeply grateful to all those who have chosen Zimbra since it was open sourced nearly a year ago.

Comments are closed.

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures