Zimbra Customer Feedback About Zimbra 9’s Open Source Status
John W. said he received a letter from a customer expressing their dissatisfaction about the recently announced change in Zimbra’s open source policy, starting with Zimbra 9. John shared the customer’s letter with those on the call. The letter states that the customer was originally seeking an open source email platform, which led to selecting Zimbra. The customer also states in the letter that Zimbra’s open source policy is important, as it provides assurances that the customer would not be forced to switch to a different product, should something occur at a future date with Synacor’s business, or a discontinuation of the Zimbra product. The customer makes the business case that without an open source policy, the customer would not have purchased Zimbra licenses or continued to pay for Zimbra support services.
Thanks again Randy for the effort and time to gather and post all this.
That customer is exactly correct.
This leads to a discussion this week on the mailing list. Here is yet another example (Bug) that is documented in both the forums and developer github comments/discussions for what I mention below so saying the community doesn't care or participates isn't accurate. This bug I mention below has existed in the product probably for 15+ years and a fix was provided with a 100% reproducible method to exercise the bug through the new bug tracking and reporting system that was recently introduced to for customers paying for support and licenses.
Bug was pid wrap around that stopped the MTA from starting. After a few months of waiting, I got wind of a discussion on github about a fix. Another customer (a respected redhat developer) attempted to argue his proposed solution for 3-4 months with his general purpose solution. That he spent time finding, fixing and reporting the bug and then I also did the same shows the incredible waste of community support and waste of our individual time thanks to this disconnected bug reporting system where we can't see what has been previously reported. Effectively, every bug hunter or investigation of a bug or user problem starts out on his own with no input from history of the community. That is incredibly frustrating and time consuming.
The redhat developer never gave up trying to get the fix accepted and it was incredible how hard he worked to get them to accept a fix. The comments in github will document this interaction with Synacor developers. I had given up and moved on but he ultimately pushed my fix through and withdrew his solution which shows you the level of frustration he had. My proposed fix was 1 line and for a reason. I didn't believe we could get the changes through he had requested and I wanted that critical bug fixed... Zimbra has always called an official postfix supplied/maintained script to directly start or stop postfix itself. The bug was Zimbra hand crafted their own status function to determine if postfix was running which had a critical bug. As a result the MTA would NOT start in some instances yet Zimbra reported it was running. Why would that be a difficult bug to fix given Postfix provided both start/stop/status calls in the same script which they already called for start/stop... That ment sudo was already setup and required nothing more than comment out a line and add a line to call the postfix status instead of their buggy function. It was finally fixed in 8.8+ but never fixed on 8.7.11 and I reported the bug and fix on that platform.
Here is the forum post after months of waiting and realizing that the fastest way to help the community was to directly post a solution and the problem. If I had not seen a zeta alliance call summary where someone was reporting this problem months later, I would probably never would have known they were stonewalling his proposed fix and jumped into the middle of that developer thread on github.
The community is here to support our Zimbra instances and we all have a vested interest in reporting, enhancing, supporting each other and fixing bugs so it's difficult for me to understand where the disconnect is with Synacor. We all want a stable product and when we have access to the source code, we can help identify and fix problems but more importantly it opens the product up to more future business that eventually leads to future sales and a more robust product. I have supported zimbra with a commercial license since 2005 so that wouldn't' change. What will change however is if there is no back stop to that commercial product then why did I invest my time and our staff's time to use the product. We chose an open platform for a reason to protect us should there be a discontinuation of the Zimbra product.
If a bug where the MTA doesn't start isn't enough to get someone's attention, what hope is there for any commercial customer to report a bug without a fix and have it resolved in a closed system? How can anyone support a closed system given this environment and how robust will this be for our customers.
I write this in the unlikely event someone at Synacor reads this.