Back from Loadays

loadaysFOSDEM (the Free and Open source Software Developers’ European Meeting) is the largest OSS community developers’ meeting in the world, gathering 5000+ attendants each year, roughly double than it’s American counterpart OSCON. In both cases we are talking about thousands of attendees, really impressive figures.

Taking into account that there are way more system administrators than software developers in the world, it would be reasonable to expect a European conference for Linux sysadmins at least as big as FOSDEM, right? Well, that’s not the case. Maybe BOFHs are less social than developers. Maybe there is less need for community interaction among sysadmins. Maybe they are more product-dependant and they thus prefer attending more product-centric events. Maybe they just prefer attending events where it’s easier for them to find a girlfriend. Maybe a combination of all. But anyway, the best community conference for Linux sysadmins we found in Europe is Loadays (Linux Open Administration Days), in Antwerp (Belgium), and it sounds really tiny compared to FOSDEM.

As I needed to give it a try, I decided to I visited it last week-end and I must confess I am not disappointed. It is a young event (this was only its third edition), organized in a small school in the South of the city, with no more than 200 attendees, most of them from the Benelux. So, at first glance it looks more like a local event than a European conference.

However, the speakers did come from the whole of Europe (from France, UK and Spain to Germany, Hungary, Italy and Russia, and of course Benelux. Even some Americans) and the quality of their talks was very high. Just to get you an idea, there were lead developer and top consultants from CentOS, Puppet Labs, Percona, MariaDB, DNSSEC, Rudder, Zorp and even Zentyal, among others, in an event with no more than 30 sessions in total. Not the typical local event, right?

Also, being a small event made it easier to talk with everyone and the atmosphere was very relaxed and easy-going. It was also easy to set up pizza-diners and social events in the evenings.

Finally, I was impressed by the quality of the organization. I know how challenging it is for a small, volunteer-based team to close the required sponsorships and to get everything in place, so a big +1 for them.

In summary, Loadays is the hidden gem for European Linux sysadmins and it might get spoiled by trying to foster its popularity. So I do not encourage any reader to attend 😀

April 8th, 2012

7 tips on open-sourcing a project

CommunityOpen 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.

  1. 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.
  2. 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.
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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

April 25th, 2011

About open source business strategies

strategyA 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.

open_source_strategies

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.

January 31st, 2011

Disrupting the market of SMB servers

DisruptiveTechnology< 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
  • 3 comments December 29th, 2009

Four years of freedom

BreakingChainsOn a day like this four years ago eBox Platform was first published as open source. Anniversaries such as this one are good chances to stop for a moment and look back to how everything started.

Before open-sourcing eBox code we had been working in it for some 20 months already, since before summer 2004. Originally the whole idea of eBox came up as a joint-project between DBS (now defunct) and Warp in order to develop an open source server to offer small and medium businesses all the functionality needed to run their computer networks and network infrastructure. The stress was put in simplicity and usability, as most small businesses do not have an IT expert nor the time to set complex systems up.

After some work we quickly realized that a Webmin approach of developing just a web interface on top of a Linux system could work fine for a single network service but it lacked the service integration required for an easy-to-use, all-in-one solution. That’s where we started developing eBox as an integration framework, an abstraction layer that could turn a bunch of independent network components into a single entity. A kind of “glue” for network services in a Linux server. It was a beautiful idea, though challenging and complex, and no one before had proposed it.

The initial business model that was conceived for eBox was to bundle it in a specific hardware (a box) and sell it like hot cakes. Hence its name “eBox”. Clever, eh? 😉 Well, the amount of work needed to develop it turned out to be much greater than expected and we did not have enough resources to fund such an adventure and its market introduction, so we turned to search for public funding.

Our initial idea had always been to make eBox open source so we organized an event at the Chamber of Commerce of Zaragoza to give solemnity to the moment (in those times open source was in fashion among the public sector, but cases of businesses open sourcing their products were really scarce). We got over a hundred attendants, including some of the most important local politicians and IT entrepreneurs, and initial interest on eBox was pretty high, at least in the local context. However, this interest faded away during the following months and it was not until October 2006, almost a year after its publication, that eBox downloads started to take off, climbing to 2,000 from a meager 500 the month before.

It is really gratifying to see how long we have gone since the kick-off of the project and since we started with the development of the community. Now, with more than 2,000 members in our community and 150 new members every month we are becoming a well-established solution in the open source market and we can soon fulfill our goal of becoming the Linux Small Business Server.

November 30th, 2009


Archives

Tags

Feeds

Recent Posts