Some nations have proposed to promote the use of Open Source software within their own government offices. Producers of proprietary software say that this would be unfair discrimination, and ask that purchasers refrain from discriminating between Open Source and proprietary software. Instead, the proprietary vendors suggest, government purchasers should compare software programs solely upon their merit.
This suggests a question: is the licensing paradigm, Open Source or proprietary, itself a merit? Should that merit be considered when making a purchasing decision? In this paper I demonstrate that an Open Source licensing policy is indeed of significant merit to the purchaser. Given a competition based solely upon merit between two programs of similar functionality, one proprietary and one Open Source, the Open Source program should win.
The table below is a quick way to get acquainted with the user-visible differences between Open Source and proprietary licensing. The column "Open Source" refers to any of the software licenses accepted by the Open Source Initiative. For "Proprietary Software" I have selected the EULAs (end-user license agreement) used on Microsoft products as representative of the proprietary software industry.
| Topic | Open Source | Proprietary Software |
|---|---|---|
| Unit cost of software per user or site. | No payment required for additional users or sites. | Requires per-user or (expensive) per-site license. |
| License Audit Cost. | No user license auditing. | Intrusive license audits with expensive settlements are common. A high book-keeping expense is required in order to appear to be in compliance when audited. |
| Software lifetime. | Software survives the demise of its vendor or discontinuation of the product. | Software usually becomes un-maintainable and can not be sold after the demise of its vendor or discontinuation of the product. |
| What happens after demise of developer or discontinuation of product? | Community, service providers, or individual users can continue development and support if any developer drops out. | Sometimes other businesses can purchase the copyright and continue a product profitably. |
| Support cost. | Competitive market for customer-service providers drives price of support down, and quality up. | Customer-service monopoly by the software copyright holder. Arbitrarily high price for service. Less incentive to improve quality of service. |
| Support lifetime. | Software can be supported indefinitely. Any customer can contract with any willing support vendor to provide support. Customers can self-support. | Software can generally not be supported once vendor declares end-of-life. |
| Who can sell support? | Availability of source and the right to modify and redistribute means that any practicioner can repair the software. | Alternative service vendors may provide a help-desk, but are unable to actually repair the software. |
| Access to source code. | Customer has the source code, or can acquire it at any time without charge. | Customer may negotiate for source-code escrow at added expense, but source-code escrow contracts tend to be overturned by bankruptcy courts, which are more concerned with transferring the full lock-in value of intellectual property to creditors. |
| Customization. | Every part of the software can be customized. | Software can be extended through scripts or plug-ins, if it provides that feature. |
| Open File Formats? | All file formats are open. File-handling source-code is directly reusable in other Open Source applications, and is self-documenting for developers of compatible proprietary applications. | Closed file formats drive incompatibility between programs. Reverse-engineering may be possible if DRM is not used to lock and obscure the file format, and if law permits reverse-engineering. |
| Who Can Make Changes? | Anyone can change any part of the software. Changes to the software can be shared directly with other developers and customers. Distribution of derived works is encouraged. | Only copyright holder can change core software. Distribution of derived works may be prohibited. |
| Is Reverse Engineering Permitted? |
Permitted, but unnecessary due
to availability of source code. |
Prohibited by license terms. |
| Size and Nature of Developer Community. | Promotes a large community of developers of the core software and compatible programs. But no guarantee that developers will be interested. | Developer of core software is supported by sales, will continue if profitable and business direction does not change. Core developer may promote developers of plug-ins and scripts. |
| Future Development Possible? | Any party that wants to invest in the work can continue development. No party can block further development. | Copyright holder can block further development, and will generally do so if they feel that an investement in further development by the copyright holder is not warranted. |
| How Development Costs Are Distributed. | Users all pay for a piece of development, either through direct participation of their own staff, or through their spending upon service businesses. | Cost of each unit of software purchased contributes to development cost. |
| Development Cost-Efficiency | Most of software cost goes to software development and service. | Most of software cost goes to expenses other than software development, such as advertising, marketing, package design, fees for retail shelf space, overhead of wholesalers and retailers. |
| Development Direction. | Any developer who cares to can pursue their own direction, the best improvements will be adopted by the developer community, other improvements can continue as "patches". | Development direction is generally set by the software vendor's marketing department. |
| Who can you sue if software fails? | Nobody. Licenses disclaim warranties, limit remedies, disclaim liability. | Nobody. Licenses disclaim warranties, limit remedies to the cost of the software, disclaim liability. |
| Copying and Redistribution. | Copying and redistribution permitted. | Backup copy allowed. No other copying permitted. Redistribution prohibited. |
| Free speech constraints in software licensing. | None. | Some license versions prohibit publication of unfavorable benchmarks and unfavorable comments regarding software. |
The above table shows some significant advantages of Open Source for the end-user. Given two programs that are otherwise similar in merit, the Open Source program would generally be of greater merit to the purchaser. This is, however, not necessarily the case for the software developer.
Next, let's look at the differences between Open Source and proprietary software that are most visible to software developers.
| Topic | Open Source | Proprietary Software |
|---|---|---|
| Who is the Developer? | The developers are a loose collaboration of businesses that make use of the software, or service businesses that cater to them. | The developer is a single company, generally expecting a payment per unit of software. |
| How Development is Funded. | Funding of further development must be indirect: as a cost-center of the businesses making use of the software to enable their business, as part of a service business, or as a research program. | Direct revenue-capture per copy of software licensed provides a revenue stream to support further development, if copyright holder feels an investment in further development is warranted. |
| High Margins Possible? |
Extremely competitive market and no possibility of customer lock-in limits margins for any business involved with the software. | Potential for customer lock-in attaches a significant monetary value to the software, high margins possible. |
| IP Value of Business? |
Open Source licensing may reduce
or eliminate value of intellectual property owned by the business. |
Significant monetary value to the software is not diminished by proprietary licensing, high margins possible. |
| Overall Value of Developers Business. | Value of business depends on people: key workers and the knowledge locked in their heads, like any service business. | Value of business depends on value of intellectual property first, people second. |
| Scalability of Business. |
Scales linearly with addition of
service personnel, like any service business. |
May scale better than linearly. |
You may conclude from the information in the above table that Open
Source is much more to the advantage of the customer than the developer.
If the developer's main activity is to produce software for sale, Open
Source may indeed not be their first choice of business method.
Would it be possible to build a business like Microsoft on Open
Source? No, and we consider this to be a feature rather than a bug. The
40% margins reported for Microsoft are unlikely for any Open Source
company. Simple economics would cause competitors to spring up in any
market with such high margins, and those competitors would have access
and right to all of the same Open Source code as the original business.
Price competition would reduce the margins to something reasonable. In
short, you can make a living by creating Open Source software, but you
can't make a killing.
But how much should the customer care about the reduced margins of
an Open Source vendor? The customer's interest is to get as much benefit
from their software purchase as possible, for the lowest possible cost.
Do high vendor margins, and high business values for the vendor, work in the customer's interest?
Only if they result in an increase in creative output from the vendor
that is so advantageous to the customer that it offsets the increased
cost. In practice, this is unlikely. What is to assure the customer that
higher prices will result in increased innovation? The software
developer is under no obligation to re-invest its profits in development
of products that are of interest to the customer. They may take those
profits out of the business rather than re-invest them, or they may use
them to diversify into lines of business that are not of interest to
their existing customers.
Another area in which the customer should carefully weigh their own
interest is the topic of short-term costs versus long-term ones. An
investment in proprietary software may yield an attractive short-term
cost savings while increasing costs over the longer term. The most
likely scenario for this is a purchase decision that locks the
customer's future purchases into a single vendor's products. The
technical mechanisms used to enforce customer lock-in are closed file
formats and closed communications protocols. These leave only one place
to turn for software that is compatible with that which has already been
purchased. Open Source software, by virtue of its
source-code-availability and the right to examine or reuse the code,
guarantees that the file formats used by that software are open as well.
Thus, a purchasing decision that takes long-term cost into account might
well place additional merit upon the Open Source nature of a purchase
candidate.
It's in the customer's interest to weigh all of the merits of
candidates for their software purchase. If a proprietary software
program offers better features, better ease-of-use, and lower
total-cost-of-ownership than an Open Source program, the customer may be
best served to choose the proprietary software. But if two programs, one
Open Source and the other proprietary, are similar in features,
ease-of-use, and cost-of-ownership, the merits of Open Source elaborated
above would tip the scale toward the Open Source program.