It’s a well known secret that (commercial) Open Source companies are quite small compared with their more traditional competitors. Company sizes of less than 100 people are common, some of the companies even don’t reach the twenties. And with this staff they need to do quite a lot, i.e. marketing, sales, support, strategy, and of course, product development. When looking at the core teams of even sizable software products it may astonish with how little manpower the development can be done. This is only partially because of Open Source. Yes, of course, it helps that you can use existing modules and frameworks and you don’t have to reinvent infrastructure type code. But what is even more important is the fact that many of these products and platforms developed are new, with little legacy and progress can be made quicker therefore. Modern software development environments are a further plus (i.e. continuous integration and testing) and the methodologies applied as well. What it comes down to is that two or three people together can come up with an impressive technology in few months and further progress after version 1.0 is staggering at least for some times. It’s only after a couple of releases when more traditional problems like the need for downward compatibility, migration paths, etc. start to influence development efficiency in a negative way. Many of the today leading Open Source technologies (be it CRM, CMS or BI and Systems Management solutions) have initially been developed by usually less than a handful people. And of course these small teams have had it much easier to coordinate things and agree on directions.There is a downside to all of this too of course. – The dependency to the individual contributors is significant and often Open Source projects fall apart when a key member of the development team leaves (or forks the code). But thanks to the nature of Open Source it’s still possible to base new developments on the existing source code.
As it has been discussed already quite widely (e.g. on the 451 CAOS blog) Nagios has been forked. The new project has been called Icinga and a nice website has been published. Of course this has stimulated some more discussions on whether a fork is actually a good thing or a bad thing. And as always there are good and bad aspects of such an event. I will not repeat the arguments here, but it’s certainly valuable to read the different opinions of people involved including one of the key developers of the projects.What is clear is that while creating awareness a fork also produces confusion. And what this example also again illustrates is that some of these Open Source projects have a very thin governance and astonishingly small core teams. And this is not good for Enterprises who think long term and are looking for future proof technologies.
Even the largest and most prominent commercial CMS vendors are taken over. It happened with Interwoven (Autonomy) and now with Vignette (Open Text). What we have as a result are “mega vendors” with multiple parallel offerings, confused customers, abandoned technologies and more migrations to come. If we compare this battlefield with the Open Source CMS landscape then it has to be said that the top 10 are pretty stable. Open Source CMS such as Typo3, Drupal, Joomla, eZpublish, Magnolia, Jahia, Apache Lenya, Alfresco, Nuxeo, etc. have continuously developed and are a good match for traditional commerical proprietary vendors in most use cases.With this newly announced acquisition of Vignette Enterprise customers will be worried and some of them will probably think about migrating away from Vignette, Open Source might well be a natural choice. Here’s a selection to start with.
It has proven that foundations, such as the Eclipse, Mozilla or Apache Foundation, are quite good vehicles to develop, maintain and distribute Open Source projects. We might even wish that more of the popular Open Source projects, such as OpenOffice, MySQL or Scribus were supported and driven by foundations. If the foundation approach is good, why don’t we see groups of Enterprises create new ones to act in their joint interest? Why don’t we see an “Insurance Open Source Software Foundation” (proposal for the acronym could be IOSSOF) to develop frameworks and platforms for the typical needs of Insurance companies? While there are few of these conglomerates out there, very few of them are visible and popular. But think about if let’s say 50 Enterprise MS Office users would just spend 10% of their annual licenses cost to fund an organization developing all the right Enterprise features for OpenOffice. With the estimated 10 million USD a nice team of developers could be paid for and the rest of the money could be used for governance and marketing.In many discussions with Enterprises people have expressed their interest in Open Source and the fact that they really like to use free (Open Source) software. But very few of them do actually contribute something back, be it work, code, bug reports, documentation or money. This is somewhat sad and impacts the Open Source eco system. Maybe Enterprises should see investments in Open Source foundations as a marketing and sponsoring expense and not take it out of the marketing budget. At the end there’s a positive signal when people read that insurance company XYZ supports the Mozilla Foundation, isn’t it?
Taking risks is not always in the best interest of a CIO. That’s understandable. But a risk averse nature also limits innovation and cost efficiency in many cases. If the old saying “CIOs never get sacked for buying IBM/Oracle/Microsoft” really still holds true, even during the economic crisis we are in, then it can be assumed that many IT organization leave out cost saving potentials. I have been in situation where CIOs rather went for multi million Microsoft Sharepoint projects than to take a bit of risk and work with well established Open Source alternatives. And even governmental organizations in most cases prefer the office suite from Microsoft instead of betting on OpenOffice.org, despite of the millions of license dollars to be paid. From a technical point of view this can’t really be explained. While both products may have their advantages and disadvantges, the usual needs of a government organization can certainly be fulfilled by both commercial and Open Source solutions.Two things are to be added here: First, Open Source technologies have improved a lot over the last years, they are certainly “good enough” for most use cases. Secondly, giving the tough economic time, focusing on spending money on true innovation and fostering the local IT services industry could be a good idea, especially for government organizations.
When discussing with large enterprises why they don’t see disadvantages of commercial proprietary software solution compared to Open Source they may point to an “escrow agreement“, a contract that ensures that they have access to the source code if anything goes wrong (provider going bankrupt, for example). So, in the worst case, an enterprise could take the source code and continue to work. But that’s theory. I have never seen a company making any use of an escrow agreement. And, different to Open Source, the code transferred under the terms of the escrow agreement, hasn’t been written with the idea of other people reading and maintaining it. Very few companies probably have the right people and skills in house to make use of the code inherited. So, while an escrow agreement signals “safety”, in reality it’s most of the time worthless.Open Source on the other side is very different. If an Enterprise asks a provider to deliver a software application with the intention to be published as Open Source code this ensures a number of things:
- The code (hopefully) is written in a way that other people can read and understand it
- The license chosen will enable the re-use of other open source projects and therefore limit the effort and cost of development
- Input from a potential community will increase the quality and provide input for further enhancements
- Processes and procedures inherited from other Open Source projects can enable higher software quality
So, even when enterprises sign an escrow agreement and can enforce access to the source code, they will always profit much less than when going the Open Source route.
Software as a Service continues to boom. Salesforce.com and other well known providers have been successful, even large companies see rented and externally hosted software as an option. The advantages are clear. (Almost) now upfront investment, monthly/yearly payments, reduced complexity and continuous enhancements and developments to make the solution better. This sounds like paradise. However there are some drawbacks too. Data needs to be stored externally, changes cannot be made so freely as if you own the software, any investment is sunk cost, little control over the software and sometimes issues with integration with existing (internal) systems. These disadvantages can be significant or not, depending on the situation a company is in. Sometimes the legislation may also have an impact. – And, to not forget, SaaS often is not cheap, numbers are typically user based and can stack up quite impressively.So, is Open Source an alternative here? Maybe. SugarCRM has agressively pitched against Salesforce.com and was able to win many former Salesforce.com customers. OpenOffice can be an alternative to Google apps or other internet based office suites. OSCommerce or Magento can be alternatives to rented online shops. If enterprises go the Open Source path they are well consulted to build some internal knowhow or to hire professional help. Done correctly though costs of Open Source solutions can be competitive with SaaS offerings.Regardless of what enterprises decide the probability that they will be using Open Source software – whether internally or as assembled components in SaaS offerings – is big.
RedHat has published an Open Source Activity Map to illustrate how different countries differentiate in the use and adoption of Open Source. This is quite an interesting tool to look at and when you compare the different countries you can see a number of tendencies:The European countries are still taking the lead with France being the most active, Spain and Germany following. Most of the top 10 are European countries. To a certain extent suprising it position 6 for the UK.The US, despite its size, is only reaching the 9th rank in terms of open source activity, China 15, India 23.Looking at the raw data it’s however worth a discussion how representative the results are. Linux – makes sense taking the RedHat view – seems to be to a certain extent equalized with Open Source. What I really liked about the analysis is the nice mash up with Google Maps and the ability to get an overview quickly thanks to Ajax and graphical visualization.
The announcement today that Oracle buys Sun is heating up discussions we had in the past. Is it good when large commercial vendors take over Open Source companies? Now, in this case, Oracle takes over a hardware vendor, but with Java, Glassfish and MySQL to name just a few, Oracle also “eats” a number of very influential and important Open Source projects. While I was positive about Sun taking over MySQL in the past, I am less sure whether I like this new situation with the largest commercial database provider taking over the largest Open Source database. MySQL has taking inroads into Oracle’s territory for quite some time and I am anxious that with this acquisition Oracle will try to marginalize MySQL. Now it also fires back that MySQL owns all intellectual property of the database management code, so forking will not help us as a weapon.What will happen with all of these other Open Source technologies Sun owned and maintained? Glassfish is a direct competitor of BEA (or the former BEA app server), Sun’s integration technology compete with similar technologies from Oracle. We haven’t yet seen a lot of committment from Oracle to nurture the Open Source projects in its possession. Let’s hope it’s different this time.
There have been a number of discussions lately on whether enterprises care whether what they use is really open source (EOS Directory), whether they are ready to contribute (Matthew Aslett, 451 chaos theory) and on how companies can design their revenue model (e.g. the open core thinking). Having talked to many enterprises over the last months and years they have their own perspective on this. Most enterprises want to work with long term viable partners, they want to use software that is still there in a couple of years and many want to purchase some sort of an insurance protection to make sure that if things go wrong they have access to help and support. The whole commercial software movements and the related VC funding is a consequence of this. However, not in all cases this lead to the best solutions and approaches. Many enterprises prefer software products that have a large community supporting it. Commercial open source software however often leads to models with fairly small companies doing the core development of a specialized product, the community being reduced to a testing and bug reporting role. Enterprises also prefer to have full access to the source code, even if they never want to use it themselves. And enterprises love software that can be supported by a number of different providers to create a competitive marketplace. Software from the Apache Foundation scores well along these criterias. VC backed open source companies forced to make money and therefore protect and monetize their IP have more difficulties to live up to these mentioned enterprise criteria. Seeing the constant changes in business models, license models and go-to-market approaches, companies out there are still looking for the recipe for success.There are a number of ways to make money with open source and combined with this there are a number of trade-offs to make and decisions to take:
- Should the core of the product be open source or commercial?
- Should extensions of the product be open source or commercial?
- Should you build a slim more consumer oriented version as open source and an enterprise oriented feature rich version as a commercial software?
- Can you monetize “management services”, such as packaging, testing?
- Can support services be provided for money?
- Do users need training services and are ready to pay for it?
- Can professional services such as product consulting, implementation/integration support be marketed?
When a company wanting to make money with open source has to answer the questions above, then there always have to be considered some consequences in key areas of the business. How will potential partners (needed to bring the software to the market) accept revenue models, how will a community react, how will potential customers cope with it? And does a decision restrict the company in the way other software components can be integrated or used?The ideal scenario for Enterprises might be a company with a widely open product (core and extensions) and an attractive but not mandatory services portfolio on top. Ideally the product is able to attract a large community and the processes and procedures applied ensure a high standard for – software quality and a manageable release frequency. It is obvious however that with such an approach growth and expected multiples are less attractive for investors than IP and product centric companies. We have even observed that a number of companies have moved away from the ideal scenario after they received VC funding and are now protecting and monetizing more and more of their IP. Which, in some cases, makes them a less attractive choice for enterprises.The continuous struggle on how to make money with something that is perceived as being free will continue. We most likely will see new models and trials and sort of “thanks” to the current economic conditions we well probably also see more humble approaches that may actually please enterprises much better than some of the marketing oriented open source misuses that we have observed in the market.