Exploiting the Collaboration between Open Source Developers and Research

Abstract

In this paper it is argued that open source developers and research projects carrying out user requirement analysis should collaborate at a closer level. In particular, we discuss how developers could take advantage of the knowledge generated by COSPA, a research project aimed at studying and supporting the introduction of open source software in the Public Administration. COSPA focuses on office automation and desktop system software and it could thus provide developers with user requirements from one of the main "corporate" users of software. To this aim, the project has established an "observer" status, by means of which interested parties may access COSPA's results, thereby fostering collaboration and increasing dissemination of knowledge.

Full text

97
Exploiting the Collaboration between Open Source Developers and Research
Giancarlo Succi, Paolo Zuliani
Centre for Applied Software Engineering, Free University of Bolzano-Bozen
piazza Domenicani 3, 39100 Bolzano-Bozen, Italy
{giancarlo.succi, paolo.zuliani}@unibz.it
Abstract
In this paper it is argued that open source developers
and research projects carrying out user requirement
analysis should collaborate at a closer level. In
particular, we discuss how developers could take
advantage of the knowledge generated by COSPA, a
research project aimed at studying and supporting the
introduction of open source software in the Public
Administration. COSPA focuses on office automation and
desktop system software and it could thus provide
developers with user requirements from one of the main
“corporate” users of software. To this aim, the project
has established an “observer” status, by means of which
interested parties may access COSPA’s results, thereby
fostering collaboration and increasing dissemination of
knowledge.
1. Introduction
Open Source Software (OSS) has grown a lot in
popularity. Linux and the Apache web server are found in
respectively 30% and 66% of the Internet’s public
servers, according to Netcraft’s survey [1]. We thus have
some empirical evidence that OSS can work well, at least
for the server side of the client-server architecture. On the
other had, it seems that OSS is not well suited for desktop
and client applications, for which we know that Microsoft
Office is the de-facto standard. The FLOSS study [3]
showed that only 8% of business and public institutions
use some kind of OS desktop software. If we consider
office automation tools only, the percentage drops to a
mere 4%.
Why such a difference, with respect to system
software? Some authors suggest that it might be due to
the fact that developers of OS system software “knew
what they were doing and how to do it” [6]. In the case of
Linux, the group of developers headed by Torvalds had a
clear idea of the requirements of the system being
developed, plus they all shared knowledge of the Unix
structure [7]. Indeed, research in software engineering has
clearly proved the importance and impact of requirements
in software development [8]. In the case of OSS,
requirements elicitation and sharing is an even more
critical activity, as development teams are usually
geographically distributed.
Another reason for the difference in popularity
between desktop and system OSS is the fact that the
former is actually much younger, and therefore it has not
benefited from the same amount of user testing and
feedback as OS system software has had. However, it
looks nonetheless very important that desktop OSS
exploits and incorporates user requirements as soon as
possible, in order to develop products grounded on users’
expectations. At the moment it is not clear how user
needs are taken into account by OS developers.
In this paper it is argued that open source developers
and research projects carrying out user requirement
analysis should collaborate at a closer level. In particular,
we make the case for a close interaction between OSS
desktop developers and the COSPA research project.
COSPA studies the introduction of OS desktop software
in the Public Administration and could therefore provide
the OS developers community with valuable information
about the requirements of a “corporate” sector.
2. The COSPA project
The Consortium aims at introducing, analysing, and
supporting the use of Open Data Standards (ODS) and
Open Source (OS) software for personal productivity and
document management in European Public
Administrations (PA).
The Consortium will analyse and support the
introduction of ODS and OS solutions in the PA by:
xDeploying ODS and OS software solutions in
several European PAs, and benchmarking their
effectiveness through a cost/benefit analysis;
xBuilding a European, multilingual, freely-
accessible knowledge and experience base by
comparing and pooling knowledge;
xDisseminating the results and the experiences of
the study through a series of workshops at
regional and European level.
In particular, the project focuses on the OpenOffice
suite: a set of key desktop applications which includes a
word processor, a spreadsheet, a presentation manager, a
drawing program, and an equation editor [4].

98
COSPA is funded by the 6th Framework Programme
(FP6) of the European Union and will run from January
2004 to December 2005.
2.1 The Consortium
COSPA is a consortium of fifteen European partners:
xAcademia: Free University of Bolzano-Bozen
(Italy, Coordinator), Computer and Automation
Research Institute MTA-SZTAKI (Hungary),
University of Aalborg (Denmark), University of
Limerick (Ireland), University of Sheffield (UK);
xPublic Administrations: Consortium of the
Municipalities of the Province of Bolzano-Bozen
(Italy), Torokbalint City Council (Hungary),
Hanstholm Kommune (Denmark), Society of IT
Management (UK), Beaumont Hospital (Ireland),
South-West Regional Authority (Ireland), Province
of Pisa (Italy), Province of Genova (Italy);
xIndustry: Conecta srl (Italy), IBM Belgium SA
(Belgium).
The structure of the Consortium is centered on university-
PA couples. In fact, every PA is co-located with an
academic partner, in order to constantly follow the
evolution of the transition to OSS.
2.2 Workplan
The Consortium will introduce, analyse, and support the
introduction in the PA of OSS and ODS. The workplan of
the project can be divided in five main activities:
1) gathering and analysis of user requirements from
the partner PAs, in order to devise possible OS
solutions. The focus of this task is not to develop
brand new applications, but rather to identify and
combine OS software and ODS which fulfill the
PA requirements;
2) pilot projects for deploying in the partner PAs
the OS desktop solutions developed on the basis
of the previous requirement study, in order to
enable the subsequent cost/benefit analysis.
Deployment will follow a two-step strategy: in
the first step we focus on desktop applications
only (mainly OpenOffice). In the second step we
will also deal with desktop operating systems
(Linux);
3) benchmarking of the deployed OS solutions,
through a statistical and cost/benefit analysis.
Financial, economic, reliability, effort, cost, and
time aspects will be considered and integrated;
4) building a European knowledge and experience
repository by comparing and pooling knowledge
acquired in the previous phases of the project.
The knowledge base will be placed on the
Internet and made freely accessible;
5) dissemination of the results and the experiences
of the project through the knowledge base and a
series of workshops at regional and European
level, with the aim of stimulate:
othe exchange and sharing of knowledge
among the partners of the Consortium;
opublic and business’ awareness on the
project and on OS in general;
ointeraction between users and OS
developers communities.
3. Synergy with developers’ community
The activities which might be of interest to OSS
developers are mainly two:
xanalysis of requirements for OSS/ODS in the PA
(activity 1); and
xpilot projects introducing OSS in the PA
(activities 2, 3).
3.1 Requirement collection and analysis
This activity aims at finding out what OSS can be used,
why and what problems have been experienced in
adopting/managing it, what parts of an application are
actually used, what parts are too sophisticated or
inappropriate for the PA, what critical PA applications
use OSS. Various requirement gathering techniques will
be used, including questionnaires, interviews,
development of user stories, and so on.
Developers might benefit from the knowledge acquired in
this phase of the project by checking how their
applications are used in a corporate environment. Of
course, developers may also consider PA’s requirements
as a driver for further evolution of their projects.
Work in this activity might possibly include the
development of ad-hoc tools which will enable the
successful integration of OS desktop software in existing
PA environments. In particular, such tools would be
expected to address interoperability issues between legacy
databases and desktop applications. This could result in a
direct involvement of the OS developers community. For
example, a project’s partner has already tackled this issue
by developing a library for “bridging” Oracle databases
with OpenOffice. Such library is expected to be released
to the OS community.

99
3.1 Pilot projects
The objective of this activity is to run experiments on the
introduction of OSS in the partner PAs, and to benchmark
the effectiveness of the deployed OS solutions through a
statistical and cost/benefit analysis. The analysis will
consider financial, economic, reliability, effort, cost, and
time aspects. The deployed OS solutions will of course be
chosen on the basis of the previous requirement analysis.
Data on usage and satisfaction will be collected in the
partner PAs by the universities, both manually and
automatically. The automatic data collection of process
and product metrics [5][9] is carried out using the PROM
tool [10]. The data collected will form the core data
source for the analysis of the effort required in the
transition to OS.
The results of the pilot project phase would be of great
interest to developers, as they could check how their
applications and tools perform in a corporate
environment. The analysis could identify strengths and
weaknesses of OSS, bugs, security pitfalls, etc.
4. Observers
In order to increase dissemination of knowledge and to
promote best practices in Public Administrations, the
Consortium has established the role of observer. An
observer can access the project’s results and experiences
in a privileged way. It may also attend project meetings
and thus give useful advises on the implementation of the
project itself.
At the time of writing COSPA has the following
observers:
xUniversity of Alberta, Canada;
xVictoria University of Wellington, New Zealand;
xUNESCO.
New observers may join COSPA at any time. On the
project’s website [2] it is available the application form
for becoming a COSPA observer.
Other research projects involved in OS could well foresee
and equivalent observer role, in order to foster
collaboration with developer communities and spread
knowledge.
5. Conclusions
Successful OSS seems to be so far confined in the system
software area, of which Linux, Apache and Sendmail are
notable examples. Desktop OSS does not share the same
amount of popularity. We argued that this might be due to
the fact that OS developers do not have access to user
requirements: for example, Linux developers knew
exactly what they needed in the system and knew how to
do it. On the other hand, it seems that developers of
desktop OSS are not in the same situation. In this paper
we make the case for a close interaction between OSS
desktop developers and the COSPA research project.
COSPA studies the introduction of OS desktop software
in the Public Administration and could therefore provide
the OS developers community with valuable information
about the requirements of a “corporate” sector. That
might clearly help and guide the development of useful
and user-friendly desktop applications.
6. References
[1] Netcraft Survey, http://www.netcraft.com/survey/
[2] http://www.cospa-project.org
[3] Free/Libre/Open Source Software: Survey and Study.
June 2002. http://www.infonomics.nl/FLOSS/
[4] The OpenOffice project, http://www.openoffice.org
[5] W. Humprey, Introduction to the Personal Software
Process, Addison-Wesley, 1997.
[6] A. Fuggetta, “Open source software - an evaluation”,
Journal of Systems and Software, 66 (2003), 77-90.
[7] E.S. Raymond, The Cathredal & the Bazaar,
O’Reilly, 2001.
[8] R.S. Pressman, Software Engineering: A
Practitioner’s Approach, 6th ed, McGraw-Hill, 2004.
[9] N.E. Fenton and S.H. Pfleeger, Software Metrics: a
Rigorous and Practical Approach, Thomson
Computer Press, 1994.
[10]A. Sillitti, A. Janes, G. Succi, T. Vernazza,
“Collecting, Integrating and Analyzing Software
Metrics and Personal Software Process Data”,
Proceedings of EUROMICRO ’03, 336-342.