Open Source and its advantages and disadvantages over Commercial software

The concept of free software wasn’t very common 15 years ago when everyone were able to get a personal computer. Commercial software products were prevailing the market and almost everybody were either using Windows 98 or XP, the documents were written is Word, Excel was used for carrying out different types of computation, BsPlayer for watching movies, even WinRar was paid, although that there was a bug – once you start the trial, you stay with it forever. When I bought my first computer, I didn’t even know that there is an operating system called Linux which can be downloaded and installed for free. And I didn’t need to because Windows was offering everything for me. I was able to play games, watch movies, chat with friends, browse the internet, etc. Most of the PC user had limited technical knowledge and the commercial software developers were aiming for designing functional and user-friendly software. This time can’t be however compared to the early 70s, when the users were actually the programmers and most of the programs were developed by computer science academics and corporate researchers working in collaboration. The software products of this time were generally distributed under the principles of openness and collaboration, because of the fact that they weren’t seen as a commodity. Software was free mainly because of the necessity of improvements and continuous integration into new hardware platforms. This was happening because different academic cultures were involved in the development process, and when the software was given to somebody else, it came with its source code so that it can be tailored to fit the specific requirements of the user. [1]

Nowadays Open source software is more widely used, than 15 years ago and this is because people have realized that it has some major advantages over the commercial software. First of all it offers more flexibility than the Commercial software solutions because it can directly be modified by the user to fit its own needs. Of course this means that the user will have to be more experienced in terms of technical knowledge and also have to understand the source code but still it leads to some positives outcomes: users become co-developers and having more developers significantly increases the rate at which the software evolves. Also the users can fix bugs, write documentation or implement new features. This factor also leads to security improvements. Commercial software is made by highly skilled professionals who are aware of the potential security problems, but before releasing their product they can’t cover all of the potential security breaches. Instead what they do is to give the product to the end-user and if a security problem arises, they simply provide a patch with the necessary fixes. In the case of Open Source, because of the fact that the codebase is reviewed by many more people, such kind of security risks can be discovered on an early stage, so that they do not affect the end users.

Another advantage for the users is obviously the fact that they are not paying anything for using such a product. The industry has estimated that the use of open source programs saves up to 60 billion $ a year. Just a simple comparison here: people who are working with Java do not have to pay for working with specific IDE (Eclipse, NetBeans, etc) in order to use the full set of its features but the ones who uses the .Net framework have to pay around 500$, which is the starting price for Microsoft Visual Studio Professional 2012. This is particularly useful for range of different user groups from Freelance developers to Startups and even big companies which want to implement low-cost strategy for their development process.[2]

Open source programs are not dependent on the company or author that originally created them. In the case when the company fails or the author is no longer interested in supporting the particular product, the community can continue to keep the project alive and even improve it.

Of course there are some disadvantages of the Open Source programs as well. The most obvious one is that an open source product can tend to evolve more in line with developers’ wishes than the needs of the end user. This could lead to problems for the users. If they do not know how to use the particular product, they will have to either spend some more time on it or to pay for training. In many of the case when the user does not pay for the product itself, he or she pays for the support. If that is not the case then fixing a particular problem may take longer than usual because open source software tends to rely on its community of users to respond to and fix problems. There is also the problem of high maintenance overhead. As the source code is freely available over the internet there’s potential for a constant stream of user suggestions for bug fixes and patches. This turns to lead to flood of patches which makes source code significantly more complex and can potentially lead to structure quality issues. And structure problems leads to higher cost of maintenance. [3]

To summarize open source has its own advantages and disadvantages. Using an open source product may be very useful in particular situations, but in order to happen so one should understand its advantages and disadvantages compared commercial version of it.



[1] –

[2] –

[3] –

“Design Patterns: Not for eating” – a response article

In the article “Design Patterns: Not for eating” the author’s explains his vision of the world of design patterns. According to him they are “off-the-shelf recipes for solving common re-occurring problems and also that they are good for raising a discussion regarding these problems”.

He agrees that they are useful in some cases, because nobody wants to “re-invent the wheel” but in the meantime he also thinks that the design patterns should be used by experienced developers only. The reason for that is because if an unexperienced developer doesn’t spend some time on thinking about the problem he or she has, applying the design patterns in this case will result in “missing out the well-trodden path“ which I understand as not gaining experience and knowledge from the particular problem.

I don’t really agree with this statement because of the following reasons:

  1. First of all I think that the author is contradicting with himself, because according to him the unexperienced developers should not use the design patterns. But if they don’t use them then they should come up with a new definition on how to “invent the wheel”. And this is not very desired because for an unexperienced developer this will be much harder than for experienced one. I believe that unexperienced developers should be exposed to different kinds of problems, but this doesn’t mean that everybody should learn CPL (Combined Programming Language) in order to understand C.
  2. According to me unexperienced developers should try to use as many design patterns whenever they can apply one (of course this depends on the given problem whether it allows a solution based on design pattern or not). The reason for that is because I see the design patterns as a manual for commonly occurring problems. I also think that the use of design patterns will significantly increase the complexity of the problem, because before implementing a design pattern, one should understand it very well. And increased complexity means that the problem requires more knowledge in order to be solved, but once solved the rewarded experience from it will be more.
  3. Another point is that I think of design patterns as a way of providing a common language for the developers with different levels of experience. The experienced developers in that case will be acting most of the time as teachers and the unexperienced ones will be their students. And if there isn’t a common language between teachers and students, the students won’t be able to make much progress. This is of course only related to the problems which can be sorted out with design patterns.

This of course is my opinion and it could be wrong as well. I am simply defending the design patterns, because some of them have helped me a lot while encountering different problems in the projects I was working on. During my first internship in a software company the first thing I learned was the Singleton Pattern which later on I used in many projects (from university and job-related ones through personal projects as well).

Design Patterns: are they so difficult to understand?


Design patterns provide a template solution to a number of different problems, encountered while developing object-oriented software. They do not offer any finished source code (e.g. in the form of library), but more or less they provide enough description on the way how to solve a particular problem. They have been used for around 40 years and they have proven to be good (they are essential part of the skill-set of any software developer). They ease the process of software development in the way of providing a common language for the developers with different level of experience. But in order to use them, one must understand them very well. Although they are very mature concept, people nowadays are still arguing what is the best way to study them. According to some, the first step is to read a book which explains them. Other think that first a developer should learn how to test, then how to refactor and in the end how to apply them. But everyone agree that essential part of study is to start coding with them as soon as possible. In the next few sections I will cover two design patterns I have used in projects developed by me and I will also explain the steps I took in order to understand them.


Single Responsibility Principle:

The single responsibility principle is one of the five steps covered in the SOLID design and its states that a class should do only one thing. The idea behind this object-oriented design, is that if all the steps are applied while developing a particular piece of software, the end product will be a robust system that is easy to maintain and in the meantime is open for extensions.

Last summer I had the opportunity to work on a relatively big project with some experienced developers. I was the main developer of the project and I was receiving supervision and advices from my colleagues. I had to develop a sub component of the main application, capable of querying data from the RSS feed of the Apple iTunes store and storing into a database. Basically the steps for accomplishing this task were the follows:

  1. Query the RSS with some parameters and received the result of the query in the form of XML file.
  2. Parse the XML, extract some values from it and used the extracted information to create more lookup queries.
  3. Receive the response from the lookup queries in the form of JSON files, parse it and store it in the database.

So in general I end up with 5 classes (Main class, two classes for parsing XML and JSON, and a utility class with all the functions I needed) for accomplishing this task. They were logically structured in the same way as the requirements stated above. The component was working as expected and then I showed it to my supervisor. He said that it will do the job, but I need to do some serious refactoring if I want it to be readable by other developers. And by that he meant that if this structure makes sense in my head, this doesn’t ensure that it will do the same if other people look at it. The thing he proposed was to implement the single responsibility principle and further split my classes into more logical entities. After some refactoring, I end up with 8 different classes which were structured in the following way: Main class, two classes expressing the structure of both the XML and the JSON files, two more classes for parsing them, one class for generating both XML and JSON queries, a database handler class and a class representing the end product of the component. So to summarize I have changed the structure of the component in such a way that every class was responsible to do only one thing. At the end this made sense to me as well, because it was definitely easy to debug, and because I gave meaningful names to the classes, a developer who only knew the main idea of my project was able to understand the structure and the logic I am following just in a matter of few minutes.

Factory Pattern:

The Factory pattern is another heavily used concept. In general a factory class returns at runtime one of several possible objects that share a common superclass. The possible cases for using it is when the developer wants to provide an interface for creating objects or simply to encapsulate the object creation.

A few years ago I had to contribute for the developing of a tower defence game in JavaFX. The game was simple as it consisted of single map with multiple levels of monsters and five different towers. This was the first time when I saw the factory pattern in action. While I was browsing the source code, in the package responsible for creating the units in the game, there were a number of different classes:

  1. An abstract class called EnemyUnit with private attributes name (string) and damage (double), and public methods for attacking, moving, displaying and setting the damage and the name.
  2. Six different classes representing the different types of monsters in the game, each of them implementing the abstract class EnemyUnit with setters for name and damage.
  3. A class called EnemyUnitFactory which returns an object of class EnemyUnit. The factory class consists of a list of key-value pairs where key is an integer from 1 to 6 and the values are one of the six different unit classes. When the class is invoked, a random number generator generates an integer (with range from 1 to 6) and uses it to access one of the elements in the list. After the element is accessed and object of the given type is created and returned.

This design expresses the main idea behind the factory pattern which is to ensure that the factory has only one job – to create enemy units at run time, and also ensures that there is only one class capable of creating ships.



There are a lot of different design patterns who can be used straight away, or need some tailoring in order to fit in the project. Nevertheless they have proved to be useful and in my opinion every software developer should be familiar with them. There are numerous books with excellent explanation about different design patterns, but according to me the best way to understand them is with coding and practicing.