10 Considerations When Using Open Source Technology

© bleakstar/Shutterstock.com

Your Business Model

You should also think about what open source can offer and how those offerings fit with the company’s goals. Some of the most compelling benefits open source can potentially offer include

• Speeding up development and time to market
• Reducing overhead
• Removing redundancy
• Increasing efficiency

Open Source Community Health

Here are some easy benchmarks for evaluating the health of an open source community:

• How well is the project site developed?
• Have the project site owners thoughtfully curated the resources and tools provided?
• Is there a ticketing system?
• Is the documentation well-conceived and regularly updated?
• How many releases have there been and over how many years?
• How many forks in the code have taken place?
• How many contributors have there been over time?
• How many users are there?
• How well known is the code outside the project home?
• Have there been any financial contributions/donations over time toward maintaining and further developing the project?
• Do any large corporate users contribute to the code or its support?
• How many maintainers are there?
• How much has the code changed over time?
• Are any statistics available about the code’s return on investment (ROI)?
• How many organizations contribute to this project?
• How often are there new releases?
• How often is there code review?
• How many regressions have there been over time?
• How many bugs?

Tech Support

Technical support for open source code can be problematic if the code doesn’t have an active user community, as we say in the previous section. An active user community can offer information and support that enables a company to deploy a stable open source code logically and systematically. The factors we list there can reliably indicate the code’s stability and quality because they point to there being people who care about the code and its viability. You must do your due diligence and research to determine the community health and, by association, the prospects for getting good technical support.

• For large deployments, it may be beneficial to have in-house support.
• On smaller projects, it may be possible to subcontract support directly from project’s owner/creator or maintainer.

If you’re embedding open source in your proprietary software, you must weigh the risk of having no control against the level of support and the level of error fixing for the included open source code.

Security

One important security consideration is how well the code has been tested/proofed against security attacks. Several out-of-the-box “defects and analytics” tools are available that produce static security reports. These tools reveal possible defects in the code and report them back to the project maintainer.

When reviewing a project portal and its documentation, it’s important to note whether you can easily report bugs, review the security protocols, and review any reports of vulnerabilities. Vulnerabilities should be included in the release notes.

Some vulnerabilities are extremely common and readily identified, and any good development process avoids them. Finding such vulnerabilities in an open source product after its release can indicate sloppy development.

The open source world has no quality assurance standardization, so all open source code comes “as is.” You shouldn’t release or use anything that your own company’s quality assurance process hasn’t validated.

Also, no centralized database lists open source vulnerabilities. There is, however, a National Vulnerability Database (NVD) that collects vulnerabilities as they are known. Unfortunately, this database often points out vulnerabilities to hackers, who then exploit them. Most deployed open source is checked against this database, either manually or using automated tools, and any vulnerabilities found are fixed quickly. Someone in your organization should be responsible for reviewing this database and managing any needed changes on a weekly basis.

Code Audits

Open source code audits are important for two reasons: They expose any potential security concerns, and they expose any potential infringement issues. Not only must an organization have policies governing software selection, vetting, and review, but it must also demonstrate an understanding of the potential interdependencies entailed in the actual use and deployment within a larger framework.

Auditors typically look for more than a simple spreadsheet as proof of proper oversight. To survive an open source audit, a company must demonstrate that it has educated its developers on the proper processes to follow before using even one line of open source code. There should also be a centralized repository of all contracts associated with open source that counsel has reviewed.

Staying on top of releases of open source code is crucial to the success of surviving an open source audit. A company’s policies and tools should require regular open source code review. The primary purpose of such a review is to verify that the code has been updated with latest releases and that any known vulnerabilities and errors reported have been fixed.

• Listing all open source components, the version in your product, and the most current version available
• A list of vulnerabilities associated with those components
• A scheduled date by which to remediate any critical issues

Reliability

You can easily gauge the value of open source code by simply using standard internet search tools. Social media also supports open source discussion through blog posts and articles discussing projects.

• Does it have a large user base? If so, it’s likely to have strong support and a good likelihood of longevity.
• Does it have a good reputation? Reputation isn’t everything, but it is important.
• Is it interoperable? You want to be able to use this code easily.
• Does it require specialized skill to use or maintain? If so, maintenance could be costly.
• Does it have sufficient, well-written documentation? Because contributors to open source have varying skills, review of documentation is critical. In fact, the use of the documentation to support the code should be part of the quality assurance (QA) done on the open source code before it’s incorporated into production.
• Has it used open standards? Code built on open standards and practices is easier to maintain.
• Does it have a good support network? A support network can include not only a user and developer community but also paid support options.
• How often has the code been updated since its inception? What is its most recent update? Frequent is better.
• Is the project site well trafficked and well maintained? Does it exhibit good governance and community participation? A review of release notes and user statistics can help in determining this.
• Is the open source license associated with the product clearly defined? Your legal counsel should review it, and you should make sure no conflicts occur with other open source agreements.
• Is there any larger group behind the development of the project? A large company that relies on the code or regularly contributes to it is a benefit.

Hidden Costs

On the surface, there appears to be savings from the outset because you pay nothing for the license and use of the code. There are hardware, maintenance, support, and legal costs, but these too may be less expensive compared to enterprise third-party offerings.

Cloud strategies and the use of open source platforms can eliminate some of the network overhead. Though the use of these items isn’t free in that development and deployment costs are associated with them, they should be significantly less expensive than in-house company-owned equipment. There are also other intangible benefits in using open source. For example, faster development time is a real and quantifiable benefit.

To understand and manage costs, take a look at the following areas of setup and maintenance, where there can be ownership costs, and determine ways to control and scope them prior to making a commitment.

Setup costs include the following:

• Hardware: Review the project site for hardware recommendations and make sure you have them on hand. If not, the cost of the hardware will need to be built into the budget.
• Integration: The size of the project will determine the size of the staff. If it’s an application, outside resources may be required. Create a deployment project plan. Analyze interfaces and interoperability. Specialists may be required.
• Replacement: If this is a replacement strategy, you must understand what components are needed. Data transfer can be time-consuming and may require specialists.
• Customization: Open source doesn’t mean “one size fits all” out of the box. You must budget for developer costs to modify code to fit your unique needs.
• Training: New software implies new training and perhaps some slowdown in productivity.

• Updates: Someone will need to rigorously monitor the project site for available patches and releases and take charge of applying them.
• Customization: Any customization your organization does to the code will require support throughout the life of the product.
• Support: User and developer support must be available throughout the life of the product.

When selecting open source software, pay special attention to these areas that may necessitate additional expenses:

• Interfaces: Because of poor user interfaces, less and inconsistent documentation, and lack of training, there could be increased time spent on administrative functions with some open source products.
• Support complaints: Because of the lack of designated support and inconsistent documentation, your internal team may spend more time on troubleshooting.
• Bug fixing: Because not all open source projects have a standardized approach to QA and regression testing, your in-house team may be responsible for finding and fixing bugs themselves.
• Additional development: After you’ve implemented an open source solution, you may find that you need further code development due to some unanticipated issue, such as poor network performance.
• Extensibility: There are no guaranties that any code will be future-proof. The only insurance you may have is that the code has been built on the latest flexible architecture in any easily utilized language.

Updates and upgrades

When a vulnerability is found, it’s published to the project and later to websites that list all open source vulnerabilities. These lists are fodder for hackers. Luckily, you can use tools — such as Zoho, Bugzilla, and MantisBT — to make sure that you don’t miss updates and that check against the current open source code you’re using for vulnerabilities and severity of them. With internal accountability for fixing issues as they occur and resubmitting them back to the project, you can handle maintenance and security with minimal risk.

Updates and new releases should go through proper quality assurance. Because no standards are established in open source for quality control, it’s your company’s responsibility to see that the standard of the open source code meets the company’s quality standards.

To avoid the risk of vulnerability attacks and of third-party update incompatibility, your company will need to take a regimented approach to updates and releases. The regimen should include a calendared weekly review of all open source updates. You can automate this process using code management tools. All security issues and bug fixes should be prioritized for immediate updates as determined by their level of severity. New functionality should be prioritized according to business needs.

There should be a centralized repository that developers use for all open source code. By limiting the accessibility to the open source code to one repository, you avoid the possibility of different teams using different versions.

Potential hardware impact

FinTech companies are well situated to advise members of the financial industry about tactics and strategies to be used to reduce operating costs and still deliver as near to real-time analytics in the areas they are required.

Speed isn’t a requirement for probably 80 percent of the data store and manipulation that goes on in most financial firms. With that said, open source has often been a trailblazer in the area of reducing costs by creating and facilitating “free” operating systems.

There are of course costs associated with the creation of hardware, which has made open source hardware development projects challenging to achieve. Even with its success, Apache’s web server and Tophat are funded only through corporate sponsorship and user conferences.

With the cost constraints around creating free open source hardware (FOSH), FOSH projects rely on the community to build hardware based on the intellectual properties developed (such as data layouts, integrated circuit schema, mechanical drawings, and so on). The academic community has driven FOSH’s creation and development to date. Its hardware development artifacts are captured via hardware description language (HDL).

However, utilizing open source software code with open source operating systems and the available security and efficiency tools can result in significant savings. Cost reductions have been reported as high as 44 percent for hardware costs based on intelligent strategies around open source, cloud-based deployments and virtual servers.

Legal considerations

Another layer of complexity becomes apparent when reviewing all open-source contracts a company uses. The contracts often have interoperability issues with each other. And finally, international use of open source may raise other legal restrictions that have to be understood and resolved.

When reviewing the licenses associated with open source, pay particular attention to the following:

• There should be no audit rights that reach into an organization’s network directly.
• There should be no fines associated with the inadvertent deployment of unlicensed open source code.
• See whether you can purchase an outside warranty for the open source used. There are no warranties with open source code. If you use it, the liability for it lies with you as the user.
• Check to see whether conflicts exist with the use of libraries within the open source code.
• Make sure there are no requirements to provide written notification of initial ownership or code creation within the code.
• Make sure there are no restrictions on the use of proprietary code with open source.

Be sure to check the open source project for pending legal actions. Your rights aren’t protected should a lawsuit be launched against a project; your right of use may be obstructed.

There should be regular training about the policies around the use and maintenance of open source for users and developers.

Non-copyleft licenses permit developers to make any changes to the code, including retaining the modification as proprietary. Purists of open source don’t like this version because it violates the spirit of open source and restricts the sharing of all functionality as it’s developed. Corporations, of course, would like to retain control over what they pay their developers to create. Non-copyleft code is therefore more acceptable to corporations and for projects needing fast and ubiquitous adoption. One of the issues with non-copyleft code development is that new functionality may not be resubmitted back to the project and may result in the original code’s use and growth being stifled due to forking.

Maintaining a directory of all open source components in your organization is no easy task. Along with the components, you must also track the license requirements and understand the potential for licensing conflicts. There are hundreds of different types of open source licenses, and the licensee must adhere to terms of each agreement it has accepted.

One of the early fears surrounding the use of open source within proprietary software remains a concern today. The broad reach of the open source agreements provides the potential loss of ownership of proprietary software if the proprietary code is inadvertently embedded in open source. This concern can be mitigated only by “best practice” development process, review, and vigilance.