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.
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":
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.
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:
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:
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:
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:
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.
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):
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.