To make sure you realize all the benefits of open source, run these simple background checks on an open source project.
During the economic downturn, enterprises increasingly adopted open source systems due to their significant cost advantages and their liberal license policies. All open source projects, by definition, provide the end user with certain perpetual rights and freedoms in using, studying, modifying, and redistributing the product. However, there is a lot of inconsistency in terms of the product quality, the governance model, and the availability of support. Thus, when selecting open source components for your enterprise, it is important to do some background checks to ensure the open source product you have selected is compatible with your enterprise business model and IT standards. Below are 10 questions you can ask to evaluate open source maturity.
1: Are the open source license terms compatible with my business requirements?
Open source is mainly protected by copyright law, and the license provides the basis for the rights you have on the software. To be classified as open source. any product needs to adhere to the four freedoms: to use, to study, to redistribute, and to improve. However, licenses often include other terms that might be incompatible with certain business models. For example, the popular GPL license asks that any improvements and derivative works you create also be released under the same quid pro quo terms.
While this seems like a reasonable condition and will be not an issue for generic enterprise use, it can be a deal breaker for a proprietary product company that wants to include a GPL component in its product. Thus, it is important to make sure you understand the terms of the open source license before you adopt a component into your enterprise. The Free Software Foundation (FSF) and Open Source Initiative (OSI) serve as guides to open source licenses, and both have pages that validate and catalogue open source licenses.
2: What is the strength of the community?
An open source project is not just about the code, but also about the open community surrounding and sustaining the project. These communities can range from the lone teen developer to a single organization to complex diverse multi-entity communities, such as found in Linux and Firefox. A well known open source law demonstrated first in Linux is that “with enough eyeballs all bugs are shallow.” What this means is given a large enough critical mass of people in the community testing, maintaining, reviewing, and fixing the code, bugs and security vulnerabilities become less of a problem. A large active, diverse, and responsive community is always a key indicator of the health and sustainability of an open source project.
3: How well is the product adopted by users?
The test of any open source project is how well it has been adopted by various user groups and organizations. Many of the mature open source projects showcase various clients who have adopted and are using their product. This gives you some assurances that the product will deliver on its promises, especially if you find an existing client similar to your enterprise.
Probably the best insight you can get into a product is from another user who has been using it for a while. The best projects have a rich community of users with a dedicated mailing list, where you can seek input on the product from a third-party user organization.
4: Can I get a warranty or commercial support if I need it?
All open source project licenses are provided free “as-is” without any warranty. Based on your need, you could also support it to a certain extent internally and depend on voluntary support from the community. Voluntary support is not expected to compete with commercial SLAs, but the general responsiveness of the voluntary support will certainly improve your confidence in investing in the product. However, it will take you only so far.
Most enterprises are looking for a neck to squeeze in terms of commercial support/warranty, and a mature community includes vendors that can deliver to certain service levels. The ideal open source project has multiple vendors involved in the product that provide different types of support from customization to maintenance to 24×7 production assistance.
5: What quality assurance processes exist?
Many of the most popular open source projects now have the maturity and stability to support mission-critical production environments, but there are still many where the stability does not meet the mark. Of course, stability requirements will depend on where you hope to apply the product. Whatever your needs, it is always good to check the quality assurance (QA) process being followed by the project in its releases. If the quality assurance processes are not up to your organizational standards, you should consider the cost of conducting the missing QA process either internally or by a suitable vendor.
6: How good is the documentation?
Some open source projects can be very poor in their documentation. The software engineers leading open source projects are often focused on developing the product, so documentation is frequently an afterthought. At bare minimum, products need user manuals and administrator guides. Sometimes these guides are available online in the form of a wiki or even tutorials. Of course, the popularity of the product should have the quality of documentation factored in, but you should always ensure this documentation is suitable for your target user
7: How easily can the system be customized to my exact requirements?
Open source, as opposed to proprietary products, inherently means that the code is available for you to customize to your heart’s content. However, the cost of customization varies based on the architecture and extensibility of the system, how cleanly the code is written, and whether the product APIs are well documented.
All good open source projects include a well documented extensible plug-in architecture that can be used to customize the product. Generally, there will be a vendor that can do this customization on your behalf for a fee. However, it’s important to have more than one option available to you (including an internal option if possible). Otherwise, you have not truly eliminated vendor lock-in by going with open source.
8: How is this project governed and how easily can I influence the road map?
There are different models for how open source projects are run and how decisions are made. The best governance model is one that includes all stakeholders — developers, users, vendors — in a transparent decision-making process. For larger open source projects, a dedicated foundation is also invaluable in providing the necessary legal backing and assuring the intellectual property is managed well. Ultimately, the better your ability to engage and influence the developer community as a user, the more responsive the project will be to your needs.
9: Will the product scale to my enterprise’s requirements?
This check is important, even for commercial products. Research case studies and performance tests to ensure that the application can scale gracefully to the demands you place on it. Many open source applications are built on the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) or J2EE technology stack, which is generally one of the most scalable technology stacks available. A lot of the popular Web application portals utilize this stack and have customized it end to end to accomplish great scalability. One of the benefits of going with an end-to-end open source solution model is the long-term flexibility it provides.
10: Are there regular security patches?
A project that takes security threats seriously and is able to fix vulnerabilities before an attack can exploit them will have an established process for keeping track of security flaws and proactively elevating fixes up to the users. Turnaround time from identification to resolution is critical. This is the same for any proprietary project, but the benefit of open source is that you have the right to audit the code base independently for any security
flaws and can fix them yourself without waiting for the community to respond.