Analysis Methodology

In preparing this white paper, we solicited our technical, functional and business experts, with the primary objective of creating a broad, practical reference guide to the best open source solutions on the market.

Choice of categories

We began by establishing a list of the categories that would be presented in this guide. It was necessary to do this due to the vast number of open source options available today. In the end, we selected only domains that make sense for corporate solutions, and in which Smile has previously implemented projects and has real expertise.

We assigned each of these forty-some categories to one of three "dimensions":

  • Infrastructure: IT asset management, firewalls, VPNs, supervision, virtualisation, operating systems, HTTP accelerators, etc.
  • Development and intermediate layers: corporate directories, databases, ESBs, web and mobile frameworks, search engines, MOM and EAI, etc.
  • Applications: CRMs, business intelligence tools, CMSs, EDM tools, portals, e-commerce solutions, etc.

Choice of solutions

For each category, we asked our technical, functional and business experts to select the best solutions, those which any company could use with complete confidence as foundations for its most ambitious projects.

We have attempted to make this guide as comprehensive as possible. More than 300 open source tools are presented here, offering you a broad choice for building the most appropriate architectures for your needs.

Assessment criteria

Our choice of tools was largely based on feedback from the field and our experience on hundreds of past projects. We also performed objective evaluations of six criteria applicable to all of our categories, an explanation of which you will find below.

Because we did not want this white paper to be a mere reference file, but rather a real guide for decision makers, we decided to make our results public.

It will thus provide you with reliable indicators covering each tool’s reputation, dynamics, the quality of its technical base, its functional scope, its expandability and adaptability, and the availability of resources/profiles to support you through its integration with your environment.

Wherever possible – and, in particular, wherever relevant – we calculated the average score of all solutions in each category in order to highlight the strengths and weaknesses of each specific tool.

The six analytical criteria are as follows:

Current reputation

A solution's current reputation is important, in so far as it can provide a sense of security or at least advance notice of potential issues. However, a reputation built on marketing investments will not last long if it is not accompanied by a dynamic community and basic technical quality.

While it will be decisive to implement a solution that is strong at the time of installation, it is even more crucial for the indicators to all have the green light, such that the solution will remain a good one over at least the next three years. Resource availability, pricing and upgradability will be directly dependent on this. For this reason, although the criterion of reputation is important, it is not enough to make an informed decision.

For this criterion, we considered:

  • Number and importance of customer references
  • Number and reputation of existing integrators (and are they independent? SMEs? large groups? is there only one integrator for the product?)
  • References in the trade press
  • Size of forum and mailing list archives
  • Google PageRank for the site, linked to the number of high-ranked websites pointing to the product’s site
  • Exchanges on social networks: Twitter, Facebook, Google+, etc.


This pertains to the solution's dynamics, particularly in respect of its community. Along with technical quality, this factor directly determines the position the solution will hold in the future. In the end, a vendor’s investments are not particularly important in view of the patches, documentation and even marketing that an active community can produce.

We believe that models in which the vendor is almost the sole integrator of its product are not favourable to the development of a community of partners contributing to the product’s dynamics.

For this criterion, we considered:

  • Increases in forum and mailing list volumes
  • IRC chat activity
  • Governance: how often are integrators and users consulted and included as stakeholders in the product’s design and upgrades?
  • Frequency of documentation updates, especially wikis
  • CVS/SVN code submissions
  • Frequency of releases
  • References by independent players, including occasional bloggers

Technical base

Investments and communities are still small compared with questions of coherence, power, and alignment with the modelling standards at the core of an open source application.

Functionalities are just the top layer built on these foundations, and the cost of implementation of the same business function can easily vary from one to five times the price, depending on the technical quality of the base. Thus, even in the case of tremendous investments, further enhancements to a product’s functional side will cease to be possible beyond a certain point, if the application is based on abstractions at too low a level, whereas a well-designed solution using clear and efficient concepts can, on the contrary, be expanded at a lower cost. Naturally, a financially sound vendor can recode its solution – a common practice today – but once your implementation of a solution has been rendered, it is quite difficult or financially impractical to adapt it to a vendor’s new offering if it has fundamentally changed. The ideal foundation should allow for continual enhancements; otherwise you will be the one to pay the price of brutal migrations.

For this criterion, we considered:

  • Compliance with existing standards (a sign of maintainability and ease of handling)
  • Power and canonicity of the abstractions utilised (sign of productivity, here referring to ORM, native web services, etc.)
  • Use of a framework
  • Degree of code factoring (sign of reliability and easy handling)
  • Strength of hooks, anchors and interfaces for dedicated plug-ins
  • Maturity and cover of web services
  • Product learning curve: a flat curve receives a lower score
  • Application modularity (Inversion Of Control pattern where possible, such that the application comprises a small kernel and plug-ins that take eqch other into account)
  • No obvious performance issues

Functional scope

This refers to the overall functional scope of the solution in relation to what is commonly found among tools of the same category.

It provides a valuable indicator regarding the tool's capacity, even if we do recommend, wherever possible, going down to the "macroscopic" level when comparing solutions for a given scope. Our thematic papers (open source CMSs, open source EDM, open source ERPs, etc.) can help with this type of comparison.

We would also like to note that, while this is an important criterion in terms of enjoying a tool that, from the outset, has as broad a scope as possible, the criterion of "flexibility" has a greater impact in terms of cost. This is because it can be relatively simple to add functionalities when a tool is flexible.

Flexibility / Expandability

Businesses must sometimes go beyond their tool’s native functional scope.  In fact, this is quite common. But how easy is this to do? This is a decisive criterion in terms of the total cost of ownership, given the cost of custom developments. Flexibility has many points in common with technology, but it places its emphasis specifically on the tool’s modularity and on the efficiency of third party developments.

For this criterion, we considered (among other points):

  • Possibility of adding plug-ins
  • Ease of modifying data structures to add or alter business object storage
  • Ease of modifying user interfaces to make them more ergonomic
  • Ease of modifying the processing performed
  • Speed and simplicity of development cycles: do classes need to be recompiled / redeployed, and do metadata need to be imported or exported to or from the database? If so, how are functional enhancements rolled out to a database in production?


Difficulty or ease of finding service providers on the market that are capable of performing advanced developments on the tool. Is it easy to find resources to implement a project? Will I be dependent on a provider?

Warning: Be careful not to misinterpret this indicator, because superior technology can easily compensate for more substantial initial adjustments. 

Know more