Pros and Cons with Open-Source and Closed-Source Software
Opinion
Monday 14th July 2025
I recently had a discussion with someone who considers to rebuild their website from Wordpress to a closed-source custom built website. According to an external consultant, Wordpress is insecure because he was able to hack an admin account in 3 seconds, allegedly. I started to look into the possible benefits and drawbacks of this consideration and wrote a report. This post however is a more general overview of open-source and closed-source software.
Note: The reason for the successful hack has never been explained.
Benefits of closed-source
Full ownership
One argument for developing your own code, or hiring someone to do it, is that you have full ownership of the application. There are some companies that have been starting to backpedal on the “Everything must be in the Cloud” agenda, and started to appreciate having control of their data instead.
However, I can’t answer what benefits of owning the code has over a GPLv2 License. For me the only valid reason for developing your own code is if you are planning to monetize on it or if you are in need for customized applications. Otherwise it doesn’t make sense to develop your own code because of reasons explained during this post.
It could also create some legal dilemmas. Owning code is more like having the rights to a musical work. If another company hires the same consultant that creates almost identical software for them, can they be sued? Most likely you end up having to license the code or make some kind of user agreement.
Another question is: how many ways can you make for example a website builder unique? Especially if it’s supposed to look similar to Wordpress. Some open source code will most likely be used anyway.
Better Security (allegedly)
The Second argument is that the code will be more secure than open-source. This argument is completely subjective and depends on who is developing the code. But let’s say it could theoretically be true, considering the following:
The developer is a cyber security expert.
The application has a bare minimum of features to exploit.
Ofcourse, no code is ever completely secure and new exploits might be discovered after some time. Another issue is that everytime you need a new feature, new security threats are introduced. It’s like buying a modern car: the more bells and whistles it has, the more things can go wrong with it. The developer has to constantly be responsible for updating and patching the application.
I would argue that well maintaned open-source projects can be just as secure as closed-source projects, if not even more secure. There are 472 million websites running Wordpress today. Undoubtably some are very insecure but I would be surprised if every one of them are so easily hackable. Many systems are insecure at their defaults and need to be hardened to become secure. Try implement security best practices for the software in question and common-sense security policies.
Examples of Security Policies are:
Adjust the password complexity requirements.
Implement 2-factor authentication or FIDO2 authentication.
Lock accounts after 5 attempted logins.
Keep track of who have admin rights and create roles to limit their privileges.
Drawbacks of closed-source
Developers are expensive
Building an application from scratch takes time and expertise, which is not cheap. And that is just for version 1.0. We also have to consider:
How to discover new threats?
How to implement new features?
Maintenance costs for patching discovered threats and implementation of new features.
The application is never “finished”; it’s always developing. If you rely on custom built software, you risk being dependent on a few key persons for a long time.
With open-source projects the burden of discovering new threats and developing patches are shared on a big community of independent developers, instead of relying on a few experts.
One alternative could also be to buy a licensed software from a company that does regular maintenance. But if the point was to own the code, then this will undermine that completely.
Lack of transparency
If you develop your own code, you are free to choose if you want to share it with the world, monetize on it or keep it for yourself.
The drawback of keeping it for yourself is that you have the sole responsibility for continued developing of the code and that can be costly, time-consuming and risky, as explained above.
The drawback of monetizing it as closed-source is that you have to convince the customers that you are not spying on them, creating backdoors for the government or selling their data to third parties. That can be challenging considering the fact that the code is hidden for other people, especially if there are already open-source alternatives.
If you share the code with the world, other people can contribute to your code. Users don’t need to trust you because they can review the code for themselves.
Benefits of open-source
Open Licenses is like owning the code
With open-source licenses like GPLv2 and 3 you are free to use, edit, copy and distribute the code as you like, as long as you are honouring the same type of freedom to others when distributing it forward. That looks like complete freedom to me.
Take for example Linux: It’s completely free. No subscription costs, nobody spies on you and you can change the code however you like. That is why, for better or worse, there are so many different Linux distributions today.
Complete Transparency
It may sound uncomfortable at first that hackers can just read the source code and find weaknesses, but that is actually a big benefit because there are then many people who can contribute to eliminate those weaknesses before hackers find them.
Case Study: XZ Utils backdoor 2024
One example of the strength of having transparent code is when someone tried to insert at backdoor into OpenSSH in 2024. The person in question had worked his way up in the maintainer hierarchy and gained enough trust to get priveleges to commit code. He then inserted malicious code that could have had devastating effects on millions of machines. Luckily a developer found out in about a month time and that code was never applied to any production releases.
Drawbacks of open-source
Voluntary work come with great sacrifice
Many open-source projects are based on volutary work of a few dedicated developers, for the benefit of all of us. Often these developers eventually get burned out and the project may stop.
That being said, there are also many developers who have managed to monetize on their projects: TrueNAS, Nextcloud and Wordpress are examples of succesful open-source projects that manage to actually make a living while sharing their code freely.
No warranties
There are no warranties on open source code. What you see is what you get. If you have a problem with your software (that you downloaded for free) you can’t just complain to somebody. What you can do instead is that you open a ticket in a relevant forum and hopefully somebody will take care of it within a few months. Then you are at least contributing in finding faults.
There are however companies specializing in giving proffesional support to Open Source products. If you subscribe to one of them, your problems will get prioritized.
Not safe from faults or corruption
There are malicious actors who wants to destroy for the open-source community. The OpenSSH incident is one good example showing the strength of having transparency, but also a weakness of having code contributors all over the world that might not necessarily know each other so well.
There are however bad actors everywhere and closed-source code contain weaknesses as well, intended or not.
Case Study: Crowdstrike 2024
The most disastrous IT infrastructure disruption happened when the american company Crowdstrike accidentaly created a bug in their “securitysoftware” Falcon Sensor, resulting in many people having to forfeit their summer vacation and caused world wide financial damage of at least $10 billion, according to Wikipedia.
The Falcon Sensor software runs at kernel level and is extremely privacy infringing, but I guess big companies like to know what their employees are doing on their computers. Worse yet, their software updates a few times a day to keep up with the latest threat signatures, without having to be confirmed by an administrator! A model that is under scrutiny now.
When the faulty code was pushed globally, immediately Windows machines started crashing with bluescreen of death (BSOD) and unable to recover. All affected machines had to be restored manually, one by one.
Worth noting that Linux systems was not affected1 because the kernel architecture is built differently than on Windows. I’m not saying that any equally disastrous event in the future will never happen on open-source software platforms, but I believe that transparency and the decentralized nature of open-source software might mitigate many of these cases. I am also not able to find any event related to Linux that comes near the Crowdstrike event.
Conclusion
Here is my summary:
Developing your own code is costly and only makes sense if there are no alternatives or you intend to monetize on it.
“Owning” the code does not have any benefits over using for example a GPL license instead.
Before jumping to conclusions, make sure you follow the softwares security best practices and implement common-sense security policies.
Closed-source software is not necessarily any more secure than open-source software.
A stable open-source project depends on it’s economic model, popularity and amount of contributors
Me personally favors Open Source alternatives because they rank high on transparency, low total cost of ownership and privacy-friendliness.
You may find contradicting information about a similar incident that caused kernel panic on Redhat systems just a few months before the Windows incident. How bad it was is difficult to find numbers on. It does however look like it was caused by a bug in the kernel, and Falcon Sensor was merely doing it’s job that time. Also, that incident didn’t get any widespread media attention as with the Windows incident.