Open source tools have been gaining momentum in recent years, largely due to the contribution of several factors, including improved user interfaces, the inability of commercial companies to compete on development quality, the level of support received in open source forums, support for multi-platform open source projects, and the development of small modular interfaces that are interoperable and not interdependent.
But what is open source code? Is it the same as free software? What might be the motivation of an organization that implements such tools? What are one’s motivations in developing in this open source manner? Most importantly – is it profitable?
Let’s imagine for a moment that I’m a pastry chef who managed to bake a cake that nobody’s ever succeeded in baking. I created a cake recipe that explains exactly how to bake it. Without the recipe, there is no cake. In this case, the most important business step should be to keep the recipe totally confidential.
In the world of software, we have a similar situation – the software you run or the page you are currently browsing contains millions of computerized instructions that make the computer do what it does. These instructions are written in a language that computers will understand precisely: machine language.
The problem is that the language of computers is a world apart from how humans communicate – rendering both incapable of understanding each other.
This situation has two solutions: simultaneous translation and pre-translation. This situation, it seems, resembles my home; When I ask my youngest daughter to tidy up her room, she doesn’t always seem to understand the words I am saying, but when I ask my older son to ask her the same question, she tidies up her room very quickly and suddenly I am able to see the rug in the room again…
The assumption is that humans understand English quite well and that software can converts instructions that were initially written in English (more or less) into instructions within a language that the computer can understand. Therefore, there are two options: writing in English and running a program that will know how to translate the English instruction file into a new file written in computer language, or writing in English and running a software that will read English instructions, translate them, and letting that run on the computer until the file is completed.
The essential difference between the two methods is that in the first, at the end of the process you will receive a rather non – understandable file by humans but excellently understandable and taken out by computers, whilst in the second method, the only file produced will be an English instruction file that one can read and change at any moment.
The most obvious advantage of the first method, from a business point of view, is that if I were to write the instructions in English and translated them into computer language, and subsequently gave the result file to someone, it would be very difficult and almost impossible for them to understand my intentions in the computer instructions, that were to make the computer act in the way it was acting. In other words, everyone who were to receive this file would be able to enjoy it as if it were a delicious cake but wouldn’t be able to bake it themselves.
In all fairness, it is also necessary to note that the first method has another advantage in the performance field, as once the English instruction file is translated into computer language, there is no need to re-run the translation job – resulting in a quicker process. However, with the presence of today’s fast processors, in many cases, it is difficult to notice the difference in speed.
Today, in many cases, most software companies still sell software products built with the first method mentioned above, and we are in fact receiving computer file instructions without the ability to fully understanding the way they operate, without knowing how to improve them or/and effectively connect them to other products used. Most software products we use daily are in fact these “cakes” that we are talking about.
In the real world, we are used to a similar concept – many of us purchase vehicles from a certain manufacturer, but not many of us maintain or fix them at the same manufacturer. What prevents a customer who bought a vehicle from one manufacturer from assembling components that are not from the same manufacturer? At the end of the day, nothing. It certainly violates the terms of warranty as no manufacturer support can be expected after changing the components of the vehicle, but technically, this customer isn’t blocked by any limitation. If he were to sell his car in the future, with or without the extras, or decide to dismantle the vehicle due to an interest in its’ mechanics, that would be perfectly legitimate.
The software field is the only field where customers are still limited by these aspects. For example, when a customer buys software, he agrees to its license not to sell the software or make any changes in its operation. In most cases, even if the customer desires to make changes in the way the product functions or to learn something new about how it functions, this isn’t possible due to the usage agreement or due to the fact that the customer does not own a human-readable instructions file to work with. Due to this inability to read or correct the instructions when necessary, such products (which we receive as computer instruction files) often present difficulties in 3 areas:
- Bugs/Security weaknesses: If I were to receive a file containing instructions that could only be read by a computer, how would I be able to tell whether these instructions are matching to what I had initially intended them to do? Perhaps while my word processor prints a file, it also transfers money in parallel from my account to an anonymous attacker, or records my password while passing them to a foreign entity?
- Interface components and other software: If the file received is written in a language that only a computer is capable of understanding, it is impossible for software to communicate with other systems and components. Evidently, some software already carries this ability, but connecting the software to a brand-new set of unfamiliar components isn’t a possibility because the file received is unchangeable.
- Lack of necessary features: In fact, this disadvantage is an extension of the previous one. When in need of a certain feature, for example language support in a word processor, this is a desired feature that would be impossible to add to a computer language file.
If one is not a particularly talented programmer, it is true that an English instruction file will not be of great use either. However, if the file delivered contains English instructions and is read and operated by millions of online users every day, it is likely that someone has read it – in the case of finding malicious code, he would report that or at least alert other users about its presence. In addition, in the case of a missing desirable feature, it is likely that someone somewhere on the network would have needed to use it in the past and found a programmer that could integrate it into their product.
One of my wife’s friends once stated that any recipe that contains more than three ingredients or an ingredient requiring at least a day of preparation, is automatically deleted from her list of favorite recipes. I believe this is because she was worried that if the recipe would be too complex, she would be prone to making more errors in its’ preparation.
In the world of software too, it is important to emphasize that such instruction files may contain thousands of instructions which would cause the software to function incorrectly (causing the word processor to sometimes replace the default printer, for example) and once again, if written in English (or is accompanied by the original English instruction file), there is a likelihood that many users will have read it and found errors. Therefore there is a high chance that someone has already corrected or reported them.
If there are so many positive aspects to this, why do I still need to pay for software? In other words, if this is such a successful method, how is it that it is not considered as the main approach today? As expected, the answer is…money. A lot of money.
Numerous software houses, throughout history, have almost entirely been basing their business model on one-off development projects (apart from improvements and changes made) and have collected payments from customers. The advantages of such a model for the software house are clear – the development, which is the most expensive part of the process, is established in a fixed period of time, and the implementation of the software for the customer is performed in a very systematic way.
Nevertheless, is this considered the only model for the development of a quality software? The alternative is the open source model. This model is seemingly simple: The developer creates the software and publishes the original software file and instructions for download – enabling users interested in copying, distributing, modifying, learning, 0r using it for free.
This sounds rather impressive, and mostly utopian, but is it truly possible to expect developers to provide such a service without demanding any wages for it? What exactly would be the developer’s motivation to do this job? What extra value would such software products bring?
The motivations for open source development are varied. Some developers decide to develop open source for altruistic or ideological reasons based on collective contributions, and others for anarchist reasons aiming to distance themselves from big software companies.
However, there exists another motivation; there are companies that decide to release their product through the open source approach precisely because their aim is not to sell it. For example, if a large insurance company decides that instead of purchasing human resource management software or document archiving software, it will internally develop it itself in an open source manner which will cause cooperation with numerous other internal programmers, resulting in the rise of the quality of the product and the accumulation of new features, without necessitating a particular development program for the company’s programmers.
In this way, the company, that did not intend to sell the software product in the first place, would not need to invest large sums in their purchase but would invest small amounts on setting up the initial project and its development, whilst the rest would be done by external programmers (private or by other companies) where the ability to use the finalized product constitutes a form of compensation for their efforts in developing the product.
It is important to emphasize that such projects do not necessarily need to be written from scratch – today, open source libraries are rich in components that can easily be combined with one another in order to create a stable infrastructure and only develop the few missing components in an open source manner. In this scenario, we should consider that in the past, a company that wanted to purchase software had to choose between two options: either build the software from scratch at extremely high cost or buy software that would only partially fit its needs – both options do not seem to be ideal.
Nowadays, with the help of open source projects, companies as such can benefit from both worlds: use free infrastructure components and use the help of programmers from around the world in order to meet the exact needs of the company and to receive a product that is tailor-made on one hand, but also very low-cost on the other.
However, it is surprising to consider that there are also numerous commercial companies that choose to develop their products (or at least part of their products) through an open source approach precisely with the aim of gaining benefit. Yes…yes…and how do they achieve this? Companies such as Zabbix develop their product as open source, offer the product for free to all who require it, and charge some customers for consulting and support services.
There are also companies such as Elastic, that offer the core product of the system as open source but charge the customer for complementary products that are offered as part of add-on packages as well as support services. Based on the amount of time that these companies have thrived, one could conclude that this open source model strongly supports their survival.
Another note before concluding: Chinese software users also benefit from the existence of open source traffic – the price of Chinese software is decreasing because the customer almost always (increasingly in the last years) has the option to switch to open source products. The software houses must now offer an attractive price, thus in fact, these open source movements are a benefit for those who support their activity, but also to those who do not.
Finally, the open source has far reaching results on our world today. The price of software is declining, more and more companies are developing products that are used in open source frameworks, while commercial companies are constantly offering their products as open source products, for their own benefit as well as our own.
Relevant Links
The adoption of open source in the banking sector:
https://bbvaopen4u.com/en/actualidad/banks-starting-embrace-open-source-finance-and-hackathons-innovate
Bruce Shneier’s article on the importance of open source transparency following the Volkswagen case:
https://www.schneier.com/blog/archives/2015/09/volkswagen_and_.html
Part of the book “The Cathedral and the Bazaar” on the differences between open source and traditional source development:
http://www.isoc.org.il/internet-il/articles-and-research/magazine/the-cathedral-and-the-bazaar
The article discusses the security behind open source in comparison to closed source:
https://www.quora.com/Is-open-source-more-secure-than-proprietary-software
Oh no!We didn’t find anything for “”,
