6. FLOSS-based business models

From SME Guide

Jump to: navigation, search

One of the first categorization of potential business models was designed in 2001 in the work of the European Working Group on Libre software[DB 00]. The taxonomy, adapted to the recent developments of the market, is:

  • Externally funded ventures
  • Public funding
  • `Needed improvement' funding
  • Indirect funding
  • Internally funded or revenue based
  • `Best knowledge here without constraints
  • `Best knowledge here' with constraints
  • `Special' licenses
  • Unfunded developments

Externally funded ventures

We consider in this category groups or companies which develop open source software through the initiative (at least in the financial sense) of some external organization. Usually those external entities determine how the funds are to be spent, and where the development efforts are headed. The developer entity just follows those more or less strict guidelines. In some sense, it could be said that the external entity ‘sponsors’ the development of some given open source software. In this category, we can distinguish at least three models, according to who funds the project and why. We have called them public funding, ‘needed improvement’ funding, and indirect funding.

Public funding

Working groups or individuals receive funding for the development of a good software product, documentation, test cases or whatever. Usually, the only constraints imposed by the funding entity are that funds must be used to complete the project. This is typical of large computer science projects, and the funding usually comes from universities or from national science grants. In fact, many large projects in radioastronomy, computational chemistry, and biology are funded this way. In addition, some consortium for the development of Internet tools and technologies have (or have had) such a funding structure. It is important to notice that in these cases the funding institution is not expecting to recover the investment, or to directly benefit from it. Usually, some expectation of social improvement is the reason for the funding.


Contents

"Needed improvement" funding

A company or organization may need a new or improved version of a software package, and fund some consultant or software manufacturer to do the work. Later on, the resulting software is redistributed as open source to take advantage of the large pool of skilled developers who can debug and improve it.

A good example of the advantages of this model can be found in an article written by Aari Jaaksi, open source manager at Nokia, describing the experience of designing the Nokia N770 and N800 products, based on Linux: "The biggest cost savings came from the utilization of already available components. We utilized several free components and subsystems as such, with no modifications. We also improved several components to better meet our requirements. Such improvement is cheaper than creating the needed functionality from scratch. Some two-thirds of the code of the Nokia 770 is licensed under an open source license. These components made it possible for us to build the software cheaper than we could have done using closed and proprietary technologies" [Jaak 06]

This can also be applied to the Eclipse ecosystem, an integrated development environment (IDE) originally open sourced by IBM and later managed by the Eclipse Foundation. Many companies adopted Eclipse as a basis for their own product, and this way reduced the overall cost of creating a software product that provides in some way developer-oriented functionalities. There is a large number of companies, universities and individual that participate in the Eclipse ecosystem; as an example:

Image:eclipse1.jpg

As recently measured, IBM contributes for around 46% of the project, with individuals accounting for 25%, and a large number of companies like Oracle, Borland, Actuate and many others with percentages that go from 1 to 7%. This is similar to the results obtained from analysis of the Linux kernel, and show that when there is an healthy and large ecosystem the shared work reduces engineering cost significantly; in [Gosh 06] it is estimated that it is possible to obtain savings in terms of software research and development of 36% through the use of FLOSS; this is, in itself, the largest actual "market" for FLOSS, as demonstrated by the fact that the majority of developers are using at least some open source software within their own code (56.2%, as reported in [ED 05]).

In at least one instance the benefits of using FLOSS for product development have been evaluated, in the context of the European INES project[INES 06]. The project researched the use of FLOSS within industrial control systems developed by European SMEs, and measured the resulting economic impact:

Economic benefit  % of companies:
Internal Replications 100%
Increased Profit 100%
Reduced Time to Market 84%
Reduced Development Costs 79%
Reduced Product Costs 79%
Improved Code quality 79%
Improved Design Re-use 79%
ROI > 200 over 3 years 74%
Increased Product Reliability 68%

It is interesting to observe that companies that are adopting this model in many case contribute back the code that is developed even when not explicitly forced by the FLOSS project license, to reduce the cost of integrating product-specific patches and to leverage external support.

Indirect funding / Loss-leader

A company may decide to fund open source software projects if those projects can create a significant revenue source for related products, not directly connected with source code or software. One of the most common cases is the writing of software needed to run hardware, for instance, operating system drivers for specific hardware. In fact, many hardware manufacturers are already distributing gratis software drivers. Some of them are already distributing some of their drivers (specially those for the Linux kernel) as open source software.

The loss-leader is a traditional commercial model, common also outside of the world of software; in this model, effort is invested in an open source project to create or extend another market under different conditions. For example, hardware vendors invest in the development of software drivers for open source operating systems (like Linux) to extend the market of the hardware itself. Other examples are related to the establishment of a platform or a specific protocol; for example the Eclipse project was extremely successful in creating a large ecosystem of tools and projects that complement and enhance it. Most companies have dropped their own internally-developed integrated development environment, and are using Eclipse as a basis even for commercial products.


Internal use

Some projects can get started as a lower-cost alternative to proprietary systems. In this case, the developer company does not have (at least in the beginning) any plan to get external income related to the sale of the software or services related to it. The company develops some system because it is useful for them, and later decides to make it open source, and distribute it widely, just to benefit from the open source development source. Probably they will get some contributions, improvements and bug fixes from external developers interested in the software, and some bug reports. Later on, the product may even reach some market acceptance, and the developer company could even get some economic benefits from it.

For instance, a large enterprise with several thousand desktop computers can decide to create some software internally, and make this software available under an open source license to get the benefits of a larger base of developers that may be interested in helping out. An interesting aspect is that recent surveys found that 25% of companies are working with other companies in the same sector to develop industry-specific open source software [CIO 07].


"Best knowledge here without constraints

In this model, a company works as a paid consultant, with contracts granted on the basis of the higher level of knowledge of their employees. Any company can implement this model, as there are no limitations that prevent a competent technician from gaining an arbitrarily deep experience of open source software systems. Of course, this also means that any firm using this model is exposed to the risk of being superseded by someone else, if the level of competence is reached but not maintained. This is one of the pure "service based" models, that will be further refined later on in this chapter.


"Best knowledge here" with constraints

To prevent competitors from "stealing" customers, a firm can place arbitrary limitations on the process of knowledge sharing, through patents or through additional copyrights that are not conferred in a direct way through the FLOSS license. It can be implemented by placing under a more restrictive license just a small (but fundamental) part of the code, usually considering it as a "black box, or by adding a set of copyrighted materials not freely redistributable, and adding in the license an obligation to show them to the end-user ("badgeware"), thus preventing others from appropriating the code.

As a special case, there may be a need for external, non-code related conditions (like code certifications) that can be inherently costly to reproduce, and those can be added to a code distribution to create a non-transferable asset. For example, the CODE*ASTER project is a complex simulation systems used by the French utility company EDF in systems as complex as nuclear power plants. The project has a GPL version, and a quality-checked and certified version that has passed the national certification tests for use in safety-critical systems design. Other examples are security certifications like EAL4+ that have been recently obtained by major Linux vendors.


"Best code here" without constraints

In this model, a company develops some open source code, and sells consulting and maintenance services on it. This is similar to "best knowledge here", but with an additional advantage in terms of time, since a competitor needs some months to create a similar code, or to understand all the intricacies of someone else's source. This gives a time advantage to the company or group that creates the software in the first place.


"Best code here" with constraints/Time-decaying licenses

An interesting twist in licensing for OSS is that of time-decaying licenses, where a software artifact changes license with time or with some specific event (for example, the release of a new version of the code). The first known example of this model was the Alladin Ghostscript postscript interpreter, and recently some security companies provide up-to-date security signatures to paying customers, and release them under a public license after some days.

This model is especially suited to rapidly changing software or other material (for example, security and virus signatures) and less practicable for software, because the old version becomes a basis to create an improved product that may be competitive with the one under the commercial license. This is exactly what happened to Alladin, that found an open source competitor (GNU Ghostscript) based on a previous version of the code, plus many improvements contributed by open source developers.


Dual licensing

One of the few models that have no counterpart in the commercial software world, Dual licensing is used by companies that want to profit from the companies that want to use or leverage an open source package without standing the redistribution conditions of the OS license. For example, the MySQL database has two licenses, one GPL (for OSS usage) and a commercial one. The customer that wants to use MySQL in a commercial product without distributing the code pays for a commercial license.

Many other project are starting to use such a scheme, that mixes the traditional commercial software model and allow to pay for continued development; the downside is that the model can be effectively used only for source packages that needs to be linked in with the code for maximum efficiency or because there is no common protocol for data exchange. This means that for example dual licensing is difficult for packages like mail servers, that use common standardized protocols to communicate with mail clients.

Dual licensing requires some specific legal and community aspects to be handled; for example, patches or modifications from external contributors require an explicit author acknowledgment of both licenses, and management of the community requires an accurate management of the border between the commercial and open source aspects of the project.


Unfunded developments

If there is enough `network effect', there may be no need for funding, just a minimal effort for the organization of releases and patches. Examples of these kinds of open source projects are the Linux kernel, GNU/Linux distributions like Debian, BSD-based operating systems such as FreeBSD, NetBSD, or OpenBSD, and the Mesa OpenGL-like library. These efforts started in many cases as the effort of a single man, or of a small group, and through good organization and volunteer work they created an extended networked structure that maintains the code. Even with some (limited) funding for some projects, all of these efforts become successful without an external grant or without explicit money offerings. In fact, this is the case for hundreds of small open source projects.


Specialized Service-based business models

Service-based business models are based on the idea of optimization, that is the capability by a specialized company to provide a service at an overall price for the customer that is less than the one the company would incur in if doing it by themselves. To get an overview of the areas that are subject to this potential optimization, we can provide an overview of the steps that are part of the adoption of a new ICT technology:

    • software selection (if Off-the-shelf components are used)[1]
    • installation
    • integration
    • technical suitability certification
    • legal certification
    • training
    • ongoing maintenance and support contracts[2]
    • at the end, migration from old system to the new one

As we will see, only a few companies are specialized in a single model, but compose them together to create service packages, in a sense making these sort of "business models building blocks"; we will however first provide an overview of each block to provide an estimate of effort and difficulties that are inherent in each step.


Software selection support

Software selection is really a multi-step phase, that starting from the identified needs and a knowledge of the software market selects a combination of packages that minimize the amount of code that needs to be developed. This minimization process is complex, taking into account not only the technical characteristics of the software being considered, but also must provide an evaluation of the “liveliness” of the OS project, the probability that its development will continue, and the availability of consultants and documentation.

A company that wants to offer this kind of service needs a substantial investment in terms of knowledge of the different packages and tools available. As the number of projects that are amenable of business or PA use can be estimated to be over 18000, there is a substantial effort just in following the new updates or announcements. This is further complicated by the fact that most project do not have an explicit “marketing mechanism”, that 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 in monitoring web sites and mailing lists, and extract from there information on new versions or new packages; this effort can be estimated in 1 man/hour per day for limited segments (for example, only Java enterprise middleware) to 5 man/hours per day for many different software segments.

The actual consulting activity is fairly simple, and consists in in-depth interviews and analysis of the need of the customer, followed by the preparation of a list of suggested packages. It is also possible to estimate the cost of integration, using data from the software engineering community related to COTS projects (Common Off The Shelf).


Installation support

A very common support activity in the OSS community is that of installation; this comes from two different aspects: the great modularity of software (that forces the installation of many, different components to create a working system) and the relative unavailability of sophisticated software installers, common in the commercial world.

This is however changing, thanks to the standardization in the Linux world of packaging systems, that makes nearly non-necessary the installation of software from source code components. The availability of package installers based on the RPM (RedHat package Manager, used also by Novell's Suse Linux and Mandriva Linux) and DEB (used by Debian and derivatives, like Ubuntu) augmented with dependency maintenance systems have greatly reduced the complexity of installation, now mostly related to the modification of the suitable configuration files to adapt the installation to a specific ICT environment.

Integration support

Another of the most common steps in OSS-based consulting is the integration step, that relates both to the 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.

Integration may require a substantial effort for large scale projects, with a relatively large amount of custom coding or the integration of commercial components if no other choice is possible. This variability is the reason behind the strong push towards standards (both de-facto and de-jure) that is the simplest way to reduce interfacing cost between disparate software components.

Technical suitability certification

This is mostly done by integrators and external consultants, and may come in two shape: certification of adherence to an international standard (for example security or quality standards) and certification of suitability for a specific environments. In a sense, in both cases the integrator or certifier 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[3].

Most Linux distributors performs 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

This is a relatively recent model, that emerged from the perceived problems of mixing code from multiple licenses, and from several lawsuits[4]. 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, that 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 OSS community to be a “tangential” model.

Patent and IP certification provides a form of “insurance” against third party claims on software patents or other copyrighted material that may be in the OSS used in a project; as any insurance form, it is quite demanding in terms of monetary funds, as patent claims may give raise to multi-million Euro lawsuits (see for example the recent patent lawsuit by Eolas against Microsoft corp. with more than 500 million dollar in requested damages).


Training

Training is another commonly found business model, as many open source projects do not have an official, sanctioned training process that is comparable to that of commercial companies. 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[5].

The simplicity of the model and the fact that it does not require software development means that it is quite easy for established training companies to compete for offering such services; also, the largest OSS project also usually have an official training programs (for example JBoss, Linux distributors RedHat and Novell/Suse).


Ongoing maintenance and support contracts

For most complex systems there is a continuous need for support and maintenance, both for bugs and feature enhancements and for the adaptation of the system to the changing IT environment. Support contracts usually are time-based (the most common is a contractual period of one year, renewable) and level-based. Levels are commonly three (corresponding to “bronze”, “silver” and “gold” support services), with varying degree of guaranteed service. For example, bronze level usually provides email-based support during work hours and access to a knowledge base; silver adds voice support and precedence of incidents over bronze contracts, and gold adds 24/7 live support[6]. While it is reasonably easy for an SME to offer standard support services, 24/7 offerings may require a slightly larger personnel base to guarantee coverage under every circumstance. Another model that is gaining ground is the acquisition of “tokens”, that are later used to buy specific support activities (for example, a support request may require one token, and an urgent one-“priority” may be bought for three tokens). This way, users may decide in a flexible way how to leverage the support offer without restrictions.

Taking into account the characteristics of support questions, it is possible to observe that most calls are easily answerable, even with only moderately skilled people (around 80% are “easy” calls); the remaining 20% usually require a much greater effort. It is possible sometimes to create “pyramids” of support, where one company provides support for those 80% of easy calls, and moves the harder ones to another company that is more specialized on a specific package or a specific issue. This requires of course the capability of categorizing calls appropriately, and requires the existence of specific support contracts between the participants; this is usually possible only if the customer base is large enough, and so is more amenable to the medium companies.

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 contribution from the outside are usually received from outside participants even in the case of very specific application areas, like for OpenCascade[7]


Migration services

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.)

Commercial-on-open

One of the simplest model for software companies is selling a proprietary software package on an open source one. It may be simply a matter of running platform (like having a commercial package running on Linux) or it may leverage an open source project with some commercial module. Examples of this abound, from commercial database systems, proprietary payroll or financial applications, to module designed to improve the usability and manageability of an existing open source project.

This second example is becoming one of the main options for funding an OSS project, and leverages the development of the OSS component to provide added value that may be of interest only to a part of the community, for example providing easy-to-use interfaces for a complex system. As the example in the previous section on time-decaying licenses, if the project is successful there is a risk of competition with an open source project designed to fill exactly the same need.

Any company that plans to follow this model should devote some effort to track the evolution of the OSS platform, and somehow participate (for example, with an active participant in the mailing lists of the project). This has the double advantage to provide an insight into the evolution of the platforms and new, potentially useful features, but also to be “good citizen” of the OSS project.


Mediation services

Mediation services are relatively new on the market of OSS models, and are based on the fact that for companies it is difficult to interact with sparse communities like some OSS projects. Mediation services provide a sort of a single point of contact, that gathers information from the developers, mailing lists, forum and such and forwards requests and bug-fixes back. These services are especially useful when the company is willing to pay for modification or changes to the code, but is unable to find a suitable service company. Usually these mediation companies try to contact directly the developers, or to find support companies that demonstrate experience in the specific package; after development, they add some certification and integration effort to deliver a single package to the customer.

This is useful especially for large scale efforts, where many different communities may be involved, or when there is no clear choice to ask for support or development. Large scale projects (like Apache, JBoss and others) usually have one or more company that provides already this kind of mediation.


Custom development

Another model that is just an application of a traditional one, the custom development is simply the offering of custom coding on an open source project. As such, there is usually a form of specialization on a single project or class of projects (for example, device driver development or open source-based J2EE systems). A company that wants to use this model should add to the traditional model an activity related to tracking the evolution and roadmap of the project on which it is specializing, in a way similar to that described in the previous commercial-on-open model.


Assessment of FLOSS business models usage

To assess the real business models adopted by FLOSS companies, we prepared an initial list of 120 companies using some popular open source news websites as source[8]; this list was further refined by eliminating companies that were not really adopting FLOSS, even using a very relaxed definition. In the specific, any company that allowed source code access only to non-commercial users, or that did not allowed for redistribution was dropped from the list; also, companies for which no information was available, or for which no clear product or service was identifiable was equally eliminated.

One of the companies included (Sourceforge, from the OSTG group) is not open source in itself[9], but represents an example of an “ancillary” model, as the site itself hosts more than 100000 open source projects and provides supporting services like mailing lists, source code versioning systems and file distribution. Also, companies that have a significant OSS contribution, but for which FLOSS is not the core business model were not included[10].

An initial set of variables were selected, including: choice of licenses, product offering (whether a single version or multiple version of a software system are offered), services offered (divided into installation support, integration, training, consultancy, legal and technical certifications), type of contracts offered (subscriptions, licensing or per-incident) and metering form. Additionally, literature from each company's website was retrieved to find references to the business model adopted and how the model impacts the value proposition of the firm. Mailing lists and search engine searches were performed to obtain indicative references of the relationship of the company with the development community, and if there is an external, non-company based support activity in the form of websites, wikis and knowledge bases.

The collected data was then tabulated, eliminating non-significant variables; for example, coupling together installation, training, support and consulting that were found to be part of the offering of most of the companies that offered support services (and coupled in a single Installation/Training/Support/consulting variable, ITSC). The significant variables left are main revenue generation (the service or contractual offer that provides the main revenue to the company) and licensing model. The first is further subdivided into Selection services (finding appropriate FLOSS packages for a need), ITSC, subscription (a recurring license) and one-time licensing. The licensing model is obtained by looking at the licensing scheme adopted by the company and whether the company services were covering a single software project or a set of projects. By performing a simple cluster analysis on the results, it was possible to identify 6 main models and a "remainder" group:

The 6 main clusters identified are:

  • Dual licensing: the same software code distributed under the GPL[11] and a commercial license. This model is mainly used by producers of developer-oriented tools and software, and works thanks to the strong coupling clause of the GPL, that requires derivative works or software directly linked to be covered under the same license. Companies not willing to release their own software under the GPL can buy a commercial license that is in a sense an exception to the binding clause; by those that value the “free as in speech” idea of free/libre software this is seen as a good compromise between helping those that abide to the GPL and receive the software for free (and make their software available as FLOSS) and benefiting through the commercial license for those that want to maintain the code proprietary. The downside of dual licensing is that external contributors must accept the same licensing regime, and this has been shown to reduce the volume of external contributions (that becomes mainly limited to bug fixes and small additions).
  • Split OSS/commercial products: this model distinguish between a basic FLOSS software and a commercial version, based on the libre one but with the addition of proprietary plugins. Most companies adopt as license the Mozilla Public License, as it allows explicitly this form of intermixing, and allows for much greater participation from external contributions, as no acceptance of double licensing is required. The model has the intrinsic downside that the FLOSS product must be valuable to be attractive for the users, but must also be not complete enough to prevent competition with the commercial one. This balance is difficult to achieve and maintain over time; also, if the software is of large interest, developers may try to complete the missing functionality in a purely open source way, thus reducing the attractiveness of the commercial version.
  • Badgeware: a recent reinvention/extension of a previous license constraint[12], that is usually based on the Mozilla Public License with the addition of a “visibility constraint”, the non-removability of visible trademarks or elements from a user interface. This allows the company to leverage trademark protection, and allows the original developers to receive recognition even if the software is resold through independent resellers.
  • Product specialists: companies that created, or maintain a specific software project, and use a pure FLOSS license to distribute it. The main revenues are provided from services like training and consulting (the “ITSC” class) and follow the original “best code here” and “best knowledge here” of the original EUWG classification [DB 00]. It leverages the assumption, commonly held, that the most knowledgeable experts on a software are those that have developed it, and this way can provide services with a limited marketing effort, by leveraging the free redistribution of the code. The downside of the model is that there is a limited barrier of entry for potential competitors, as the only investment that is needed is in the acquisition of specific skills and expertise on the software itself.
  • Platform providers: companies that provide selection, support, integration and services on a set of projects, collectively forming a tested and verified platform. In this sense, even linux distributions were classified as platforms; the interesting observation is that those distributions are licensed for a significant part under pure FLOSS licenses to maximize external contributions, and leverage copyright protection to prevent outright copying but not “cloning” (the removal of copyrighted material like logos and trademark to create a new product)[13]. The main value proposition comes in the form of guaranteed quality, stability and reliability, and the certainty of support for business critical applications.
  • Selection/consulting companies: companies in this class are not strictly developers, but provide consulting and selection/evaluation services on a wide range of project, in a way that is close to the analyst role. These companies tend to have very limited impact on the FLOSS communities, as the evaluation results and the evaluation process are usually a proprietary asset.

The remaining companies are in too limited number to allow for any extrapolation, but do show that non-trivial business model may be found on ancillary markets. For example, the Mozilla foundation obtains a non trivial amount of money from a search engine partnership with Google (an estimated 72M$ in 2006), while SourceForge/OSTG receives the majority of revenues from ecommerce sales of the affiliate ThinkGeek site; it is possible to classify those as “public funding” and “indirect funding” following the EUWG classification [DB 00].

There is a large variability in business model adoption, and it has been observed that companies change their mix of models with time; as a general observation, models that allow for greater industrialization (like platform providing) tend to be more effective than service-based models that are more human intensive; the 451 group in a recent survey found that 70% of the open source companies analysed had at least some service-based model in use, but that model represented the primary revenue model only for 8% of them.

The fact that open source is in a sense a non-rival good facilitates cooperation between companies, both to increase the geographic base and to be able to engage large scale contracts that may require multiple competencies. Three main collaboration strategies were identified among smaller companies: geographical (same product or service, different geographical areas); “vertical” (among products) or “horizontal” (among activities). Geographic cooperation is simpler, and tends to be mainly service-based; an example is the Zope Europe Association, that unites many service providers centered on specific Zope and Plone expertise. Vertical cooperation is done by companies that performs an integrated set of activities on one or more packages. Multiple vendors with overlapping products can collaborate on a single offer (eg. operating system and Groupware), that may form a more interesting or complete offer for the selected customer segment.

Image:vertical1.jpg

Horizontal specialization facilitates the creation of “collective service specialist”, that performs a single activity, on (usually) a very large number of packages. Collaboration allows for the creation of an integrated service package along multiple software offerings, with each company specializing in a single activity like training or support.

Image:horizontal1.jpg


  1. there is an additional first step, identification of needs, that is not in itself specific to OSS, but is usually part of the responsibilities of the internal ICT staff of the company or the administration that needs to perform the migration. For this reason it is not included in the list
  2. Keen, P. "managing the economics of information capital": maintenance is 40% per year for 5 years on average of the initial cost of software
  3. For example, the open source CODE-ASTER simulation package by EDF (the French utility) is certified as suitable for use in the simulation and design of nuclear power plants; and the AdaCore ADA environment (based on open source components) is used in many avionics and high-availability environments with DO-178B certification.
  4. It is interesting to notice that most of these lawsuits are only marginally related to open source licenses, and that the uncertainty has been in some way spread by commercial companies that are being threatened by open source in their market.
  5. The variability depends on the complexity of the course and the specificity of the knowledge to be transferred.
  6. This subdivision has been extracted from support contracts of several ICT support vendors, but slight variation may be found- for example, 4 levels instead of 3, or different kind of support material other than the knowledge base.
  7. It has been reported that 20% of the “package value” of OpenCascade has been contributed by outside partners and developers; both in term of code and documentation and ancillary material. This percentage has been found in other projects, like JBoss.
  8. Among them: FreshMeat, Slashdot.org, OSNews, LinuxToday, NewsForge and some blog sites devoted to FLOSS business models like those of Roberto Galoppini, Matt Asay, Fabrizio Capobianco. Additional information was retrieved from Google searches.
  9. The original code for the SourceForge collaborative development environment was open source, and from its change of license several “forks” appeared, including Gforge.
  10. This for example includes IBM, HP and Sun; all of which are important FLOSS contributors, but for which open source software is just one of the overall revenue streams (along hardware, IT services and more).
  11. An exception is MuleSource, that uses a MPL+Attribution license similar to the “badgeware” license described later. As the MuleSource CEO mentions, “So, if you use Mule in your software product and sell it commercially, then you are required to either make a licensing deal with us or keep the "powered by Mule" logo visible.” It is still debated by the community and experts if “badgeware” licenses are really open source; some of those have been submitted to the Open Source Initiative for evaluation, and at least one was approved by OSI.
  12. The original BSD license introduced the “advertising claim”, that required the licensee to maintain in the advertising material mentioning feature or use of the software the wording “This product includes software developed by the University of California, Berkeley and its contributors”.
  13. Examples of RedHat clones are CentOS and Oracle Linux.

Previous Next

Personal tools