Ict@innovation: Free your IT Business in Africa/2-9

= Module 2.9 Taxonomy of FOSS Business Models =

Duration
1:30hrs

Delivery method
For instructional purpose, it is advised that trainers/lectures use lectures and debates as a major means of delivering this module. In addition, presentations and exercises are also suitable method of delivery for this module.

Introduction to FOSS Business Models
FOSS offers opportunities for a wide range of business models. Each model deriving value from the freedom businesses and individuals have in using, modifying, sharing and redistributing legal copies of the software. One element common to all FOSS business models is that more profit is made around services instead of sales of already developed software products. At the level of service-based business models there is actually little or no significant difference between FOSS business models and proprietary business models. A proprietary software oriented company may give the same quality maintenance services to a client as that provided by an FOSS company. The main difference lies


 * in the way the company generates revenues,
 * how customers benefit from the company's products and services. FOSS provides access to the source code and the right to modify it, proprietary software does not, and
 * the cost model employed

There are also some differences regarding the core capabilities needed to run the business model. FOSS business models require FOSS skills and (at least some) interaction with the community. But there are no necessary differences between FOSS and proprietary business models regarding the partner network, the markets / customers, the distribution channels, the relationship to customers and the management of these relationships.

The fact that the source code of FOSS is open while the source code of proprietary software is closed does not matter if the FOSS client does not want or is not able to check or modify the code. The main business advantages of FOSS are not so much on the demand side but on the supply side. A proprietary vendor is limited to mostly few or one type of software provider or developer. FOSS is usually provided by a much larger community of developers and testers, or vendors. This community provides a powerful test bed and developer pool that allows FOSS businesses to interact with this community in a meaningful way to shorten development cycles and time needed for customizing software to clients' needs. To interact with the community in such a meaningful way is however bound to two fundamental conditions:


 * 1) The community supporting a company's FOSS services must be large enough, and it should also show some degree of professionalism, such as the capacity to stick to schedules or the existence of key players in the community that can be contacted to change the software, fix bugs, to organize work within the community, etc. The most essential company-community dynamics is that the company must consider itself as being part of the community, and reciprocally, the community must see the company as responsive to their needs and aspirations.
 * 2) The second point is crucial when FOSS businesses in many developing countries are considered. Evidently, a company selling services on top of FOSS products will be able to get more and better support from the community if it continuously interacts with the community, participates in communications and events, maybe sponsors some events, sends bug reports or patches to the community, etc. A successful FOSS company MUST NOT just download the software from a project's website or forge but MUST remain visible to the project’s community in anyway it can. The most extreme form of cutting the company off from the potentials provided by community support is to create a fork of the community software, as forks are usually not welcome by many FOSS communities (See module 1.1).

In Europe and North America businesses have all opportunities ranging from full FOSS collaboration to forks. Forking a project might be a useful strategy for a company if, for instance, the community does not support functionalities the company wants to be integrated in the software, or if the release schedule does not fit in the company's plans. The disadvantage of forking a project – which may lead to the loss of community support – is less pronounced in niche markets (where communities are small anyway) or in communities that are large enough to split and to provide support for the original FOSS solution as well as for the fork.

However, in many developing countries businesses face a very limited choice of opportunities. Because the communities are often very small, businesses have difficulties to find effective local community support. The situation of FOSS businesses in many developing countries can be compared to a company in an unintended fork situation, they rely on their own capacities to understand and modify the code, to find and fix bugs, to adapt the software to customer needs and so on. As a result, while FOSS enables firms in Europe and North America to use the community in order to save software development and deployment time, firms in developing countries often do not have these opportunities.

Taxonomy of FOSS Business Models
Taxonomy is systematic way of naming and organizing content into groups that share similar characteristics. In classifying African FOSS business models, a faceted topology is considered. A faceted taxonomy is a star-like structure with each node in the star being associated or linked with the item in the center of the star. For example; Apache being the center of a star with each node or sub-project (HTTP Server, Ant, Harmony, Jakarta, Tomcat, etc.) representing one of it’s over 70 projects. In the FOSS business models taxonomy represented in the figure 2.8.1 below, the four essential FOSS freedoms (see module 1) and business value are at the center of the star. Protruding from the center are nodes or business models which are found to be in operation in the case studies.



Figure 2.9.1: Faceted Taxonomy of African FOSS Business Models 

Table 2.9.1 below summarizes business models captured in the case studies. In the table, the following legend is adopted: SSL = Software Selection, INS= Software Installation, INT= Software Integration, STR= FOSS Training, MAS= Maintenance and Support, MIG= Software / Systems Migration, CON = Consultancy, LOI = Software Localization and/or Internalization, DEV = FOSS Development and Customization CET = Technical / Legal Certification.

Table 2.9.1: African FOSS Business Models captured in Case Studies.

Software Selection
Revenue is made in the software selection business model by charging services associated with helping customers select the most appropriate FOSS application for a given task. Daffara, C. (2007) highlighted that software selection is really a multi-step phase, starting from the identified needs and knowledge of the software market to the selection of packages that minimize the amount of code that needs to be developed. There is ever increasing proliferation of FOSS and often more than one type of software is available to perform the same task. For example; both OpenOffice and KOffice are suitable word processing suits.

A company wanting to offer this kind of service may need substantial investment, in terms of knowledge of the different packages and tools available, forges and projects offering the software solution, communities behind the software, security issues, and be able to evaluate the selected software against international standards such as the ISO 9126 - reliability, functionality, maintainability, portability, usability, and efficiency. Furthermore, argued Daffara, C. (2007), most projects do not have an explicit “marketing mechanism”, which spreads information on features and capabilities on a software package like commercial software firms. This means that companies that want to offer software selection consulting services must dedicate a certain effort just to monitoring web sites and mailing lists, and extract from there information on new versions or new packages. All, but two of the companies from the case studies are adopting this business model.

Installation
One of the most common FOSS businesses is to offer to install FOSS for customers who do not possess sufficient skills in the installation and maintenance of FOSS solutions. With GNU/Linux operating systems in particular, there are lofts of different interactive and non-interactive package installers in use which makes software installation and upgrading much easier. Package management systems (eg. dpkg for Debian / Ubuntu or deb packages; RPK for RedHat/Suse rpm packages) and installers (e.g. Synaptic with APT) are used to install, remove and obtain software information. While money can be made by installing software, care should be taken that companies do not charge much for this service. Rather, software installation should be seen as “gift” service and the company should FOSS installation as a means to cultivate a critical mass of customers for future activities such as the maintenance of the installed software or the training of clients in the use of the software. All the companies studied are adopting this business model, with some variations.

Integration
The business model behind FOSS integration involves charging customers who want certain components to be integrated into their (new or existing) systems. In order to be involved in this type of business, companies need to have the expertise and skills needed to understanding how a particular solution or software works as a unified system. Complex software systems are made up of many small bits and pieces or components. Often components need to be added or remove so that the software system operates in the way the customer wants it. Daffara, C. (2007) pointed out that software integration businesses may need to adopt a two-step approach to this type of business. Developing and mapping “specific configuration step necessary to “fit” an open source component in an existing structure and to the custom development necessary to add the missing functionalities or correcting the incompatibilities”. Thus, software integration as a business requires a lot of technical and software competence; although there are Enterprise Application Integration (EAI) tools such as openadaptor. In the case studies, only three companies are involved in the software integration business.

Training
FOSS training as a business is the most common business model in Africa and is captured in 100% of the cases studied). FOSS training has a success factor due to the nature of the FOSS phenomenon, development process, and community dynamics. The FOSS phenomenon is a relatively new concept, warranting substantial investment in training people on FOSS basics. FOSS projects in general have poor documentation and even where documents are available, the style of presentation and content is often very difficult to understand form a non-technical or novice perspectives. Software help is always available in forums and mailing lists. However, many users, especially in Africa, do not have the experience to participate in FOSS forums and mailing lists. This makes it difficult to obtain help from FOSS projects. Active participation also requires Internet access and good connection, which has remained a potential barrier for full participation in FOSS projects activities. These FOSS barriers have turned out to be good avenues to establish and conduct FOSS training. The FOSS training business training can take many forms (see module 6), ranging from training for certification to training customers in the use of FOSS solutions. Daffara (2007) concords that companies installing or supplying an FOSS solution also need to train the customer alongside. Training is usually personnel-intensive, and requires some effort for the creation of the initial training material to be used during the courses. A good estimate of work needed is that it is necessary to invest around 3 to 8 hours of course material preparation for each hour of training delivered.

Maintenance and Support
Software is like a car with open hood (as in FOSS) or welded hood (as in proprietary software) and needs to be maintained. Users need frequent support when the software malfunctions or performs as unexpected. Daffara (2007) offered a comprehensive narrative on the maintenance and support business model by highlighting that in most complex systems there is a continuous need for support and maintenance, both for feature enhancements and for the adaptation of the system to the changing IT environment. Support contracts usually are time-based and level-based. Levels are commonly three (corresponding to “bronze”, “silver” and “gold” support services), with varying degree of guaranteed service.

The support model is used by many companies that turned a commercial package (not completely successful in the commercial market or unable to completely fulfill its market potential) into an open source one; the underlying idea is that the authors of the code are supposed to be the most qualified experts for support it. The first famous example of this model was the Zope application server, with many others in active existence (for example, the computer aided design OpenCascade toolkit, Compiere, Alfresco and many others). It is interesting to notice that contributions from the outside are usually received from outside participants even in the case of very specific application areas, like for OpenCascade. All the companies in the case studies provide support and maintenance for their customers.

Software Migration
Similar to integration services, migration is based on the deep knowledge of both the starting and end IT environment. Most migration services are based on software packages that help in automating the migration (for example of user configurations), or on pre-configured “packages” of OSS that provides complete substitutes of proprietary environments. Examples may be mail/groupware systems or desktop operating system replacements. Migration services usually require a specific integration step in addition to the base migration, and for some large scale effort may require coordination among different companies, offering coordinated service (for example, one specialized in porting custom code, one in migrating mail services, etc.). The Case Study below shows software migration of Department of Computer Science and Information Systems (CSIS). Uganda Matyrs University.

'''Migration Case study: Department of Computer Science and Information Systems (CSIS). Uganda Matyrs University'''

Consultancy
FOSS based consultancy services is one of the most common business practice documented in the case studies. However, most of the companies utilizing this business model are doing more consultancies in the proprietary software domain. In the FOSS world, FOSS developers who want to be independent start a consultancy business. This business model is seen as a means to make a living and become independent but at the same time keeping an eye on what goes on in the FOSS world. Consultancy business takes many forms; ranging from domain name registration, web design and hosting, installation and configuration of learning management systems, to server maintenance and the supply of hardware with Linux (mostly Ubuntu) installed. Thus, FOSS consultancy is rarely a standalone business, but rather operates in juxtaposition with other business activities. This being the case, it is important to bear in mind the following tips:


 * What are your competitors doing?
 * How much are they charging for services similar to what you are offering?
 * Consider sub-contracting services
 * Get marketing and business skills
 * Understand the legal aspects of doing business in your area.

Localization and Internalization
Localization of a piece of software is the process of modifying or changing specific parts of the software (e.g. adding a company logo) so that it meets the needs of local markets or customers’ requirements. Localization enables software users to interact and identify themselves with the software in a language and culture which is native to them. Localization is more than just an FOSS business practice, it is philosophical and patriotic. Properly done, it gives the users the feeling of ownership and control over the software and business. Internalization is the process developing or modifying a piece of software so that it meets the needs of different locales or language requirements. Software internalization has wider implications and much broader than localization. Most often the terms localization and internationalization are used interchangeably. According to World Wide Web Consortium or W3C, internalization entails:


 * 1) Designing and developing in a way that removes barriers to localization or international deployment. This includes such things as enabling the use of Unicode, or ensuring the proper handling of legacy character encodings where appropriate, taking care over the concatenation of strings, avoiding dependence in code of user-interface string values, etc.
 * 2) Providing support for features that may not be used until localization occurs. For example, adding markup in your DTD to support bidirectional text, or for identifying language. Or adding to CSS support for vertical text or other non-Latin typographic features.
 * 3) Enabling code to support local, regional, language, or culturally related preferences. Typically this involves incorporating predefined localization data and features derived from existing libraries or user preferences. Examples include date and time formats, local calendars, number formats and numeral systems, sorting and presentation of lists, handling of personal names and forms of address, etc.
 * 4) Separating localizable elements from source code or content, such that localized alternatives can be loaded or selected based on the user's international preferences as needed.

As a viable FOSS business model, the case studies demonstrate that it only makes business sense to internationalize software if there is market for it. It makes little business sense for an FOSS company in the Gambia, for example, to spend considerable time and effort in translating Mozilla Firefox to the Fula language when the official language and majority of the business community speaks English. However, localization is a big business throughout Africa. Customers want to have ownership and want their logos on their product and they feel much better if they can click in Swahili Anza (Start) or kufungua faili (Open File). However, many users would rather welcome “This program has stopped responding” than the Swahili equivalence “kuacha kukabiliana”. This shows the sensitive nature of localizing software and companies should take great care, know the ethics of their business milieu and consult with customers before engaging in any localization business activities.


 * Resources and tools for localization of FOSS is available at: http://www.iosn.net/l10n
 * Sasikumar, M., Aparan, R., Naveen, K., Rajendra, M. (2005). Free/Open Source Software. Guide to Localisation. International Open Source Network. Centre for Development of Advanced Computing, CDAC Kharghar Mumbai, Maharashtra 400614. Available at: http://www.iosn.net/l10n/l10n-howto-toolkit/guide.pdf

Software Development and Customization
The FOSS development paradigm leverages the internet and a community of volunteers to develop, customize and deploy software of high quality within a shorter development cycle. The software is assumed to be better in quality, responding to different customer demands overtime. Innovation in happens because X individual or company with competent skills downloads the source code and customizes the software according to (customer) needs. The software is then released with the ‘improvements’ to the customer or community via the project website or through a software forge (e.g. SourceForge, Gforge, Freshmeat, etc). However, for most small businesses fine-tuning software or applications functionalities according customers’ needs is limited to “development – via- customization”. In this process, a company does not work with or change the core of the software, but just customizes the graphical user interface (GUI) to meet client’s need. In some cases, a company with expert software development staff can develop their own software and release it as “Free for download software”. Customers can download and use the software as is or pay the company for further customization. However, customizing FOSS does not always give an FOSS SME autonomous freedom. For example, if a company or individual uses Zimbra collaboration Suite Open Source edition license, and have modified the software, the company is required to use the Zimbra Inside logo on the web client interface.

Certification
Daffara (2007) discussed technical suitability and legal certification is viable FOSS business models. He went on to argue that technical suitability certifications is mostly done by integrators and external consultants, and may come in two shapes: certification of adherence to an international standard (for example security or quality standards) and certification of suitability for a specific environment. In a sense, in both cases the integrator provides an insurance that the software package complies with a specified set of rules, and is legally liable for such compliance. Limited scope certifications, like security assurances, are quite within scope of SMEs, while large scale quality assurance of components is quite difficult to attain if the open source project itself does not have an in-place explicit mechanism for project management. Most Linux distributors perform this suitability test in a very simple way, by selecting the most plausible candidate version of a source code package depending on the distribution target (for example, in so called “enterprise edition” distribution only stable versions are used, while for "bleeding edge" distributions the latest unstable version is selected).

Legal certification, according to Daffara (2007) is a relatively recent model, which emerged from the perceived problems of mixing code from multiple licenses, and from several lawsuits. Legal certification is related to the following areas: correct use of OSS and commercial licenses, patent certification, other intellectual property certification. The first area is related to the mixing and correct use of components, which may have different licenses and different restrictions. While more than 70% of the open source code is actually released under the GPL, more than 50 other licenses exist, and some fundamental components are released under a non-GPL license (the Apache foundation software, Mozilla/Firefox or the Eclipse integrated development environment).

When using and integrating many different components, it is fundamental to be able to verify that all code is properly used and accounted for. This is really a task that requires legal capabilities, more than technical ones, and for this reason is perceived by the FOSS community to be a “tangential” model.

Due to the inherent nature of technical suitability and certification, non of the companies in the case studies reported generating revenue from business activities in this area. However, the African FOSS business market shows promising signs in these areas.

Other Business Models
Some new and hard-to-categorized “African FOSS Business Models” emerged, which participants believe to have huge business potentials.

1. In the area of FOSS packaging


 * FOSSCDs (www.fosscds.co.za) forge business.
 * Pack schema....vs freedom toasters, opencafe concept.

2. In the area of FOSS marketing


 * Build a FOSS repository of goods and services


 * FOSS companies can use and benefit from incubator
 * Others assorted business models
 * Provide FOSS documentation
 * FOSS Strategic management,
 * Policy advise, legacy issues for start-up companies


 * Specializing of FOSS for Mobile devices
 * Data archiving, storage
 * Data processing
 * Accounting, survey, tax and census data analysis

Status of FOSS Policies in South- and East Africa
The table below shows the status of open source policies captured in the South and East African region. Note, apart from South Africa and Kenya, no known FOSS policy exist even though FOSS businesses are thriving in these countries. How did that manage to do this? what are future implications for operating FOSS business without policy backing? what should come first, establish a policy and encourage business practices around it or use existing business environments to build policies to help protect those businesses and make the uptake of new ones much easier?

= Module 2.9: ASSESSMENT =
 * 1) Exercise: Use available resources (internet, contacts, local news, etc) to update and fill out the 'unknown' information in the table in module 2.8.2. Provide the same information for countries you may know and are not listed in the table
 * 2) Discussion 1: Using your knowledge of the respective countries in Africa, Do you think the companies in the Case Studies are addressing the market demands for each of their industries?
 * 3) Discussion 2: Do you think the fact that there are / are not FOSS policies in place are a major stumbling block for these companies?
 * 4) Discussion 3: What more do you think the companies can do better in the countries where FOSS policies are not in place?

= Assignments and Answers = TASK

Use the template below to interview a FLOSS-based company in your country.Some examples from participants

Previous Chapter | Next Chapter