Ict-innovation/FBT/5-4

= Module 5.4 Marketing FOSS =

Duration
0:45hrs

Delivery method
For instructional purpose, it is advised that trainers/lectures use lectures, role play and group and individual exercises as a major means of delivering this module.

Introduction
To a large extent, the software market is still dominated by proprietary software. Business specializing in commercial software have, over time, developed and implemented strategies to market their products and services. There is a wealth of other well-established companies from which new entrants can learn. Marketing FOSS products, on the other hand, is relatively new and marketing strategies which may have worked well prior to the Internet boom in the 90's may need to be revisited and improvements made where necessary. This module discusses, among other issues, strategies to be adopted, barriers to overcome, and knowledge and skills needed to successfully market FOSS products.

Clients and markets to target
Choosing which clients and markets to target is a strategic decision for your company. Your choices include:


 * other firms, both large and small
 * public bodies
 * local representations of international organisations
 * educational institutions: schools and universities
 * individual users

Each of these groups of client will have different specific requirements. Of course, these requirements also vary with the country, region and city or town your clients are based in. The better you get to know the requirements of your clients, the greater your chance of satisfying them. For this reason, many FOSS companies specialize in serving only one or two of these groups.

Overcoming barriers to adopting FOSS
Below, we discuss oft-cited barriers to adopting FOSS, along with their respective solutions.

Availability of support:
YOU are the solution. You can build a business on providing support to FOSS users, especially larger organisations. The fact that FOSS is often well documented, with vibrant communities around many programs, means that you will find it relatively easy to build up the necessary skills.

Availability of applications:
There is an enormous bandwidth of FOSS applications, serving almost every purpose. There are very few areas where there is no adequate FOSS application available to perform a certain job.

However, many people have grown attached to proprietary applications they have long been using. When preparing a migration, it is therefore essential to reassure them that they will have available the applications they need, and that they will be able to use those applications. The former may be accomplished by showing clients in detail which FOSS application will replace which proprietary program. The latter is a matter both of selecting user-friendly applications, and of offering adequate training to users.

In larger organisations, there usually are three approaches to replacing proprietary applications. These can be combined as necessary:


 * 1) find and deploy a sufficiently functional FOSS replacement.
 * 2) for applications where there is no FOSS equivalent, one option is to make them available on the internal network via a terminal server.
 * 3) continue to run the proprietary application in a virtual machine.

Software quality:
FOSS very frequently is very good, since in theory everyone is able to inspect the software, find errors, and report or fix them. Yet quality may vary, especially for projects with small communities. The overall variation in quality is not greater than for proprietary software.

Legal concerns:
Some clients may worry about becoming exposed to legal claims by using FOSS. In fact, the legal risk associated with FOSS is no greater than in the case of proprietary software. Usually, it is even smaller, because your client does not have to worry about acquiring software licenses.

It is your task to ensure that you adhere to the licenses of the FOSS packages you are using when integrating a solution. This should be a standard item in your contract with your client.

These legal worries also represent a business opportunity. You can offer, for a fee, to indemnify your client against legal claims made in relation to the solution you're selling. If all legal issues sound complicated for your business undertaking, please consult a legal expert.

Untold fears:
A client's CIO may fear that his importance in the company will shrink in line with IT costs, as budgets are adapted. This will usually not be the case. On the contrary, when costs do shrink significantly, the CIO will be able to claim the managerial merits for the savings.

Users may sometimes believe that the absence of a license fee for the software means that this software is low-end, and by extension that their work is not taken seriously. Here, it is very important for all those involved in the deployment of a FOSS application or solution to work with the users rather than against them. A good way is to talk to as many users as possible to hear about their IT needs. Your time will be well invested, since users feel that they are being listened to. Accordingly, they will be much more open to the changes you bring to their work environment.

The TCO debate
TCO stands for "total cost of ownership". In its simplest form TCO refers to all the costs associated with acquiring, installing and using a piece of software. This loosely defined concept covers a wide range of items, such as license fees, installation costs, and maintenance costs.

There is an argument about whether TCO is lower for proprietary software or for FOSS. While TCO varies from case to case, FOSS will generally have an advantage when long-term costs are figured in.

Somewhat counter intuitively, the fact that FOSS is available free of license costs does not greatly influence its position in the TCO debate. Even for proprietary software, license fees make up only a small proportion of total costs over time. This is especially true when your FOSS business is working in an environment where much of the proprietary software that is being used is unlicensed, and has been acquired at a price near zero. For large deployments, it is also quite common for large proprietary vendors to use a loss-leader strategy, giving away software licenses e.g. for the operating system for (nearly) no money in order to gain customers for applications building on that operating system. For these reasons, license fees often fail to work as a convincing argument for FOSS.

It is common for customers to move to new applications, be it because they offer better functionality, or because a proprietary supplier has disappeared from the market. Since most proprietary applications store data in their own proprietary format, it is usually very difficult for the customer to convert his data to a new format.

FOSS avoids this problem by using open standards - ways of sending, receiving and storing data that are publicly documented, and can be implemented by anyone. This has two important consequences:


 * it is easy to replace one component of a FOSS solution with another. The customer is not bound to specific applications, but can simply choose the ones that work best.
 * the customer avoids being locked into a particular software or file format, giving him greater flexibility in choosing suppliers.

This usually means substantially lower costs over the long term. Critically, it also means that the customer does not depend on a particular application from a particular supplier to access and manage his data. The customer effectively gains control of his own IT infrastructure.

The TCO argument is often used by proprietary vendors, using questionable data to argue that while FOSS may be cheap in the beginning, it costs more over the long term. In reality, the opposite is usually the case: E.g. a migration to FOSS will carry about the same costs as a migration to the next generation of proprietary software, but once the migration is over, IT costs tend to become substantially lower.

Making the case for your FOSS solution
There are a few steps you should follow when working with a client, in order to come up with a solution that meets the client's needs:

Identify the client's needs. Don't just rely on his explanations; try to observe first-hand how his company or organisation works, so you will get a better idea of the problem you're trying to solve.


 * Find FOSS products that meet your client's needs.
 * Compare them to proprietary alternatives, on functionality quality and cost.
 * Select the best products, and reject the others.
 * Try to find unbiased data to balance the marketing hype.
 * Be comfortable with your decisions, and be ready to present them to your client in a convincing manner.

Module 5.4: ASSESSMENT
Exercise 1: For an illustration of the independence afforded by FOSS, read through the case study on the German city of Munich's migration to GNU/Linux [Available at http://www.osor.eu/case_studies/declaration-of-independence-the-limux-project-in-munich ]. Identify and list down Munich's reasons for migrating, and the benefits the city hopes to obtain.

Reason 1:....................................................................................

Reason 2:....................................................................................

Reason 3:....................................................................................

Benefits of migration to the city council.....................................................................................................................................................................................................................................................................................................................................................

Exercise 2: Read through Mark Taylor's article on "The true cost of migrating to open source"[Available at http://www.zdnetasia.com/insight/software/0,39044822,62054142,00.htm ]. Imagine yourself in discussion with a skeptical client: how do you convince him that a migration to FOSS will be the better option in the long run? Among other things, your client will confront you with the view that "FOSS has a higher TCO"

Previous Chapter | Next Chapter