Enterprise Executive 2017: Issue 2 : Page 40

A R CHI T E C T ’ S | C OR N ER S. MICHAEL BENSON pen source software has been advocated for over 20 years and is extremely successful in some categories such as operating systems, web browsers and some databases. But before you decide to completely jump on the open source bandwagon, there are some things you should know about it so you are not blindsided. The most important thing to understand is that open source software is not free. There is a very good possibility that most of you are using Linux in your data center so you know the value of obtaining it from a distributor that can provide an acceptable support package with it. Even so, there are nuances around supporting an open source distribution that can make service tricky at times. Commercial product owners can make changes to their products at will, but it’s not always so with open source program distributors. I worked with a company several years ago that ran a standard open source Linux distribution with a support structure from the distributor in place. We ran into some issues with a very specific aspect of security that took many months to isolate to a Linux driver. Not only was diagnosing the problem more difficult, but getting a fix to the problem was not very timely because of how the distribution was released. Had this been a commercial product owned by the vendor, I think it could have been resolved much more quickly. E nt e rp r i s e E xe c u t i ve | 2017: Issue 2 O There is no doubt that the open source paradigm can lead to more innovation since more developers understand the source code and can submit enhancements. This sounds like a good thing and, in theory, can lead to faster development of more features. But it can also be troublesome for companies that would like to control operational spending while staying in front of their competition. Here are several issues you should be aware of when assessing open source packages. Few Roadmaps Open Source Does Not Mean Free Open source projects rarely have roadmaps for future development items, which means that most companies cannot reliably depend upon needed features being included in a timely fashion. Open source project leaders control the content of releases and are not driven by potential revenue since that is not a part of the equation. Many companies have resorted to joining open source projects and funding enhancements they need, which cancels out the savings from not having to pay license fees. Some developers are funded by companies to work on specific features, but who gets called when a bug is discovered? Distributors can work to identify problems, and many of them participate Lacking Support Structure 40 |

Architect’s Corner

S. Michael Benson

Open Source Does Not Mean Free

Open source software has been advocated for over 20 years and is extremely successful in some categories such as operating systems, web browsers and some databases. But before you decide to completely jump on the open source bandwagon, there are some things you should know about it so you are not blindsided. The most important thing to understand is that open source software is not free.

There is a very good possibility that most of you are using Linux in your data center so you know the value of obtaining it from a distributor that can provide an acceptable support package with it. Even so, there are nuances around supporting an open source distribution that can make service tricky at times. Commercial product owners can make changes to their products at will, but it’s not always so with open source program distributors.

I worked with a company several years ago that ran a standard open source Linux distribution with a support structure from the distributor in place. We ran into some issues with a very specific aspect of security that took many months to isolate to a Linux driver. Not only was diagnosing the problem more difficult, but getting a fix to the problem was not very timely because of how the distribution was released. Had this been a commercial product owned by the vendor, I think it could have been resolved much more quickly.

There is no doubt that the open source paradigm can lead to more innovation since more developers understand the source code and can submit enhancements. This sounds like a good thing and, in theory, can lead to faster development of more features. But it can also be troublesome for companies that would like to control operational spending while staying in front of their competition.

Here are several issues you should be aware of when assessing open source packages.

Few Roadmaps

Open source projects rarely have roadmaps for future development items, which means that most companies cannot reliably depend upon needed features being included in a timely fashion. Open source project leaders control the content of releases and are not driven by potential revenue since that is not a part of the equation. Many companies have resorted to joining open source projects and funding enhancements they need, which cancels out the savings from not having to pay license fees.

Lacking Support Structure

Some developers are funded by companies to work on specific features, but who gets called when a bug is discovered? Distributors can work to identify problems, and many of them participate in the projects so they can fix them, but if you have no support contract in place, you are left to support the software with your own personnel. The value proposition of open source is that it will lower your costs, but without a defined support structure, your operational costs go up.

Specialized Hardware

Not all open source software needs to be aware of specialized hardware. However, getting features developed for specialized hardware can be troublesome because developers do not normally have access to that hardware and cannot test with it or even understand how to exploit it. In the example I mentioned earlier, the problem was with exploiting a security hardware feature the package developers did not have access to. It took setting up a special test environment for the package developers and collaboration among several parties to be able to diagnose and fix the problem. To be fair, many commercial software development organizations have the same problem, but getting the bug fixed is more streamlined in most cases.

Security

Anyone can get access to the source code for an open source package, even bad actors. There are several examples of malicious programmers introducing exploitive modifications to the project. One example of an accidental security exposure was with the OpenSSL project where a bug called Heartbeat was introduced in the code in 2012. Secure Sockets Layer (SSL) is used to protect private communication over the internet and the Heartbeat bug provided a way to read past the end of the buffer and into the unprotected memory to access passwords and crytographic keys. Heartbeat was in distribution for over two years and on an estimated half a million servers before it was discovered.

User Interface Design

Most open source developers are driven by providing new features in the package, but rarely have much training in usability design. Because they develop the code, it can be obvious to them how it works even if it is not obvious to many others. This phenomenon, called “programming for the self,” results in packages that are feature rich, but highly difficult to use. Some have attributed the lack of a strong desktop Linux to this problem. For many, user interface is an afterthought that rarely gets developed.

Despite the list of issues, there is still strong sentiment for using open source software in enterprises. While surely valuable for many companies, it is a good idea to be aware that it might not be the panacea to controlling costs you think it will. As I always urge, assess the potential savings for your environment and don’t let distributors act as consultants.

S. Michael Benson is retired as an Executive IT Architect after 30 years at IBM. He held positions in development, architecture, management and technical sales. He holds a Master’s Degree in Computer Science from Marist College. Email: smbenson58@gmail.com

Read the full article at http://ourdigitalmags.com/article/Architect%E2%80%99s+Corner/2761245/399971/article.html.

Previous Page  Next Page


Publication List
Using a screen reader? Click Here