Two months ago there was a discussion in our forum proposing to make it English-only (it was mostly English, but there were two small Spanish and Portuguese sections). Almost at the same time, there was a petition to open a Dutch-speaking board. Which decision should we take?
Both options had good convincing reasons. If we standardized to English-only, we could avoid dispersion of information and isolation of groups of users in language-specific islands. Every comment, suggestion, solution and improvement could be shared equally for everyone in a common language. And Zentyal users need to have some level in English anyway, because no one can work in IT nowadays without understanding Shakespeare’s language.
However, even if people can understand written English, interacting in a forum is a different matter. Many users would feel more comfortable if they could do so in their mother tongue. So, forcing everyone in English might make us actually lose many interactions from potential users who can then start their own Zentyal forum elsewhere in their own language. The result would be eventually similar with either option, except that with an English-only forum, users interactions would be scattered in different sites, instead of different boards in the same forum.
With this rationale we eventually opted for a multilingual forum. We can open as many language-specific boards as required, with three conditions:
- The main forum language will remain English
- A board needs to have at least one person responsible for its moderation and maintenance
- Every useful contribution will be translated and shared in the English sections and/or in the community documentation
So, once we set these minimal rules, and once mmullenders kindly offered his help, we launched the Dutch board. The results have been very positive: the board started to get alive and during the 7 weeks since launch, it has accounted for some 5% of all the forum posts during the same time. More importantly, the number of Dutch forum member has increased by an astonishing 40%!!! Which means that either there were many Dutch who did not feel comfortable writing English, or that our SEO in Dutch has improved and we have been found by many new users searching in their mother tongue. That is easy to prove: take the words “VPN achter een proxy server” (VPN behind firewall), one of the topics started during the past 7 weeks. Now google them and the first result is our forum 
Proost Nederland!
Encouraged with these results, this week we launched the French board, again after a petition from the community and with a responsible for it (christian, one of our Forum Moderators, who happens to be from France). The results are even better: in just two days the number of posts in French have surpassed the total number in Dutch, and a google search of a topic started yesterday, with such a generic title as “Comment envoyer et recevoir des mails” (How to send and receive emails) is on the top 10 results!!! All I can say is: Mes félicitations à la communauté francophone! 
Now, when will we have boards in German and Italian? 
Tagged: Community, Contributions, forum, international, languages, members, Zentyal 21 July, 2011
Although this post might a bit off-topic, I believe it might be worth a try. At least, it brings back the blogging spirit I had some years ago, when I posted more often and spontaneously
So, I would like to summarize the lessons I found most interesting from a talk I just attended. It was delivered by Pekka Himanen at the conclusion of the 5th International Committee of Experts, a board created eight years ago by the city of Zaragoza among its efforts to promote knowledge society and become a hub of innovation.
Pekka Himanen, well-known by his best-seller “The hacker ethic” and his publication with Manuel Castell “The Information Society and the Welfare State: The Finnish Model”, is one of the internationally best-known researchers of the information age. He obtained his PhD in Philosophy as the youngest doctor ever in Finland at the age of 20 and was selected as one of the 200 Young Global Leaders in 2005. His talk was centered on the culture of creativity as a driver of economic and social development and here are the four most important lessons I found:
- Innovators, businessmen and culture. In order to create a hub of innovation you need three things: creative people, producers/managers (i.e. businessmen and investors) and a culture of creativity. I found particularly interesting the key role of entrepreneurs and businesses to foster innovation, specially in the current context when anything related to business is increasingly demonized (as so was shown by some of the attendants during the later debate).
- Athens, the innovation hub of all times. The most successful case of innovation hub in the Western world is in Athens, 2500 years ago. A relatively small group of people (a city-state estimated in 100,000 inhabitants) managed to develop by themselves the foundations of current Western culture, from philosophy to politics, law, science, literature and arts, in a relatively short time. Any small town has the potential of becoming a world-class innovation hub if the three previously mentioned ingredients meet simultaneously. By the way, the population of ancient Athens was 30% foreign. Food for thought!
- Innovation hubs happen in physical and reduced environments. Ancient Athens was 2 kms wide, and most of its cultural life happened in the Agora (the Greek forum), a 300×300 meters space. Physical proximity is not only important but necessary if you want to be innovative (heard that, bencer?)
- Switch the tragedy-mode off. In a reply to an attendee’s comment filled with bitter critics to politicians and collective self-pityness, Himanen explained the example of the Greek tragedy (yes, plenty of lessons to learn from our Mediterranean neighbors): it all started when the main character believed his fate was inevitably dreadful; after that deep conviction was attained, all his subsequent actions were just steps to meet his unavoidable final destiny. Real life is very similar: if we believe we cannot escape our dreadful fate, our actions will inevitably lead to self-destruction. Complementary to this line of thought, he commented that in nowadays society, there is a trend to outsource our own lives: we base our happiness in those who provide leisure and entertainment and we blame everyone else of our misfortunes, instead of trying to find the sources of our happiness and misfortunes in ourselves.
Pragmatic philosophy for a Tuesday evening…
Tagged: events, innovation, zaragoza 6 July, 2011
Open source is an attractive badge that most software vendors are eager to wear, especially in times when customers’ budgets are being tightened and their ears are keen to hear about cost cutting. However, many vendors’ approach on open source are filled with myths and false expectations, most probably because they did not experienced it by themselves.
During the last 10 years I have being deeply involved with open source business almost non-stop and from multiple points of view (system integrator, business association, software vendor, etc) and I have had the chance to discuss about it with many different people (customers, vendors, VARs, public sector, contributors, users, etc). So, I will try to sum up what I have learned in the way in just 7 tips, hoping to do my bit in understanding how software vendors can sensibly embrace open source.
- Know why you do it: once you open-source a product there is no way back, so you better know why you are doing it. There are many reasons why it would make sense for a company to open-source its technology. For example to improve the quality/functionality of its products, to grow its user base, to gain visibility, to prepare for international expansion, etc. However, open-sourcing will have a profound effect in many of the operations, from sales to marketing, business development and, of course, R&D. Have a very clear understanding of why you are doing so and communicate it internally before going forward.
- Make it useful: it seems an obvious tip, but I found several vendors planning to open-source their core product, but keeping an essential part under a commercial license. The result would be a useless piece of software, with no way whatsoever of doing anything unless you pay for the license. Needless to say it is impossible to develop a user community around a useless product. In addition, making a product difficult to install or undocumented will turn it almost equally useless.
- Be active: when a potential contributor stumbles upon your project, one of the first things he/she will decide is whether spending a few hours testing and learning about it will be worth his/her precious time. That is, does the project seem active enough and thus guarantee some continuity to make use of initial investments of time. If you just publish it and “let them come and code for free” (sic) you are very much mistaken. You need to show commitment with your own project, by fixing bugs, releasing new versions or answering questions in the forum, especially in the beginning regardless nobody is downloading it. Otherwise, you will not find valuable contributors
- Get ready for different kinds of contributions: many vendors have the wrong perception that the main contribution they might receive are “free programmers”. However, the value received from the community will probably have very different forms. To start with, testing and debugging is a cumbersome task that usually consumes around half of the total R&D resources in a product’s life cycle. A large community, by trying it in very different scenarios and by very different users, can hunt the most hidden bug. Moreover, localization, a costly task acting often as an important barrier for internationalization, can be another benefit that the community can bring to the table. User requirements, documentation, expert suggestions and, eventually, code can be some other valuable contributions as well. However, you need to make it easy for users to contribute and be ready to receive and process these contributions in an orderly way
- Plan ahead: to outsiders it might seem that communities spring out around any project like magic and that “build it and they will come” is the way to go. But that is far from reality. Developing a community requires a continuous effort in communication and promotion, as well as investing much energy in providing technical support and documentation for free. You might also want to open up your community governance to externals, which will require a careful design of rules and a plan to make it happen. All these tasks mean precious time and resources that should be reserved in advance
- Hunt the community champions: members in a community do not behave uniformly. In fact, a year ago I had a look at the behavior of Zentyal forum members and the results were enlightening: just like in Pareto principle, 20% of members were responsible for 80% of posts in the forum. That means that a community will very likely have a small core of enthusiasts, surrounded by a bulk of occasional contributors and users. You need to spot your champions and focus your energies on them
- Be patient: developing a community is a complex and long process of engaging in a conversation, creating trust, educating your users, sharing common goals and developing in common. It is not something that you can build in one day, but it will probably take a few years before you can call it a community
Tagged: Committment, Community, Contributions, Development, Governance, open source, Pareto, Tips, Zentyal 25 April, 2011
A few weeks ago, the 451 group posted an update for their open source business strategy framework, which summarizes the different strategies that can be put in place by an open source vendor in aspects like license, copyright, development and business model.
The framework is comprehensive but at the same time condensed, and it is quite self-explanatory for anyone in the open source business. However, I wonder whether it would make more sense to extend the framework to apply to any software vendor, including also the strategies that could be implemented by a business choosing not to open up the source code. I believe it would be very interesting to be able to grasp at a single glance what are the different options a software vendor can choose regarding revenue, licenses and development models, without having to be previously categorized into open source or closed source vendor.
One reason to support a more generic vendor approach is that it is very hard to implement a purely open source strategy, when most of the possible options are just a combination of open and closed source licensing: dual licensing, open core, open platform, etc. So, the limits between an open source-based business strategy and a closed source one are at least fuzzy. How much different would be, let’s say, a business developing an open core product under a cathedral development model from another business not publishing any of its code but giving away a trial version for free? They might execute differently, but the results would be reasonably similar: they would both find it hard to have a developers community but they would both have good chances to create a successful users community. Just remember that the largest users community is that of Photoshop, not quite open source I would say.
Another reason is that a company needs to be able to explain its strategy to very different audiences, from customers, partners and media to community members and investors, and not all of them are open source savvy. Sadly, one generation after the first release of Linux, a large part of the market and influencers still see open source as a geek, idealistic, non-commercial movement. Explaining the plan of action of an open source-based business as a natural set of decisions within a generic software vendor strategy framework would do much to overcome their initial prejudices.
And finally, if you have a look at the 451 group’s framework, there are actually few modifications required to make it work for a generic software vendor. For example, the list of revenue generators are valid for almost any software company, from Google to Microsoft, from Oracle to Facebook, from IBM to RedHat, or from a system integrator to a local reseller.
I believe the 451 group is doing a great job in analyzing and modeling different viable strategies for open source-based companies. But I also believe that there is a risk in assuming that their management and direction are completely different from more “traditional” software companies. In my opinion there are way more similarities than dissimilarities and there is a lot to learn from, let’s say Microsoft, but I leave that for another post.
Tagged: business model, open source, software, strategy 31 January, 2011
Time flies! It seems as it was yesterday when we presented Zentyal (then called eBox Platform) at the Chamber of Commerce of Zaragoza five years ago. It was a big thing, because that very day we were making the project open source software, allowing anyone to download and redistribute it, publishing the source code for free public scrutiny and starting the creation of a community.
As 5 years sounds like a round number, this might be a good moment to look back and summarize the lessons learned. I guess the main questions to answer are “If we could travel back in time, would we still make Zentyal open source? Is it worth it?” and “What would we have done differently?”
The first question is easy to answer: definitely yes. I cannot conceive Zentyal as closed source software and I wonder whether the project would exist today hadn’t we open it up then. I could sum up the lessons learned on the way in the following three points:
- Open source is the best market test: you will learn quickly whether the product has any interest among users and whether it is wise to continue investing your time and money in it.
- Nowadays in the software market, if you want fast growth and to become a relevant player in your market quickly, you need to be open source. If you prefer a slower, more traditional path of growth, you will probably be obsolete before you can become international.
- You need to know what you make open source and why: on one hand, once you open up the code you cannot take it back, and it is not straightforward to generate a sustainable business model based on a free product; on the other hand, turning a user forum into a user community is a long and costly process, so you have to be ready to invest time and effort in the community, probably more than what you would initially expect.
And what would we have done differently? I would have had a community manager/responsible since day 1. And I would have created a community-based organization/rules since day 2 (if not since the very day 1). These are key aspects that will define how your users will interact with your project and how your community will evolve. And most importantly, you can only see the results in the long term, so spending a bit of effort in the beginning means big gains in the future.
Anyway, let’s not become too philosophical. This is a time of joy and there is a big chocolate cake waiting to be tasted (courtesy of Heidi, thanks!). Happy anniversary Zentyal and cheers everyone!
Tagged: Anniversary, Community, Development, Zentyal 2 December, 2010
Some people have asked in the community forum how to pronounce Zentyal, as it does not seem straightforward in some languages. Well, the short answer is that we don’t care much about how people say it, as long as they say it The long answer is to mix Zen and Essential and pronounce it your way.
However, if you still want more detailed indications, here is a list of how we believe Zentyal should be pronounced in different languages:
Flags borrowed from Wikimedia.
Tagged: brand, Zentyal 23 August, 2010
As I pre-announced in my previous post in this blog, we are planning to change the way eBox Platform is developed. During the past seven years the project has followed a classic in-house development approach, where a company (us) has taken most of the responsibility. And as eBox Platform is an open source product, it has benefited from the help of a community of users. The community contributions have been very valuable, specially when it comes to product feedback, localization, testing and debugging. And thanks to all of us, eBox Platform is becoming a real alternative to Windows Small Business Server.
However, during the last few months, quite a bunch of community members have proposed to become more involved in the project, assuming some of the responsibilities that we are doing (or should be doing) now. From the start, back in 2004, we believed this was the right approach: to take the project to a stage where the community can lead its development, a true open source product. And now we think is that moment! Of course this does not mean that we are stepping out. Quite the contrary, our involvement can only increase from now on. But we believe that more people, not just the employees of one single company, should have the chance to get involved in the project and have the right to assume responsibilities, give their opinion and help taking decisions.
So, following the spirit of the Ubuntu community teams we are launching the Localization Team, a combination of language-specific, self-governed groups which will collaborate to achieve native-quality translations of eBox Platform. This team is just the first step towards a true Ubuntu-like community, with boards governing the community and the technical development and specific teams working on particular areas.
In order to coordinate the Localization Team, we have developed an initial set of simple rules which we consider logical and positive for the organization of translation groups. The team consists of a Localization Leader, elected for two years, as well as a Language Leader and a Quality Supervisor for each language, together with any translator who wants to join a translation group. The Localization Team will coordinate through the Forum and language-specific mailing lists and will meet via IRC once every three months to establish goals and take the main decisions. None of these rules are written in stone and we will be more than happy to see groups adjusting their functioning to maximize their own efficiency. Initially Mateo Burillo, from the eBox staff, will take the lead of the Localization Team, but we hope to see soon candidates from the community interested in coordinating the whole team.
So, if you want to help in localizing eBox to your language, you just need to register in our translation platform and start posting. It is advisable to register in the general translation mailing list too, in order to coordinate with other translators. And if you consider becoming Language Leader, do not hesitate to contact Mateo Burillo (mburillo at ebox-platform dot com) so that he can set up the needed infrastructure (mail lists and such).
Feel free to leave any comments to this post or in the Forum!
Tagged: Community, Development, Organization, Teams, Ubuntu 11 August, 2010
I am excited to break the news on behalf of the whole eBox team: We are going to change the name of eBox Platform! And although this is positive news, the decision was not taken lightly nor it has been easy to say goodbye to our former identity and find and embrace a new one. However, we have found that this decision was necessary, and the sooner we took it the better
As you can imagine, any name change is a complex process and there should always be a very good reason to do it. So, why do we do it? Why did we think that eBox is not a good name for us anymore? Well, basically because there is no box! Although our initial idea, when we started with the project seven years ago, was to embed the software in a particular appliance and sell boxes, we soon realized that it was much more interesting to focus solely on the software and develop a well-integrated, semi-automated, versatile open source server.
But this change in our approach has lead to a growing difference between what we do and what our name means. In fact, many people are convinced that we sell boxes when they first hear about us. Only once we explain what eBox really is and what is our subscription-based value proposition, they start to become interested in the product.
We have been thinking about making the change a number of times earlier, but as you can imagine, it is never a good time for something like this. However, during the past year the number of downloads, community members and general interest in eBox Platform has started to grow exponentially and we’ve become even more painfully aware of the faults of our current name. This has made us feel that it is kind of “now or never” momentum, and that the problem will not be solved by waiting longer.
Something that we would like to stress above all, is that only the name changes. We are still the same team, with the same goals, same open source license, and same everything. In fact, we are working on increasing our commitment on open source and adopting a more community-driven development model, but I will come back with that in a different post.
The new name will be made public in a few weeks and there will be additional information regarding the change in the Planet eBox and the Forum. Feel free to leave any comments to the post or the Forum and stay tuned!
Update: it has been disclosed, the new name is Zentyal!
Tagged: brand, eBox, Market 5 August, 2010
When developing an open source project you start to see some traction relatively soon after the first release. A few months later there come encouraging comments from enthusiastic users who soon become regular posters in the forum, mailing lists and IRC. The downloads figures and web traffic statistics start to rise, slow but steady. You start receiving contributions, appearing on magazines and blogs, seeing a word-of-mouth effect being constantly spread on twitter, receiving a flow of partnership proposals all around the world, and you start wondering “Did we really do it? Do we have a product that really solves an important problem better than any other product? Are we the best thing since sliced bread? Are we going to become really popular, like Janet Jackson after showing her boobie at the Superblow?”. And then, back to earth, the questions in mind are rather “So, how could we keep in track and reach our full potential?”.
Getting the first enthusiastic supporters and starting a word-of-mouth effect is just the beginning. Unless you try to push it somehow, it will take many years before you become a little bit known mainstream, if you ever get to that point. And when you push forward, there is still a long and exhausting road to take your project to a tipping point, after which the whole word-of-mouth process accelerates and takes traction by itself. And just bear in mind that the effort you will need to invest is very considerable and the results can only be seen in the mid-term, so you need to remain constant.
At eBox, we considered from the start that communication and promotion of our project was crucial if we ever wanted to get to a critical mass of users, and we knew that sporadic appearances in media or blogs was not enough to take us there. So, for the last 18 months we have had a full-time person in communication, which is a lot for a startup with no external funding and with strong needs in resources for R&D, service delivery and sales. There was a lot of work to do first setting up the communication basis before we could start with any visible action, but now things are up and running and we have well-established processes that can help us, for example, to start, spot and participate in discussions about eBox on the Internet.
However, having full-time professionals in communication do not generate popularity overnight. Although we had a healthy growth in all our indicators for the past 12 months (around 5-10% monthly growth in downloads, in new forum members, in incoming links, etc), we are just now really harvesting the fruits of our communication efforts. There are at least three facts that prove that eBox is becoming popular and getting closer to the tipping point:
- Linux Format, the leading Linux magazine in the UK, made a benchmark about Linux firewalls for its June 2010 issue, where it included all the best-known firewall-specific Linux distributions, and eBox. The fact that eBox was included would be just a good reason to celebrate, but it becomes better, as it was actually chosen as the best firewall solution!
- Security researcher Russ McRee found a security vulnerability in eBox during last month, which was promptly solved. Although we cannot be proud of any security vulnerability in eBox, it is definitely an important milestone that security experts start to specifically look for issues in our technology.
- The average number of eBox downloads during the past 6 months has more than doubled last year’s average. We are now close to 30,000 downloads per month, which looks like a pretty good number. Last month at LinuxTag I attended a presentation by Larry Augustin claiming that SugarCRM had 60,000 downloads per month. This means that eBox, without the $30M+ in VC funds of SugarCRM, has managed to reach almost half of their numbers. I agree the comparison is not direct: a small business server is not the same product as a CRM, but we are both aiming at the SMB server market, which makes the comparison still valid.
So, things seem to be accelerating now. In my view, there is still a lot of work to do to get to that tipping point, but we are getting closer everyday. This would be a good timing for us to reassess our identity and make sure that all our communication elements are right and in place, before any further change becomes painfully costly.
5 July, 2010
< borrowed from Wikipedia >Disruptive technologies are innovations that improve a product or service in ways that the market does not expect, typically by being lower priced (“low-end disruption”) or designed for a different set of consumers (“new-market disruption”). Disruptive technologies are particularly threatening to the leaders of an existing market, because they are competition coming from an unexpected direction.
In low-end disruption, the disruptor is focused initially on serving the least profitable customer, who is happy with a good enough product. This type of customer is not willing to pay premium for enhancements in product functionality. Once the disruptor has gained foot hold in this customer segment, it seeks to improve its profit margin. To get higher profit margins, the disruptor needs to enter the segment where the customer is willing to pay a little more for higher quality. To ensure this quality in its product, the disruptor needs to innovate. The incumbent will not do much to retain its share in a not so profitable segment, and will move up-market and focus on its more attractive customers. After a number of such encounters, the incumbent is squeezed into smaller markets than it was previously serving. And then finally the disruptive technology meets the demands of the most profitable segment and drives the established company out of the market. An example of low-end disruption is the way digital photography has largely replaced film photography.</ borrowed from Wikipedia>
No market is shielded against disruptive technologies, and the market of SMB servers is no exception. In fact, it shows all the conditions for such a disruption to happen, as it is a market in which:
- There is a clear leader (Microsoft)
- With a mature product (Windows Small Business Server)
- Over-provisioned product, providing more functionality than needed and overwhelming end users by the plethora of features
- Established on a continuous, evolutionary innovation cycle
- With little or no commercial interest in the lower segments of the market (WsSBS has no product or pricing segmentation for customers under 75 employees)
- With a strong motivation in abandoning the less profitable customers and focus in the more profitable ones (rising the license price by 80% is forcing customers in the low-end to look for alternatives)
Moreover, Linux and the open source tools for network management (Samba, Postfix, Squid, Snort, eGroupware, Spamassasin, ClamAV, etc) have a huge disruptive potential in the SMB server market, as they bring a great advantage in pricing (in fact, they are free). Besides, similarly to other disruptive technologies, they started offering a lower level of functionality than their closed source alternatives, but they have evolved and caught up or even surpassed them in many markets (close to 90% of the supercomputers in the world are based on Linux, which is a good indicator of the quality level this technology has reached).
However, in spite of these conditions, open source solutions have a very low presence in the market of SMB servers. The reason is simple: for a server solution to enter the SMBs, it needs all its components to be tightly integrated and be easy to administrate. SMBs do not have resources nor time to deploy complex high-performance solutions, so highly integrated products such as WsSBS cover pretty well SMBs’ technological needs.
This is where solutions such as eBox Platform, developed after the integration of standard open source components, have the required disruptive potential to change the market balance. On the other hand, as the software integrating these components is also open source, there are additional advantages, both in development costs (users community greatly helps reducing the effort needed for design, development and testing) and in sales and promotion costs (due to the word-of-mouth effect generated by the community and the option to try the product without previously paying for it). Thanks to this, it is possible to compete with the market leader with a lower cost structure, turning thus the market of lower-end customers profitable.
Finally, as it is not possible to use a traditional license-based business model, there is need to be innovative in the value proposition and bring it closer to customer’s needs. For us the solution came in the form of SaaS model (access to the eBox Control Center, offered mainly for VARs and MSPs) and subscription services (disaster recovery, cheap VoIP calls, security audits, reports and alerts, etc), which are not offered by the market leader.
In summary, the key points to disrupt the market of SMB servers are:
- Focus the product initially in the lower-end of the market, to later improve in functionality and start growing in the market stack
- Center the innovation effort in improving system integration and task automation, as well as usability and easiness of administration
- Use open source methodologies for development, distribution and commercialization of the product, generating a user community around the project
- Develop the value proposition in technologies and services that allow for a better convenience of use, such as SaaS or subscription to remote services
Tagged: business model, disruptive innovation, eBox, entry strategy, Linux small business server, Market, open source, small business server, SMB 29 December, 2009
Previous Posts
Zentyal in English
Zentyal in Spanish
Zentyal in German
Zentyal in French
Zentyal in Italian
Zentyal in Russian
Zentyal in Chinese