Open source software firms have made a push for the business world for quite some time now. The idea of running a business on software whose source code is readily available for anyone to tinker with gained considerable validity when IBM announced its full on support for Linux on its hardware, including z Series mainframes, in 1999.
The potency and capability of open source software is not in doubt. Open source software powers much of the Internet: Linux, the Apache Web server, sendmail, and OpenSSL are just a few important Internet technologies that are open source, among many.
But a little doubt has recently been cast on open source software. The nation of Brazil, which made a big to-do about its move to open source software in 2003, recently made a huge purchase from Microsoft, citing a lack of skilled developers to provide the country with the apps it needed. The German city of Munich, which switched to open source in 2004 amid much hoopla, is now considering bringing back Microsoft products at the request of local agencies.
Both governments have their reasons, and there are plenty of reasons pro and con to consider open source for your business. Here we present our arguments for both sides of open source for business.
With a commercial product, you can't inspect the code for bugs or flaws. With open source, you can have a lot of people looking at the code other than the vendor. If you got talent in-house, they can do things with the code without having to rely on the vendor for that level of customization or just plain bug fixing.
There is a maxim known as "Linus's Law," named for Linus Torvalds, the creator of Linux. It states "Given enough eyeballs, all bugs are shallow." That means the more people who can see and test a set of code, the more likely any flaws will be caught and fixed quickly.
Once you start modifying open source code, the responsibility for the integrity passes to you. If you don’t have the talent, things could get out of hand very quickly and you find yourself with a product you have to fix, possibly requiring considerable resources. As a result, a lot of people don’t want that kind of responsibility. They want the vendor to own it.
Also, more eyes is no guarantee. The Heartbleed bug in OpenSSL was a severe vulnerability that was believed to have gone more than two years before it was discovered, and OpenSSL is completely open source. OpenSSL is almost ubiquitous in its use and there was still a long gap before Heartbleed was found.
You can't beat the up-front costs. Just download the code from SourceForge, The Apache Foundation, GitHub or some other legitimate source and you’re ready to go. Many open source products are available in a basic free edition and a for-cost premium edition, like most of the Linux distributions.
Over time, open source software can cost more in a number of areas. Say you decided to make heavy modifications to a product. You own it at that point. If you got a problem, you can't call a vendor for support, if you've got a problem, you own it. That means putting resources onto the problem that might be needed elsewhere.
There can be other long-term costs as well. If a project falls into neglect or abandonment and you are heavily invested, it could be expensive to transition to something new. OpenOffice, a free office productivity suite created by Sun Microsystems as an alternative to Microsoft Office, has been neglected for years as volunteers drifted away from the project. Now the Apache Foundation is looking at shutting it down, meaning everyone who uses it will have to transition to LibreOffice or Microsoft Office.
It's the same risk you take with commercial software, although commercial products are often acquired while on their deathbed and there can be some support to be had.
Open source is no longer a new thing. Red Hat has been around more than 20 years and survived the DotCom meltdown at the turn of the century, while The Apache Foundation has been around 17 years. Many of these companies are larger and healthier than commercial software firms.
The open source development process is not as deeply organized as commercial software. It varies from app to app and project to project. The OpenOffice example is a good one. Volunteers drifted away and new ones were not attracted.
In general it's not a good idea to bet your business on an open source projected staffed by volunteers. You want one with a professional organization behind it that uses all of the regular disciplines of a good software development shop, avoiding things such as:
* No license, or using a GPL license. The GPL license requires distributing your modifications to a code base and you may not want to do that.
* Not maintaining and updating the code. That's a red flag for a project near death.
* No or poor documentation. No one wants to download a massive open source project and then have to read it line by line to figure out what the programmers did. Good comments are as vital as good code.
Likewise, there are signs a project is in trouble. They include:
* The codebase is too big.
* The code doesn't compile properly.
* Poor documentation.
* They didn't use standard build tools. That includes Microsoft's Visual Studio. It's a fine IDE but anathema to open source and many open source developers still detest Microsoft.
* Poor choice of hosting. SourceForge and GitHub are standard. After that it becomes questionable.
* Inconsistent licensing.
* No governance.
Do your homework on the company behind the project and make sure it's run by professionals.
There is a whole generation of younger developers who have only known open source tools. And that population will grow each year. Open source tools have become the tools and appdev environments for many developers and they know nothing else.
Open source never took off on the desktop despite repeated efforts. Microsoft still owns the desktop, and that is an important target. Brazil and Munich turned away from open source exclusivity because they couldn't get desktop products they needed compared to what Microsoft offers.
And Microsoft does outreach to developers and to its end customers like no one else, and they make it very easy for customers to remain customers by being there to help out. They take a lot of the weight themselves so if a problem happens those problems are rectified quickly. That's not always the case with open source products.
Having access to the source code not only means finding bugs but potential back doors, keyloggers or anything else malicious. You can trace the code's execution and see what it does, an option not available when you get a compiled application.
When many people have access to the source code of open source software, someone with bad intentions can wreak some havoc. A malicious insider can be far more harmful than any external hackers and can use their access to exploit vulnerabilities, create bugs or malicious code, steal identities or just plain annoy other users. So it falls on to the open source user to secure their code, control access and monitor changes just like any other piece of internal code.