Open Source and the Abundance of Choice

Open Source is a great idea that enables people to build complex software projects in communities, and no one can deny that the open source community has produced excellent software for almost any purpose and need. Things became challenging, however, if one wants to create an environment based on several open source components that should work well together and serve their purpose well into the future. When the list of desired features is first created, and the overall architecture designed, one can start selecting the actual components needed.

The first step in the evaluation is often to search for potential products by using appropriate keywords and checking whether someone has already done something similar. Usually search quickly yields results such as: ”The 10 Free Open Source  Tools that Kick Ass”. Great! Someone has already done something similar and documented their experiences on their blog. In reality, however, the discovered blog article is often just a listing of products related to the given fields, with a brief description of each product.

In most cases the blog article has comments where random users tell about their own experiences with the listed products. Unfortunately, most of the comments only speak about specific features and particular products, and the poster hasn’t necessarily familiarized themselves with any other products except the one used in their organization. Comments which take a wider view and detail personal experiences with multiple products, are unfortunately less often found.

When the initial list of potential products has been made, it’s time to start digging deeper and comparing the products. It often comes quickly evident that forming a clear picture of the situation is not that easy. Also, one often quickly realizes that the program in question is in fact divided to into two versions: the commercial enterprise edition and the free community edition. So, now that you just had reduced the original list of ten possible products down to, say, five choices, you are back to square one. Next you have to assess how the community and enterprise versions differ from each other.

Next item on the checklist is project activity. In short, one needs to find out how actively each project has been developed in recent times. Most likely our original search has given us links and reviews of old projects. In the worst case, project may have not have seen any development in the last couple years. Or, alternatively, one might notice that the community has been so active that the project is forked into a couple new development branches – in which case you have to assess how mature each branch is compared to the original.

Finally, when the list has been reduced down to two or three best options, the actual work will begin. All the products selected for evaluation should be installed and tested. The mere installation is likely to take more than a few moments, especially given the fact that documentation is hardly the strongest feature on many OSS projects. After installation one should learn to use the selected products so that an evaluation of their features can be made. Somewhere between all of this, the nature of the API of each solution must be considered, and one needs to analyze how the API can be used to expand the solution and take advantage of its features.

As can be seen, the process of selecting the right product can start to escalate quickly, becoming more and more laborious and eventually the amount of work required simply explodes.

In my case the job is to select the needed set of tools for administrating corporate infrastructure. The amount of components needed for this is quite large. Because of this, success does not consist of merely selecting the best individual products, but I should also assess how the products can be easily integrated with each other – or with existing systems. Also, the choice of products cannot be just based on the amount of features each product has, but easiness of use should also be considered, so that understanding and managing the whole solution would not end up being the responsibility of a one single person.

When making choices, I tend to rely as far as possible to the existing software packages that are delivered with the operating system. Although discovering the right software packages from the operating system’s own basic repositories is not final answer to all problems, at least I can be relatively sure that some else has assessed a similar situation from a similar perspective because the software has been included to the distribution. It is also certain that, for example, security updates can be found automatically, without having to look answers from various project forums.

In my experience, you can do almost everything by yourself if you so wish. DIY solutions can often yield surprisingly good results. Yet, doing everything by yourself is not an end in itself, and, metaphorically speaking, Volvo often beats Ferrari. Volvo might not be the coolest car available, nor does it run as fast as Ferrari, but you can be sure that it’s durable. And if your Volvo breaks, you can be sure to find spare parts for it.

The writer is a Solutions Architect at Anders Inno.