wp_understanding open source

7/30/2019 WP_Understanding Open Source

http://slidepdf.com/reader/full/wpunderstanding-open-source 1/69

Understanding open source and

free software

➔ History

➔ Philosophy

➔ Licences

➔

Support➔ Market

➔ Economic models

➔ Development models



Understanding open source and free software

[1] PREAMBLE

[1.1] Smile

Smile is an company of engineers

specialising in the implementing of open

source solutions and the integrating of

systems relying on open source. Smile is

member of APRIL, the association forthe promotion and defence of free

software, Alliance Libre, PLOSS, and

PLOSS RA, which are regional cluster

associations of free software companies.

Smile has 320 staff members in France

and 400 throughout the World which

makes it the largest company in France

specialising in open source.

Since approximately 2000, Smile hasbeen actively supervising developments

in technology which enables it to

discover the most promising open source

products, to qualify and assess them so

as to offer its clients the most

accomplished, robust and sustainable

products.

This approach has led to a range of

white papers covering various fields of

application. Content management

(2004), portals (2005), business

intelligence (2006), PHP frameworks

(2007), virtualisation (2007), and

electronic document management

(2008), as well as PGIs/ERPs (2008).

Among the works published in 2009, we

would also cite “open source VPN’s”,

“Firewall open source flow control”, and

“Middleware”, within the framework of

the “System and Infrastructure”

collection.

Each of these works presents a selection

of best open source solutions for the

domain in question, their respective

qualities as well as operational

feedback.

As open source solutions continue to

acquire new domains, Smile will be

there to help its clients benefit from

these in a risk-free way. Smile is

present in the French IT landscape as

the integration architect of choice to

support the largest companies in the

adoption of the best open source

solutions.

Over recent years, Smile has also

extended the range of services it offers.

Since 2005, a consulting department

has been supporting our clients both in

the pre-project phases and in project

guidance. Smile has had a graphics

studio since 2000 which in 2007 because

an Interactive agency which, in addition

to graphics creation also offered e-

marketing expertise, publishing andrich interfaces. Smile also has an

agency which specialises in Third Party

Application Management, support and

operating of applications. Finally, Smile

is based in Paris, Lyon, Nantes,

Bordeaux and Montpellier. It is also

present in Spain, Benelux, Switzerland,

Ukraine and Morocco.

© Smile – Open Source Solutions - Reproduction authorised according to the “by-nd”




[1.2] This white paper

Three is a lot of talk about free software and open source, but when you dig a little,it seems that there are a lot of people, even among IT professionals, who have quite

a superficial knowledge of the phenomenon.

On the one side, there are committed enthusiasts who thoroughly enjoy the

community approach but do not always know the economic aspects and on the other,

decision-makers from the business world who are increasingly sensitive to the

benefits of open source solutions but know little of the philosophy and history or

even issues concerning licences.

This white paper is an introduction to the open source phenomenon, the biggest

revolution affecting IT since the Internet. As we will see, the movement startedbefore the web but the powerful upheaval of IT economics has only been felt over the

past few years and is just starting.

The aim of this paper is to popularise, especially in trying to explain open source to

those who are not involved in it, but are starting to sense its importance and need to

understand the phenomenon better.

It should be noted that the open source World is subject to various “controversies”

which have been inflaming minds and splitting communities for many years. This

started with the name free software versus open source software or even GNU/Linux

versus Linux. Even though we need to mention them, we will pass rapidly over

these internal disputes in order to spend more time focusing on what seems to us to

be the most fundamental.

This white paper is distributed under “Paternity-No modification” 2.01 Creative

Commons licence. It can be freely re-distributed.

I would like to warmly thank those people who have sent me their comments,

corrections and improvements, particularly Benoit Jacquemont, Frédéric Couché

and Benjamin Jean.

Patrice Bertrand

General Director

1http://creativecommons.org/licenses/by-nd/2.0/fr/.


http://creativecommons.org/licenses/by-nd/2.0/fr/

http://creativecommons.org/licenses/by-nd/2.0/fr/




Content

[1] PREAMBLE.......................................................................................................2[1.1]SMILE...............................................................................................................................2[1.2]T HIS WHITE PAPER.................................................................................................................3

[2] INTRODUCTION...............................................................................................5[2.1]T ERMINOLOGY......................................................................................................................5[2.2]OPEN SOURCE PHILOSOPHY.......................................................................................................6[2.3]FREE BEER ?!.....................................................................................................................8[2.4]T HE BENEFITS OF OPEN SOURCE FOR THE CLIENT ..............................................................................8

[3] THE OPEN SOURCE MARKET.........................................................................13[3.1]A FEW STUDIES..................................................................................................................13[3.2]A POWERFUL WAVE.............................................................................................................14

[3.3]AN ECONOMIC ANALYSIS.........................................................................................................14[4] HISTORYAND FAMOUS FIGURES.......................................................................................17[4.1]HACKERS.........................................................................................................................17[4.2]RICHARD M. S TALLMAN AND THE FSF......................................................................................18[4.3]L INUS T ORVALDS.................................................................................................................18[4.4]ERIC S. RAYMOND AND THE OSI............................................................................................19[4.5]T HE SIGNIFICANT DATES FOR OPEN SOURCE...................................................................................19

[5] COPYRIGHT AND LICENCES...........................................................................22[5.1]ELEMENTARY PRINCIPLES........................................................................................................22[5.2]T HE BSD FAMILY..............................................................................................................25[5.3]T HE GNU GPL LICENCE......................................................................................................25

[5.4]INTELLECTUAL PROPERTY AND PATENTS........................................................................................30

[6] SUPPORT.......................................................................................................32[6.1]OPEN SOURCE AND SUPPORT ...................................................................................................32[6.2]COMMUNITY SUPPORT AND SUPPORT BY PUBLISHERS........................................................................32[6.3]3 SUPPORT LEVELS...............................................................................................................33[6.4]SOFTWARE LAYERS...............................................................................................................34

[7] BUSINESS MODELS........................................................................................38[7.1]PRINCIPLES.......................................................................................................................38[7.2]T HE FOUNDATIONS...............................................................................................................39[7.3]T HE DISTRIBUTORS..............................................................................................................41[7.4]T HE OPEN SOURCE PUBLISHERS................................................................................................43[7.5]T HE SERVICE PROVIDERS.......................................................................................................55[7.6]SUMMARY.........................................................................................................................57

[8] DEVELOPMENT MODEL.................................................................................59[8.1]INTRODUCTION....................................................................................................................59[8.2]ORGANISATION, INSTANCES......................................................................................................61[8.3]DEVELOPMENT MODEL ...........................................................................................................62[8.4]T HE T OOLS.......................................................................................................................64

[9] CONCLUSION.................................................................................................66





[2] INTRODUCTION

[2.1] Terminology

The source code is a version of a programme which is legible and intelligible to

people. It is the source code which is written by the computer engineer and the

programmer and which can be re-read and modified by others. The programmes

can then be compiled, which produces the object, binary or even executable code

which is not comprehensible.

Free software or open source software is a programme whose source code is

distributed and can be used, copied, studied and redistributed without restriction.

We should note that there are interpreted computer languages, such as PHP which

only exist in the form of source codes. However, even when the source code is

available, it is not always authorised to modify it. It is the terms of the licence,

granted by the author or holder of the rights, which specify whether or not it is

permitted to re-use it, or redistribute it, and under what conditions.

“Logiciel libre” is the proper French translation of free software, the name launchedby Richard Stallman and defended by the Free Software Foundation, la FSF.

Open source is the name of the Open Source Initiative, which publishes on the site

opensource.org the conditions to be met by a licence so that it can be called open

source.

Free software is defined by four fundamental freedoms: executing the programme,

adapting it, studying it and redistributing it. We should underline that free access

to the source code is simply made necessary by these fundamental freedoms and is

not an end in itself.

The open source software is defined by the 10 articles of the open source definition,

which we will return to later.

These two names are almost equivalent, but correspond to different schools of

thought. Given that neither one is prepared to be absorbed by the other, the

Americans sometimes use the term FOSS for “Free and Open Source Software” , or

even FLOSS for « Free/Libre and Open Source Software ».

We felt that using “FLOSS” throughout the white paper would be heavy for the

reader and we decided to use the term open source. It should nevertheless be noted

that FLOSS is the official term adopted by the European commission.





[2.2] Open source philosophy

[2.2.1] A fundamental freedom

For Richard Matthew Stallman, the father of the Free Software Foundation (1985),

or “RMS” for those familiar with it, free software is above all about freedom. The

freedom each individual should have to use, modify and redistribute any programme.

A freedom as fundamental as the freedom of expression. And inseparable from other

values, ethics and social responsibility.

Using this logic, non-free, “proprietary” software therefore is an attack on this

fundamental freedom. Free software is therefore not a simple alternative, and even

less the choice of a business model from among others. Proprietary software is“depriving” software in the sense that it deprives people of freedom, and in so doing

it is intolerable. It really is above all a fight between good and evil.

You could smile at this Manichaeism, but we should more admire and appreciate

this extraordinary wealth of software which the movement started by Stallman has

made available to everyone. A revolution is not born from wet ideas and you need

Stallman’s intransigence to create a real break and a movement of deep thinking

where freedom goes hand in hand with values of social solidarity and self-help.

[2.2.2] A development model

For Eric Raymond, it is not really about ethics or even philosophy, it is first and

foremost about demonstrating the superiority of software developed using a

community open source development model and to have them enter the economic

sphere.

For Eric Raymond, the dogmatism of the FSF does not play out in favour of the

movement and it is superior quality software more than ethical values which will

see open source win through

He founded Open Source Initiative with Bruce Perens, in 1998, in order to promoteopen source (cf. “Eric S. Raymond and the OSI”, page 19). The “open source”

movement” seems to some like a marketing operation in favour of free software. For

Richard Stallman however, it is not possible to cast aside the founding values,

especially freedom.

Ten years later, the scar of this split between free software and open source has not

healed and it is not possible to choose one name over another without causing

fireworks in one or other of the camps. In practical terms, Stallman concedes that

“both terms practically describe the same category of software. However, they

represent views based on values which are fundamentally different.”





[2.2.3] World heritage

At the end of the day, we are proposing here our own vision of open source, which is

not so much about liberty as progress and heritage. Here is the text of an article

which sets out this point of view.

"We are dwarfs standing on the shoulders of giants ". It is in the field of science that

this thought is heard. And it is true that the scientists of today are not more

intelligent than those of yesterday but they benefit, from the time they start their

training, from centuries of accumulated science and it is on this immense bedrock

constructed by Newton, Einstein and others, that they bring their own tiny rocks.

Computing is not exactly a science. But should it need to build everything for each

generation? If this were the case, it would be condemned to rapidly reach its limits. Are the computer scientists of today more gifted than those of yesterday? Certainly

not. Did they learn more things when they were studying? Doubtlessly a little. But

this would not be enough to propel oneself further.

Because if, in science, the heritage lies entirely in knowledge, in computing there are

two heritages: knowledge on the one hand and the source code on the other.

Knowledge progresses slowly and there is little basic knowledge to build, just look at

Firefox or even Eclipse which were unknown 15 years ago. If computing is

progressing it is more through the heritage of the source code than by knowledge,

that is to say that today we can rely on a vast bedrock of source codes.

At the outset, computer scientists had to create everything, practically for each

programme. Then operating systems provided the first level of bedrock which has

become more sophisticated over the years and high level languages have contributed

increasingly rich libraries.

On this elementary bedrock, we have added bases for development, frameworks

which constitute a second layer. And this is not all: we also have a quantity of high

level components which we can assemble to build new applications. In total, 90% of

the code used in these systems will be derived either from the operating system, the

frameworks or the components. We will have only really developed 10% of specificadded value.

This is an important acknowledgement: computing is progressing because the code

bedrock which provides our heritage is growing.

If I were to make a huge effort and develop a new programme which represented,

let’s say, a million original code lines, responded to a need and were a great

commercial success, it would certainly be a great adventure which might make me

rich and would be useful to my clients.

But I wouldn’t really have advanced computing by one jot because three years afterme if someone else wanted to go even further down this road in order to make a

better programme but didn’t have mine, he or she would have to start from the same





place as me, re-write my first million lines of code so as to finally be in a position to

finally add 200,000 lines which would progress it a little further. Given that he was

not able to stand on my shoulders, his or her feet would be in the same mud as mine

and there would be no choice but for him or her to also become a giant..

It is the humanist dimension of open source by considering that we each offer our

own rock and by building on this common heritage which allows us to go further.”

[2.3] Free beer ?!

Given that “Free” means both “unpaid” and “unshackled”, the advocates of free

software strive to explain that it is about freedom and not about paying, based on

the saying “free as in ‘free speech’ and ‘free market’, not as in ‘free beer’” .

In French, this ambiguity does not exist but we have retained the saying “free

software does not mean gratis’. From this saying some people understand that free

software may come at a price. This is not strictly false, but it almost is. Let us

explain.

There is nothing in the open source licence which would stop the distribution of the

software being charged. But the people you are distributing it to would be

authorised to duplicate it and re-distribute it free of charge if they so desired. Here

we see that it is quite difficult to sell something that others can offer for free!

As we will see in explaining the economic models, it is not possible to charge a user

right to use open source software. It is possible to charge for the related services

(integration, back-up, training, etc), and/or a user right associated with a non open

source licence for the software.

In practical terms therefore, we have to hold fast to the view that an open source

software programme is absolutely free both in terms of its acquisition and use, as far

as its licence is concerned.

As we shall see, this does not prevent it being accompanied by an offer for payingservices: integration, back-up, training, further developments or even legal

insurance. In this way, the “total cost of possession” is rarely nothing, even if it is

nearly always less than that of an equivalent proprietary solution.

[2.4] The benefits of open source for the client

[2.4.1] Not only cheaper…

Of course, the economic benefits are among the top reasons given in the choice of

open source solutions. Even if “free does not mean gratis”, these solutions always





have a possession cost which is significantly lower than their proprietary

equivalents.

The price of services also tends to be lower because the opening of the product alsofacilitates the dissemination of knowledge.

However, as these solutions mature, the lower cost is not the first choice

consideration.

The main arguments are therefore:

The non-dependence or lesser dependence on a publisher. We know that

changing tools can be expensive and publishers may be tempted to profit from

the cash cow made up of these captive clients. In English this is referred to

as vendor lock-in.

Opening is also about weight. The open source solutions are generally more

compliant with standards and more open to the addition of extension modules.

Sustainability is another strong choice consideration which we will come back

to later.

And finally quality because in a lot of domains open source solutions are really

objectively better. The very high number of uses and therefore feedback but

also their integration of high level components allows many to outstrip

proprietary products, particularly the older ones.What greater pleasure can there be for computer scientists but to use programmes

over which they can acquire complete mastery without any technical or legal

barriers.

[2.4.2] Sustainability

In terms of sustainability, open source solutions do not have a guarantee of eternal

youth. They may also die but it is a slow death!

The worst that can happen for an open source solution is progressive disaffection onthe part of the communities, generally in favour of a more promising solution.

Consequently it is possible that one day you may have to change product. But at

least the phenomenon is always slow and the client has the time to organise the

change.

It should also be stressed that even if the original publisher goes bankrupt one day,

it would still be possible for a community to take over the product and its upgrades,

this is the principles of open source licences.

The fame, scope, uses, development and community dynamics are all sustainability

criteria which are relatively easy to assess and a leader open source solution offers a





guarantee of sustainability which is greater than the majority of the proprietary

solutions.

[2.4.3] Opening

A word also about the issue of the opening. The possibility to make modification in

the sources is fundamental at the theoretical level but sometimes risky at the

practical level (cf. “Mastering the sources: a right, not a duty”, page 11). It is

therefore not in these terms that we should asses the opening, but rather in the

capacity to accept add-ons or to interface with other applications.

In essence, we need to understand that any commercial publisher does not have

interests which converge with those of its clients. Certainly it is needs to grow in a

competitive environments and its product needs to be at the same level as those of its competitors. But once it is well positioned, the publisher can take the view that:

Its product needs to be successful but not too much because if it requires more

servers, this would mean more licences being sold.

Its product needs to be robust, but not too much, because it is necessary to

continue to sell back-up.

It’s product needs to be open, but not too much so that the clients remain

dependant.

We are not saying that proprietary publishers would be so Machiavellian as to

degrade these qualities in their products, we are only saying that the strategic

priority is not necessarily focused on these qualities.

In terms of opening, we should underline the fact that proprietary software is not

the only way to capture a client. Document formats are also a strong weapon to

achieve vendor lock-in. Over recent years, there has been a strong awareness of the

importance of open formats, in other words documented and free to use. They are

both the condition for the independence but also of the sustainability of these

documents and of the interoperability of the applications which share these

documents2

.

[2.4.4] Security

The domain of security merits a special mention because in terms of security, access

to the sources is virtually an obligation. It is inconceivable that the French army

would use a VPN for its communications which had been received in a executable

format from an American or Chinese publisher.

It terms of security it is absolutely obligatory to be able to audit what a programme

is really doing and this can only be done by analysing its sources.2 To know more: http://blog.smile.fr/open -documents-a-bridge-between-office management-and-content-

management


http://blog.smile.fr/open%20-documents-a-bridge-between-office%20management-and-content-management








To do this does not imply that the programme needs to be open source. Some non-

open source publishers have accepted delivering the sources to their clients after a

non-disclosure agreement has been signed.

However, it is another argument altogether which makes open source vital here:

peer review, in other words by other experts and as many other experts as possible.

Let us provide a small parallel. When it started, cryptography mainly used secret

algorithms. It was felt that the protection of the algorithms contributed to security.

After the war, a revolution started: it was finally concluded that a secret algorithm

whose quality is only affirmed by the small team which created it, had a strong

change to be defective, if not now then certainly in a few years. On the other hand,

algorithms, which are publically disclosed, are analysed by hundreds of experts

throughout the World. If they have a defect, this is rapidly identified and known.The same can be said about the programmes that execute these algorithms: the best

way to ensure their perfection is to expose them to being audited by thousands of

experts.

Let us finally add another argument: in terms of security, old algorithms which have

stood the test of time are generally preferred, and the latest innovations are not

trusted. The RSA algorithm dates from 1977! It is natural that since this time, the

programmes implementing these algorithms have become part of the common

heritage, if not the public domain.

It is therefore normal that the government’s website which is dedicated to ITsecurity3 affords a major place to free software.

[2.4.5] Mastering the sources: a right, not a duty

We need to point out that it is often misunderstood that it is not at all necessary to

master the sources of an open source product in order to deploy it, use it and benefit

from it. You don’t have to master them, look at them or even download them.

Only just a few years ago, some open source products sought to only distribute the

sources thereby obliging the user to recompile and generate his or her programme.This somewhat extremist approach has been abandoned today as it jeopardised the

dissemination of the open source.

Being aware of sources is a right and not a duty.

Similarly, modifying sources is a fundamental right but in a lot of cases it is

something which is not recommended. This is for several reasons:

There is a significant risk to weaken the product because your code will not be

as well tested as the rest and you will have written it with a reduced overall

mastery.

3 http://www.securite-informatique.gouv.fr/


http://www.securite-informatique.gouv.fr/

http://www.securite-informatique.gouv.fr/




On larger products, making modifications requires a significant investment,

heavy involvement and therefore a serious budget.

Your modified version is therefore a fork, an alternative version of the product.It will not benefit, or will find it difficult to benefit from back-up either from

the publisher or the community and it will be necessary to re-introduce your

modifications in the new versions in order to benefit from them.

In a majority of cases, these reasons prevail. However, if they were to block any form

of contribution, the vitality of open source would be compromised.

What is needed is for everyone, whether an independent developer or organisation,

to measure the investment that can be made in a project, get involved by conducting

an extensive debate with other project developers and making modifications not in a

corner, but consistent with the common frame of reference.

This means that it is totally desirable to enrich the product within the community or

by liaising with the publisher, but it is not generally advisable to do it otherwise.

[2.4.6] Pseudo open-source

In theory, it is enough to offer one’s sources under an accredited licence in order to

lay claim to an open source software programme. Users, however, need to tread

carefully with pseudo-open-source products.

It sometimes happens that publishers of proprietary solutions which are failing in

the market place, particularly in the face of the growing power of competitor open

source solutions make a final strategic shift before they disappear and declare that

the product is becoming open source. They distribute the sources more or less

willingly and then send their sales force to proclaim to the market that they are

from now on as open as the open source competitors. However, their heart is not in

it and they have the firm resolution to not let anyone have the mastery of their code

and to retain their stranglehold over them.

For clients, these solutions are the worst of all Worlds because, at the end of the day,

they will not have any of the benefits of the open source and, in particular, will besubject to the same vendor lock-in as with a proprietary solution. But worse than

this: the experience shows that these solutions nearly always disappear the

following year.





[3] THE OPEN SOURCE MARKET

[3.1] A few studies

All analysts, both in France and the Unites States agree on the extraordinary

breakthrough of the open source solutions in the economic sphere over recent years

and that this will continue in the years to come.

It is always difficult to measure the penetration of open source in terms of billions of

Euros. To the extent that the largest part of the products are used free of charge, the

market share in terms of deployment is immensely bigger that the market share in

terms of turnover. It is better to measure the open source market in terms of

proprietary replacement value, in other words the market value of an equivalent

proprietary product.

In France, the Syntec, for its part in a study in 2007, estimates that the market for

open source software and services represents 450 M out of a total market for €

software and services of 30 BL , or a market share of 1,4%. This market is set to € grow by 50% per year, on a market which is growing by 6,5%, which should see the

open source software market double in two years. Syntec estimates that the trend

will be to use IT systems which mix open source and proprietary without prejudice.

According to a 2007 study by Pierre Audoin Consultants, the open source market in

France is growing at approximately 70% per year. In France, the public sector has

a special place and the Markess study in 2007, estimates that the public sector

spends on average 11% of is IT budget on free technologies, compared to 7% in 2006

and 14% in 2009. The reasons given by decision-makers are both budgetary

constraints as well as the need for independence and interoperability.

France appears as a forerunner in this field but, for its part, IDC estimates that the

world market for open source will grow from 2 BL$ to 6 BL$ in 20111.

A study quoted by “Le Nouvel Economiste” in March 2010 gave the following figures

for the open source market:

2008 2010 2012 CAG

EU 3.5 7.4 12 25%

France 1.1 1.9 2.9 13%

Germany 0.7 1,5 2.5 27%

UnitedKingdom 0,7 1.5 2.5 27%





The “CAG” column on the right is the average annual growth rate.

Finally, let us all quote the American study by Saugatuck Technologies, which

assesses the share of open source software used in US companies to be 10% andestimates that this will grow to 15-20% between now and 2010.

However, going beyond market share, all analysts agreed when looking at the

penetration of open source, that one of the most important factors will be the

reduction of IT costs in the future.

[3.2] A powerful wave

As we will see later, open source is far from being a new phenomenon. In somedomains, this seniority is one of its strengths: open source software has increased

over the years, has become even more robust and has seen its market share settle

down, in particular in respect of infrastructure layers and development tools.

But these last few years have witnessed a significant acceleration of two newer

phenomena.

The first is that companies, including some of the biggest, no longer have any

reticence in respect of open source. The large DSI and Purchasing Departments have

understood that it offers products which are both particularly solid as well asoffering real economic benefits. We are seeing more and more tenders mentioning,

and sometime requiring, open source solutions.

The second is the appearance of new actors namely publishers of commercial open

source solutions. In a way which is similar to low-cost airline companies, these new

entrants are relying on a different business model to bring a new dynamic to an IT

environment which is often weak. Databases, content management, CRM, ERP,

Decision-making ... in an ever increasing number of domains, these new actors are

revolutionising the market and offering unrivalled value for money.

The emergence of companies which are open to open source as well as solutionswhich are becoming ever richer, has been made possible by specialist IT service

providers who are investing in the building of strong expertise and are capable of

offering quality back-up.

[3.3] An economic analysis

It seems to us to be interesting to quote here an analysis by Tim O’Reilly, the

publisher of the collection by the same name and one of the thinkers on open source.





In an article from 20034, he goes back to the break caused by the simplification of

the material which started in 1981 when IMB created a PC compatible market by

opening up its architecture. He used the term « commoditization », which referred

to « commodities », ordinary goods such as wheat or petrol, goods whose prices canfluctuate, where there is no specific added value and which are interchangeable,

simplified

The simplification of the materials led to an immense software industry dominated

by Microsoft. It also gave birth to Dell, who was the first to understand that the

materials had become a simple industrial commodity.

Twenty years later, open source brought about a similar schism, a change of

paradigm, the simplification of the software, nay its demonetisation. Operating

system, servers, databases, these software components loss the essential part of themarket value they have and this simplification gave birth of a new industry whose

exponents are Google, Amazon, eBay and Facebook. The new giants of the web who

are using hundreds of thousands of servers need demonetised software.

Some denounced the destruction of value when the traditional publishers lost

market share to the competition from open source solutions, or else were constrained

to drastically lower their prices. However, this is a sign of any type of progress,

regardless of the field, to cause this sort of shake-up, a “creative destruction” based

on the set phrase. At the end of the day, a lower cost of the programmes brings a

productivity gain for all industries who use the software and therefore a gain in

terms of living standards for everyone.

In the United States, some apparently intelligent people such as Steve Ballmer

compared open source to communism, the supreme insult!

In an certain way, it could be said to be the exact opposite: open source is a pure

product of capitalism. Isn’t one of the laws of capitalism that as soon as one actor

start to derive an exaggerated profit from its market position, competitors appear to

bring this profit back down to a reasonable level? However, it seems that this law

has not been able to play out for a long time in terms of software publishing. At the

end of the day it is open source which will restore a reasonable profit level to the

software industry. If 100 million people on the earth need an office suite then it is

enough for them to spend 0.1 each in order to finance a satisfactory development €

effort. In an indirect way, this is the price offered by open source.

As such, there are also domains where simplification is not the order of the day and

where, on the contrary, it is open source which is bringing a new dynamic of

progress to sclerotic markets. It continues to do this by rehabilitating the

competition and therefore innovation, as well as bringing a return to a fair market

price.

4 http://www.oreillynet.com/pub/a/oreilly/tim/articles/paradigmshift_0504.html, Tim O’Reilly also

benefited from a previous analysis of Ian Murdock : http://ianmurdock.com/open-source-and-the-

commoditization-of-software/


http://www.oreillynet.com/pub/a/oreilly/tim/articles/paradigmshift_0504.html

http://ianmurdock.com/open-source-and-the-commoditization-of-software/



http://www.oreillynet.com/pub/a/oreilly/tim/articles/paradigmshift_0504.html






Generally speaking, with open source it is experience, in other words knowledge

which give it its value to the detriment of simple property or seniority. Placing a

monetary value on the knowledge is simply proportional to the rarity of the

expertise in respect of the demand, based on ordinary market laws.





[4] HISTORY

AND FAMOUS FIGURES

[4.1] Hackers

It is important to stress that, in a certain sense, open source is as old as IT itself

When in the 60’s, the first computers arrived at universities, free access to

programmes was the norm. When a university professor finds a new molecule, heor she shows the process to its colleagues, when he or she writes an interesting

programme, it is also shown to colleagues. This is the normal approach of scientific

progress.

The 60;s and 70’s are known for hackers, more often than not brilliant students from

the best American universities who threw themselves with passion into the first

stutterings of computing. They spent nights on their programmes waiting to be able

to access a few hours of machine time, which was a rare commodity. They shared

their tips and their programmes at different clubs.

In 1962, Spacewar, a programme developed at the MIT, is sometimes cited as thefirst open source project as well as the first video game. Created by a small team, it

got better over a number of years thanks to the multiple contributions made possible

by the free access to the source code.

The term hacker at this time did not have the same negative connotation as today: a

hacker is therefore a programmer who is both passionate and gifted. Not very

different from nerds, “pollards” in French, they were the people who laid the

foundations of modern computing and many went on the create the leading

companies of today.

Hackers have a philosophy, the hacker ethic, which advocates free access to

computers and programmes and, more broadly speaking, the freedom of information.

Overall they are mistrustful of authority - – in line with the student movements of

the 60’s but more than anything they are convinced that there is beauty and art in a

programme and that information technology can lead to a better World.

It was in the 1970’s that the practice of not distributing the source codes of

programmes became widespread, and that the business model of the proprietary

software publisher appeared.

The defining date of the schism between free software and proprietary software canbe traced to the meeting of the Homebrew Computer Club, in 1976. During this

meeting, Bill Gates and Paul Allen presented a Basic programming language which





they had written for the Altair 100, one of the first microprocessor computers. The

members of the club took the perforated tape representing the programme, copied it

and distributed it. Furious, Bill Gates, wrote a letter which became famous entitled

“Open Letter to the Hobbyists5 ”, in which he explained that the work of developersshould be able to be properly remunerated, and that if it is not, then it will be

innovation that will be stifled. The reasoning is correct, but the future will show

that it is also possible to develop great programmes in open source.

[4.2] Richard M. Stallman and the FSF

Richard Matthew Stallman might be considered as the founding father of free

software according to current thinking, and he is sometimes described as the last of the real hackers. Since 1983, he has been looking for an operating system and tools

which are free to use and launched the GNU project, which sought to create the first

free operating system, inspired by Unix. In 1990, the project was well-advanced

particularly with an excellent C compiler (GCC), a reputable publisher and a large

panoply of utilities. Even the kernel (GNU Hurd) had hardly started when Linus

Torvalds brought out his Linux kernel.

In 1985, Stallman founded the Free Software Foundation (FSF), which was both the

body in charge of the GNU project, a place for reflection and a vehicle to promote

and defend free software. The FSF created the GNU GPL licence, and its recent

change to v3 (cf. “The GNU GPL licence”, page 25).

Richard Stallman is not a normal personality; he is a thinker and activist as well as

a hacker. He continues to travel the World today in order to promote free software

and does not allow people to forget the founding values of the movement.

[4.3] Linus Torvalds

In 1991, Linus Torvalds, a Finnish student aged 21, was working on developing an

operating system kernel. He was partially inspired by Minix, an experimentalkernel which accompanied the book by Andrew Tanenbaum, which has been a

reference work since 1987 : « Operating Systems : design and implementation ». In a

few months of working he brought out the version 0.01. At the end of 1991, Linux

was licensed under GPL, which contributed to launching a strong community

development dynamic which led to the Linux version 1.0 in 1994.

Linus Torvalds is more of an architect and developer than thinker or an open source

militant; he is respected by everyone but rarely takes part in heated debates which

agitate the communities. Even today, he is still acting as arbitrator for the major

directions of the Linux kernel.

5 http://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists


http://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists

http://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists




We should underline that the operating system is made up of the kernel and a large

number of unitary components without which the kernel would not be able to be

used. Given that a majority of the components surrounding the Linux kernel came

from the GNU, Richard Stallman believed that it was appropriate to still call thesystem GNU/Linux, in recognition of the contributions from the GNU project.

[4.4] Eric S. Raymond and the OSI

Eric S. Raymond is one of the famous advocates of open source. He has written

different works including “The Cathedral and the Bazaar” one if the founding works

of the movement6.

He mainly defends the superiority of the development model and therefore the

quality of the applications more than the moral and humanist questions.

Contrary to Stallman, Raymond is not a top flight hacker, he is more a thinker on

open source. He disagreed with Stallman in various articles, believing that the

fundamentalist positions of the latter could harm the movement.

Eric Raymond is, along with Bruce Perens, one of the founders of the Open Source

Initiative (OSI), which he created in 1998, the year when Mozilla was made

available on open source which would mark a symbolic victory for the movement.

Even today the OSI is a little bit the guardian of open source through itsopensource.org site which carries the official definition of an open source licence,

published on the site and which provides a consensus.

The opensource.org site also published an inventory of accredited public source

licences, totalling some sixty licences.

[4.5] The significant dates for open source

60-70 The hacker years – see above

1983 Year of the “GNU Manifesto” by Richard Stallman.

1984 Start of the development of the GNU project, first free operating

system; the Hurd kernel will not start until 1990.

1985 The Free Software Foundation

Distribution of the Window X Graphics layer in open source by MIT

1989 Creation of the GNU GPL licence

6 http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/


http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/




1991 Linus Torvalds distributed the first version of Linux

1993 Creation of the Linux Debian

FreeBSD 1.0 distribution

1994 First RedHat distribution

1995 First version of the Apache Http server

1997 “The Cathedral and the Bazaar” by Eric S. Raymond

1998 Netscape delivers Mozilla in open source

Debian 2.0

IBM chooses the Http Apache server for its web offer

The “Halloween Documents” Microsoft internal notes were put in the

public domain

1998 First version of Typo3

1999 Stock market floatation of Redhat

2000 SUN opens the Open Office suite in open source.

First version of eZ Publish

Smile uses Cofax, CMS open source for the CEA and Egide.

2001 Stock market floatation of Mandriva

2003 SCO, with the help of Microsoft, attacks IBM and some others claiming

rights over Linux.

2005 Creation of Alfresco, open source publisher of a GED solution.

2006 Redhat acquires JBoss, for 350 million dollars.

SUN announces the move of Java to GPL

2007 The French National Assembly adopts Linux for the workstations of

members of Parliament.

2008 SUN buys MySql for 1 billion dollars.

Google launches Android, an OS open source for smart phones

2009 Oracle purchases SUN for 7 billion dollars





Nokia opens its Symbian platform in open source

2010 French open source companies, organised into regional associations

meet at the offices of the Free Software National Council.





[5] COPYRIGHT AND LICENCES

[5.1] Elementary principles

Open source progress are not programmes “without licences” as is sometimes

understood. On the contrary it is their licence which makes them open source.

Neither are they in the public domain, in other words not belonging to anyone in

particular or exempt from rights of ownership.

When a developer writes a programme he or she holds the copyright. In certain

cases, it can be the company employing him or her who holds the copyright. The

copyright can also be sold as an intangible asset from one company to another.

The holder of the copyright is free to define the use which can be made of its

programme:

S/he can keep it for him or her and forbid its use by anyone else whatsoever.

S/he can sell his or her rights to a third party, either an individual or a

company.

S/he can use his or her copyright to specify the conditions placed on the use of

his or her programme. S/he writes the conditions in the terms of the user

licence.

It should be noted that under French law, it is not easy to give up your rights and

irreversibly put your programme in the public domain.

It should also be explained that it is not the distributing of the sources which makes

a programme open source, it is the right, contained in the licence, to freely use them,

modify them and freely redistribute them.

It is therefore important to fully understand the following logic: at the base of open

source there is the licence, and the licence only comes about from the copyright.

Consequently, all open source software has an owner, they do not belong to “nobody”

or even to “everybody”. In certain circumstances, this owner may be a not-for-profit

foundation or else it maybe an ordinary commercial company. There may also be

several co-authors, particularly after a series of successive contributions.

The holder of the rights is free to set the licence conditions or even change them and

s/he is also free to make developments or exceptions or to distribute to some

according to one type of licence and to others according to another.





The person receiving the programme, on the other hand, is not free. He is bound by

the terms of the licence. Certainly, s/he has not signed a contract but s/he has been

informed about the licence and it stipulates that s/he only has the right to use the

programme pursuant to certain conditions. Where these conditions are refused,s/he does not have the right to use the programme.

[5.1.1] Elementary information about licences

All open source licences have some common sense clauses in common:

The clear identification of the owner of the copyright, including through copies

or derived work.

The obligation to retain the licence notice in place on the programme and onderivated work. Obviously this is a technical requirement: it is useless to

define the terms of the licence if they are removed after the first copy.

The protection of the author in respect users of his or her programme, any

defects and the consequences of these defects: “this programme is supplied ‘as

is”. This is the least which can be required: if the author allows you to use his

or her work free of charge you are hardly going to sue him or her for damages.

It should be noted that in a few countries, the paying distribution of a programme

entails unalienable rights. Generally speaking, the licence cannot be contrary to

National law. This is why it says “If you cannot distribute the programme by bothsatisfying your obligations linked to the licence and other applicable obligations, then

you cannot distribute the programmes at all”.

This is to say that either both National laws and the licence can be respected, or it is

not possible to distribute the programme under the said licence.

[5.1.2] Definition of a free software programme

As referred to above, free software is defined by respect for the four fundamental

freedoms: executing the programme,

studying the programme and adapting it according to needs (which obviously

implies access to the source code),

redistributing the programme to help the next person,

and finally improving the programme and distributing these improvements to

the public (which also implies free access to the sources).

As already stated, the prime aim is freedom, access to the source is only a pre-

requisite in order for this freedom to be respected.





[5.1.3] Definition of an open source licence

The OSI, Open Source Initiative, has stipulated a precise definition of what is meant

by open source, a definition which is today virtually universally recognised.

Having a precise official definition is very important, a licence shouldn’t be able to

be more or less open source: it either is or it isn’t, things need to be clear.

The OSI site, opensource.org, also indicates what are the main licences which

comply with this definition. Of course, it includes well known licences, starting

with GPL, which we will go into more later on.

The definition involves ten points of which the first three are the most important:

1. Free distribution: the licence should not prohibit anyone whatsoever from

selling the programme or giving it away.

2. Code source: the licence should allow distribution on the form of a source

code and if the source code does not accompany the programme it should be

available in a manner which is easy and practically free.

3. Derived work : the licence should allow modifications and derivated work and

should allow for this derivated work to be distributed under the same licence

terms.

Let us go back to point 3: the licence should, as a minimum, allow the distribution

of derivated work under the same licence. It should not necessarily make it an

obligation. We will see that this nuance is at the heart of the distinction between the

BSD family and the GNU family, non-copyleft and copyleft.

Among the other articles on this definition there are difference clauses of non-

discrimination: the licence must not exclude any group of users, any domain of

application or any technical environment. For example the author of the

programme may not, as a militant pacifist, specify that his or her programme may

not be used to guide missiles. If such a clause is added, than the licence is no longer

open source.

[5.1.4] GNU and BSD licences

There are two large families of open source licences: the BSD family and the GNU

GPL family. People sometimes talk of copyleft licences for the second and non

copyleft for the first. Of course, “Copyleft” is a play on words referring to “copyright”.

But this does not necessarily mans that copyleft is an abandonment of the right.

So that there is no confusion, we should specify that if the FSF and the free software

movement prefers copyleft, starting with the GPL, there is no link between freesoftware and copyleft: BSD licences are also from free software.





Finally, we will look later at a few licences called weak-copyleft, which have

intermediary requirements.

[5.2] The BSD Family

The BSD licence (Berkeley Software Distribution) authorises any use of the

programme, its source code and derived works. The code under BSD licence can

particularly be used in software under a non-open source licence. It is known that

Microsoft has taken the TCP-IP under BSD back into Windows, and that MacOSX

is based on FreeBSD.

The only specific constraint is the prohibition on looking to derive advantage from

the name of the author, here the University of Berkley.

This is therefore the most liberal licence which entails the least constraints: the

programmed under BSD licence are virtually in the public domain. It is also

perhaps the oldest given that it dates back to 1980. It is not forbidden to modify the

text of the licence so that there is a multitude of versions to be found which are

virtually word perfect. This is a handicap for the clarity and legibility of the.

In the BSD family, there is also the MIT licence and the Apache licence. The latter is

very important given that it has already been used for about fifty projects for the

Apache foundation. The differences between these difference licences lies in thedetail.

[5.3] The GNU GPL licence

[5.3.1] The GNU GPL licence

The GNU GPL licence is used by 70% of open source programmes. But this

percentage is not the most important since some flagship software of open source areunder other licences.

The GNU GPL, “GNU General Public Licence”, is characterised mainly but is article

2 which lists the right to modify the programme and to redistribute these

modifications which constitute derivative works provided that they are under the

same GPL licence.

This is what some people call the viral nature of the licence: it is communicated

through derivative works. However, it is more correct to speak of reciprocity or of

quid pro quo.

Of course, the question is to know what exactly is a derivated work and what is

meant by distribute ? There is a cast amount of literature on this topic but still





uncertainties exist. There are some who even think that it is no bad thing to leave a

few doubts.

Let us look at what is clear.

[5.3.2] What is meant by “derivated work”?

For sure, if you take a part of the source code for programme A, you change some

lines or you add some lines to get programme B, this is a derived work.

What is also clear is that if you use functions from programme A from programme B

by linking the two programmes (“link”), then here also, programme B is a derived

work. This link between the programmes can be static or dynamic, in other words

only resolved when executed. There is a debate as to knowing if a dynamic link givesrise to a derivated work.

In modern technical environments, there is, in fact, a diversity of means to use the

services of a programme apart from calling on a function. Using the services of a

programme A by using standard exchange protocols does not mean that programme

B is a derivated work. If this were the case, then a navigator addressing a request

on a site whose programmes were under GPL would itself be obliged to be a GPL.

In fact, it is often accepted that a B programme is considered a derivated work of

programme A if B cannot function in any useful way without A, regardless of the

technical means of the link.

What about a programme which uses a MySql database for example, under GPL

licence ? If this programme does not use libraries under BPL licence to call up the

database, then it only uses the services of MySql through standard protocols which

does not mean that it is GPL itself. However, this programme can only function by

using a MySql database, then it could be considered that it is a derivated work after

all. It should be borne in mind that the FAQ of MySql on the topic of licences has

been criticised for suggesting that any form of commercial use needs to be under a

commercial licence, which is wrong.

[5.3.3] What does “distribute” mean?

Here again, some things are clear. It is certain that if you market your programme

as a software programme, this is called distributing.

On the other hand, using a programme within the same organisation is not

distributing. This means that a company can build a derivative work and use it

internally on as many workstations or servers as it deem appropriate without being

bound to distribute the work’s source codes. This is an essential point in the

economic sphere.





Another important question is that of the client-supplier link in IT jobs. When a

service provider such as Smile constructs an application using components under a

GPL licence, and delivers this application to its client, the service provider must

deliver all the sources included added ones. This obligation to distribute the sourcesONLY involves people who are receiving the programme, in this case the client. It is

not required to make them public.

Moreover, the client can either keep the programme for itself (in other words within

its organisation), or distribute it but then it must be under the GPL licence.

We should also note that using or offering the work as a derivative work in the form

of an online service (software as a service), even commercial is not distributing. This

is what Google does, for example. On this point refer to the AGPL licence below.

[5.3.4] The Spirit of the GPL

Beyond mere words, the spirit of the GPC licence is that as the author or owner of a

programme I give the right to use its sources provided that you do the same. In

effect it s quid pro quo.

The effect of the GPL licence is to divide the world into two “camps”. The GPL and

the rest of the World. If you are on the GPL side then all the open source asset under

GPL is accessible to you without restriction. If you are in the other camp, in other

words you do not want to distribute your code by giving others the same freedom

which was given to you, then you cannot benefit from it.

This is what can be derived from the quid pro quo and what the critics of this licence

call its viral aspect.

[5.3.5] Compatibility of the licences

The question of licence compatibility is vital. If programme A in under licence L A

and programme B is under licence LB, then is it possible to construct programme C

using both A and B? Programme C will inherit the requirements of L A and those of

LB, and if there are any contradictions between these requirements, it is impossible

to respect both so it will be necessary to renounce the use of A and B.

Given the domination of the GPL licence in open source, the main question is the

compatibility with the GPL licence. An open source programme, which has a licence

within is incompatible with GPK would have a more reduced use.

Included in the list of compatible licences are BSD, MIT, or the Apache

licences(GPL-v3 compatible). Among those which are not compatible, we can cite

the SUN CDDL, Eclipse, Mozilla licences.





The following7 is taken from the gnu.org site. The arrows show licence

compatibility.

We should note that a L A licence which is of the copyleft type and practically

identical to the GPL, but with another name, would not be GPL compatible since the

derivative work could not be both GPL and L A . This is the case for example of the

“reciprocal” licence recently introduced by Microsoft, the MsRL.

[5.3.6] LGPL

The LGPL licence is very closed to the GPL but authorised to use the programme

functions from another programme without any requirement in respect of these

programmes which may not by under any open source licence themselves. This

licence is therefore very appropriate for functions libraries destined to be used by

different programmes, without placing very heavy conditions on these programmes.

LGPL initially meant Library GPL, but the name has been changed to Lesser GPL

because Richard Stallman wanted to minimise the link that “library = LGPL” and

allow libraries to also be envisaged under GPL. LGPL is a compromise between the

strong desire to promote open source and avoid it becoming used by proprietary

software and on the other hand the desire to deliver the greatest service through the

widest possible use.

It should be noted that beyond the linker permission, the LGPL introduces some

more subtle conditions to the linker programme. Some programmers have preferred

7 Image © 2007 Free Software Foundation Inc.





to distribute under GPL with a special linking exception, as an addendum

authorising the use of the function.

The GPL with special linking exception is more legible and more permissive whichled to it being chosen by SUN for the JDK.

[5.3.7] GPL-v3

Version 3 of the GPL licence was completed during 2007 and was deployed on a

gradual basis.

It seems to improve the v2, and adapt it to a context which has changed in respect of

the following points:

A stricter legal definition of the terms which leaves less to interpretation ;

The ban on preventing by physical means, or as a result of not supplying the

information required, the installation of the modified software on the target

hardware. This is what was called tivoisation, from the name of the Tivo

company the manufacturer of the video recorders used for this purpose.

The case of the ban made in a number of countries of bypassing the DRM. A

work derived from a GPL-v3 software programme cannot invoke this ban. In

other words, that it is not forbidden to write a DRM programme using GPL-v3

components but it is forbidden to ban it being bypassed. Protection against claims for software patents: the person distributing his or

her code under GPL-v3 licence gives all the user rights permitted by the

licence and undertakes not to pursue users in respect of software patents.

The possibility of adding certain special restrictions to the licence, including a

limited number of possibilities, which provides a little more flexibility in

respect of licence compatibility problems.

[5.3.8] AGPL (Affero)

As we saw above, it is not forbidden to take a GPL licensed programme, construct a

programme which will be a derivative work on this basis and use this programme for

the person’s own needs, including using it within his or her own organisation but

without distributing the sources. In the same way, it is not forbidden to offer an

accessible service which has been constructed using this derivative work on the

Internet and without distributing the sources because this use is not a distribution.

Before the increase in the offers for hosted services, of the Software as a Service

(SaaS) type, this type of use expanded rapidly. However, if you think about it,

making the programme directly accessible to one’s end users through the internet is

a good way to prevent access to the source whilst at the same time being involved incommercial use which is similar to distribution.





It was to respond to this risk of bypassing that Affero, in coordination with the FSF,

created the AGPL or Affero GPL licence. It is identical to the GPL but adds an

article which says that if the initial programme allows access by the network and

distributes its source on the network then the derivative programme should do thesame.

The article is the following:

« Where the programme as received by you is planned to interact with users through a

network and if, in the version you have received, a user interacting with the

programme had the possibility to request the forwarding of the programme’s entire

source code, you should not withdraw this possibility for the modified version of the

programme or a derivative work of the programme (...) »

This is a basic measure and it seems to us that it is likely to become more

widespread in the future.

[5.3.9] “Weak copyleft”»

The distinction between copyleft and non-copyleft is not actually binary. Between

the BSD, which has virtually no requirement in terms of derived work and the GPL

which requires the same licence, there can also be intermediary requirements.

These are the of the “weak copyleft” type, particularly the MPL, Mozilla Public

Licence and CDDL from SUN. Like the GPL, the MPL licence requires the copiedor modified source code, where redistributed, to be so under the terms of the same

MPL licence. But this requirement does not go beyond the border of the source code

file so that MPL source code files can be associated with other files to create a

programme without special conditions on this derivative work. MPL and CDDL are

not compatible with the GPL

Similarly, the Eclipse and EPL licence authorises commercial derived works under

non-open source licences therefore, but with a few requirements, among others, to

identify the original EPL portions and to indicate the manner in which to obtain the

source.

[5.4] Intellectual property and patents

The general term of intellectual property refers to all legal aspects relating to the

ownership over the intangible assets created through intellect.

Programme copyright is a notion which is quite clear. Even if the lack of clarity

possible in respect the notion of derivative work has been referred to above, one

thing is sure: if a programmer sits at his keyboard and writes a code which he thinks

about himself, he is not in the process of violating any copyright whatsoever. Eitherhimself/herself or the employer is the owner of the copyright over his code.





In other words: it is known when copyright is being breached. This is not the case for

patents and no developer if s/he needs to ask himself or herself at each line whether

s/he is in the process of breaching any patents among the millions deposited.

It is important to understand the distinction between copyright and patent.

Copyright – which is the basis of the licences, whether free or not, relate to a

programme, whereas a software patent relates to a process in the vaguest of senses.

The double click on the mouse for example (patent 6,727,830), or even establishing a

list of task for programmers (patent 6,748,582) and other aberrations. The majority

of these patents have no value, but this would only be known at the end of a long

and costly process. Their value is in the perspective of the process and not its

outcome.

In 1991, Bill Gates said “If, at the time when most of today’s ideas were invented people had understood how patents were granted, our industry would be totally

paralysed today” . Indeed, if Dan Bricklin, the inventor of the spreadsheet with

VisiCalc had deposited a patent in 1979, Microsoft would not have been able to bring

out Excel before 1999.

Today, the major publishers deposit patents in the United States, by the thousands.

They do no attack each other but they use the threat of action quoting patents as the

atomic weapon against smaller publishers and the open source World. In a manner

which is totally organised, almost avowed, they use patents to tighten their oligopoly

and stifle innovation.

It is sometimes though that open source software has more to fear from software

patents simply because their code is open. If they use algorithms which are covered

by patents then this is easy to discover. On the other hand, if Microsoft or Oracle

uses a code which infringes a parent or even a copyright, this would be extremely

difficult to demonstrate.

Very fortunately, software patents are not common in Europe. but the danger is

great and their advocates are not disarming.





[6] SUPPORT

[6.1] Open source and support

Support for programmes is a key question in IT in general, and even more so in open

source.

What do we mean by support? The capacity to provide help in using the programme

and correcting the programme, where necessary.

Support can be addressed to end users, such as programme users or even to the

programmers working on the programme.

The use of programmes for critical tasks, particularly in companies, absolutely

requires support because the risks of a blocking situation is too great whether this

blockage is caused by an anomaly, misuse, poor configuration, incompatibility, etc.

The question of support is a sensitive topic in terms of open source software. In the

first place, because there is a basic difference for products originating in the

community, between community support and support by the publisher. In thesecond place because publishers of proprietary products would like to think that

support is a weak point of open source software.

It is true that the open source licence states in large letters: this software is

supplied as is, without guarantees etc… Indeed, it would be extraordinary to claim

anything from the author who gave you the right to use his work. However, we

sometimes forget that the absence of a guarantee is more often also invoked by

proprietary licences.

[6.2] Community support and Support by publishers

In terms of open source support, the two Worlds should be separated: community

products on the one hand and the products of commercial publishers on the other.

Community products (Linux, Apache, PHP, …) first and foremost benefit from

community support. In other words, based on the willingness of developers involved,

who answer questions from users on mailing-lists and forums. It is also based on

the monitoring and handling of anomalies on the community development platforms.

When the community is active, as is the case for large products, this communitysupport may be very effective, extremely reactive and better than commercial





support. Nevertheless some users remain upset that it comes without a guarantee

and that there is no-one who can be attacked if the problem is not resolved. In

reality the majority of back-up support provided by commercial publishers is also

without any guarantee as to the outcome.

Apart from the community aspect, there is also the diversity of products. An

information system can currently include more than 10 different products in the

software “pile” : Linux, Apache, Tomcat, MySql, Hibernate, … When a problem

arises, who should you turn to ? Professional clients are asking for a single contact

point to handle the initial levels of back-up.

Very earlier on in the development of open source, commercial players responded to

this back-up request. This is the positioning of the “distributors: such as Redhat or

Mandriva, but also the first SSLL in France, such as Alcôve, Linagora or OpenWide.

From the side of the open source publishers (MySql, eZ Publish, OpenERP and

others), the question is different: the publisher is a commercial company and its

business model is essentially based on its offer of support. Here therefore, the

support mechanism is very close to that of the proprietary product. It is not

identical however, because at the same time, and in addition to the publisher’s

paying back-up, there is often community support whose extent varies according to

the products.

However, more often than note, corrections affecting the code are not provided by the

publisher.

For new publishers of open source, product support is the basis of the business

model, it is their raison d’être and their unique source of revenue. We can therefore

expect good quality support including a variety of options in terms of reactivity.

[6.3] 3 support levels

We should first of all recall the usual definition of the support levels:

Level 1: a non-expert operator notes the request, enters it in the monitoring

tool and consults simple instructions to try to resolve the problem.

Level 2: an expert who works in a variety of fields analyses the request and

carries out an initial diagnosis. S/he resolves the problem or finds a way

around it consistent with the extent of his knowledge or else determines to

which specialist area it should be referred.

Level 3: a specialist makes the final correction.

A correction involving a programme’s source code can only be made at level 3.





Of course, a general rule in terms of support is that interventions need to be limited

to the initial levels and only have one at level 2 which is responsible for signposting.

This is shown in the following diagram:

[6.4] Software layers

Below, we distinguish 4 lays of a typical open source platform:

The GNU/Linux operating system. Level 3 can only be provided by

communities (Debian), or specialist distributors (Redhat, Mandriva,

Canonical).

The sundry system components, generally included in the distribution,

typically Apache or Tomcat. Even those are also supported at level 3 by

communities, for example that of the Apache Software Foundation.

High level solutions of open source publishers, typically eZ Publish, OpenERPor Nuxeo. At level 3 these can only be supported by the publisher.

Finally, the modules of specific applications or complex configurations of these

applications. This can be, for example, an entirely specific business application

built on an open source framework or a set of templates of content

management tool extension. More often than not they are made by the end

client’s teams. Of course, it is the person which produced them who is the best

placed to provide the level 3 support.

It is clear that the stability will increase between these 4 layers: bugs in Apache are

rare, but in Linux they are even rarer still. High level solutions are less robust


N1 N2 N3

Users

Supportlevel 1

Supportlevel 3

Supportlevel 3

Supportlevel 3

Supportlevel 2

Records and appliessimple instructions

Analysis, diagnosisand signposting

Resolves the problemin the code




than Apache but the probability of bugs is the strongest in specific developments

simply because they only have a limited number of users and average maturity.

This is what is represented in the following figure:

Consequently, it is clear that the need for support is very high for the higher levels.

Where there is a single contract period, it would naturally be the person involved on

these layers.

[6.4.1] Support in the absence of specific applications

The following diagram represent the case of open source products being used “as is”

with no or very little. This is typically the case of an OpenOffice suite deployment.


Open source

solutions

LAMP

OS

Client

end-user

Distributor

Editors

Distributor

/

Community

Distributor

Open source

solutions

LAMP

OS

Client

end-user

Distributor

Editors

Distributor

/

Community

Distributor




If the configuration includes a publisher product in addition to the communities’

products, and still in the absence of a specifically prepared configuration, then the

client can go directly to the publisher for the levels 1, 2 and 3 of its product and to

the distributer for lower levels. It is rare for publishers to want to provide level 1and 2 for the product across the whole of the configuration.

[6.4.2] Integration Support centre

Finally, some service providers offer to provide multi-product global support at levels

1 and 2. This is the heart of the matter for some SSLL, but some generalist SSII

are also involved here.

It is rare for them to have the experience required to provide level 3 support across

the whole range of components, but they can construct sufficient experience on some

of them.


Open source

solutions

LAMP

OS

Client

end-user

Distributor

EditorEditor

Distributor/

Community

Distributor

Open source

solutions

LAMP

OS

Client

end-user

Distributor

EditorEditor

Distributor/

Community

Distributor

Open source

solutions

LAMP

OS

Client

end-user

Distributor

EditorEditor

Distributor/

Community

Distributor

Open source

solutions

LAMP pile / J2EE

Components

OS

Clients

End-users

Editor

Integration

support

centre

Distributor

/

Community

Integrator

Distributor

Communities

Open source

solutions

LAMP pile / J2EE

Components

OS

Clients

End-users

Editor

Integration

support

centre

Distributor

/

Community

Integrator

Distributor

Communities




[6.4.3] Case of a specific application or configuration

The following diagram represents the case were the client is using a specific

application or a complex configuration of an publisher’s open source solution which

has been prepared for him or her by an open source solutions integrator.

In the case of this diagram, the integrator is the best suited to provide support at

levels 1 and 2 for the whose pile and to turn to appropriate expertise for level 3.

It can sometimes happen that the client has several configurations on the same

layers and to have conferred overall support on these layers to a distributor.


LAMP pile / J2EE

Components

OS

Clients

End-users

Editor

IntegratorDistributor /

Communities

Open source

solutions

Application or

specific

configurationIntegrator

Distributor /Communities

LAMP pile / J2EE

Components

OS

Clients

End-users

Editor


Communities

Open source

solutions

Application or

specific


Distributor /Communities




This second diagram shows a alternative in which the final client turns to a

distributor for the bottom-end support: operating system and to the integrator for

the higher components.


LAMP pile / J2EE

Components

OS

Clients

End-users

Editor


Communities

Open source

solutions

Application or

specific


Distributor

LAMP pile / J2EE

Components

OS

Clients

End-users

Editor


Communities

Open source

solutions

Application or

specific


Distributor




[7] BUSINESS MODELS

[7.1] Principles

What we refer to as business model is the operating principles which provide the

company’s profitability. The analysis can be extended to not-for—profit

organisations by being less interested in their income and expenditure.

In fact, not everything is free in open source and there is a real open source economy

which has its own peculiarities.

There are three different large families of open source software: (1) Foundation

products (Apache, Eclipse, Linux, …), (2) community products and (3) publisher’s

products. The question about business models is mainly raised for the latter whose

offer constitutes a growing share of open source assets.

We know that open source software products are not always written by volunteers

during the evening after work for pleasure or glory. This type of enthusiastic

developer who uses his spare time to progress projects certainly exists. They exist

and we can thank them but at the end of the day they only write a small part of theopen source programmes which we are using.

The question is often asked by incredulous beginners: But if it’s free how can that

work, somebody needs to get paid at some point?

Here we will look at the 4 types of open source players:

a) Foundations

Similar to the Apache, or Eclipse Foundation, these are not-for-profit organisations

who stimulate and drive the development of large open source products.

b) Distributors

In a similar way to Redhat, Canonical (Ubuntu) or Mandriva, they select tools and

components around a Linux kernel and provide the packaging, distribution and

support. Often they also act as publishers.

c) Publishers

They create a software product which they distribute either fully or partially underan open source licence. They handle the promoting of their product and offer back-

up.





d) Service providers

Open source service providers of open source sell services as a lump-sum or fee basis.

The service can involve consulting, integrations, support, training, hosting, etc.

[7.2] The foundations

The foundations and other not-for-profit organisations have a very important place

in the open source ecosystem.

The largest open source products and those which are the most widespread, came

from these foundations or else or handled by them.

The Free Software Foundation, already referred to above for its definition of free

software and the GNU GPL and its mission to defend and promote free software,

continue to play a key role in the development of the components for the GNU

Project which as associated with the Linux kernel.

Let’s us now look at some of the other large foundations.

[7.2.1] Apache

The Http Apache server is the founding product of the foundation by the same name.It dates back to the beginnings of the web, namely 1995 when some developers came

together within the Apache Group and tried to improve the first Httpd of the NCSA,

as an alternative to the Sun and Netscape tools. With effect from 1996 and up to

the present day, the Apache server is the most used on the web.

The Apache Software Foundation (ASF) is a not-for-profit American law association

and one of the temples of the open source. In this World of the open source, it is the

only body which has both the means to drive large and multiple projects and which

is not looking for profits.

Owing to this non-commercial vocation, the ASF is motivated to initiate quality

projects which can be used freely by the most people possible. It is also this

characteristic which leads companies or developers to give programmes to the ASF.

Apache project programmes belong to the ASF which distributes them under an APL

licence, a non-copyleft licence.

The Apache foundation is funded by a few sponsors and some revenue is generated

for the organisation from seminars, sales of goodies and on-line donations.

Nevertheless, the foundation remains with a very small budget.

In its 2005-2006 accounts, which in 2010 are the last published, its declared income

of 150 K$, including 95 K$ from donations and 50 K$ from income from its services





broken down between Apache conference receipts (environ 30 K$) and the Awards

Codes (20 K$).

Expenditure over the same period was only 33 K$, of which 28 was dedicated to thefoundation’s main aim to distribute its software programmes to the public free of

change, in other words mainly hosting and operating costs.

We can therefore see that the financial flows are minuscule compared to the effective

power of the foundation in its mission to promote and develop large open source

applications.

The progress of projects is mainly based on volunteers, but also on gifts in kind

which can be made by companies by authorising some of their developers to work on

Apache projects during working hours whenever convenient. Specific agreements

make it possible to ensure that the fruit of such work belongs to the ASF.

There is some fifty Apache projects whose fame, distribution and quality vary.

Overall, a common feature is having a sound software architecture based on

standards.

We will mention here a few of these products: Apache Httpd, Perl, Lucene, Tomcat,

Ant, Cocoon, Lenya, OfBiz, Struts, and many others…

[7.2.2] Eclipse

Eclipse is an initiative which brings together large IT companies, at the initiative of

IBM, to initially develop a integrated development platform (IDE, Integrated

Development Environment), of the same name.

The company changed its status in 2004 to become the Eclipse foundation a non

profit organization.

The mission is to organise and create a set of design, development and management

tools as well as components and frameworks.

The strategic interest for IBM is to counter the Microsoft environment in companies.

In effect, the quality of the development tools plays an important part in the

adoption of a platform by developers and the Java development tools were often

judged less well integrated and less ergonomic that those of Microsoft.

The foundation is funded by its members, large IT companies (IBM, Intel, BEA,

Motorola, Nokia, Oracle, SAP, Zend, …). It has staff for administration work, but

the developers are independent programmers or those working for companies who

give them time to work on these projects.

The foundation supplies 4 services to the Eclipse community:

A hardware infrastructure which hosts the work,





A legal framework for issues of intellectual property,

Processes for community development,

And the promotion and facilitation of projects within the ecosystem.

[7.3] The Distributors

Distributors are companies such as Redhat, Ubuntu, Mandriva, Suse and a few

others whose activities are to:

Select products and versions around the Linux

Validate the maturity and robustness of these products

Distribute these products and their updates, that is to say their transmission

to users-clients

Provide support for these products: hot-line, handling of requests, consulting,

training

Initially, in the 90’s, the preferred means on distribution was on disk and then CD

and the main activity of the distributors was the burning and distribution of CDs.

Today, distribution in mainly online and the heart of a distributor’s job has changed

to focus on support

Distributors now essentially distribute products whose rights they do not hold. They

therefore do not have the choice of proposing such and such a licence or a GPL

licence and a commercial licence as some publishers do: it is the holder of these

rights who decides on the licence. Open source distributors distribute the majority

of products under GPL and a few under BSD or other licences.

Some are also publishers of a few products which they distribute.

[7.3.1] Redhat

Founded in 1994, Redhat is by far the biggest in the market with more than 2800

employees throughout the World in 2009. For a lot of companies, particularly in

the United States, Redhat gave its credibility to the open source.

Redhat is also one of the most important contributors to the Linux kernel and is also

the publisher of open source products including, in prime position, the JBoss

application server acquired in 2006 or tools such as Hibernate.

Support is available via subscription paid on an annual basis. The price depends on

the products involved and the service level. In the Redhat catalogue this rangesfrom $350 to $2500, per year and per server. The model is therefore very recurrent

by construction. It should be noted that the support contract includes an





“Intellectual Property protection” clause, legal insurance which protects any clients

from any action by holders of patents. This is a very valued clause in the United

States.

Subscriptions represent 82% of the revenue for Redhat with the rest coming from

training and consulting. AS far as costs are concerned, we are able to identify, but

without knowing the share of each:

The usual costs of a commercial company: general services, HR, commercial

services, marketing. It should be noted that business and marketing costs

represent 30% of turnover, and the other administrative costs, 20%.

The costs associated with the support services:: hot-line, experts, consultants

The costs of developers contributing to the distributed open source productssource, or research and development: 18% environ.

In total the net profit for Redhat for 2008-2009 was approximately 79 79 M$, on a

turnover of 653 M$.

[7.3.2] Mandriva

If Redhat displays a stunning health, the French Linux distributors have, on the

contrary, experienced some difficult years. Formerly Mandrakesoft, the company

has been distributing and supporting Mandriva Linux since 1998 which has reached

the top 10 of global distributions.

Floated on the stock market in 2001, the company has followed a bumpy path, going

through receivership in 2003, managing to show some positive results in 2004 before

plunging back into the red. In the 2006-2007, financial year, the turnover was 4,2

M with an operating loss of 2,3 M . The latest figures available to March 2010 are € €

those for the third quarter of 2008 with a turnover of 0,83 ME, and an operating loss

of 0,64 ME. It seems that is particularly suffering from the growth of the Ubuntu

distribution.

Mandriva publishes its own products: the Pulse 2.0 IT equipment managementsolution and the Ldap Mandriva Directory Server. In 2007, Mandriva also acquired

Linbox.

[7.3.3] Debian

Even if it is not a similar business model, we should make a special mention here of

Debian, a non-commercial Linux distribution, the oldest, most communal and the

closest to the founding values of the open source. It is also the second most used

Linux distribution Linux.





A project founded by Ian Murdock (today working at SUN), in 1993, it is

characterised by the Debian Free Software Guidelines, released in 96 (which

inspired the Open Source Definition), and its packages management system.

[7.4] The open source publishers

[7.4.1] Open source publisher

The editor holds the product rights, provides the development, promotion,

dissemination and support.

Initially, the only commercial actors involved in open source were distributors morethan publishers, with the flagship player being Redhat.

It was MySql who opened the way to the logic of the open source publisher and, over

the past few years, this model has given birth to a number of particularly dynamic

actors.

Open source editors are ordinary commercial companies, that is to say not-for-profit.

Like an ordinary publisher, they massively invest in the development of their

product and sometimes also in its marketing and promotion. The only difference is

that the product is distributed under licence or sometimes double licence.

Why do they choose this model? Apart from sticking to the values of the open

source, they have no doubt analysed that open source is the only way of piercing a

market which is a prisoner of a few oligopolies. Similar to low-cost airline

companies, these new actors are following a slightly different business model so as to

break open the vested interests.

If the economic outcome is very similar, these new actors have nevertheless specific

characteristics in relation to the classic publishers. In the first place, they are small,

very small organisations compared to the publishers in place. MySql had 360 staff

at the time when SUN acquired it. Their forces were then largely focused ondevelopment and product support. They do a little marketing and a little business

development. Like the los-cost companies, from a structural perspective they have

very low costs which enable them to survive with low income.

After all, developing a quality programme is expensive, even if it is open source. A

little less expensive that its proprietary equivalent perhaps because (a) it can rely on

other open source bricks to the extent that this is allowed by the licence, (b) it can

benefit from community contributions and (c) it probably has more enthusiastic

developers. But all this does not lead to a half price software programme.

Since developing a programme is expensive, its publisher needs to find a return onits investment and even a certain risk premium given that its risk is great to not

have the success which is hopes for.





This raises the question of the business model for open source publishers, often

inseparable from the choice of licences. Let us look at what these models are and

the big trends of the moment.

[7.4.2] Really open source ?

Some publishers might be tempted to be “more or less open source”, distributing

sources without the user rights or with different restrictive conditions. In short,

saying that they are open source but without being really.

Fortunately, this is not possible and it is the fundamental contribution of

institutions such as the FSF and the OSI, to unambiguously define what an open

source licence is and what it is not.

Open source editors can therefore not cheat, they need to distribute their products

under an accredited licence. This means that users can freely and without charge

redistribute the said products, which is the definition very definition.

The majority of publishers choose the GPL licence which has two great advantages

for them: (1) it is known and it therefore perfectly visible, it is perceived by the

market as a benchmark of openness, (2) it prohibits others from integrating the

product into a proprietary development and therefore from making money of the

back of the author who holds the copyright.

[7.4.3] Business model of the open source publisher

Open source publishers have three types of income:

Sales of licences

Sale of support

Sale of services

Sometimes this is supplemented by income from their partner integrators: paying

partnership for some, or commission in the business contribution, when prospectsare directed towards the partners

And of course, under expenses, we also find:

Product development

Support

Sales and marketing

Publishers also benefit from the open source at the level of the costs: by being able

to rely on the extraordinary asset of the code already available under open sourcelicence, they make major savings in development costs.





[7.4.4] Sales of Licence

“Sales of Licences” and “open source” seem to be a contradiction. As a matter of fact,

even if it is not forbidden to pay for distribution, it is not possible to ask for payment

for a user right on an open source software programme (cf. “Free beer ?!”, page 8).

But there are many examples of double licences possible.

a) Getting out of the GPL

The first is a non-open source licence, in other words proprietary, which enables the

client to not be bound by the obligations of the GPL licence. In particular, if the

client wants to distribute a derivative work by using the programme and does not

want to distribute its sources, then it needs to acquire a commercial licence.Publishers such as eZ Systems or MySql offer this option.

For high level applications, for example CMS eZ Publish, it is generally not a source

of major revenue because the aim of the make a site and rarely make a profit.

However, in the case of MySql, the sale of licences represents more than half of

turnover.

b) Additional paying modules

The second case is the one where the publisher offers modules in addition to themain application with these modules being exclusively under commercial licence.

Depending on the circumstances, the open source part may be more of less complete.

However, if it is too light and gives the impression of being a simple bait to hook the

pigeon, it will be rejected. If the open source application is of quality and the paying

modules are optional, the model can work, We should quote Talend and Pentaho, as

publishers who have chosen this model.

c) Dependence between support and licence

The third case, the most current is that where the publisher creates a dependence

between its offer of support and the commercial licence. In this case, the publisher

offers no support, even paying, on the open source version. In order to have support,

it is necessary to choose the commercial licence. This is the case for the Alfresco

publisher for example.





[7.4.5] What revenue?

For an open source publisher, possible sources of revenue are the following:

support and maintenance, again in the framework of recurrent contracts

associated services: audit, consulting, training and integration

user rights associated with the licence, therefore to a non-free licence.

royalties from authorised service providers

Within a perspective of global and rapid expansion, publishers cannot bet too much

on services. Integrated a product is tempting at the beginning but this does not

make it possible to build a network of integrating partners.

But more than anything, a business model based on the service is perceived by

publishers and those who finance them as a “non-scalable” model, in other words

which does not allow the income to be increased without increasing the number of

staff and therefore the costs. Overall a model which does not allow the margin rates

of proprietary publishers.

[7.4.6] Model 1: solely support

Some publishers have a business model based almost entirely on the offer of back-up

support. In this category is eZ Systems, Nuxeo, Tiny (OpenERP), Spago.

There is only one version of the product and a single licence – therefore open source

– a single source reference and corrections which are available to all. The product

can be freely downloaded and “clients” have the right to user the product without

paying for support.

Given that the support is clearly optional, the clients need to be shown the benefits

which they can expect from it. With information technology managers at large

account companies this is generally not too difficult. In the case of acquiring critical

software, no-one can imagine going to explain to the Chair person of the Company

that it was possible to take out back-up support but they decided to decline!

Moreover, large IT departments already understand that the savings are already

great compared to the software programmes which they were using previously.

With smaller companies however, sometimes this can be difficult to demonstrate.

One of the difficulties of pure annual support is that if it has not been used during

the year, some people may hesitate at renewing it. Of course, you could say: there

is an insurance logic in back-up support services. Just because you were not burgled

this year doesn’t mean that you are going to cancel your insurance! But from their

side, they would reply: if this has worked for a year without any problems, it can do

so for one year more!





This is the problem and the paradox of back-up support: the more the product is

quality, the less the back-up is easy to sell.

However, most products are continuously changing under the pressure of competition. Open source products tend to change faster than others. The product is

never completely stabilised, it is forever moving and support is precious if being used

professionally.

[7.4.7] Model 2: stability and support

Other publishers choose a model which pays for stability. They distribute their

product under two licences, one free and the other non-free. However, this is not

completely the same product.

In this category we could quote Alfresco, Jahia, Pentaho, eXo, Liferay.

With the non-free licence, the customer has an “enterprise-ready” , “ production

grade” , “ fully tested” version, etc. Whereas the free version entitled “community” or

“labs” is presented as not stable, not tested, really something for geeks, dangerous

and especially not used in production.

This is the vocabulary used, but in actual matter of fact the difference are not

always well identified. The publisher cannot sustain two different code benchmarks

over the long term and therefore needs, as a minimum, to synchronise community

and enterprise from time to time. In general, the community version currently being

developed on which developers are continuously working, whereas the enterprise

version is the one which has been frozen and then looked at in-depth, has received

certain patches and continues to receive them continuously in the form of support.

In this way, paradoxically, the community version is ahead of schedule, it has the

latest functions but is less stable either owing to being ahead of the developments or

behind in relation to the corrections. In a code sources manager, it could be hopes to

extract the latest stable version, even to reapply the patches but here this is not the

aim.

The support comes in a bundle with the enterprise licence to which it cannot be

disassociated, whereas, on the other hand one could not hope for any support, even

paying, on the free version.

For the publisher, the advantages are numerous.

The community version held to distribute the product, to get it known at the global

level both by potential clients as well as potential integrators.

Moreover, once it has started with the enterprise version and its support has been

annualised, it is delicate to go back to a community version. the downgrading would





be managed as a real migration. There is therefore a form of loyalty which does not

permit the only paying support.

On the contrary, the disadvantage is that if the community version is too instable, itdoes not contribute to the good image of the product or to its promotion. And if, on

the other hand, it is of good quality, it risks being used despite alarming warnings.

Letting users experiment with an instable version is not always sufficient. The

complete process of adoption is often: gather information, download, experiment,

real non-critical project and finally strategic project. For a lot of companies, the

community version must enable a real non-critical project to be reached which will

enable a strategic choice to be made. It is to this that the degree of stability should

carefully.

[7.4.8] Model 3: Advanced functions and support

Finally, the third model is that of a double licence defined according to the level of

functionalities: a GPL version with reduced functionalities or an enterprise version

with advanced functionalities.

In this second model, for example Talend, Jasper, or even MySql can be found.

In this case, there is no difference of quality or stability. The programmes

corresponding to the first level of functionalities are the same. Like for any other

programme, the sources manager identifies the latest stable versions, and the latest

builds, but anyone can also download the latest stable version. On the other hand,

the sources for the enterprise version are not distributed at all.

Not defining the difference in terms of offer quality in a certain way offers a better

image of the publisher, its capacity to produce a solid software programme. It avoids

the association of ideas “free-unstable”, which is quite unpleasant and also without

basis.

But here also resides in the border: a sufficient amount must be put into the free

version so that it is widely distributed and gives the impression of a rich product butat the same time being sufficiently limited to not allow strong added value.

[7.4.9] The support

As seen, the support is the main source of revenue for the majority of open source

publishers. The offers of support are more often than not based on an annual

subscription per product, server or processor.

The support generally includes :

Preferred access to the patches and to specific resources.





The handling of problems whether anomalies or user problems or

implementation.

Possibly audit, certification, remote control software, proactive supervision andcorrection services.

a) Patches

The patches can be tried to maintain a gap between the corrective level of the clients

being supported and the public sources benchmark. However, they do not abuse this

because it is also the reputation of their product which is at stake on the open source

version. On the other hand, supported client receive the “push” patches without

asking for them.

The support contract may also include access to certain privileged resources: forums,knowledge bases, mailing lists and even documents. But here again not to freely

distribute documentation is generally rather punitive. It should be remembered

that free uses are also flagship products for the use under critical conditions which

will require support.

b) Resolving problems

A lot of contracts differentiate different levels in terms of

Number of problems over the year

Problem reaction time

Hot-line opening times

Correction guarantee

Taking of control

The link with the support is generally by web or mail for basic contracts and by

telephone for top of the range contract.

[7.4.10] Three open source publishers

a) MySql

MySql A.B. is a Swedish company, publisher of the database of the same name.

In 1994, there was no lightweight relational database and even less open source.

Postgres has been created in 1990 by Michael Stonebraker, already the founder of

Ingres. But at this time, Postgres was not using SQL but QUEL as query language.

In 1994, Hughes, an Australian student, made for Postgres a query translator of

SQL to QUEL, and then finished off by re-writing the storage layer by simplifying





the functionalities to a maximum. His project was called mSql, and it rapidly

acquired fame.

In 1995, Michael Widenius, from Swedish company TcX added an SQL interfacewhich was compatible with mSql on the Unireg home database engine. From the

outset, the company adopted an open source publisher model which rapidly created a

wave of membership and contributions.

It was only in 2000 however that MySql went under GPL licence. Up to this date, a

specific licence excluded Windows platforms and prevented anyone from offering

paid support. Making such a licence would not pass the criteria for the open source

definition.

MySql AB had 30 employees and a turnover of 40M$ in 2006, the last known figures

at the time of the purchase by SUN. We should understand to what extent these

figures are minuscule compared to the large traditional publishers. In the same

year, Oracle has 68 000 employees and a turnover of 17 Md$. In other words 400

times more.

In 2004, the version 4, MySql modified its licence conditions, with the connectors

allowing programmes to access the base by changing from the LGPL licence to that

of GPL. The implications are very strong. In effect, the fact that a programme uses

a database does not imply that it is “built on” the database in the sense of the GPL

licence. A priori therefore, a programme can use both a MySql under GPL, without

falling under the obligations of the GPL licence. However, to make this call,applications will most often use the connector supplied by MySql. In this way, by

placing the connectors under the GPL licence and not LGPL, MySql is seeking to

extend to the applications using its server, the implications of the GPL and in this

way to push clients more towards its non-open source licences.

This is why this change in commercial policy was poorly received in the open source

communities. The PHO developers in particular invoked the incompatibility

between the licence used for PHP. In order to respond to this, MySql added a

particular clause, the “FLOSS exception8”, and the armistice was concluded with the

PHP community.

Finally, in January 2008, SUN purchased MySql for approximately 1 billion dollars

representing around 20 times annual turnover. The deal was seen as an awareness

on the part of the traditional players, of the growing power of the open source

publishers.

MySql sold its MySQL Enterprise product which is essentially a service offer. The

services principally relate to audit, support and consulting.

8http://www.mysql.com/about/legal/licensing/foss-exception.html


http://www.mysql.com/about/legal/licensing/foss-exception.html






The service offer is disassociated from the nature of the licence: by default, it relates

to programmes distributed under GPL licence, but the client can choose to use the

commercial licence at the same price.

On its site, MySql explained the general principal that the use of the base in the

context of a commercial organisation needs to be under a commercial licence. The

authorisation to distribute within the same organisation without the need to make

the sources public is not explained but it flows from the GPL licence.

b) eZ Systems

eZ Publish is a content management tool (CMS) written by Bård Farstad in 1999

and distributed under GPL with effect from 2000. From the outset the product is

better designed than the majority of PHP applications, especially at this time. Itrapidly adopts an object modelling and a layer of abstraction thereby allowing it to

work with any database.

As for MySql, the revenue over the initial years came mainly from integrating the

product into its own projects in the local market Norway. In 2002, the product

already enjoyed Worldwide recognition and people were already speaking of the

“PHO killer application”!

With effect from 2004, eZ Systems established itself in various European countries

and then in the United States.

In 2006, eZ Systems put the few components associated with the CMS and which

were not already under open source. In April 2007, eZ Systems raised 5 M$ in

capital from Norwegian investors which certainly gave a new fervour to its aim of

becoming the content management system of choice for the biggest companies. In

2009, a new capital was raised

The business model for eZ Systems is fundamentally based on support, with silver,

gold, and platinum products, which are differentiated by the number of incident

tickets included and the coverage times with prices ranging from $6990 to $13990.

c) Alfresco

Alfresco was founded in 2005 by the former manager of Documentum and Business

Objects, who took with them the architect of major publishers and major capital.

Alfresco is therefore the perfect example of the new generation of open source

publishers.

The first generation of open source publishers had generally started out at

university or in their garage and had slowly grown by building a community, On the

contrary, Alfresco directly had the means to finance a top flight team, both in terms

of development and marketing and to become known in less than two years as a





major player in its market, tat of Electronic Document Management (GED),

typically a paralysed market in the hands of a few old major players.

Alfresco distributed its GED product under two licences :

A Community, version under GPL licence

An Enterprise licence under commercial licence

Alfresco did not offer any support, even paying for the community version whereas

the Enterprise version, on the contrary, comes with it support in the form of an

annual subscription per server.

In terms of licences, it is interesting to note that Alfresco started by using a licence

from the MPL (Mozilla), with a special clause making it obligatory to present awarning message on all pages of the application. At the start of 2007, Alfresco

moved under GPL licence for the community version also for better legibility of the

open source policy.

Alfresco clearly states in its FAQ that use within its organisation is not considered to

be distribution which is something that not all publishers says as clearly.

The community version is modified on an ad hoc basis whereas the enterprise

version is the subject of validated quarterly releases.

It should also be noted that the partnership contract signed by Alfresco with itsintegrators prohibits them from integrating the community version so that it is

difficult for users of the version to obtain any professional support.

[7.4.11] Law of large numbers

In order to prosper, open source publishers need to be in a large numbers logic,

similar to MySql: the fact that 10 million users pay nothing to MySql AB is not a

problem if, out of this number, there remains 10 000 who have uses which are

sufficiently strategic and wish to have the publisher’s support with a guaranteed

response time.

The percentage of clients who call on publisher support depends on the type of

product. For a consumer product, for example an open source anti-virus, it would be

difficult to have a lot of people pay for support or to sell its paying version. For a

product whose vocation is heavily B2B, for example Electronic Document

Management, the share of clients asking for support would naturally be bigger.





[7.4.12] Community contributions

Open source publishers generally count quite little on community contributions, at

least at the heart of their product. They accept them because this is the logic of open

source, but they hardly encourage them and one might be forgiven for thinking that

it would not sadden them to retain the control over their product.

It should be noted that if its piece of code is accepted, the contributor should

generally sign a specific agreement which allows the publisher to freely dispose of its

code. This is quote natural because if each contributor is able to specify its own

licence conditions, the end product would be a chaos of hopelessly entangled licences.

In order to benefit from a community dynamic, whilst retaining the mastery over the

kernel of their product, some publishers put in place an extensions device whichenable contributions to be made to enrich the product individually and

independently of the kernel and thereby ensuring compatibility with future versions.

[7.4.13] Kernel, extensions and ecosystem

The model which seems to be the most effective and the best compromise is that

which distinguishes the kernel of the product, under the publisher’s responsibility

and the extensions which are made by external contributors.

The principles of the separation are the following:

The kernel should be very robust, it is certified by the publisher; external

contributions to it are rare.

The interface between the kernel and the extensions is well documented and

stable, in other words than any change to the version of the kernel does not

usually imply, at least not often, any change to the version of the extensions.

The publisher stimulates the development of extensions as they give value to

its product and also are witness to the existence of a community which, in

itself, is a gauge of sustainability. The publisher, in general, offers a platform

which makes extensions available. It can, where necessary, provide anevaluation of certification mechanism for the extensions.

This kernel/extensions model is what provides the best point of equilibrium between

the respective roles of the publisher and the community, by linking the guarantee

and commitment of the publisher with the dynamism and enormous development

capacity of the community.

[7.4.14] The “Forks”

A “ fork” is the name given to a break in a development project in which a newdevelopment team starts from the same software base in order to develop the

project in its own way.





Open source licences authorise all forks, which is the very definition of open source.

Broadly speaking, there can be two reasons for a fork: a disagreement as to the

technological directions or a disagreement over the commercial policy and licences.

Consequently, if a publisher adopts a direction which the community does not like, it

exposes itself to a fork. For example in 2006, the ERP Adempiere, was born from a

form of Compiere arising from a commercial policy which turned its back on the

communities following the arrival of investors into Compiere Inc.

Other famous examples are the fork which gave rise to Joomla in 2005, from

Mambo, a very popular content management tool.

Depending on the circumstances a fork can take off or get by according to the

dynamism of the community. There are also non-community forks which are fromcommercial companies, for example the OpenBravo ERP which are was based on

Compiere as the basis of its development.

The fork is like the sword of Damocles over the publisher’s head and which force it to

remain faithful to its values and community. However, on the contrary, some

publishers may also conclude that it is better to avoid their kernel being truly

mastered in the communities.

[7.4.15] Intellectual property and Patents

In the United States in particular, publishers are offering, along with their offers of

support, legal protection in relation to possible breaches of software patents. In this

country, a company who uses programmes which violate patents could be attacked

and be the subject of potentially enormous claims for compensation if its company is

rich.

In recent years this has become one of the most virulent axes of attack by open

source competitors starting with Microsoft which used its agreement with Novell to

keep alive the idea that there is a risk in this regard. Paradoxically, these

intimidations are serve commercial open source publishers who are, at the end of theday, as much selling legal protection as they are product support.

In Europe however, IT programmes are explicitly excluded from the European

Patent Convention and generally speaking the use of the Courts is less part of the

culture so that there is not the same level of fear.

[7.4.16] Publisher-integrator

The IT market has for a long time been divided between publishers and integrators.

Publishers develop products which are likely to satisfy a large number of clients.Integrator use these products to build information systems which meet a specific

need of one of their clients.





Whether open source or not, there has always been service providers tempted by the

dual role: publisher and integrator at the same time, a publisher which integrates

its own product and the integrator which only has a single product in its catalogue.

And this has never worked. This is because in order to win markets, the publisherneeds to build a network of partner integrators and it cannot manage this if the

publisher itself is the main competitor for its own integrators.

In the solutions market, you frequently come across such publishers-integrators but

they never turn into leading solutions. The temptation is great for the publisher

who is finding it hard to find its own business model and, the same time, finding it

difficult to convince service providers to use its product, to do this itself. However,

the market more often than not punishes these combinations.

[7.5] The Service providers

For IT service providers and open source solutions integrators, the business model is

practically unchanged, based on the sale of services and expertise around open

source products and doing this in the form:

of support

of turnkey projects,

of consulting or technical assistance services

Here, we distinguish two types of activities to which often different service providers

belong: open source support and open source integration.

[7.5.1] Open source support service providers

Here we have distinguished distributors and service providers, even if distributors

are service providers in their own way. However, from a historical point of view, the

border is still marked out. Distributors are offering no other service than

distribution, support and training around software included in their ‘distribution’.On these components, on the Linux kernel in particular, they have expertise which

is practically irreplaceable.

However, there is such a diversity of open source components that the need appeared

very early on to have global support concentrated in the hands of a single service

provider. It was around this task that the concept of SSLL was born – Free

Software Service Company: a company which proposes to provide the deployment

and support for open source software based multi-product configurations. These

were joined later by generalist SSII which opened open source support centres.





Open source support service providers such as Linagora for example, can also build

specific applications but the heart of their business lies in support, for example for

ready to use products such as the Open Office suite.

[7.5.2] The integration of open source solutions

The integrator service providers of open source solutions – such as Smile – are

building global applications, IT systems based on open source software.

Of course, they are also providing support for all their creations including specific

developments and configurations and related products, but the essence of their

business lies in integration and construction of applications.

The added value of the open source integrator starts in the choice of solutions.Open source brings an immense profusion of solutions of which some are immature

or, on the contrary, obsolete. This richness is also a handicap: lots of clients are

frightened of making the wrong choice. The open source integrator cannot wait for

to select the happy winners, it needs to permanently assess and supervise so as to

identify promising products and those which are the most solid.

After this, a systems integration project based on open source resembles a general

integration project and demands the same methodological expertise both in terms of

development as well as in project management.

In the chapter dedicated to the development model, we will see that open source has

also driven development and integrator service providers are the first to use good

practices but also good tools which stem from open source: IDE, sources

management, testing tools and continuous integration, anomalies monitoring, etc.

Open source integrators are ahead of the curve in this respect.

[7.5.3] Open source service and traditional service

Open source products have no publisher who is likely to offer commercial assistance

or marketing or pre-sales support or project phase support. Even for commercial

open source products, publishers are often small organisations with limited

resources and rather more focused on product development.

The Service provider is therefore often responsible for part of the upstream

investment which is traditionally incumbent upon the publisher: it selects the most

solid and sustainable products and provides promotions and sales as well as part of

the support.

Faced with the extraordinary growth in terms of open source solutions, all IT service

providers are hoping for a share of the cake; it is in this way that the large

generalist SSII ended up being interested.





However, with each revolution, whether related to technology or the business model,

the actors in place are not able to catch the new wave. This is because they are

faced with a dilemma which can be summarised as follows: “can it be permitted to

kill the historical cash cow?” .

The phenomenon is know and was perfectly analysed by C. Christensen in The

Innovator's Dilemma (1997). Major airline companies against low-cost carriers,

historical telephone operators against new entrants but also IBM against Microsoft,

and now Microsoft against Google. History repeats itself and the free versus

proprietary battle is of the same type: a traditional integrator cannot give up the

manna it is deriving from proprietary software and its high prices. Unless open

source is specified in the specifications, the SSII will propose a proprietary product.

In this way, by not investing in technological monitoring and the relationship with

open source communities or publishers, they lack legitimacy in these new territories.

[7.6] Summary

By means of a summary, we are analysing the relationships between these different

open source actors by considering three types of interactions in the form of flows:

Services, including writing of programmes, support, back-up, consulting,

training, integration.

The source code, in other words the software.

Finally money, which makes a business model out of all this!

[7.6.1] Service flows

In the following figure, we are showing the intellectual service flows between the

various actors identified. This service can involve programme development or

integration, consulting, support or training.

The main service flows are:

Contributions in the provision of salaried developers by distributors such as

Redhat, donors such as IBM or Google and, to a lesser extent, commercial

publishers and integrators to the benefit of foundations such as Apache which

are handling large-scale open source projects.

Offer of integration services, development and support for integrators and

commercial publishers to clients and end users.





[7.6.2] Source code flows

In the following figure we have shown the source code flows. In order to distinguish

this from the development service, which comes from previous flows, we only

consider here the delivery of programmes already written.

Here, the main flows are:


Foundations

Integrators

Donnors

Distributors

Clients and

end-users

Commercial

editors

Voluntary

developers

Foundations

Integrators

Donnors

Distributors

Clients and

end-users

Commercial

editors

Voluntary

developers

Voluntary

developers

Foundations

Donnors

Commercial

editors

Clients and

end-users

Integrators

Distributors

Voluntary

developers

Foundations

Donnors

Commercial

editors

Clients and

end-users

Integrators

Distributors




The source code constituting the large open source software programmes

distributed by the foundations and used by the commercial publishers and by

the integrators.

The programmes distributed by the distributors to the end users.

Programmes from commercial publishers to clients.

[7.6.3] Cash-flows

Finally, this last figure represents the cash-flows between the various actors.

The main flows are distinguished:

Payment by end clients for back-up services to commercial publishers, editors

and distributors

Payment by end clients for integrations services and support to integrators.


Voluntary

developers

Voluntary

developers

Donors

Commercial

publishers

Integrators

Clients and

final users

Distibutors

Voluntary

developers

Voluntary

developers

Donors

Commercial

publishers

Integrators

Clients and

final users

Distibutors




[8] DEVELOPMENT MODEL

[8.1] Introduction

[8.1.1] Halloween document

In 1998, an internal memo was leaked from Microsoft. Since it entered the public

domain it has been known as the Halloween Document I 9 .

In this document which Bill Gates himself sent to his board, an analyst had looked

at the open source movement and the dangers it presented for the company. It

especially recognised that:

Open source projects have reached or exceeded the quality of proprietary

products

Open source projects are now projects or large scale and great complexity

Open source projects have specific advantages which are impossible to

reproduce in terms of motivation and number of participants.

Beyond ethical considerations, beyond a commercial war it was a shock for Microsoft

to realise that a development means which was radically different could work as

well and sometimes better.

It is in this way that the development model for large applications is one of the more

interesting aspects of the open source movement.

[8.1.2] Cathedral and the Bazaar

What Microsoft discovered in 1998 had already been analysed and theorised by EricS. Raymond in an essay which remains a reference: The Cathedral and the Bazaar.

In it, he compared the traditional development model, the cathedral, and the

development model initiated with Linux, the bazaar model.

In his analysis, the cathedral model is not only that of the proprietary software

products, it is also that of large open source projects such as GCC. This model relies

on a compact team of developers, working over relatively long development cycles

and distributing sources at the end of each phase.

9 http://catb.org/~esr/halloween/


http://catb.org/~esr/halloween/

http://catb.org/~esr/halloween/




The bazaar model on the other hand, functions in a manner which seems disordered,

where a large number of developers are involved in a continuous cycle of production

of tests.

It is this bazaar model which is so representative of open source which we will now

explore.

[8.1.3] Large community projects

When we speak of open source development model, we are only speaking of

community projects and, generally, of the largest of these such as Gnome, Mozilla,

Apache Httpd, Eclipse, Linux. The publishers which distribute their products under

licence generally have traditional development models and do not have any

particular desire to extent their community of developers.

Studies show that more often than not a small number of developers contribute the

biggest share of developments. Out of a project where 200 programmers have

participated, we typically find that 10 of them wrote 50% of the code.

Like all IT projects, open source need a few visionary leaders and top level architects

in order to both show the way and define how it can be broken down into modules.

For the largest projects, it is often noted that the main developers are not volunteers

but salaried staff from IT companies. Their employers have different reasons for

letting them work on these projects which may be:

Marketing: being able to report in its marketing that it has a “commiter”,

working on a flagship project is similar to a major advertising budget.

Governance: it is a way of having its say on the product’s strategic directions.

Technological platform: a product platform can be pushed forward more

dynamically where they are directly users and on which all or part of their

business depends.

Mastery: the company will be competent and qualified to offer product

support.

Also the motivation of staff, both those who are actually participating and

those who could do it.

[8.1.4] A Linux development year

The LWN.net site published a very interesting analysis10 on the contributions to the

Linux kernel and from where they over a development year (2.6.16 to 2.6.20) :

28 000 added changes

10 http://lwn.net/Articles/222773/





By 1 961 different developers

Replacing 1,26 million lines with de 2,01 million lines of new code.

The kernel increased by 754 000 lines.

In total:

Development is effectively the same at the very large scale

Linus Torvalds is now only the author of a very small part of the code

A majority of developers are paid by their employer (Red Hat, IBM, Qlogic,

Novell, Intel, …), who provide approximately 2/3 of the code.

[8.2] Organisation, instances

[8.2.1] Developers, committers

Even if any methodology is looking to make quality less dependent on the individual

value of developers, it nevertheless remains true that the experience and talent of

each along with motivation are fundamental parameters.

Open source projects, at least the most prestigious among them generally have an

advantage in this regard. They attract the best and most motivated of programmers

because taking part as Linux committers Linux is the supreme recognition for a

developer.

Committers are individuals authorised to directly submit their contributions to the

sources frame of reference. To become a committer, an individual should have made

quality contributions and earned the respect of his or her peers. This is therefore a

logic or reward based on merit and peer assessment.

[8.2.2] Governance

In a project there are choices to be made, decisions to be taken. Who decides and

based on what process?

Generally speaking, open source projects have a relatively democratic functioning,

within the scope of the committers, and even has a court of arbitration which often

comes down to the project “guru”.

Foundations are more formalised institutions with a board of directors totalling

some ten members who are annually elected by the committers. The board meets

periodically (virtually), around once a month and takes its decisions which arepublished in a report which is made public.





Some projects, Gnome for example, have formalised the rules this democracy. In

others, a more reduced nucleus, even an individual, delivers the final arbitration.

For the Linux kernel this is typically the role of Linus Torvalds. However, in all

cases, the hierarchy within the project is only based on the value and recognition of peers.

[8.3] Development model

[8.3.1] Cascade development model

Traditional development models, whether cascade or “V cycle” are not suitable to

community projects.

The linear linking of different phases supposes overall planning and an allocation of

centralised tasks. Furthermore, independently of the community context, these

models poorly adjust to very large projects: they do not allow evolving needs to be

managed and they do not sufficiently take account of feedback from one stage to the

next.

[8.3.2] Modularity imperative

In order for a few hundred developers to be able to work without stepping on each

other’s toes, it is important to define proper boundaries and identify modules of a

manageable size by a developer.

If good modularity, in other works the cutting up of the project into smaller entities

is one of the elementary principles of software engineering, in the large open source

projects this becomes a vital requirement. The logic of “divide and rule” is

unavoidable.


Developmentsand unit tests

Integration

Acceptancetests

Design

Needsanalysis




The principle is therefore to cut the overall system into sub-systems whose

interfaces are perfectly defined so that each sub-system can evolve in its

development independently of the others, provided that the agreed interfaces are

respected.

Inside such a sub-system, the breakdown is carried out at the level of classes, objects

and functions.

[8.3.3] Iterative development

The predominant community development model is called iterative or “spiralled”.

Its fundamental features are:

on the one hand, a breakdown into modules which each follow their owndevelopment cycle

on the other hand, the iteration of short, repetitive cycles (specifications,

development, integration) in an independent way for each of the modules.

This is in an overall context of continuous integration which makes it possible to

measure progress and to manage regressions, particularly in the incompatibilities

which might appear between the modules.

The spiralled module also has aspects which could be called “Darwinian”, in other

words that at any time a developer can give birth to a new version of a module which

may, or may not, replace the previous one to which it is considered to be superior.


Design

Developments and

unit tests

Intégration

Deployment andtests

Needs analysis

Design

Developments andunit tests

IntégrationDeployment and

tests

Design

Needs analysis Needs analysis

v1

v2




The following diagram therefore gives the general functioning in which each module

follows its own spiralled cycle.

We should stress that these development models are not specific to the open source

community. They may be suited to a variety of large projects. Nevertheless they

owe a lot to the experience of the open source projects.

a) Test and access to the code

The final phase of a development cycle is stabilisation and testing. We speak of the

beta version when the programme is in the hands of a sub-set of volunteer final

users.

Open source projects have a clear superiority in the testing phase from two angles.

Firstly, as a result of the greater number of persons taking part in this phase and

their greater motivation. And secondly, by the free access to the sources which

enables anomalies to be better qualified.

[8.4] The Tools

Large open source projects have developed the methodology but they have also

enormously contributed to the tools which accompany it.

[8.4.1] Integrated environment

For a long time, the open source development tools were a bit rustic. Sophisticated

from a technical perspective but somewhat lacking in terms of ergonomics.

However, things have changed and as we saw above, the Eclipse platform is the best

illustration of this. Initially it was more geared towards Java development but





today it is suitable for all environments and its exceptional modularity allows it to

welcome an extraordinary number of extensions. Even development teams which

are not specifically geared towards open source have today adopted this platform.

[8.4.2] Sources management

Source management tools such as CVS or SVN are the basis of any community

development. They allow the simultaneous management of hundreds of additions by

developers by precisely identifying each modification, its date and its purpose which

allows a modification to be traced back.

The use of these tools has today become widespread but large open source projects

would quite simply not be possible otherwise.

[8.4.3] Generation tools

Another family of tools where open source excels is that of generation tools which

allow programme generation operations to be automated by managing inter-

component dependencies. Since the rustic Unix make, up to Ant, and more recently

the Rolls of the category, Apache Maven.

[8.4.4] Continuous integration

Open source projects have generalised the practice of continuous integration.

Continuous integration consist of generating and controlling the entire application of

a daily basis so as to identify, as far upstream as possible, any possible regressions,

errors or incompatibilities between modules.

It has been known for a long time that the correction cost of an anomaly increases

significantly over time which separates its appearance in the code from its detection.

Continuous integration therefore simply seeks to reduce this time to a maximum: if

on D Day a programmer makes a change involving a bug, s/he is informed of his or

her error on D+1 and the correction cost will be very low.

Continuous integration comes within the more general framework of test-driven

development. This approach consists of writing scenarios and putting in place the

related tools, before writing the programmes. Tests go from the unitary level to the

interfaces level.

The main continuous integration tools are CruiseControl, and Continuum, which is

integrated into Maven.





[8.4.5] Request and bugs monitoring

Less sophisticated, but nevertheless important, are the tools for monitoring requests

and anomalies, the “issues” , with the famous Mantis, in particular but also Bugzilla,

associated with the Mozilla project.

[8.4.6] Exchange tools

At the end of the day, developers use practically all existing community tools for the

development in which they often participate:

Automatic mailing-lists

Forums

Wiki, in particular for specifications and documents

Instant messaging





[9] CONCLUSION

I hope that this small work has helped you understand open source better and that

we managed to convey to you a little of our enthusiasm.

Open source is a marvellous movement, both in terms of its values of freedom,

liberty, solidarity, transparency and through the benefits it brings to both citizens

and companies alike.

Even if open source traces its roots prior to the web, we can state that today it isheralding the biggest IT revolution since the Internet. The use of the word revolution

is not excessive given that the established positions have been overturned and the

business model of many companies reconsidered.

To go further and understand the contributions of open source for your activity, your

company we recommend that you read the other white papers from Smile: content

management, portals, business intelligence, document management ERP, … in all

these domains, Smile has assessed the best open source on the market and offered

you its feedback.