9 reasons to switch to open-source
In this article, I want to point out several reasons why companies of all sizes should switch to open-source technologies. I will try to indicate moments that are not only beneficial for developers, but also for business (customers). I’ll make a reservation that this is not about the end products of the software, but about the platforms — web servers, proxies, databases, etc. The article is informal, therefore, without numbers and graphs. However, you can find them at some links below. I often see a discussion of the benefits of using open-source products on English-language resources, however, in our country they are still afraid of them.
There is no complete study to decide whether to use it or not. For example, only the pros are given. However, you are well aware of the arguments against. For each item you can find an anti-example, but the point is in the statistics, which you can find on the links. However, in my opinion, these arguments work best for web applications.
Let's start in order:
This also includes security flaws (exploit capabilities). Why is this so? There are a large number of developers working on open source projects. Therefore, defects are detected and eliminated very quickly.
If you like objective evidence, here is, for example, an article on comparing the number of bugs in open-source and proprietary products from Coverity: www.techrepublic.com/article/open-source-vs-proprietary .
Consequently:
It was once thought that open-source loses security to proprietary products. Closed-end vendors often use this argument. However, numerous independent studies have shown that now open source software is, on average, more secure than proprietary.
Many factors are associated with this. For example, many security problems can only be detected by observing the code directly. Participants in the open-source community find and fix such holes, while in proprietary software such defects can go unnoticed for years.
Well, in general - the fact that you do not show your code to anyone does not make it better written.
Programmers who work on source code projects like what they do. Very often, they use these projects in their work. I think everything is clear here. From here, in fact, many other advantages follow, which are described below.
I mean "programmers work." “Programmers” == “lazy people.” The fact is that a truly lazy programmer will always find the opportunity to make his work easier and faster.
All over the world, everyone has long understood that routine can always be ruled out. If you are a programmer and do routine work - think about it, you are doing something wrong.
That is why web developers around the world choose a console approach to task execution (goodbye, Windows), use scaffolding, scripting.
Among the Russian specialists, for some reason, the console is not in honor, but in vain - this is the path to Zen and productivity.
For example, how to deploy an application on the Meteor.js platform (http://meteor.com)?
Everything! You have a working application, with the database already spinning on the server. In one simple move, you can publish your application on the Internet:
Now the question is: how to deploy the simplest Java EE application? A bad example in the context of propriety, but still. Taking an Oracle ADF deployment as an example would be very cruel. Firstly, you can’t do it in the console (pull your hand to the mouse ?! Nooo ...). You will most likely need to download and install Eclipse, Idea, or Netbeans. Then you need to download and install Tomcat, Glassfish, WebLogic, or whatever else you use for the servlet container there. Launch the IDE, click a little mouse, and, with any luck, everything will start immediately!
At this time, the developer at meteor.js already made a functional application (http://www.smashingmagazine.com/2013/06/13/build-app-45-minutes-meteor).
Top management often chooses proprietary products precisely because of the availability of support contracts. I have repeatedly heard exclamations in the style of “We have a partnership contract with ...! But there will be problems with this backbone, what will we do? ”
In fact, large mainstream projects have a large community around them, which is always ready to help in resolving issues, while, despite the presence of contracts, support requests, for example, Oracle, may remain unresolved for months.
The community consists of the same developers as you, with the same problems that someone has probably encountered.
Anyway, in the case of open-source, programmers always have the opportunity to solve the problem themselves, as discussed in the next paragraph.
Unlike proprietary software, you can make changes in an open-source project yourself. Of course, this is not an argument for business (“Why should we spend time developing someone else's project?”). However, for the experts themselves this is a very useful and enjoyable experience. In addition, as I mentioned above, problems with blocking defects can be solved, in this case, much faster.
The time to market for a product (Time To Market, en.wikipedia.org/wiki/Time_to_market ) is much lower, which directly follows from points 2 and 3.
No comments.
Moreover, proprietary products draw money from you constantly and in proportion to the scale of your infrastructure.
Now technology is rapidly changing and developing. Open source projects tend to be more adapted to change than proprietary software.
Choose a platform based not on what affiliate contracts you have, but on what problem you want to solve. Here is the whole range of platforms and you are not dependent on anyone's plans for releases.
It is useful to read on this subject:
There is no complete study to decide whether to use it or not. For example, only the pros are given. However, you are well aware of the arguments against. For each item you can find an anti-example, but the point is in the statistics, which you can find on the links. However, in my opinion, these arguments work best for web applications.
Let's start in order:
Open-source applications contain fewer defects
This also includes security flaws (exploit capabilities). Why is this so? There are a large number of developers working on open source projects. Therefore, defects are detected and eliminated very quickly.
If you like objective evidence, here is, for example, an article on comparing the number of bugs in open-source and proprietary products from Coverity: www.techrepublic.com/article/open-source-vs-proprietary .
Consequently:
Security
It was once thought that open-source loses security to proprietary products. Closed-end vendors often use this argument. However, numerous independent studies have shown that now open source software is, on average, more secure than proprietary.
Many factors are associated with this. For example, many security problems can only be detected by observing the code directly. Participants in the open-source community find and fix such holes, while in proprietary software such defects can go unnoticed for years.
Well, in general - the fact that you do not show your code to anyone does not make it better written.
Enthusiasts work on open-source projects
Programmers who work on source code projects like what they do. Very often, they use these projects in their work. I think everything is clear here. From here, in fact, many other advantages follow, which are described below.
Lazy people work on open source
I mean "programmers work." “Programmers” == “lazy people.” The fact is that a truly lazy programmer will always find the opportunity to make his work easier and faster.
All over the world, everyone has long understood that routine can always be ruled out. If you are a programmer and do routine work - think about it, you are doing something wrong.
That is why web developers around the world choose a console approach to task execution (goodbye, Windows), use scaffolding, scripting.
Among the Russian specialists, for some reason, the console is not in honor, but in vain - this is the path to Zen and productivity.
For example, how to deploy an application on the Meteor.js platform (http://meteor.com)?
$ curl https://install.meteor.com | /bin/sh
$ meteor create myapp
$ cd myapp
$ meteor
Everything! You have a working application, with the database already spinning on the server. In one simple move, you can publish your application on the Internet:
$ meteor deploy myapp.meteor.com
Now the question is: how to deploy the simplest Java EE application? A bad example in the context of propriety, but still. Taking an Oracle ADF deployment as an example would be very cruel. Firstly, you can’t do it in the console (pull your hand to the mouse ?! Nooo ...). You will most likely need to download and install Eclipse, Idea, or Netbeans. Then you need to download and install Tomcat, Glassfish, WebLogic, or whatever else you use for the servlet container there. Launch the IDE, click a little mouse, and, with any luck, everything will start immediately!
At this time, the developer at meteor.js already made a functional application (http://www.smashingmagazine.com/2013/06/13/build-app-45-minutes-meteor).
Community Support
Top management often chooses proprietary products precisely because of the availability of support contracts. I have repeatedly heard exclamations in the style of “We have a partnership contract with ...! But there will be problems with this backbone, what will we do? ”
In fact, large mainstream projects have a large community around them, which is always ready to help in resolving issues, while, despite the presence of contracts, support requests, for example, Oracle, may remain unresolved for months.
The community consists of the same developers as you, with the same problems that someone has probably encountered.
Anyway, in the case of open-source, programmers always have the opportunity to solve the problem themselves, as discussed in the next paragraph.
Opportunity to contribute to the development of the project
Unlike proprietary software, you can make changes in an open-source project yourself. Of course, this is not an argument for business (“Why should we spend time developing someone else's project?”). However, for the experts themselves this is a very useful and enjoyable experience. In addition, as I mentioned above, problems with blocking defects can be solved, in this case, much faster.
Faster development speed
The time to market for a product (Time To Market, en.wikipedia.org/wiki/Time_to_market ) is much lower, which directly follows from points 2 and 3.
Cheap
No comments.
Moreover, proprietary products draw money from you constantly and in proportion to the scale of your infrastructure.
The ability to adapt quickly
Now technology is rapidly changing and developing. Open source projects tend to be more adapted to change than proprietary software.
Choice
Choose a platform based not on what affiliate contracts you have, but on what problem you want to solve. Here is the whole range of platforms and you are not dependent on anyone's plans for releases.
It is useful to read on this subject:
- www.techrepublic.com/article/open-source-vs-proprietary
- www.linuxfoundation.org/publications/linux-foundation/collaborative-development-trends-report-2014
- www.huffingtonpost.com/vala-afshar/10-reasons-to-use-open-so_b_5766718.html
- www.huffingtonpost.com/vala-afshar/red-hat-cto-5-business-be_b_5309043.html
- www.acquia.com/blog/open-source-value-proposition
- www.slideshare.net/mjskok/2014-future-of-open-source-8th-annual-survey-results