Interview with the CTO of the French Tax Agency, IT Dept., Jean-Marie Lapeyre

Sunday, January 22 2006 @ 11:02 AM EST

Jean-Marie Lapeyre is Ingénieur des télécommunications, Directeur technique du système d'information fiscal.
In English, he says we can just say CTO of the French Tax Agency, IT department.

I had the opportunity to interview Lapeyre, whose decision to go with open source/open standards made news recently.

He gave a presentation at JBoss World Barcelona 2005, "Technological Choices for the Renovation of the French Tax Information System," which you can find here [PDF]. It provides still more evidence that the earth is not flat (translation: your TCO is not higher with FOSS than with Microsoft Windows).

The description of his presentation on the JBoss site goes like this:

The French Directorate-General of Taxes (DGI) was represented on JBoss World Barcelona's Customer Panel by DGI's CTO, Mr. J.M. Lapeyre. Through this presentation, J.M. Lapeyre gave an in-depth explanation of the existing environment within the DGI, its challenges, and the technology needed for Project Copernic: to modernize the whole of DGI's administration process while being able to offer new online services. Project Copernic is a full implementation of Service-Orientated Architecture (SOA). In this presentation, Jean-Marie Lapeyre describes how JBoss and Atos Origin were chosen; the reasons why, and the end results, including a saving of millions of dollars through use of JBoss Professional Open Source technology.

Millions of dollars saved. The presentation gives you an idea of how massive the projects are that Lapeyre is tasked with and what the software needed to be able to accomplish. France has 55 million citizens who can e-file their taxes and access their information, and 3 million corporations, and there are 80,000 tax agency employees needing to use the software. On page 6 of the presentation, you will find a list of reasons why Free and Open Source Software is a rational choice. At the top of the list is "Standards Compliance & flexibility of use." And you'll find a box that says, "Demonstrated (much) lower TCO (75 to 90%)".

On page 9, you'll see the process that resulted in a strong FOSS policy. On page 10, they relate that they issued a "neutral" request for proposals, setting forth their requirements (for example, on page 11 you'll see that one requirement was that every critical bug must be solved within 48 hours), and after receiving proposals, and evaluating them, here's the conclusion: "The evaluation demonstrated that open source rival or beat proprietary software on a technical level. More importantly, it proved that there are mature offers for cost-saving professional support and service." So in 2004, they signed with Atos Origin/JBoss. On page 11, it says they cut their "software costs (TCO) by 4 (for the JBoss part) to 10 (on a global scale)." I naturally was interested in talking with him about the decision to use FOSS.

********************************************************

Interview with Jean-Marie Lapeyre

PJ: Please can you describe what your agency does and how you came to decide to switch to FOSS?

LAPEYRE: First of all, the context: I am CTO of the French Fiscal Agency (since
2002). In France, our agency is in charge of all taxes due in the
country, local or national.

We re-defined our IT policy in the summer 2000 (I was in charge of this as,
then, Lead Architect), along with the launch of our 10-year-long
program called Copernic, to rebuild completely our IT system (a billion
euros investment). This policy was built around a strong architecture
paradigm (today commonly known as SOA : Service Oriented Architecture)
and a strict compliance with open standards.

It is important to note that choosing a product is not part of the
policy. It's a tactical choice, knowing that we strongly want to be
independent from vendors, as far as possible. We opted then to consider
Free and Open-Source Software (FOSS) as one of our options, every choice
thus based on rational criteria (features, performance, sustainability,
Total Cost of Ownership, etc.).

Concretely, we decided to try FOSS in late 2000 by deploying our income
tax management system on GNU/Linux machines (without changing the
application itself, client-server based on Oracle*Forms). We installed
about 1000 servers (850 in production to which must be added, test,
development, spare, etc.) which are operational since February 2001.
This can explain it (in French).

This experience was very positive: this infrastructure became, by far,
our cheapest one. We haven't had any failure of the system since the
beginning.

We had several other (very good) experiences with FOSS from 2001 to
2004. In particular, I used to underline the choice of our J2EE server
implementation: after an open Request For Proposals, we chose JBoss
server along with professional support and service (contract signed in
June 2004). You can read the story of this choice, and more details of
the things described above, on the slides I used for the last JBoss
World Conference (last October).

The important thing is that, since June 2004, strengthened by our very
positive experiments, we chose to change a bit our policy and commit
to FOSS.

This means that for every software choice we have to make, if an
available FOSS piece of software answers our needs and meets the
necessary requirements (say, maturity, ability to be industrialized,
strength of the community, etc.), then we are inclined to use it. And because we develop nearly every business software we use
(there is no real market for managing French taxes :-) , it leads to make
FOSS the main part of our software asset, including the critical parts
of it (besides those for which we have made another choice beforehand).

You can understand that we change our products when there is an
opportunity to do it (very often along with a business evolution). We
have a stock/flow approach, without any "forced walk".

Along with this change, we have just signed a new contract for support
and service around every piece of FOSS we use - around 170 - (it is not
advertised for the moment, we are preparing our press releases). I think
it is one of the biggest contract of this type in the world (if not the
biggest).

As far as workstations are concerned, we have just begun to deploy some
parts of FOSS on it (or in the infrastructure around). For example, we
are now deploying SAMBA for file and print serving.

On our 80,000
client machines themselves, because we have to change the version of our
office software (Office 97), we are finishing the overall study with a
strong option for OOo, but because the stakes are not only technical
here (thinking of the users), our preference for FOSS must be
consolidated with a global evaluation of the impacts.

I hope that you are now convinced that our FOSS-friendly policy is not
just "vaporware".

PJ: Is there a copy of the policy online somewhere?

LAPEYRE: Not really. We are not used to publishing this kind of document (cultural
habit). We just attach all the required documents in our RFPs, and we
talk about it in conferences and in interviews. I think it
is largely summed-up in the JBoss slides. There is a longer description,
in French, in this document.
An English translation is in progress.

PJ: What is the plan for the future?

LAPEYRE: It's a methodology, not a plan. It's a
strategic choice which leads progressively to the deployment of FOSS in
every part of our IT system.

PJ: So, you have FOSS now running in how many areas?

LAPEYRE: Our "new" servers are all GNU/Linux based (databases - finally a
small amount of servers, both considering by number or by processing
power - run on a proprietary UNIX - we will probably switch to GNU/Linux
next year). Now, a bit less than a 4000 servers infrastructure runs on
GNU/Linux with a FOSS framework above it (Apache, JBoss...).

PJ: Can you tell us why you decided on FOSS? What advantages do you find?

LAPEYRE:
FOSS helps us to achieve our strategic goals: control of our IT system,
long-term sustainability, and independence from vendors.

As a side effect, it allows us to cut our software costs We are
trying to evaluate the software TCO implied by our policy. It's
probably a bit more than an overall factor of 10 (speaking of strict
software costs: licensing, support, corrective and basic evolutive
maintainance). It's less for critical pieces of software like
application servers (around 4), much more for others (see below).

PJ: As far as office software is concerned, what do you need it to do?

LAPEYRE: We do not use a lot of advanced features in office software. Our
employees mainly use our specialized business applications. So we have
only quite basic needs.

One benefit we have already used (on the previous version) is the
standard file format which eases the connection with business
applications and allows us to be consistent with our policy, even for
this type of computing use. But it is not the definitive argument
here.

PJ: Have you calculated how much money a migration to OpenOffice would cost? How much it might save long-term?

LAPEYRE: It will cost probably 3 to 10 man years to adapt the business
applications, and cost some (a bit less than 3) tens of millions of
euros less than switching to a recent version of Microsoft office
(licensing costs and training mainly).
This last one, once every, say, 5 years.

PJ: Whose idea was it to consider FOSS?

LAPEYRE: Mine.

PJ: And how did you come to know about FOSS?

LAPEYRE: When in college, I discovered it and quickly became convinced that
behind this philosophy, there is a strong model for mutualization of
software costs (design, development and, more important, long-term
maintainance), much better than the proprietary model. In fact, it is a
realization of knowledge propagation and sharing (better to exchange
than to hide).

PJ: What operating system do you use at home, if I may ask? If GNU/Linux, care to tell us which flavor?

LAPEYRE: Well I think you have guessed well: single boot GNU/Linux machines.
Gentoo on my main computer, Mandrake (not switched to Mandriva flavor
yet) on my laptop.

PJ: Finally, thinking of the OpenDocument Format issue in Massachusetts, does the
French government have a specific policy favoring open standards?

LAPEYRE: As I said, we (Tax Agency) have a strong policy in favor of open
standards. It is a government-wide recommendation but can not be
considered as a policy because the different agencies are not bound to
it; it is just a general trend.

PJ: Some say that governments should care more about the fact that the majority of people use Windows already instead of stressing completely open standards. If you were in a conversation with someone in a government agency other than your own and this came up, how would you respond? Why are open standards particularly important/beneficial to governmental entities?

LAPEYRE: Considering the specific nature of the missions involved, it is probably important to be able to be as independent as possible and try to make sustainable choices in the long run. And because IT systems are now the heart and the nerves of our organizations, the principle must apply to it. I hope we do agree on that.

But on the other hand, we know it is dangerous and inefficient to follow this principle too blindly and let us specify and develop highly specific, home-made systems. This leads to a failure every big organization has probably already lived.

So, we are stretched between the principle and pragmatic necessity, which, if applied without a clear understanding of the rules of this industry, can lead to concretely abandoning home keys to actors not necessarily sharing the same goals.

I think the balance is to rely on open standards; it is the only one I can imagine.

This path is not more or less difficult to take (this is our operational experience), comparing to the one considering that *today* a majority of users have one particular tool. But clearly it is the only one which is sustainable. This is emphasized by the very short cycles of our industry: the changes are sometimes very quick here (think about IBM thirty years ago, and Apple twenty years ago, and Netscape ten years ago, and, well, IE and Firefox today).

Hopefully, FOSS is a good way to run this path. But there is never any guarantee. A policy must live and be served every day.