Open source vs commercial apps: the differences that matter II

---

Editor's note: This is the second and final part of our feature on software policy. Part one examined the license model differences between open source and commercial software. This week's instalment dwells on issues related to cost, security, flexibility and interoperability of each software models.

---

The ongoing debate on commercial software versus open source has sometimes centered on whether one approach to the software licensing and development model is inherently superior to the other.

In truth, there is nothing inherent in the models that makes one better than the other.

Both models each serve the specific needs and circumstances of the environment where the software is to be deployed. And such needs and circumstances ultimately determine what factors are relevant and applicable, and whether certain advantages and disadvantages of the open source or commercial software model should be given more weight and consideration in determining the approach for that implementation and deployment.

When making the comparisons, it is instructive to look from the standpoints of cost, security and flexibility.

A. Cost
The argument that open source software is cheaper than commercial software should be considered in the context of the lifetime costs of a product, which proponents of commercial software would argue are at least comparable between both models.

In terms of purchase price, it is reasonable to assert that open source solutions tend to be cheaper than commercial software. However, it is also valid to consider the cost of software as a total cost involving the entire lifecycle of the software, rather than the one time purchase price.

Increasingly, new business models are being introduced to attract customers with lower up-front costs, but with higher recurring costs (e.g. cheap mobile phones in exchange for recurring subscription packages). Accordingly, the cost of software should not be assessed merely on the start up purchase price, but also on the long term support and maintenance needs, in addition to other less tangible issues like usability of the product and productivity gains from the use of the products.

In addition, it is often necessary to consider the cost of retraining users for an alternative product. Such retraining costs may be quite significant when one takes into account the total time spent by the users undergoing such retraining and the initial lower productivity levels while the users familiarize themselves with the alternative product.

While there are many studies and surveys in this area offering different costs analysis models, technology decision makers should ultimately weigh the full range of costs, including lifetime costs and migration costs, when evaluating their own choices in this area.

B. Security
It has been argued that open source solutions, with their source code available for public scrutiny, is inherently more secure than commercial software solutions, whose source code is not published.

On the other hand, it has also been argued that it is easier to find and exploit flaws in software whose source code is published. The debate in this area rages on.

The truth of the matter is that the security of any technological product and implementation is not predetermined by the method of development or distribution. Some commercial products are less secure than their community-developed counterparts, just as some open source products are less secure than their commercial counterparts. While the design of security features matters significantly, it is even more important how well the software is deployed, configured and maintained, including upgrading the products to fix flaws as they are discovered.

These variables are contingent on the customer taking due care--not the licensing or development model.

In considering whether making source code available for public scrutiny makes the code more secure, one needs to understand the genesis behind this argument. This line of thought is consistent with the oft-cited axiom that "security by obscurity is no security". However, the fundamental basis of that axiom is not that obscurity (or the absence of public knowledge) of the security mechanism is inherently insecure, but that a security mechanism cannot be considered secure on the basis that no one knows how it works.

Clearly, a security mechanism that relies on a secret mechanism (as opposed to, say, a secret key) that no one knows will quickly fall apart once the secret mechanism is made known. This is a separate issue from keeping a security mechanism confidential. Still, its security does not exist by virtue of its mechanism being kept a secret.

Security may be derived from the use of an appropriate secret key that may be changed from time to time. A concealed security mechanism may potentially be more secure, as it is necessary to discover the security mechanism as well as the secret key before the mechanism can be broken or defeated.

In the open source community, where voluminous quantities of source code are available, it is not realistic to expect that every single line of the code has been scrutinized by a wide range of security experts. New packages and add-on software are developed and distributed regularly, but they may not have undergone the same level of scrutiny as, for example, that of the core kernel of Linux. Users who obtain such packages are likely to compile, install and use the software even before taking a look at the source code, even though it may have been provided with the software. Only a very small minority of the community will indeed scrutinize the source code of every program before using it. Given such a scenario, it appears premature to declare that open source is superior in security.

The concern over the lack of access to source code is increasingly also being addressed by commercial software vendors who make available such access to source code for specific purposes. For instance, a number of Asian Governments and security agencies have had access to the source code of commercial software products, and have undertaken security review of such products. This access provides the Government with the opportunity to rigorously review the source code of the product, as they would also do so with the source code of an open source solution. With time, there are also increasing instances of the source code of other commercial software products being released publicly. The availability of source code for the purposes of undertaking a security review is hence no longer a compelling basis to prejudge commercial software and open source solutions.

Another argument in this area of security focuses on the assertion that there have been many more reported cases of security flaws in commercial software solutions compared to open source solutions. Here, it should be borne in mind that the problems may be more prevalent and widespread as a result of the popularity of a platform or software, and not due to its design or the method of software development. The platform that is more commonly in use will be the platform that security attacks are more likely to be launched, as hackers arguably have a greater incentive to hit a larger target than a smaller one.

Security flaws are a result of a combination of factors, including the software design and implementation as well as user behavior and usage, coupled with the skill and expertise of the user in installing, deploying and maintaining the software. Anecdotal experiences relating to the number of attacks borne by commercial platforms are not necessarily testimonies to the notion that open source solutions are less vulnerable or that commercial software solutions are more vulnerable.

Taken in totality, it is not at all clear that one can draw any reliable conclusions about whether a product is more or less secure on the basis of the software development model on which the product is built or its licensing model. The security of any software product and implementation is not pre-determined by the method of development or distribution, but by the proper design of security features, and more importantly by the correct deployment, configuration and maintenance of the software by the customer.

Bottomline? Each product and implementation should be assessed on its own merits and strengths.

C. Flexibility
The argument that open source solutions are more flexible for customers compared to commercial software stems from the ability of a customer to examine the source code and make the necessary alterations to the code to effect changes in the behavior of the system desired by the customer. This also allows the technically-savvy customer to potentially identify any problems in the system and to make his own changes or fixes to the software to rectify the problem.

There are resources available for both commercial software and open source solutions to address the bugs and security weaknesses in the software.

There is however no clear advantage with either model when it comes to obtaining bug fixes for known security problems.

Fixes for commercial software are typically available only from the software providers, who have an incentive to ensure the reliability and trustworthiness of the bug fixes released, since their credibility will be severely affected if a bug fix results in more problems.

On the other hand, bug fixes for open source solutions come from a greater variety of sources. They may be developed through community effort and distributed through channels such as discussion groups. Such fixes may be iteratively refined and improved on by the community if the initial fixes do not correct the bug completely, and may be subject to less rigorous testing before they are released. Community contributors of such "public" bug fixes do not usually bear the same accountability and responsibility as "commercial" bug fixes that are distributed by commercial software providers.

The flexibility to modify source code in an open source solution also leads to another phenomenon known as "forking". Forking occurs when one developer decides to modify the software source code and takes a path that is divergent from the original software such that any subsequent changes or improvements made to one version of the software will not apply to the other version. Issues of compatibility and continuity will therefore arise and need to be managed when forking occurs. A notable example of forking occurred in the early days of UNIX when different hardware vendors produced different variants of UNIX for each of their platforms, e.g. System V, BSD, AIX, Solaris, HP-UX, etc.

On a smaller scale, customers who make their own modifications to the software will also find that the continued support and maintenance of such changes becomes a more involved process, as the support resources need to be equipped with the knowledge of the prior customization done as well as the skills needed to perform subsequent alterations. In contrast, commercial software solutions tend to have a more well defined and controlled upgrade and migration path for products. Customization built on such platforms using the published application programming interfaces often will continue to work with upgraded and future versions of the product with little or no changes.

Ultimately, in considering whether flexibility is important in making a software choice, the main issue to consider is whether there is a need for specialized customization to be done to the acquired software (whether at the application or operating system level) to meet specific or unusual needs.

If the answer is yes, additional resources should be provisioned to maintain such non-standardized customization from the standard release of the acquired software. If customizations are not done to the acquired software but are instead built in addition to or at a layer above the software, the software development model of the acquired software is, in that scenario, not a relevant consideration.

Interoperability and Open Standards
One of the common motivations behind a push to evaluate or prefer different software development models relates to the desire to address the concerns of interoperability. Standardization for interoperability facilitates a customer's ability and flexibility to choose from a range of competing software products to meet his intended purpose. Where customized products are acquired, it is similarly important for such products to remain inoperable with other existing solutions or future additions so that they do not quickly become obsolete.

The use of open standards promotes interoperability as the standards provide a clear definition of how information and data are to be exchanged between different components operating together. However, open standards are not synonymous with open source, and do not exist only by virtue of open source. Instead, open standards are created through a defined process or procedure where collaborators collectively discuss and decide on what the standards should be for information and data exchange. This is unlike the situation where software developers are free to individually choose and decide how to code the internals of the software. Once defined, open standards are available to any software developer, and they do not require open source software for their adoption or use.

Software industry players, regardless of the software licensing or development model adopted, recognize the need for interoperability and are already working together to define such standards. The role of Governments should be to encourage and facilitate such standardization initiatives, and raise the general awareness and incentive for domestic software industry to collaborate with international players in this regard.

Effective standardization efforts at the basic functional level will bring about greater competition at the higher application levels. Vigorous competition among different, but interoperable, technological products will allow customers to exercise free choice among innovative products to select the solution that best serves their needs. The undue preference for one particular product, platform or software licensing or development model not based on objective criteria such as open standards will inevitably disturb the competitive forces that can bring about the best results for consumers.

Key Actions
In light of the issues highlighted above, in considering options between open source and commercial software choices, the following should be kept in mind:

• Cost considerations should be viewed in totality. While cost is an important issue, it is usually not the sole determining factor; in some situations, such as in mission critical or public safety systems, cost may even be a subsidiary concern.

• If the security of a product is important to the customer, the primary consideration should be to ascertain that suitable and adequate resources are allocated to ensure the correct installation, deployment and maintenance of the software, rather than make predeterminations based on the underlying software model. A technological product is only as secure and reliable as the extent to which the users have taken the necessary care to properly install and maintain the product. A poorly maintained product offers little security, regardless of the software development model used to create the product.

• If a security review of the source code is required, further resources should also be allocated to meaningfully scrutinize the source code of the components to be deployed. It should not be assumed that because the source code has been made publicly available that it has, in fact, been sufficiently reviewed.

• Suitably skilled and trusted manpower need to be available, and if necessary, developed, to support the software platform. It should be assessed whether such expertise needs to be available in-house or from an outsource vendor. The cost of such resources for migration and support should always be considered as part of the total cost of choosing the product.

• Requirements for flexibility in modifying the acquired software should be carefully considered against whether the expertise to exploit such flexibility is available, and if the necessity for flexibility is fundamental or merely incidental. The long term support implications for nonstandardized modifications to the software should also be factored into the purchase decision.

• The use of open standards should be promoted, and such standards should not be defined exclusively in relation to any particular software development model, but should be available generally to any software developer.

Conclusion
In the discussion above, the arguments that have been commonly raised regarding open source and commercial software solutions are analyzed with a view to distilling their validity from their rhetoric. The analysis demonstrates that, while the rise of different software licensing and development models has certainly furthered innovation and therefore strengthened the overall software marketplace, it does not follow that the evolution has necessarily created a "superior" method of software development, or that a "superior" approach of licensing necessarily exists.

As we have seen from the first part of this discussion, the open source and commercial software development and business models have complemented each other in a number of aspects. Nonetheless, the debate continues to rage on with regards to which model is "superior".

Having considered the issues above, it is clear that the issue of which model is "better" lies with the specific circumstances or requirements that a customer may face, rather than in the inherent nature of either model.

Mr Goh Seow Hiong is the Director of Software Policy for Asia of the Business Software Alliance.