Mario Silic

Andrea Back

Information security and open source dual use security software: trust paradox

Keywords: information security, dual-use technology, open source security software, FLOSS, trust, hacker, Nmap, ohloh.net

Nmap, free open source utility for network exploration or security auditing, today counts for thirteen million lines of code representing four thousand years of programming effort 1 . Hackers can use it to conduct illegal activities, and information security professionals can use it to safeguard their network. In this dual-use context, question of trust is raised. Can we trust programmers developing open source dual use security software? Motivated by this research question, we conducted interviews among hackers and information security professionals, and explored ohloh.net database. Our results show that contributors behind open source security software (OSSS) are hackers, OSSS have important dual-use dimension, information security professionals generally trust OSSS, and large organizations will avoid adopting and using OSSS.

Introduction

"Why would thousands of top-notch software developers contribute for free to the creation of a public good?" was a question asked by [START_REF] Lerner | Some Simple Economics of Open Source[END_REF].

Ten years later, interest for open source software (OSS) development and community collaboration has been taken to another level. Some popular community collaboration web sites, such as SourceForge2 , have over three hundred thousand available projects 3 with over three million developers participating and contributing to this open source community. Moreover, we saw an uptick in the number of companies, creators of some popular closed source software, being involved in OSS. One example is IBM's contribution to Eclipse with over twelve million lines of code 4 .

As we saw the phenomenon behind OSS growing, in parallel, the corresponding research was giving more attention to producing important studies. With the rise of the OSS 'movement' [START_REF] Dibona | Open Sources. Voices from the Open Source Revolution[END_REF]Markus et al., 2000;[START_REF] O'reilly | Open source: the model for collaboration in the age of the Internet[END_REF], different studies saw OSS teams as virtual organizations [START_REF] Crowston | Open Source Software Projects as Virtual Organizations: Competency Rallying for Software Development[END_REF]Gallivan 2001; Malone and Laubacher 1998; Markus et al. 2000). As such, participants of these organizations are providing their work without financial remuneration or any special interest. Question that many researchers asked is why? Why do developers contribute (Hars and Ou 2002;Lakhani et al. 2003).

Top programmers associated to open source movement are often coming from hacking milieu, and one of the first well-known examples is Linux. Open source software project created by Linus Torvalds, software engineer and hacker, who started the project in 1991 being single contributor. Few years later, Linux project attracted several thousand programmers [START_REF] Moon | Essence of distributed work: the case of the Linux kernel[END_REF] to produce today's one of the most known open source software.

Number of open source projects (e.g. Nmap security scanner) are dealing with information security where their dual use raises trust and security concerns.

On the one side, Black hat hackers can use it to conduct illegal activities against target networks, while on the other side, information security professionals can use it to safeguard their network by discovering security issues and potential threats. In this dual-use context, question of trust is raised. Current research did not explore the link between trust and dual-use context of the OSSS, and we aim to close the existing research gap by exploring the following questions:

Who are the programmers behind open source security software?

Can we trust programmers developing open source dual use security software?

To answer these questions, we will conduct qualitative interviews with fourteen information security professionals who use Nmap OSSS.

We proceed as follows. Firstly, we explore the literature on open source software, dual-use technology and trust theory. Secondly, we present the research methodology outlining data collection and analysis. Thirdly, we discuss the findings of the study. Finally, we conclude by providing some directions for future research, implications for practice, and highlighting limitations of this study.

2

Literature review

In 1998, Bruce Perens and Eric Raymond, together with other hackers created the "open source" movement [START_REF] Perens | The Open Source Definition[END_REF]. The open source movement creations that followed produced a number of open source software with an ever increasing number of contributors. For Linus Torvalds, creator of infamous Linux kernel, the motivation behind it was that it was just "natural within the community" [START_REF] Torvalds | Interview with Linus Torvalds: what motivates free software developers? First Monday 3 (retrieved from the World Wide Web[END_REF] or it was "fun to program" [START_REF] Torvalds | Just for Fun: the Story of an Accidental Revolutionary[END_REF]). Today's evolution of open source software brought a number of applications in different areas and there is almost no closed software that does not have an equivalent in the open source milieu.

One such area relates to information security where different open source security tools appeared. Question of trust is raised as these open source security tools having dual-use behaviour could have potentially undesired consequences on the security of the information system. In the next sections we will discuss open source and information security literature to finish with trust question.

It is also important to define what "hacker" term means. Unfortunately, there is still no consensus among scholars on the final definition as two opposite definitions are today widely used. One definition speaks of an unorthodox, highly talented professional programmer having deep knowledge and understanding of computers. Another definition refers to one who obtains unauthorized, illegal, access to computers. Recently, we saw clearer separation among different hacker subcultures (White hat, Black hat, Grey hat, Blue hat, Neophyte, Script kiddie, Hacktivist, Elite hacker), but in this study, we keep generic "hacker" definition provided above where we see a hacker as a highly talented programmer that can, eventually, conduct some illegal activities.

Open source dual use and information security

Open source software (OSS) phenomena were widely studied in past years. Research mostly focused on incentives and motivations related to career concerns and peer recognition [START_REF] Lerner | Some Simple Economics of Open Source[END_REF], Hann et al. 2004), learning and enjoyment [START_REF] Lakhani | Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects[END_REF], and private reputations playing a significant role [START_REF] Lerner | The Simple Economics of Open Source[END_REF]. Virtual organizations and teams where members are working in different countries and using collaboration tools to contribute to the open source appeared as an important research area [START_REF] Hertel | Management virtueller teams auf der basis sozialpsychologischer modelle[END_REF][START_REF] Hertel | Managing distance by interdependence: goal setting, task interdependence, and team-based rewards in virtual teams[END_REF].

Intrinsic and extrinsic motivations were studied in a number of empirical studies showing why OSS developers contribute to OSS development (Hars and From the extrinsic motivation factors, one is related to the "own-use" value, which refers to "internalized extrinsic motives to create OSS for contributors' personal use" (von [START_REF] Krogh | Carrots and Rainbows: Motivation and Social Practice in Open Source Software Development[END_REF]. This own-use value is guiding developers to fix bugs and add features they need. This personal use can lead to possible modifications of the source code which could be difficult to identify in millions of lines of code. An open door for possible malicious programming code inside of the OSSS could be opened. Dual-use question and trust in this coding paradigm can be raised.

Dual-use technology (Evans and Hays, 2006) is a term referring to a technology that has two faces: one that can be used for peaceful aims and one that can be used for military aims. One example is Global Positioning System (GPS), originally used for military use, while today it is widely spread in different end user applications in end user aims. According to Eriksson (1999), any action that will try to prohibit the means of information warfare altogether or restricting their availability -are largely impossible due to the ubiquity and dual-use nature of information technology. Reppy (2012) argues that the dual-use nature of cyber technology along with its status as a quasi-public good defines both the source of the benefits of the technology and the limits to government control. OSSS represents a good example of the dual-use where a number of unanswered and controversial questions arise. Controversies have two sides: on one side, the question can be asked who are the end users of this potentially dangerous security software? Hackers? Information security professionals? On the other side: can you trust these tools if you are using them for peaceful aims?

OSSS can be used by attackers to perform illegal activities by exploiting vulnerabilities identified on the remote systems [START_REF] Cavusoglu | Efficiency of Vulnerability Disclosure Mechanisms to Disseminate Vulnerability Knowledge[END_REF][START_REF] Cavusoglu | Security Patch Management: Share the Burden or Share the Damage?[END_REF] representing the negative side of the use. The positive side would be used to proactively monitor and safeguard network.

This opens a question of trust. Can information security professionals trust software developed mostly by hackers, which at the end are using these same tools to add features they need. This "add features they need" represents an important own-use value factor where past studies showed that developers develop open source software they find useful by adding features they need [START_REF] Lakhani | How Open Source Software Works: 'Free' Userto-User Assistance[END_REF], [START_REF] Osterloh | Open Source Software Development-Just Another Case of Collective Invention?[END_REF], and Raymond (1999)).

Trust and OSS

McAllister (1995) defines trust as "the extent to which a person is confident in and willing to act on the basis of, the words, actions, and decisions of another". Later, Jarvenpaa generalized this definition to the team level (Jarvenpaa et al. 1998) and this is very valid for OSS teams as what one OSS team member provides as an output from his participation will depend on the efforts and contributions of other team members. Some previous studies showed strong link between trust and project participation decrease (Jarvenpaa and Leidner 1999) followed by important number of changes in project members structure (von Krogh et al. 2003).

For McAllister (1995), affective and cognitive parts of trust are very important. Affective trust is about emotional attachment between two sides: trustor and trust target. [START_REF] Stewart | The Impact of Ideology on Effectiveness in Open Source Software Development Teams[END_REF] pointed that affective trust can be "relevant to potential developers' psychological and emotional reasons for joining, staying with and contributing to OSS teams". On the other side, cognitive trust specifies rational assessment of the target by the trustor (McAllister, 1995) where utility and reputation motivations appear as key components which lead programmers' project participation. Gallivan (2001) explored OSS project participants (core developers, peripheral developers and message posters) identifying different types of trust occurring in the relationships between them. Figure 1. shows these three major groups and trust relationships assumed to be reciprocal. Gallivan (2001) also argues that "the OSS movement appears to rely on explicit forms of control to a much greater degree than on trust" which can be explained either by the fact that trust is probably implicit and unacknowledged in the OSS project lifecycle or it can also be that OSS projects avoid to rely on trust as it could make them vulnerable to members' illegal activities.

Research methodology

Our research used ethnographic approach and observations to answer the first research question related to programmers' profiles behind OSSS combined with qualitative interviews and to answer the question related to trust paradox qualitative method was used. In the next sections, we introduce the research setting and explain qualitative and observation approaches used in the paper.

Research setting

To investigate our research question we will use open source security tool Nmap, which is a free network security open source scanner. Nmap was created in 1998 by Gordon Lyon who is network security expert, open source programmer, writer, and a hacker. It is used for network scanning and security audits. It is one of the most popular open source security tools. It was also used in popular "The Matrix Reloaded" movie. Reason for Nmap choice is because it is very popular among information security professionals, but it has also wide usage within computer underground community. It also appeared as a good research tool already used in academia (see e.g. [START_REF] Haines | Validation of Sensor Alert Correlators[END_REF]. Nmap, being one of the most popular OSSS, is used to set the stage for all interviews and guide all discussions.

To answer the question related to developers behind OSSS, we used observations and qualitative interviews. We analyzed ohloh.net database, large online OSS com-munity with important number of open source projects, of Nmap programmers and randomly identified twenty project contributors. Using internet and Google search tools, we explored profiles of each of the twenty contributors.

Nmap security scanner

Nmap was published in 1997 in famous Phrack (www.phrack.com), an underground magazine with full source code included. Since then, with the help of the computer security community and security enthusiasts, its development continued at an ever increasing pace. Its main purpose is to discover computers and services on the target network. Nmap is an example of the dual-use tool which can be used by hackers in gaining access to unauthorized systems and performing illegal actions. Its typical usage is to discover vulnerabilities on the remote system so they can be exploited by the attacker. On the other side, information security professionals use Nmap to better understand their network, discover potential security issues, and check for eventual vulnerabilities in order to protect their network.

ohloh.net OSS community

With its Web 2.0 based application programming interface (API) [START_REF] Allen | Ohloh Web Site Api[END_REF]) it represents a large OSS community indexing open source software. With over 500,000 OSS, it connects 1.8 million contributors. Ohloh is not a forge (e.g. sourceforge.net). It does not host projects and code, but it connects to project source code repositories and provides analytics insights about project contributors, activity, demographics and code composition.

As explained in the research setting, we use ohloh.net database to identify Nmap contributors in order to explore their profiles and see if programmers belong to hacking milieu.

Data Collection and Analysis

We gathered data through two different methods. First, we conducted fourteen semi structured interviews between November and December 2012. Second, we used ohloh.net website to complete our first insights on programmers' profiles behind Nmap OSSS. Interviews lasted between 25 to 35 minutes long (on average 28 minutes), totaling 38 pages of transcribed text. Interviewees were chosen from two different categories: information security professional (six interviewees) and programmers (eight interviewees) from different organizations: security companies (36%), large firms (36%), medium size firms (14%), independent experts (14%). Some of the questions we used to conduct interviews were: "In your opinion who are programmers behind open source software?", "How do you see the relationship between trust and open source security tools?", "Did you ever use Nmap to conduct illegal activities?" and "Can programmers inject some malicious code into open source security tools?" Extracted data from ohloh.net was used to confirm insights from interviews, and after identifying randomly selected twenty contributors from Nmap (https://www.ohloh.net/p/nmap/contributors), we explored their profiles to understand if contributors were hackers. We used observations to identify which contributors described them as being hackers.

We used NVivo software program (version 10) to code the interviews and used exploratory analysis as suggested by [START_REF] Creswell | Educational research: Planning, conducting and evaluating quantitative and qualitative Research[END_REF]. Data was analyzed and we identified and highlighted different ideas to get some first insights from interviews. Next, we coded different patterns, data, phrases and words and grouped them into defined categories and themes. In this preliminary analysis, two main themes emerged that we further analyzed and discussed in the next sections.

Findings

In this section we will explore the findings related to our research questions about programmers' profiles behind OSSS and if we can trust these programmers developing OSSS.

Overall, our findings supported by interviews and data observed from ohloh.net website showed that: 1) Programmers developing open source security tools have important hacking background; 2) Open source security tools have important dual use; 3) Information security professionals generally trust open source security tools and, 4) Large organizations do not trust open source security tools.

To preserve interviewee's anonymity we will proceed as follows: to each interview we will add "INT" with corresponding number between 1 and 14 identifying the interview. For instance, "INT2" will correspond to Interview 2.

Contributors to open source security tools are hackers

Project members have usually great programming skills and are code addicted. They usually create and code for fun. Interviews and observations of ohloh.net Nmap participants revealed that contributors to open source security tools are hackers. Out of eight programmers we interviewed, seven confirmed that majority of contributors consider themselves as hackers. For one interviewee (INT 3) there is a natural link between being hacker and contributor: "…well, I think you cannot dissociate hacker subculture and the fact you want to create…hacker by its definition is someone who needs to be seen and heard…in that context, we contribute…". For another one (INT2) hackers are at the origin of the OSS movement: "..an example is Linux kernel, it all started as fun and Linux was born…from hacker's coding…this was the origin and now, I see myself as a true hacker, not like some script kiddies…I feel my contribution is visible…". Other interviewees (e.g. INT 4,INT 7,INT 6) also spoke about hacker's heavy involvement in the open source community projects as for them you cannot be programmer without being hacker. When asked about ethical hacking and more precisely if they ever conducted any black hat activities, almost all interviewees confirmed positively highlighting that it is a normal learning process, especially when you are younger and eager to learn faster. One interviewee (INT 4) said "I used to be black hat hacker but its definition is always challenging…I never stolen anything…I did not rob anyone…I wanted to learn and learn faster…today, I see things different-ly…".

After these first insights from interviewees which clearly pointed to a strong link between contributor and hacker, we analyzed data from ohloh database by exploring randomly selected contributors of Nmap open source security scanner.

By using observations, we explored their profiles and could confirm our initial insights from interviewees, showing that out of 20 contributors representing our sample, 15 declared themselves as hacker.

One example is from Nmap contributor that declared on his website: "I'm a FOSS hacker" or another one stating: "Free Software hacker and Security Enthusiast".

These facts answer our first research question by confirming that programmers behind open source security tools are hackers. However, it is also important to highlight that all interviewees clearly stated that they consider themselves as white hat hackers (hackers that do not conduct illegal activities). This leads to our second research question where knowing that programmers equal hackers we can naturally ask -can we trust them knowing that OSSS have the dual-use side? The answer to this question will be analyzed in the next sections.

Open source security tools dual use

As seen in the previous section, major contributors to OSSS are hackers. Taking into account the fact that dual-use means that hackers can use the tool to conduct illegal activities but also tools can be used for peaceful means by information security professionals, we explored this dual-use paradox by interviewing information security professionals. For one interviewee (INT 9) dual-use can be important threat when using tools like Nmap as you don't have any guarantee behind: "If I know that my 'enemy' is using the tool to attack my system -the same tool I'm using…there is a problem there…" Other interviewees (e.g. INT 10 and 12) agreed with this but also added that distinction should be made between very mature projects such as Nmap and some new ones that appeared recently and are still at early development stage: "…you can't be sure…who knows? Maybe they can modify a piece of code that will impact my network without that I see it immediately…still, I know for mature projects [Nmap] there is very clear code release process…I guess it would be difficult to change something…" (INT 10).

Information security professionals generally trust open source security tools

Despite dual-use challenge and the fact that open source security tools are developed by hackers, there is a strong direction in trusting open source security tools by information security professionals. Several interviewees highlighted that trust is somehow inevitable and that for well known OSS tools it is part of its fundaments.

For one interviewee (INT 14) trust is "mandatory…without trust any open source project could be challenged". For another one (INT 13) "trust is like a marriage -it is that invisible link you don't check proactively but you also have mechanisms to do itat the end, we trust but can also check and understand if anything is potentially harming you".

When questioned about ways and methods to check eventually the source code of the open source security tool that they are using, most information security professionals agreed that it would be very difficult as "you need to have the knowledge and also, there are millions of lines of code…it would take you an eternity to check it".

Overall, information security professionals generally trust open source security tools but they also recognized that trust cannot be easily checked due to projects' complexity and time constraints.

Large organizations do not trust open source security tools

Our finding from previous section showed that information security professionals generally trust open source security tools despite the facts that there is no easy method to check the trust relationships. However, several information security professionals confirmed that large organizations, per their policy and procedures, do not trust open source security tools and usually outlaw them by forbidding any use of these tools. One interviewee (INT 12) explained that fear is justified as in large organizations it is not easy to control "if you have 10,000 employees and you allow all of them to use some open source security software, where source code can be literally modified by any of these employees, you can potentially have important security flaw…so what they do -they simply 'outlaw' it by forbidding access to the software". Another interviewee (INT 11) challenged this by explaining that a number of governmental organizations implemented open source software and no major issues have been observed: "take the example of French government where they implemented Linux at large scale and open source kicked out closed source software…there was no big impact on information system security". Most of other interviewees had an agreement on the fact that large organizations tend not to trust open source security tools but they also highlighted that more we understand underlying mechanisms behind OSS projects and the way they are controlled, more trust will be there. One interviewee spoke of companies such as RedHat that started as open source companies but are now offering OSS software combined with some trust relationships (INT 9): "RedHat is the perfect exam-ple…today they sell 'trust' combined with free open source system -Linux…large organizations have much higher trust when they know there is a commercial organization that brings trust and guarantee…"

Discussion

In this section we will discuss our findings presented in the previous section. From different interviewees held with information security professionals and hackers, together with data from ohloh database, we found that main contributors to OSSS are hackers. Also, despite dual use side, information security professionals generally have trust in OSSS. However, large organizations avoid OSSS use in their network.

Previous studies that explored questions like 'Who are the developers' provided demographics statistics on programmers of OSS (e.g. [START_REF] Lakhani | Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects[END_REF], Hertel et al. 2033) without revealing programmers' profiles such as their hacking background. With our study we provide the answer to this question from a more holistic perspective where we confirm hackers are top contributors to OSSS.

Also, our study confirms previous study (Gallivan, 2001) that speaks of implicit and unacknowledged trust that does not necessarily appear in OSS project descriptions. [START_REF] Harrison | Managing and partnering with external stakeholders[END_REF] argued that too excessive controls could lead to 'conflict and distrust,' and this is what we saw also in our study, where for contributors, too much of control would be harmful as there seems to be a general agreement on trust level between different process stakeholders. Gallivan (2001) While some past research on trust confirmed that 'trust building' and 'control mechanisms' are two factors that should ensure confidence in another party's behaviour [START_REF] Das | Between trust and control: developing confidence in partner cooperation in alliances[END_REF], our research shows that another factor we call 'leader link' should be part of the triangle. This 'leader link' would have compliance and police role by guaranteeing trust to its partners.

Conclusion

This study tried to answer two important research questions: who are the programmers behind OSSS; and can we trust programmers developing open source dual use security software? Our study revealed some important findings: contributors behind OSSS are hackers, open source security tools have important dual-use dimension, information security professionals generally trust open source security tools and large organizations will avoid adopting an OSSS.

With the present research we close existing research gap as dual-use technology related to OSSS usage and adoption within organizations, in the context where these same tools developed by hackers did not get significant research focus in literature.

Our findings contain some practical implications for organizations to take into account, especially for large organizations, where we found a need to have 'leader link' involved in 'control' and 'trust' triangle. This leader would bring more trust to open source software and would reduce risk level.

Limitations of this study relate to the fact that we focused only on one (Nmap) OSSS which could have some influence on some insights from interviewees. Moreover, to understand programmers' profiles we relied on what programmers were saying about their background and if they considered themselves as hackers or not. More quantitative approach would be more accurate in this context.

For future research directions, it would be interesting to approach the trust topic more from black hat perspective trying to understand underlying motivations they could have when coding. Also, more in-depth study is welcomed to understand contributors' profiles, their background and trust relationships.

Fig. 1 .

 1 Fig. 1. Structural patterns of trust in open source software projects(Gallivan, 2001)

Ou 2002; Lakhani and Wolf 2005; Roberts et al. 2006; Wu et al. 2007).

  also argued that there is no need for high level trust for collaborative software development and our study further extends this direction by adding relationships between organizational size component and trust. In this relationship, large organizations will refuse OSSS use and adoption unless there is a trusted provider of open source technology (e.g. Redhat) where source code remains free and open but trust component is guaranteed by open source leader.

https://www.ohloh.net/p/nmap

http://sourceforge.net

http://sourceforge.net/about

http://dash.eclipse.org/dash/commits/web-app/commit-count-loc.php?sortBy=loc&show=


Björn Lundell
email: bjorn.lundell@his.se

Jonas Gamalielsson
email: jonas.gamalielsson@his.se

Open Standards and Open Source in Swedish schools: on Promotion of Openness and Transparency

We draw from a study aimed to establish the state of practice concerning schools' expectations and provision of IT and software applications in Swedish schools. Analysis focuses on Open Standards and Open Source Software (OSS), and considers educational lock-in. Results consider schools' expectations and provision of software and standards for digital artefacts, and show that schools expect students to use a variety of different software systems including a number of well-known OSS. The study reveals significant misconceptions concerning standards and software applications, characterises problems, and presents some recommendations for action.

Introduction

The use of IT and pedagogical software in schools has received significant attention in many countries in a desire to gain positive pedagogical effects and prepare students for society and working life (e.g. [START_REF] Balanskat | The ICT Impact Report: A review of studies of ICT impact on schools in Europe[END_REF]IES, 2009;[START_REF] Livingstone | Critical reflections on the benefits of ICT in education[END_REF]. In acknowledging mixed experiences there is also some research addressing teaching and learning experiences from Open Source Software (OSS) usage at University (e.g. German, 2005;[START_REF] Kilamo | The Community Game: Learning Open Source Development Through Participatory Exercise[END_REF][START_REF] Lundell | Learning Through Practical Involvement in the OSS Ecosystem: Experiences from a Masters Assignment[END_REF] and high school levels (e.g. [START_REF] Lin | Free/libre open source software implementations in schools: Evidence from the field and implications for the future[END_REF], but there is a lack of research on expectations and provision of open standards and OSS in schools for young students.

As part of a study aimed to establish the state of practice concerning IT usage in Swedish public sector schools with students in ages 7-19, this paper presents novel results from an analysis covering all Swedish schools for young students (ages 7-16). Specifically, results presented concern: provision of OSS applications for use by students; requirements for students related to use of different document formats (standards); requirements for students related to use of software applications for writing essays; and provision of software applications for writing essays. Our analysis provides a state of practice and addresses different implications of educational lock-in and its long-term implications.

A number of factors motivate consideration of Open Standards and OSS in an analysis of IT usage in public sector schools, and there are a number of initiatives and previous research efforts related to the study.

First, skills development in the ICT sector has been identified as important, not only for public sector procurement and standardisation, but also for a range of different stakeholder groups. We note that the European Commission reports, in its annual scoreboard, that "sufficient ICT skills" is an area of major concern as half of "European labour force does not have sufficient ICT skills to help them change or find a new job." (EC, 2012) Second, it is widely acknowledged that there are risks and different types of lockin effects associated with use of closed file formats [START_REF] Egyedi | Standard-compliant, but incompatible?![END_REF][START_REF] Ghosh | Open Standards and Interoperability Report: An Economic Basis for Open Standards[END_REF][START_REF] Lundell | Why do we need Open Standards?[END_REF]. One such concern is educational lock-in which may occur in situations when a company sponsors provision of IT and training of teachers [START_REF] Kirk | Microsoft to fund IT training in developing world, IT worldcanada.com[END_REF], and with such practices there may be significant long-term effects on IT practices.

Third, previous research show that adoption of IT and software systems in the public sector sometimes, perhaps unintentionally, inhibit a fair and competitive market based on important principles of transparency, non-discrimination and equal treatment (e.g. Lundell, 2011). Such practices, with widespread adoption and use of closed standards in the IT area, may significantly reinforce competence development related to certain proprietary technology. Over time, this may contribute to a lack of competence in certain technology areas, with associated risks for lack of skills or an unbalanced pool of skills in the market.

Fourth, despite established principles in European and national law aimed to stimulate a fair and competitive market for public procurement (e.g. Directives 2004/17/EC and 2004/18/EC) it is clear that widespread misconceptions concerning Open Standards and OSS (e.g. FLOSS, 2002) reinforces bad procurement practices in the public sector (e.g. Lundell, 2011).

Fifth, despite a number of national policies and strategies (e.g. UK, 2012;Regeringen, 2009) aimed to achieve a number of desirable effects for the public sector by promotion and use of Open Standards, such as compatibility and interoperability issues [START_REF] Ghosh | Open Standards and Interoperability Report: An Economic Basis for Open Standards[END_REF], there are also other potential benefits, such as strengthening democracy, which can be achieved by promotion of Open Standards. For example, it has been claimed that standards "are also strongly relevant to democracy to the extent they affect the conditions under which citizens engage in the democratic process." [START_REF] Denardis | Open Documents and Democracy: a Political basis for Open Document Standards[END_REF] The rest of this paper is organised as follows. First, we provide a background on the situation in Sweden (2) followed by our research approach (3). Thereafter we make some observations concerning the responsiveness to the study (4), followed by a presentation of the results (5, 6 and 7) of the study. Finally, we discuss results and present conclusions (8).

Background

Openness and transparency have been recurring themes in public speeches from representatives for the Swedish government for a number of years. For example, in its [START_REF] Egyedi | Standard-compliant, but incompatible?![END_REF]IT bill (2004/05:175)/05:175), the Swedish government declared that the use of Open Standards and OSS should be promoted (EU, 2005). More recently, in a public speech during the Swedish EU presidency, the responsible minister presented the Swedish position on the importance of openness in the public sector: "It is my belief that we need a clear definition of openness in the European Interoperability Framework and that the definition of open standards and open source software as defined by the European Interoperability Framework version one has served us well so far. The use of open standards and open source solutions decreases the public sector's reliance on specific vendors and platforms and it increases European competitiveness as well as the transparency" [START_REF] Odell | Redovisning av uppdrag om uppföljning av IT-användning och IT-kompetens i förskola, skola och vuxenutbildning[END_REF] From a policy perspective, the concept of Open Standard has been clarified in the Swedish context through inclusion of a clear definition of openness, adopted from the EIF version one (EU, 2004), in the first report from the Swedish e-Governance initiative (SOU, 2009). With the clarification of this fundamental concept, important principles underlying the idea of an Open Standard have been established.

First, use of an Open Standard ensures that data can be interpreted independently of the tools used for its generation, something which is particularly important in an educational context as students cannot be expected to buy (or pay for renting) specific proprietary technology when studying in Swedish public schools. In fact, the The Swedish Schools Inspectorate examines an important principle for education in Sweden, namely that "education shall be free of charge" (Skolinspektionen, 2011), and clarifies that costs for calculators used in public schools and costs related to use and insurances of laptops provided to students for use at school and at home cannot be charged for. However, a minor fee (approx. €10) can be accepted on an occasional basis, such as for costs related to a day with outdoor activities.

Second, when a standard is published, its technical specification contains sufficiently detailed information, and it is provided under royalty free conditions (FRAND, 2012) it can be used as a basis for implementation in software systems under different proprietary licenses and different OSS licenses. Such a standard, which adheres to the definition of an Open Standard (SOU, 2009), fulfils fundamental prerequisites of non-discrimination and equal treatment promoted in national policies and directives for public procurement. With Open Standards as a basis for procurement of IT, software systems, and educational (digital) learning objects (i.e. educational material, documents, and data which are maintained in Open Standards) in an educational context, there will be reduced risks for discrimination against students. Such a policy and practice is well in line with a statement from Kroes, then European Commissioner for Competition Policy, in a public speech: "No citizen or company should be forced or encouraged to use a particular company's technology to access government information." [START_REF] Kroes | Being Open About Standards[END_REF] In the context of the Digital Agenda for Sweden, the Swedish minister responsible for IT has addressed the topic IT usage in schools and education (Näringsdepartementet, 2011). In a public speech, the same minister commented that many schools provide IT equipment to their students, but also stressed: "I would argue that for schools there is much room for improvement in terms of IT use." (Hatt, 2012a) Further, in another public speech on the topic "Every single child has the right to modern IT in schools", the same minister amplified the importance of openness for promotion of democracy in her conclusion: "With openness and transparency, we can strengthen democracy, promote innovation and new jobs." (Hatt, 2012b) In light of this, we note that current practice is far from this vision as the Swedish National Agency for Education is acting just the opposite of these recommendations and the view of the European Commissioner for Competition Policy when they publish information in closed file formats on their website (Skolverket, 2011), and thereby promote use of proprietary licensed software and closed formats.

Recent statistics reported by the Swedish National Agency for Education show that computers are most commonly used when teaching the subject Swedish (as a native language) with students aged 13 to 15 years old (Skolverket, 2010). For this group of students, results for computer usage when teaching Swedish show that 17% of the students "never" and 32% "rarely" use computers, which imply that almost half (49%) of Swedish students rarely or never use computers. It should be noted that writing essays and reports are rather common activities in primary schools, and in light of these results, statements concerning room for improvements in terms of use of IT by the Swedish IT-minister may, perhaps, not be perceived as surprising. Further, according to the chair for the educational commission at Swedish Association of Local Authorities and Regions, most students learn IT at home with associated risks for a digital divide and that there is an urgent need for an IT-strategy for Swedish schools and IT competence in schools (SKL, 2011).

Research approach

Our goal is to establish the state of practice concerning IT usage in Swedish public sector schools, and to address this a study was designed in order to collect responses from all public sector schools in Sweden through data collection via each municipality.

With a tradition of openness and transparency in its Swedish public sector, there are high expectations and a strict policy on governmental responses to questions and requests for public documents: it is expected that all questions are responded to, and requested public documents must be provided.

The study included 12 questions and 4 requests for public documents. The same questions and requests for public documents are used for all schools, and specifically address a number of aspects concerning students' IT usage.

In this paper, we focus on public sector schools for young students (in ages 7-16) and present our analysis of responses related to the following questions:

-Which OSS and IT equipment (i.e. stationary computers, laptops, tablet computers, etc.) are provided to students in schools in your municipality for use in school work? (see section 5) -Which document formats (and versions of these) are students in schools in your municipality expected to manage in order to be able to read, write and edit documents (as well as to be able to exchange these documents electronically with teachers and other students) to be able to engage in school work? (see subsection 6.1) -Which software (and versions of these) are students in schools in your municipality expected to have access to and regularly use in order to be able to read, write and edit documents (i.e. essays, instructions and other texts that students should prepare and communicate with teachers and other students) to be able to engage in school work? (see subsection 6.2) -Which software (and versions of these) are students in schools in your municipality provided access to on stationary computers and on portable computers (i.e. laptops or tablet computers etc.) for use in order to be able to read, write and edit documents (i.e. essays, instructions and other texts that students should prepare and communicate with teachers and other students) to be able to engage in school work? (see section 7)

At time for the design of the study, we had informal dialogues with practitioners in the domain, including potential respondents in the study, in order to scrutinise our design and planned actions for data collection. From this we obtained a number of useful insights about the domain which was accounted for in our detailed planning of the study, and in particular concerning detailed planning of the data collection process. As part of this process initial results have been presented and discussed with practitioners and policy makers in several national and EU contexts (e.g. [START_REF] Lundell | IT Usage in Swedish Primary Schools: Observations on Innovation and Educational Lock-In[END_REF].

When the data collection was initiated (January 2012), Sweden had 9,5 million citizens (in its 290 municipalities) of which 889000 were students (in ages 7-16) in one of the 4616 public sector schools. For data collection, we sent an email containing the questions and requests for documents in plain text to each municipality (290 in all), with follow-up reminders sent over a twelve month period. The text in the email was supplemented with two attachments (one ODF and one PDF/A-1b file) comprising data collection for the study. The instructions clarify, for reasons of privacy, that respondents can reply via email or by sending a letter containing printed documents.

The study resulted in both quantitative and qualitative data. Quantitative data was analysed to gauge the overall position with respect to informed decision making about students' IT usage in public sector schools. The text of responses, together with that of supplied documents, was analysed qualitatively, to give some insight into the real state of practice.

Responsiveness to the study

The request email was sent to the registered address of each municipality. A municipality is required to respond promptly at least with an acknowledgement (usually an acknowledgement is interpreted to mean within 24 hours). If no response was received within four working weeks, then a reminder was sent. This continued with, for each reminder, increased emphasis. After the fourth reminder the email also included a clear request for an acknowledgement of receipt of the email, and after more than twelve months of elapsed time since the initial request (and in one case after thirteen reminders) all municipalities had acknowledged receipt of the email. We note that the fourth reminder resulted in a significant effect and we received many acknowledgements of receipt of the email during a short time-window (slightly more than 4 months after the initial request).

Figure 1 presents an overview of the data collection process (for the 370 days following the initial request). The dashed line shows accumulated proportion of acknowledged receipt of the email over time and the solid line shows the proportion of respondents that have responded to questions in the data collection over time. Prior to initiating the data collection we anticipated a complex process when collecting data for schools in larger municipalities, but it came as somewhat of a positive surprise to us when we observed that it was not more difficult in comparison to data collection from schools in smaller municipalities.

It should be noted that the email sent for data collection included requests for public documents that they are required by law to respond to (at least with a notification of that requested documents do not exist, or that documents cannot be provided according to a decision in the organisation, e.g. for reasons of national security or privacy).

Initially, some municipalities seem to have ignored the email despite the fact that it contains a request for public documents, whereas yet others explicitly declined to respond. Several provided partial responses, which are probed further. On average, it took 76 days and 2.7 reminders since the initial request before a municipality acknowledged receipt of the email, and even longer before receiving a survey response (at time of writing more than 1800 reminders have been sent concerning the questions in the survey). Many of these reminders contain clarifications and explanations, and a number of telephone conversations have also been used for clarifications.

Some municipalities explicitly declined to respond and others provided partial responses, which were probed further. Some delays were evidently caused by confusion over who should respond, no individual feeling able to respond to all requests. This meant that the email was circulated within and between organisations (as there are also different types of collaborations between schools and municipalities). In many cases this resulted in partial answers being given from different parts of an organisation and from the data collection process it is evident that several individuals were involved. Many respondents expressed reluctance to provide responses and all requested documents, and in some cases even some frustration. In a few cases, respondents (and some non-respondents) even explicitly stated that they have no interest in contributing to the study and no interest to provide requested documents. However, the vast majority of respondents have expressed significant interest in the study and amongst those that have responded several have expressed that they look forward to its results.

The initial request was responded to by 10% of the respondents. A reminder elicited further responses, resulting in a 19% response rate and after a second reminder, 27% had responded. At time of writing, the response rate for the study is 73%. In addition, some respondents provided requested documents, but did not respond to the questions (6% in total) which implies that we obtained valuable information from 79% of all respondents. On average, it took 138 days and 6.4 reminders since the initial request before receiving these responses.

Use of Open Source software in schools

Results show that schools typically use several hundreds of software applications and many respondents provided detailed lists of precisely which software they use as requested. However, a number of respondents gave explicit reference to specific software packages (provided by specific suppliers), whereas others explicitly mentioned a handful of software applications with a note that they also use other pedagogical software. From the information provided in detailed lists of software applications used in schools, we find that many schools use a mix of proprietary and OSS licensed software.

From analysis of responses that explicitly mention the OSS used, we find that a number of different OSS applications are provided to students. Table 1 presents an overview of OSS solutions provided by schools which have been mentioned by more than a single respondent. As many respondents did not provide information extent to which OSS is used in schools may be (somewhat) underestimated. However, the number of respondents that explicitly commented on their lack of control for which software they use came as something of a surprise to us.

Expectations on use of document formats and software applications for writing essays

As writing essays, reports and other texts is one of the most common activities in primary schools, this section presents results concerning what a school expects from its students concerning use of specific document formats and specific software for writing, editing, and exchanging documents with teachers and other students.

Expectations on use of document formats for writing essays

From analysis of responses related to what schools expect from their students concerning use of specific document formats six broad categories emerged that could be meaningfully interpreted. These six categories represented 93% of all responses concerning what a school expects from its students and below we comment on our analysis of these. For the remaining 7%, it was not possible to give a meaningful interpretation due to lack of information in each response. We make a number of observations from our analysis of responses in the identified six categories.

The first category (39%) includes responses for which it is evident that respondents understand what a document format actually is. For most of the responses in this category commonly used document formats are identified (see Table 2 for an overview of the most common formats). However, there were also some respondents which included file formats primarily aimed at other types of files (in addition to document formats) in their response. File formats primarily aimed at other types of files mentioned in responses include file formats for images (e.g. bmp, jpg, png and gif), video/multimedia (e.g. mpeg4, wmv, avi), and audio (e.g. wav). Several responses include expectations for use of several document formats. From the second category of responses (29%), it clear that many of those responding do not understand the concept of document format. Most respondents in this category mention software applications which schools expect students to use for writing documents. Responses include: "MS Office", "Word", "Office", "Open Office", "iWork", "Software which is compatible with MS Office", "Office Pro Plus 2003-2010", "MS Office 2010", "Microsoft Office 2007", "Word 2003", "Office 2003". There are also some responses in this category which included other types of software, file formats (not primarily aimed at editing text), and platforms, such as: "Fronter", "outlook.com", "word and pdf", and "Word for XP". A few responses in this category were more elaborated. For example, one respondent seems to equate "Word" with a document format: "In general it is word and PDF that we expect students to be able to read" and another responded with a policy for its municipality concerning document formats as follows: "The recommended document format in our municipality is Office 2007". As public schools are governed by municipalities, this policy (implicitly) also applies for all schools in this municipality. Others seem to be more aware of their unfamiliarity with the concept of document format. For example, one respondent commented on the lack of understanding and that "most schools use office software. I do not know what the student understands, nor how they have learnt the software. The educators in X-municipality may register for PIM but there is no explicit requirement for the level they are expected to achieve. Today this is up to each headmaster to decide."

The third category (20%) contains responses which refer to specific software with an explicit account for associated format without being specific about which document format they expect students to use (i.e. selection of software implies format). Hence, for these respondents it is clear that consideration of which software the school should expect students to use precedes any decisions on document formats. Several responses in this category were vague and implicitly referred to formats provided by a specific vendor or product. For example, responses in this category include: "Microsoft's", "The formats in Office 2007", "The document formats which are supported by Apple", "The formats supported in Open Office", and "All formats which can be generated by our software".

The fourth category (5%) includes a number of responses which made explicit that the school does not expect students to be able to use specific document formats. Several responses clarified that it does not matter, as illustrated by these responses: "Nothing is expected", "There are no documented guidelines or requirements", and "We currently do not have any such requirements". Some responses were more elaborated and the responses show some awareness of the challenges associated with different versions of document formats and different versions of software for those formats: "So far it has sometimes been difficult for primary school students and teachers because there are several versions of word processors and suppliers. The primary school currently strives for the iPad and we do not yet know what this will lead to". Some respondents did not explicitly respond to the specific question concerning document formats, but it was still possible to identify expectations concerning use of document formats. This comprises the fifth category (5%) of responses. From analysis of responses to other questions in the data collection (most notably those related to expectations concerning use of software) we included into this category responses which were explicit about expectations concerning software use. Hence, responses in this category (implicitly) clarified expectations and the responses were similar to those responses that were categorised into the third category (which explicitly expressed expectation regarding document formats). The remaining responses were categorised into the sixth category (2%) and included a few responses in which respondents explicitly express uncertainty.

From these responses, it is apparent that there is confusion concerning what a document format actually is and how choice of such formats may affect users. This includes awareness of the potential impact on students when schools express, explicit or implicit, expectations concerning such formats. In particular, there is considerable confusion amongst respondents concerning the difference between a document format and software systems aimed for reading, writing, and editing of documents.

Expectations on use of software for writing essays

Related to the issue of document formats, the study also investigates what a school expects from its students concerning use of specific software applications (and software provided as a cloud service) for writing and managing documents.

From analysis of responses it is clear that a majority of schools expect their students to use (one or several) specific software applications (see Table 3). Some respondents included details concerning which specific version of the software they expect their students to use, whereas others provided no such information. Table 3 does not distinguish between responses that make a difference between "Microsoft Word" and "Microsoft Office" (with or without specific version number), and all such responses are summarised into one row. Similarly, we do not distinguish between "iWork", "Pages", and "Apple" (these responses are merged into one row, "iWork" in Table 3). Amongst respondents who included expectations concerning specific version, we note that Microsoft 2010[START_REF] Egyedi | Standard-compliant, but incompatible?![END_REF], and 2003dominate. However, responses that included version also mentioned 97, 2000[START_REF] Egyedi | Standard-compliant, but incompatible?![END_REF]. For "OpenOffice", most respondents did not mention a version, but amongst those that did, versions mentioned ranged from "OpenOffice 2.0" to "OpenOffice 3.3". For "LibreOffice", only one response mentioned a specific version (3.4.4).

To gain some additional insights concerning the relationship between expectations for document formats and software we specifically analysed the second category in subsection 6.1 (i.e. the respondents that do not seem to understand the concept of document format) and investigated their expectations for software. From this, we find that 93% of those that do not seem to understand what a document format is expect students to use a proprietary licensed software (e.g. Microsoft Office and iWork), whereas the remaining 7% expect their students to use a software which is licensed under an OSS license (e.g. OpenOffice and LibreOffice) that can be obtained without a license fee.

To further analyse the relationship between expectations for document formats and software we also analysed the first category in subsection 6.1 (i.e. respondents that seem to understand the concept of document format) and investigated their expectation for software. From this, we find that only 3% of respondents expect their students to only use document formats for which there are software applications provided as OSS.

Provision of software applications for writing essays

From our analysis of responses we find that a clear majority of schools provide (one or several) specific proprietary software applications to their students (see Table 4). Some respondents included details concerning which specific version of the software they provide to their students, whereas others provided no such information. Some responses include several software applications (and software provided as a service) that they provide to their students. Table 4 does not distinguish between responses that make a difference between "Microsoft Word" and "Microsoft Office" (with or without specific version number), and all such responses are summarised into one row. Amongst respondents who included expectations concerning specific version, we note that Microsoft 2010[START_REF] Egyedi | Standard-compliant, but incompatible?![END_REF], and 2003dominate. However, responses included version also mentioned 97, 2000[START_REF] Egyedi | Standard-compliant, but incompatible?![END_REF]. For "OpenOffice", most respondents did not mention a specific version, but amongst those that did, versions mentioned ranged from "OpenOffice 2.0" to "OpenOffice 3.3". For "LibreOffice", only one response mentioned a specific version (3.4.4).

We analysed the correspondence between responses concerning expectations of file formats and software (as reported in subsections 6.1 and 6.2) with responses concerning the provision (as reported in this section) of software to students for writing and managing documents, and make a number of observations. First, perhaps unsurprisingly, we find that in almost all cases when a school expects its students to use a specific software the school also provides that specific software to its students. However, responses show that some schools expect their students to use specific (proprietary) solutions which the school does not provide to its students. Secondly, there are also schools which expect their students to use specific OSS solutions that they do not provide to their students. It should be noted that in such cases, it is critical that students are allowed and able to adopt and install the specific OSS (that the school expects them to use), either on their own equipment or on stationary computers or laptops provided by the school.

Discussion and Conclusions

In a public speech in the Swedish context, the Swedish minister responsible for IT stated (Hatt, 2012a):

"The objective of the Digital Agenda for Sweden is that Sweden will be the best in the world at using digitization opportunities. It is a goal that not only means that we should follow the trend, but we really should be at the forefront of it."

In light of this ambition, it seems clear from the results of the study that current practice is far from this ambition and that Swedish schools face significant challenges concerning IT education and usage.

Concerning use of document formats and software applications, our results show that many schools expect their students to use document formats that are based on a technical specification which "is not complete" and "include references to proprietary technology and brand names of specific products" (EU, 2012). This, in light of presented results, imply that many students are expected to use proprietary software provided from a single vendor. Such expectations from schools are certainly not in line with the regulations from Swedish authorities concerning the requirement that education shall be free of charge for students in Swedish public schools. Further, as such expectations contribute to educational lock-in and clearly are in conflict with national goals concerning use of Open Standards in the Swedish public sector, they also inhibit innovation in society as a whole.

Although our results show that OSS is used to some extent, it is evident that current practice, in the majority of schools, promotes use of software based on proprietary technologies, closed document formats, and a closed mindset for IT usage amongst students. From an educational perspective, a more strategy would be to utilise solutions based on Open Standards for which there exist OSS implementations.

In the short term, it appears that an effective recommendation for schools based on the results would be to always undertake evaluations of document formats prior to decisions on software applications, and in so doing always consider interoperability and lock-in scenarios.

We acknowledge an inherent uncertainty in our results concerning IT usage in Swedish public sector schools for young students caused by lack of responses from 27% of respondents. Therefore, we undertook a further analysis of different data sources made available by those that did not respond to questions in order to reveal some insights concerning use of specific software in this group. Data sources for this analysis include information provided in response to the initial request for public documents by those that did not respond to questions (in total 6% of all respondents), other information provided via respondents' web sites, and via direct dialogue. This information provided insights into specific instructions for how to use specific software, which software has been adopted and deployed to students, and other statements indicating various decisions concerning use of specific software in the educational environment. From this we conclude that there are strong indications that the proportion of respondents providing proprietary software applications is somewhat underestimated. In addition, we found that this analysis only identified software already explicitly mentioned in responses (and explicitly mentioned in table 4). Further, this analysis also identified an acknowledgement of inherent problems related to use of different file formats, and we also observed explicitly stated expectations concerning use of specific file formats.

To conclude, results from the study suggest that there is significant scope for improvements in the Swedish formal education concerning IT usage. In particular, there are many misconceptions and significant unawareness amongst respondents. Many schools seem unaware of the potential with Open Standards and OSS as enablers for innovative use of IT that does not discriminate any student.

Fig. 1 .

 1 Fig. 1. Overview of the data collection process

Table 2 .

 2 Expectations concerning document formats for respondents in the first category

	Expected document	Percentage of
	formats	respondents
	doc	87
	pdf	55
	docx	51
	odt	29
	pages	5
	rtf	4

Table 3 .

 3 Expectations concerning use of software applications for writing documents

	Expected software applications	Percentage of respondents
	Microsoft Office	77
	OpenOffice	18
	LibreOffice	9
	iWork	6
	Google docs	4
	Others (responses include MS	2
	Live, Works etc).

Table 4 .

 4 Provided software applications for writing essays and other documents

	Provided software applications	Percentage of respondents
	Microsoft Office	81
	OpenOffice	20
	LibreOffice	9
	iWork	5
	Google docs	3
	Others (responses include MS Live, Works etc).	2

concerning specific version of the software provided, our overview presents the license used for each software at time of writing. www.7-zip.org Amongst other OSS mentioned, responses for use in schools include: CMS and blogging tools (e.g. Wordpress), development environments and platforms (e.g. Eclipse, Netbeans), calculator applications (e.g. KCalc), pedagogical software for astronomy teaching (e.g. KStars), text editors (e.g. NotepadPlusPlus), personal information management tools (e.g. Evolution), text-based web browsers (e.g. Lynx), remote desktop servers (e.g. ThinLinc), libraries and programs for handling multimedia data (e.g. FFmpeg), Linux distributions (e.g. Ubuntu), and e-mail server and web clients (e.g. Zimbra), and administrative software for administration and dialogue between students, their parents and the school (e.g. Unikum).

In acknowledging that not all respondents explicitly mentioned all software they use we note that three OSS projects are the most widely adopted: Audacity, Firefox, and OpenOffice. Further, five additional OSS projects also seem widely used as there are more than a dozen of respondents reporting use of one of these: Amis, Freemind, Gimp, LibreOffice, and VLC.

From our analysis of responses, we note that several respondents lack (or at least report to us in their response that they lack) documentation of which software they use. From a licensing perspective, such lack of documentation is obviously not an issue, whereas for proprietary licensed software it is important to keep track of precisely which software is being used. For this reason, one may conjecture that the


Jonas Gamalielsson
email: jonas.gamalielsson@his.se

Björn Lundell
email: bjorn.lundell@his.se

Alexander Grahn
email: alexander.grahn@his.se

Stefan Andersson
email: stefan.andersson@redbridge.se

Jonas Feist
email: jfeist@redbridge.se

Tomas Gustavsson

Henrik Strindberg
email: henrik.strindberg@findwise.com

Towards a reference model on how to utilise Open Standards in Open Source projects: experiences based on Drupal

It is known that standards implemented in Open Source software (OSS) can promote a competitive market, reduce the risk for lock-in and improve interoperability, whilst there is limited knowledge concerning the relationship between standards and their implementations in OSS. In this paper we report from an ongoing case study conducted in the context of the ORIOS (Open Source software Reference Implementations of Open Standards) project in which influences between OSS communities and software standard communities are investigated. The study focuses on the Drupal project and three of its implemented standards (RDFa, CMIS, and OpenID).

Introduction

Many organisations are currently restricted in their choice of software because of restrictions imposed by existing systems. There is a lack of interoperability and a risk of different types of lock-in. The use of Open Standards and OSS implementations of standards can reduce the risk of lock-in, improve interoperability and stimulate innovation [START_REF] Lundell | How can Open Standards be effectively implemented in Open Source? Challenges and the ORIOS project[END_REF][START_REF] Friedrich | Making innovation happen: The role of standards and openness in an innovationfriendly ecosystem[END_REF]. Further, it is widely acknowledged that there are challenges in implementing Open Standards (FRAND, 2012) and that standardisation has significant impact in the IT market and is subject to review within the digital agenda in the EU (Europe Economics, 2012). Open Standards, especially when implemented in OSS, have the potential to address challenges such as promoting a healthy and competitive market, reducing the risk for organisations of being technologically locked-in, and creating a basis for interoperability, and offering a basis for long-term access and reuse of digital assets [START_REF] Lundell | How can Open Standards be effectively implemented in Open Source? Challenges and the ORIOS project[END_REF]. Open standards are especially important for small companies, something which is acknowledged in national IT policies (Gov.uk, 2012).

In this paper we consider influences between OSS communities and software standard communities. In so doing, we report on an investigation of how communities involved in reporting and handling issues related to the implementation of a standard influence and are influenced by communities involved in the development and maintenance of the standard. We focus on OSS communities for the Drupal implementations of the three software standards RDFa, OpenID and CMIS, and associated software standard communities.

Towards a reference model for Open Standards and OSS

OSS implementations of software standards have made significant contributions to the establishment of standards [START_REF] Behlendorf | How Open Source Can Still Save the World[END_REF]. Even if a number of standards in the software domain have been adopted and implemented in OSS projects, there is limited knowledge concerning the relationship between standards and their implementations in OSS (FRAND, 2012). Such knowledge is of particular relevance to small companies. For this reason this relationship with associated issues are explored in an ongoing collaborative research project [START_REF] Lundell | How can Open Standards be effectively implemented in Open Source? Challenges and the ORIOS project[END_REF]. In this research project, we seek to establish a reference model to aid concrete actions for any stakeholder wishing to utilise software standards in an Open Source context. In order to achieve this, we are conducting a number of studies on specific software standards and specific OSS projects.

We draw from an ongoing case study in which we specifically explore the Drupal OSS project and its relationship with three specific standards governed by three different standardisation organisations. By choosing RDFa (a W3C standard), CMIS (an OASIS standard), and OpenID (a foundation governed standard), our study includes investigation of standards provided under different governance models. Further, it was of interest to explore both core and add-on implementations of standards. RDFa and OpenID are both core implementations in Drupal, whereas CMIS is implemented as an add-on. The selected OSS project and the three specific standards represent specific examples of projects which are of interest to the companies involved in the ORIOS (Open Source software Reference Implementations of Open Standards) project. These exemplify core technologies used in the daily business and constitute a relevant set for investigation for all stakeholders involved in the project. Further, the relationship between standards and their implementation is complex (FRAND, 2012), which potentially has significant impact for small companies wishing to use Open Source provided under a copyleft license [START_REF] Bain | Scene Setting -Licensing models for standards and for open source[END_REF]. From this we choose to investigate an OSS project (Drupal) provided under a strong copyleft license.

As part of our approach we first establish a characterisation of the three selected standards and the Drupal project by undertaking an analysis of release history, commits to the source code repository and contributing committers over time. Second, we investigate influences between OSS communities and software standard communities with respect to participation. In so doing, we focus on the three chosen standards using the issue tracking system of Drupal. Third, for RDFa we investigate influences between OSS communities and software standard communities with respect to common issues. The data for the Drupal project was collected from the Drupal website (Drupal.org, 2012), where all issues for Drupal core, RDFa, CMIS and OpenID were used in the analysis. Issue data for all releases of Drupal version 7 was used (including development versions), from the date of the first issue posting until 30 Nov. 2012. The issue data was collected and thereafter parsed and analysed using custom made scripts. More specifically, the timestamp and contributor ID for all issue postings was recorded. In addition, a search for issues in issue tracker, forums and mailing lists was performed by means of manual inspection of content in order to identify issues common to both the Drupal RDFa community and the W3C RDFa community.

Results

RDFa is a standard model for interchange of data on the web by embedding of metadata within web documents (W3.org, 2012), and is governed by W3C since 2008. CMIS (Content Management Interoperability Services) is a standard that defines a layer of abstraction for the control of various document management systems and repositories by the use of web based protocols (Oasis-open.org, 2010) and is governed by OASIS since 2010. The OpenID standard for decentralised authentication provides means for proving that an end user is in control of an identifier (Openid.net, 2007) and it is governed by the OpenID Foundation since 2007. All standards investigated in this paper are licensed under royalty-free conditions1 which allow implementation in GPL licensed OSS projects.

Drupal is a content management platform written mainly in PHP, which is provided under the GPL Open Source license (Drupal.org, 2012). It can be used to create "broschureware" style web sites as well as web sites involving blogs, forums and other forms of collaborative environments. There are more than 600000 users and developers in the Drupal communities. Further, there have been 146 committers who have contributed a total of 88091 commits over 828174 lines of code (Ohloh.net, 2012) to Drupal core. The first commit to Drupal core was contributed in May 2000, and the most recent commit in Dec. 2012. There have been seven first level Drupal releases in the interval Jan. 2001 through Jan. 2011Jan. (v1-3 in 2001Jan. , v4 in 2002Jan. , v5 in 2007Jan. , v6 in 2008Jan. , and v7 in 2011)). In fact, there have been 113 releases (evenly distributed in time) in total since v1.0 including second and third level releases. The latest release (v7.17) was made available on 7 Nov. 2012.

Figure 1 (top diagram) shows number of issue postings (including issue creation and commenting) for Drupal core. Number of contributors over time for Drupal core is shown in the middle diagram in the same figure. An observation is that issues relevant for version 7 of Drupal are raised more than 9 years before the first stable release in Jan. 2011. Further, it is evident that significantly elevated activity precedes the first stable release of Drupal 7, whereafter the activity drops considerably. It can also be noted that there is an increasing trend in terms of number of monthly contributors until the time of the stable release after which the number of contributors stabilizes. Figure 1 (bottom diagram) illustrates number of issue postings over time for the parts of Drupal implementing the RDFa standard (green), the CMIS standard (red) and the OpenID standard (blue). Overall, it can be noted that the issue activity level is more modest for the implementations of the standards when comparing with all parts of the core. We also note that issue postings for OpenID go back to Jul. 2007, whereas issue activity for RDFa and CMIS started considerably later (Oct. 2009 andMar. 2010, respectively). The Venn diagram in Figure 2 provides an overview of the contributions to the Drupal issue tracker. The total number of contributors and postings for RDFa (green circle), CMIS (red circle) and OpenID (blue circle), is shown. Further, the figure illustrates the number of contributors who have contributed to the issue tracker for the seven possible (and mutually exclusive) combinations of the three standard implementations, and also shows (in brackets) the proportion of all postings for the different standards that the contributors in the different project combinations have contributed. Proportions for RDFa, CMIS and OpenID are coloured in green, red, and blue, respectively. It can be observed that the 17 contributors who have been been active in the issue tracker for both RDFa and OpenID have contributed the majority of the postings for RDFa (81,3%) and 30,1% of the postings for OpenID. Hence, there is significant influence between the RDFa and OpenID communities that contribute to the issue tracker. Further, there is very limited influence between CMIS and the other two standards since 98,2% of all CMIS postings are provided by 45 contributors who are only active in CMIS. For the rest of this section we focus on the RDFa standard. When comparing the set of Drupal RDFa issue contributors with the set of participants in the meetings of the RDFa standard working group, there is one individual who is active in both communities. This person has contributed 199 (36%) of all 552 RDFa issue postings and has participated in 33 (31%) of all 104 RDFa working group meetings in the time period Feb. 2010 to Nov. 2012.

Further, RDFa related issues have been identified which appear in both the issue tracker and in the context of the W3C community involved in RDFa standardisation. One example is an issue on how some RDFa content is interpreted in Drupal (and other RDFa parsers) due to the use of XML literals that was raised in Jan. 2010 on the issue tracker. Deep processing of XML literals would be required to solve the problem, something which was currently not supported in the specification of RDFa. The same issue was subsequently acknowledged and discussed at a W3C meeting in Oct. 2010. Another example is an issue from Jan. 2010 concerning the validity of Drupal generated RDFa code, where one RDF validator reports invalid Drupal code for a specific attribute whereas another validator does not (i.e. two different conformance tests produce different results). This issue was afterwards discussed on the public RDFa mailing list at W3C in Apr. 2010. Further, the issue of support for Drupal specific needs and work practices concerning RDFa has been a recurring topic during several W3C meetings.

Discussion and Conclusion

Based on our experiences from participation in standardisation processes in different contexts (including OASIS), we acknowledge the inherent complexity of standardisation. It is not uncommon that development of standards is initially driven by needs stemming from specific usage scenarios involving stakeholders in different organisations. Therefore, standards are often subject to subsequent refinement, adaptation, and generalisation to fit new needs and usage scenarios. Our results illustrate this in the identified issue on support for Drupal specific needs and work practices concerning RDFa. Further, standards are often not detailed enough to enable for unambiguous software implementations. This, in turn, may imply that whoever makes the first implementation has precedence in terms of how to interpret a standard, and in particular when such an implementation becomes widely adopted.

Further, our results show that two conformance tests have been used within the Drupal project, which may impact on any business agreement involving Drupal. This imposes further complexity. For example, if a public sector organisation wishes to procure a system based on Drupal for which there is a need to have interoperability with a specific legacy system, it is essential to address both conformance and interoperability between systems. In such a scenario a conformance test used earlier may now be outdated as the specification of the standard evolves. This would increase the complexity even further since requirements on a specific standard are expressed through requirements for interoperability with its legacy system.

In scenarios when there is a lack of interoperability, despite conformance to the standard according to a specific conformance test, there is of course a limit to what a customer can realistically expect from its supplier. Minor issues concerning lack of conformance and interoperability may perhaps be solved in kind through a constructive dialogue between stakeholders involved. However, further development efforts involving additional cost may be necessary in cases when customer expectations significantly exceed what the business agreement advocates.

In addition, for standards which initially address specific usage scenarios, it is often the case that only a subset of the standard is addressed in conformance tests. For some standards, there is also a lack of conformance tests.

In conclusion, our study shows an inherent complexity concerning issues stemming from different stakeholder groups involved in standardisation and software implementation of standards. Further, we observe different kinds of influence both within the Drupal community (between different sub-communities implementing different standards) and between the RDFa community in Drupal and the RDFa standardisation community in W3C. The findings from our analysis of the Drupal project make an important contribution towards a deeper understanding of challenges concerning relationships between OSS software communities and software standard communities.

Fig. 1 .

 1 Fig. 1. Number of issue postings (top) and contributors (middle) in Drupal core. Bottom: Number of issue postings for RDFa (green), CMIS (red), and OpenID (blue)

Fig. 2 .

 2 Fig. 2. Contributions to Drupal issue tracker for RDFa (green), CMIS (red) and OpenID (blue)

RDF: http://www.w3.org/2012/09/rdfa-wg-charter, CMIS: https://www.oasis-open.org/news /pr/oasis-members-approve-content-management-interoperability-services-cmis-standard, OpenID: http://openid.net/intellectual-property/