The Economist has posted yesterday that “open source software has won the argument“.Others, for example Matthew Aslett expanded on this thought and asked additional questions, i.e. where to go from here.In my eyes this is not really about war and winning, it’s more about finding a well thought through co-existence of proprietary and Open Source software. It’s about industrializing software production, i.e. making the development process more effective and efficient. And it’s about broadening access to good software for everybody. There are good reasons for inventors and clever engineers to publish their work as proprietary software and generating some return for their hard work. And there are good reasons for opening commodity technologies and for leveraging the distribution power of the Open Source approach. I always stated that the future will bring co-existence of both worlds and this seems where we are heading too. Good for us.One caveat though: As it has recently been discussed there is still often no fair competition between commercial vendors and Open Source solutions. The case of Switzerland where a big Microsoft deal was closed without even looking at (Open Source) alternatives is an example. So, maybe the “war” is still not won?
Enterprises are used to purchase software following a standardized procurement process. This process is supported by commercial vendors by supplying information, answering RFPs, sending materials, providing free support, delivering proof-of-concepts. etc. When an Enterprise turns to Open Source, many of these things are not granted anymore, especially when you are dealing with community supported software. The illustration below compares a typical Open Source community, a commercial Open Source vendor and a traditional commercial software vendor along the services typically requested by enterprise.
What can be easily seen is that Enterprises must change their attitude a lot if they really want to deal with true Open Source communities. As not all of the Enterprises are willing to do so, an interesting market for “commercial Open Source” vendors has been enabled. These commercial Open Source vendors such as SugarCRM, Alfresco, SpringSource, etc. close the gap between what a traditional commercial vendor is offering and what a community is able to do. It comes with a price of course, but still is very attractive, especially when Open Source elements and commercial elements are combined in a good way.
When Enterprises are looking for Open Source solutions and technologies there are a number of information sources they can leverage. EOS Directory is one of them, but there are many more and they do cover different aspects.SourceForge is of course the mother of the inventories. It’s geared as a repository of all aspects of Open Source and lists hundred thousands of technologies. It shows projects and subprojects and therefore may contain just too much information to be able to quickly identify what you need.FreshMeat sits under the same umbrella as SourceForge and also provides a listing of a large number of Open Source projects. Again, no real filtering, masses of information.Ohloh takes a quite technical perspective and presents aspects of the code and the contributors. Similar to SourceForge there’s no intention to filter and select, therefore it’s a lot of information to go through.The Open Source Katalog is a consolidated version of EOS Directory for German language readers.Yeebase also publishes a listing of Open Source projects with user based ratings and concentrated information per project. The number of projects is substantially bigger than with EOS, there’s no Enterprise specific selection or filtering. The language is German.Ostatic is also one of the newer directories and grew already to an impressive size.There are of course many more things to consider depending how deep down you want to go, i.e. mailing lists, source code repositories, project wikis and so on. Starting with the listings and directories is though always a good idea. It’s easy to pick a short list and then go deeper where it’s useful. Google as the mother of search will also help and provide not only indications on popularity but also further links to explore.
EOS Directory is all about Enterprise ready Open Source software. And of course we have documented our criteria for the individual ratings on this site. But let’s take on step back and rethink what makes a project/software actually Enterprise ready. Of course different companies have different opinions but there’s quite a bit of consensus what is important:
- The software must be of high quality, reliable, scalable, etc. So all (most) of the traditional qualities must be fulfilled. That’s all about software engineering.
- There must be enough usage of the software to “guarantee” survival of the technology for the foreseeable time
- The software must be well documented, both in separate documents as well as in the code. There are companies who only use Open Source software, if there’s at least a book published on it
- There must be a vibrant community of a significant size behind the software. In some cases this community may be replaced by a company that would have to fulfill at least the minimum criteria in terms of size and financial viability. Here Enterprises are often forced to make compromises.
- The community (or company) governance is transparent and state-of-the-art methodologies, approaches and principles are applied when developing and maintaining the software. Many enterprises love the Apache Foundation for its strict set of rules here.
- There should be at least some market for professional support and integration services around the project. Ideally this market is where the Enterprise using the software is situated.
- The software is written in a programming language and using components and frameworks that are long term viable and ideally a standard in themselves. Many enterprises prefer Java based open source software and there are some where PHP is a no go.
- The license model applied is compatible with Enterprise usage and allows for enough freedom to not restrict the Enterprise in its development and business strategies.
- The functionality and features must be good enough to meet Enterprise standards. This includes security features, user experience and everything else you expect from software.
These criteria are representing quite a high bar and many Open Source project probably would fail in one area or the other. It’s though much easier to make a compromise when you can influence the roadmap or even the software itself. And here’s a true advantage of Open Source against proprietary software that by the way should meet most of the same critera and doesn’t in many cases.
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.