Back in 2008, many of the frontrunners of our Kopano team used to work at Zarafa. There, ten years and 100 days ago, we decided to make our groupware software open source. I knew the transition would be a challenge, but I also knew it was the right thing to do. Now that open source software is becoming more mainstream, I would like to share with you our journey to open source and the lessons that we’ve learned.
In the beginning…
It all started with the idea to introduce open source benefits into office automation by replacing Microsoft Exchange with a smart alternative. With the growing adoption of Postfix mail transport servers in the 2000s, we wanted to combine the strong points of open source backends, with the widespread use of Microsoft Office. This meant we had to create a product that made Microsoft Outlook compatible with open source mail servers.
Enter, Zarafa.
Zarafa was a Microsoft Exchange replacement that made use of quite a few open source products, like the popular LAMP stack (Linux, Apache, MySQL, PHP). However, during the first two years of its existence, the product itself was still proprietary.
Zarafa was very lightweight compared to Microsoft Exchange. And, because we used MySQL as database-backend, it could deal with much bigger databases. Email transport was managed by Postfix or Exim or whatever could call your delivery methods. Users were managed in the local database, the local Linux-system, OpenLDAP or whatever, could speak with the LDAP-protocol (including Microsoft ActiveDirectory and Novell eDirectory).
Going open source
As we became increasingly involved in the open source ecosystem, we started to discuss the possibility of making Zarafa open source so we could improve our software quality and increase our brand visibility. At the Zarafa summer camp in Brussels, in summer 2008, we – a diverse group of technical enthusiasts – came up with a list of considerations.
Current stack (ease of transition)
We first asked ourselves if we could make the step from closed source to open source within a reasonable timeframe and with our existing resources. Because all external components were already open source, the answer to that question was yes. After all, all that had to be changed was the core product and that, according to the team, would be doable.
Team commitment
As open source is all about teamwork, we felt that everyone in the team had to be committed to the ideology behind it. Fortunately, most of our team members were already involved in one or more open source communities on an individual basis. For them, going open source with Zarafa was just the next logical step: “practice what you preach”.
Business model
Our last consideration was the business model. Because would users continue to pay for our software when it would also be available for free? We decided to take the risk, and adjusted our business model from pay-per-license to a Freemium type open core subscription model. In this model, everybody could use our web and mobile components, but only paying users had access to our MAPI outlook connector and certain multi-server features.
The big transition
Of course, the transition turned out to be more challenging than anticipated. Not only needed our development teams to get used to the fact that every comment and piece of code would now be visible to the public, but we also had to deal with contribution agreements and think about the new business model.
The developers went into cleaning mode, while the rest of the company went into invention-mode. It wasn’t easy, but we managed: on 19 September 2008 Zarafa, now called Zarafa Collaboration Suite, was officially open source.
The news did not go unnoticed: we got Slashdotted. We had to call our hosting friends at night to ask them for their help. Shortly after, partner requests from over the world followed.
Many former Zarafa partners are now Kopano partner.
After the transition, we worked closely together with various distro packagers and maintainers including Debian, OpenSuse, Fedora, CentOS, Univention, ClearOS and many more. As a result, Zarafa was adopted by distro users over the whole world. The downloads on our website tripled, our server load exploded.
Lessons learned
Don’t be scared to offer things for free
As expected, there were potential customers who decided to use the free community version rather than the supported version. However, quite a few of these companies later switched to the paid subscription with guaranteed support and tested binaries. We realized that offering a free community version is a great way to let people play around with your software so they can see how it can benefit them. We found that if people liked what they saw in the community version, they were happy to pay for a professional, supported version.
Not everyone will be happy. And that’s OK.
Going open source, on the one hand, means more control for organizations using the software (think about data ownership and data protection). On the other hand, it means less control for the vendor. For example, other people can make changes to your code that perhaps were not on top of your priority list. This is all part of the open innovation game, which we think is great. But not everyone does. And that is OK. Let them go. Because open source only works when all parties are committed.
Collaboration is key
Working on an open source product with like-minded, talented people is fun and exciting. But it is also hard. For example, together, you will have to make adjustments to your packaging and architecture to enable distro maintainers to package your software. However, quite often, different contributors have different priorities and preferences. So if you want to keep the engine running, it is important to communicate and collaborate well.
Easier integration with REST API
We developed the so-called PHP-MAPI and Python-MAPI framework so PHP and Python developers could connect to Zarafa’s mail, calendar, and contact items. These frameworks helped to integrate with quite some other open source applications.
However, both of these approaches still required developers to have a lot of knowledge about the inner workings in MAPI. In retrospect, it would have made more sense to build a REST API to make the integration with the groupware stack easier.
Going all the way with Kopano
After two years or so, Zarafa was evaluated by external experts. One of these experts was Roberto Galoppini who developed an open source rating system, taking factors into account like maturity, stability, documentation, QA processes, packaging, maintainability and licensing.
It became clear that we should have thought better about how open source we wanted to be. Going open source is not just a matter of flipping the switch. There are many ways to make your solution as open as possible. You can choose to use open source 3rd party software, go 100% AGPL or anything in between.
With Zarafa, we started transitioning to open source without exactly knowing which shade of open source we wanted to be and ended up somewhere in between. At the time it seemed the right direction. Knowing what we know now though, we probably should have made a different choice. After all, the open core model goes against the open source model which encourages full transparency. Fortunately, when we started Kopano, we were wiser and went all the way: 100% AGPL.
In my next blog, I’ll try to provide some insights into the role of open source at Kopano and the way I see open source in the (near) future.
Want to stay updated?
Sign up for our newsletter and get the latest news and updates sent straight to your inbox.
