116 KiB
Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?
Jonas Gamalielsson*, Björn Lundell University of Skövde, P.O. Box 408, SE-541 28 Skövde, Sweden
ARTICLE INFO Article history: Received 19 October 2012 Received in revised form 7 November 2013 Accepted 8 November 2013 Available online 21 November 2013
Keywords: Open Source software Fork Community evolution
ABSTRACT Many organisations are dependent upon long-term sustainable software systems and associated communities. In this paper we consider long-term sustainability of Open Source software communities in Open Source software projects involving a fork. There is currently a lack of studies in the literature that address how specific Open Source software communities are affected by a fork. We report from a study aiming to investigate the developer community around the LibreOffice project, which is a fork from the OpenOffice.org project. In so doing, our analysis also covers the OpenOffice.org project and the related Apache OpenOffice project. The results strongly suggest a long-term sustainable LibreOffice community and that there are no signs of stagnation in the LibreOffice project 33 months after the fork. Our analysis provides details on developer communities for the LibreOffice and Apache OpenOffice projects and specifically concerning how they have evolved from the OpenOffice.org community with respect to project activity, developer commitment, and retention of committers over time. Further, we present results from an analysis of first hand experiences from contributors in the LibreOffice community. Findings from our analysis show that Open Source software communities can outlive Open Source software projects and that LibreOffice is perceived by its community as supportive, diversified, and independent. The study contributes new insights concerning challenges related to long-term sustainability of Open Source software communities.
© 2013 The Authors. Published by Elsevier Inc. Open access under CC BY license.
- Introduction Many organisations have requirements for long-term sustainable software systems and associated digital assets. Open Source software (OSS) has been identified as a strategy for implementing long-term sustainable software systems (Blondelle et al., 2012a; Lundell et al., 2011; Müller, 2008). For any OSS project, the sustainability of its communities is fundamental to its long-term success. In this study we consider long-term sustainability of communities in OSS projects involving a fork. Our overarching goal was to establish rich insights concerning how and why the LibreOffice project and associated communities have evolved the LibreOffice project and associated communities have evolved. More specifically, we report on commitment with the LibreOffice project, retention of committers, and insights and experiences from participants in the LibreOffice community. Overall, the study has revealed several key findings. First, the LibreOffice project, which was forked from the OpenOffice.org project, shows no sign of long-term decline. Second, the LibreOffice project has attracted the long-term and most active committers in the OpenOffice.org project. Third, our analysis shows that Open Source software communities can outlive Open Source software projects. Fourth, LibreOffice is perceived by its community as supportive, diversified, and independent.
The issue of forking OSS projects has been an ongoing issue of debate amongst practitioners and researchers. It has been claimed that “Indeed, the cardinal sin of OSS, that of project forking (whereby a project is divided in two or more streams, each evolving the product in a different direction), is a strong community norm that acts against developer turnover on projects” (Agerfalk and Fitzgerald, 2008). Further, it has been claimed that few forks are successful (Ven and Mannaert, 2008). Therefore, it is perhaps not surprising to see claims for that “there must be a strong reason for developers to consider switching to a competing project” (Wheeler, 2007). However, it has also been argued that “forking has the capability of serving as an invisible hand of sustainability that helps open source projects to survive extreme events such as commercial acquisitions, as well as ensures that users and developers have the necessary tools to enable change rather than decay” (Nyman et al., 2012). Similarly, Brian Behlendorf, co-founder of Apache Software Foundation, states that the “right to fork means that you don’t have to have any tolerance for dictators, you don’t have to deal with... people who make bad technical decisions – you can put the future into your own hands, and if you find a group of other people who agree with you, you can create a new project around it” (Severance, 2012). Another argument is that code forking can positively impact on both governance and sustainability of OSS projects at the levels of the software, its community and business ecosystem (Nyman and Lindman, 2013). From this, there is clearly a need for increased knowledge about how OSS communities are affected by a fork.
There are two specific objectives. For the first objective, we characterise community evolution over time for the LibreOffice project and the related OpenOffice.org and Apache OpenOffice projects. For the second objective, we report on insights and experiences from participants in a community of the branched project LibreOffice in order to explain how and why the project has evolved after the fork from its base project OpenOffice.org.
The paper makes four novel contributions. First, we establish a characterisation of the LibreOffice project and the related OpenOffice.org, and Apache OpenOffice projects with respect to history, governance, and activity. Second, we present findings regarding developer commitment with the projects under different governance regimes. Third, we present findings regarding retention of committers in the projects under different governance regimes. Fourth, we report on rich insights and experiences from participants in the LibreOffice project with a view to characterise its community and its way of working. In addition, we demonstrate approaches involving metrics for analysing long-term sustainability of communities (with or without forks) in OSS projects, and illustrate their use on different OSS projects.
There are five reasons which motivate a study on the LibreOffice project. Firstly, LibreOffice is one of few OSS projects which have had an active community for more than 10 years (when including the development in OpenOffice.org), with significant commercial interest. Secondly, there have been tensions within the OpenOffice.org project which finally led to the creation of the Document Foundation and the LibreOffice project (Byfield, 2010; Documentfoundation, 2013a). Thirdly, the project has reached a certain quality in that it has been adopted for professional use in a variety of private and public sector organisations (Lundell, 2011; Lundell and Gamalielsson, 2011). Therefore, its community is likely to attract a certain level of attention from organisations and individuals. Fourthly, previous studies of the base project OpenOffice.org (Ven et al., 2007) and more recent studies of LibreOffice (Gamalielsson and Lundell, 2011) show that there is widespread deployment in many organisations in a number of countries. This in turn imposes significant challenges for a geographically distributed user community. Fifthly, previous results (Gamalielsson and Lundell, 2011, 2012) and anecdotal evidence from an official spokesperson for the LibreOffice project (Nouws, 2011) suggest significant activity in the LibreOffice community. This motivates a more in-depth investigation of how and why the LibreOffice project evolved.
Hence, there is a need to extend previous studies on the LibreOffice project and in so doing include investigation of the project which LibreOffice was forked from (the OpenOffice.org project) and also alternative branches (the Apache OpenOffice project). An investigation of the OpenOffice.org project is interesting since it has been widely deployed. Further, the project is a natural source for recruitment to the LibreOffice project. Similarly, Apache OpenOffice is also interesting to investigate since it is the project that succeeded the OpenOffice.org project after Oracle abandoned it. Further, the investigation of Apache OpenOffice enables a more comprehensive study of community dynamics since the OpenOffice.org project is a potential source for recruitment to the Apache OpenOffice project as well.
For the rest of this paper we position our exploration of sustainability of OSS communities in the broader context of previous research on OSS communities (Section 2). We then clarify our research approach (Section 3), and report on our results (Sections 4 and 5). Thereafter, we analyse our results (Section 6) followed by discussion and conclusions (Section 7).
- On sustainable Open Source software communities
Many companies need to preserve their systems and associated digital assets for more than 30 years (Lundell et al., 2011), and in some industrial sectors (such as avionics) even more than 70 years (Blondelle et al., 2012b; Robert, 2006). In such usage scenarios “there will be problems if the commercial vendor of adopted proprietary software leaves the market” with increased risks for long-term availability of both software and digital assets (Lundell et al., 2011). Similarly, for organisations in the public sector, many systems and digital assets need to be maintained for several decades. This causes organisations to vary concerning different types of lock-in and inability to provide long-term maintenance of critical systems and digital assets (Lundell, 2011). For this reason, sustainability of communities has been identified as essential for long-term sustainability of OSS.
There are many different aspects of an OSS project that can affect community sustainability. Good project management practice includes to consider different incentives for contributing to OSS communities. This in turn may affect the future sustainability of communities (Bonaccorsi and Rossi, 2006). Previous research has shown that there are a number of different kinds of motivations for individuals and firms that have impact on any decision concerning participation in OSS projects. Such motivations are sometimes categorised into economic, social, and technological types of incentives (Bonaccorsi and Rossi, 2006). Earlier research also suggests that an effective structure of governance is a basis for healthy and sustainable OSS communities (de Laat, 2007). In particular, aspects such as clear leadership, congruence in terms of project goals, and good team spirit are of fundamental importance. Moreover, the community manager in an OSS project plays a key role for achieving an effective structure of governance (Michlmayr, 2009). Further, the licensing of OSS may affect the community. It has been claimed that “fair licensing of all contributions adds a strong sense of confidence to the security of the community” (Bacon, 2009). It has also been claimed that the choice of OSS license type “can positively or negatively influence the growth of your community.” (Engelfriet, 2010) To successfully master the art of establishing a long-term sustainable OSS community is a huge challenge. As in all organisations, there are “times in every community when repetition, housekeeping, and conflict play a role in an otherwise enjoyable merry-go-round. When the community begins to see more bureaucracy and repetition than useful and enjoyable contributions, something is wrong.” (Bacon, 2009)
A fork is often a consequence of inadequate OSS project governance. It has been claimed that forks “are generally started when a number of developers do not agree with the general direction in which the project is heading” (Ven and Mannaert, 2008). In particular, conflicts within communities can arise due to inadequate working processes, lack of congruence concerning project goals, and unclear (or in other ways inadequate) leadership. There are different views on what is considered an OSS project fork. It has been claimed that in order to be considered a fork, a project should (Robles and Gonzalez-Barahona, 2012): (1) have a new project name, (2) be a branch of the original OSS project, (3) have an infrastructure that is separated from the infrastructure of the original project, e.g. web site, mailing lists/forums, and SCM (Software Configuration Management system), (4) have a new developer community that is disjoint from the community of the original project, and (5) have a different structure of governance. There are also related concepts that are similar to OSS project forking such as (Robles and Gonzalez-Barahona, 2012): cloning (which involves the design of a software system that mimics another system), branching (where source code is duplicated within an SCM, creating parallel threads of development), derivation (which involves the creation of a new software system that is based on an existing system and which is compatible with the existing system), and modding (where existing software is enhanced, typically by enthusiasts, by providing patches and extensions to the existing software). There are different possible outcomes of a fork attempt. Four different categories have been identified by Wheeler (2007): (1) the forked project dies (e.g. libc/glibc), (2) the forked project re-merges with the original project (e.g. gcc/egcs), (3) the original project dies (e.g. XFree86/X.org), and (4) successful branching where both the original and forked project succeeds and typically have separate communities. A possible fifth outcome is that both the original and forked project dies (Robles and Gonzalez-Barahona, 2012).
Governance is of fundamental importance for sustainability and evolution of an OSS project and its associated communities. Three different phases of governance have been identified by de Laat (2007): (1) “spontaneous” governance, (2) internal governance, and (3) governance towards outside parties. The first phase of governance concerns the situation where the community (including both volunteer and potentially commercial actors) is self-directing without any formal and explicit control or coordination. Given the licensing framework, control and coordination that emerge stem from the degree of contribution by individual members. High performing members of a community may become informal leaders. The second phase is often adopted in larger projects that have existed for a longer time, and involves formal and explicit control and coordination in order to support more effective governance. Different tools are used for this including modularisation of software, assignment of roles to contributors, delegation of decision making, training and indoctrination, formalised infrastructure to support contributors, and leadership style (autocracy/democracy). A third phase of governance became necessary due to an increased external interest in OSS projects from national and international organisations in both the private and public sector. This increased institutionalisation of OSS led to an increased risk of litigation due to software patent infringements. As a solution, initiatives were taken to create legal shells around OSS projects to protect against lawsuits. One way of implementing this is by establishing non-profit foundations (such as the Linux Foundation and the Mozilla Foundation) for the governance of OSS projects.
In the context of OSS projects, it has been shown that “little research has been conducted on social processes related to conflict management and team maintenance” (Crowston et al., 2012). There are several open questions related to this, such as “How is team maintenance created and sustained over time?” (Crowston et al., 2012). Our study is also motivated by the fact that there is a lack of research presenting rich insights from large and widely deployed OSS projects. In particular, there is a need for increased knowledge related to community involvement in projects involving a fork. We also note that there are different, and seemingly conflicting, views amongst practitioners concerning the effect of a fork on involved projects and associated communities. This further motivates our study. For the remainder of this section we position our study with respect to earlier research.
There are a few studies focusing on forks in an OSS context. However, none of these studies focus on community involvement over time and do not investigate specific OSS projects in-depth. One of these studies focused on motivations for forking SourceForge.net hosted OSS projects (Nyman and Mikkonen, 2011). Another study surveyed a large number of OSS project forks with a specific focus on the temporal evolution of forks, reasons for forking, and outcomes of forks (Robles and Gonzalez-Barahona, 2012). A similar but more limited study focused on the motivations and impact of the fork mechanism in OSS projects (Visser, 2012). Another study has a focus on code maintenance issues in forked projects in the BSD family of operating systems (Ray and Kim, 2012).
Further, there are studies on the evolution of OSS projects over time, but such studies do not always have a community focus and are not always targeted at specific projects. Examples include a study on the total growth rate of OSS projects (Deshpande and Riehle, 2008), and work on the evolution of social interactions for a large number of projects on SourceForge.net over time (Madey et al., 2004). Another example is a study on survival analysis of OSS projects involving the application of different metrics based on the duration of thousands of projects in the FLOSSMETRICS database (Samoladas et al., 2010). There are also studies which focus on the evolution of software over time for specific OSS projects but which do not consider the community aspect. An example is a study on the Linux kernel based on Lehman’s laws of software evolution, which involved the application of code oriented metrics over time (Israeli and Feitelson, 2010). A similar approach was used in a case study on the evolution of Eclipse (Mens et al., 2008). Further, the growth of FreeBSD and Linux was studied and compared to earlier results on code evolution (Izurieta and Bieman, 2006). Another study on the topic of software evolution proposes a model of the Linux kernel life cycle (Feitelson, 2012).
A somewhat different strand of research involves development and application of different kinds of statistical measures for estimation and prediction of the survivability (Raja and Tretter, 2012; Wang, 2012), success (Crowston et al., 2003, 2006; Lee et al., 2009; Midha and Palvia, 2012; Sen et al., 2012; Subramaniam et al., 2009; Wiggins et al., 2009; Wiggins and Crowston, 2010) and attractiveness (Santos et al., 2013) of OSS projects. Such measures may consider factors related to (Wang, 2012): developer characteristics (e.g. user and developer effort, service quality, leadership and adherence to OSS ideology), software characteristics (e.g. license terms, targeted users, software modularity and quality), and community attributes (e.g. organisational sponsorship, financial support, trust and social network ties). However, forks are usually not explicitly addressed in such research and the focus is more on the overall survivability or success of OSS projects rather than focusing on the behaviour of communities associated with the projects. Further, such research typically use a large selection of projects from different OSS forges for statistical validation of the measures, whereas our study provides an in-depth analysis of a few inter-related OSS projects employing both a quantitative and qualitative approach.
There are other studies which do have a focus on the evolution of communities for specific OSS projects, but do not address the effects of a fork. For example, case studies have been conducted on the Debian project involving quantitative investigations of evolution of maintainership and volunteer contributions over time (Robles et al., 2005; Michlmayr et al., 2007). Another study involved an investigation of developer community interaction over time for Apache web server, Gnome and KDE using social network analysis (Lopez-Fernandez et al., 2006). A similar study involved the projects Evolution and Mono (Martinez-Romo et al., 2008). Case studies on the Nagios project (Gamalielsson et al., 2010), and Top-Cased & Papyrus projects (Gamalielsson et al., 2011) addressed community sustainability and evolution over time with a special focus on organisational influence. Other research partially focusing on community evolution are early case studies on large and well-known OSS projects including the Linux kernel (Moon and Sproul, 2000), Gnome (German, 2003), Apache web server (Mockus et al., 2002), Mozilla (Mockus et al., 2002), and FreeBSD (Dinh-Trong and Bieman, 2005). Further, there are no earlier reported in-depth studies on any of the three projects (LibreOffice, OpenOffice.org, and Apache OpenOffice) with a focus on the evolution of OSS project communities over time except for our own earlier studies on LibreOffice (Gamalielsson and Lundell, 2011, 2012). In a study on the process of participation in OSS communities, Shibuya and Tamai (2009) compare the communities for the Writer tool in the OpenOffice.org project, MySQL server in the MySQL project, and GTK+ in the GNOME project. This was done using different kinds of project documentation and quantitative data from bug tracking systems and source code repositories. However, this is a very limited study which only partially covers the OpenOffice.org project. There is another study that also has a community focus but from an open user experience design perspective, rather than a community evolution perspective (Bach and Carroll, 2010). Further, there are studies on OpenOffice.org without a community focus. One such study focused on code evolution (Rossi et al., 2009). Specifically, the study explored the relation between code activities, bug fixing activities, and software release dates for five projects including OpenOffice.org. In another study the maintenance process of the OpenOffice.org project was analysed using its defect management and version management systems (Koponen et al., 2006). There are also studies focusing on issues related to migration, adoption, and deployment of OpenOffice.org (Huysmans et al., 2008; Rossi et al., 2006; Ven et al., 2010; Seydel, 2009).
- Research approach
To address our first objective (to characterise community evolution over time for the LibreOffice project and the related OpenOffice.org and Apache OpenOffice projects) we undertook an analysis of the LibreOffice project and the related OpenOffice.org and Apache OpenOffice projects. This was done through a review of documented project information and a quantitative analysis of project repository data in order to investigate the sustainability in OSS communities. This included analysis of different project phases under different governance regimes. For the OpenOffice.org project this encompassed both the time period with governance by Sun Microsystems and by Oracle. For the rest of this paper we refer to the three projects as OO (OpenOffice.org), LO (LibreOffice), and AOO (Apache OpenOffice). OO with governance by Sun Microsystems is hereafter referred to as SOO, and OO with governance by Oracle is hereafter referred to as AOO.
To contextualise insights from the LibreOffice project, we undertook an analysis of data from a number of different sources. First, we established a characterisation of the three projects (LO, OO and AOO) by undertaking an analysis of: the history and governance of the projects, the release history, and commits to the SCM and contributing committers over time. Second, to investigate developer commitment with the projects we used different metrics that consider to what extent committers have been involved in and contributed to the different projects under different governance regimes. Third, to investigate retention of committers in the projects under different governance regimes we used different metrics that consider: the recruitment of committers over time, the retirement of committers over time, the distribution of commits for committers contributing to different combinations of projects, and the temporal commitment patterns between projects for committers.
In our quantitative analysis we adopt and extend approaches from earlier studies (Gamalielsson et al., 2011; Gamalielsson and Lundell, 2011, 2012). This is done in order to analyse the contributions in terms of committed SCM artefacts of the OSS projects over time. SCM data was collected from the official repositories for LO and AOO, and for OO from a website recommended at the AOO website which keeps the legacy source code. The data for the LO project was collected from the LO website,1 where the Git sub-repositories “core”, “binfilter”, “dictionaries”, “translations” and “help” were used in the analysis. The choice of sub-repositories was done after having a personal dialogue with key LO contributors. For the OO project, data was collected from an archive website,2 where the Mercurial repository was used in the analysis. Data for the AOO project was collected from the AOO website,3 where the SVN repository was used in the analysis. Data until 31 May 2013 were used for LO and AOO, and data until the end of the OO project (April 2011) were used. Logs for all projects were extracted from the repositories and these were thereafter analysed using custom made scripts. Further, a semi-automated approach involving manual inspection was used to associate commit id aliases with the same actual committer.
To address our second objective (to report on insights and experiences from participants in a community of the branched project LibreOffice in order to explain how and why the project has evolved after the fork from its base project OpenOffice.org), we undertook a case study on the LO project in order to investigate experiences from participants in the project with a view to gain insights from the effects of the fork that led to the establishment of the LO project.
In order to analyse insights and experiences concerning participation in the LO project, the two researchers conducted interviews with active participants in the LO community. As our goal was to specifically identify incentives and motivations for creation of the LO project, our strategy for identifying potential interviewees was to include key informants in key roles and interviewees with long experience from the project. In addition, we also sought to include interviewees with less experience who joined the project after the fork as a strategy to include additional perspectives. Interviewees were selected on the basis of being actively involved in the LO project.
Data collection was based on the results of face-to-face interviews conducted in English. Interviews were recorded, transcribed, and vetted by each interviewee. Questions were prepared in advance, and shown to the interviewee before the conduction of the interview. Each interview was conducted in an informal setting and allowed each interviewee to extensively elaborate on all issues covered during the interview. A total of 12 interviews were conducted, ranging in time from 8 to 43 min and resulting in 67 pages of transcribed and vetted interview data.4 In this process each interviewee was allowed to further elaborate and clarify their responses.
Analysis of the transcribed interview data took place over an extended time-period to allow time for reflection. Individual analysis was supplemented by group sessions in which researchers discussed and reflected on the interpretations from each researcher.
The coding of interview data was conducted in a manner which follows Glaser’s ideas on open coding (Lings and Lundell, 2005). The unit of coding was sentences or paragraphs within interview notes. The focus was on constant comparison: indicator to indicator, indicator to emerging concepts and categories (Lings and Lundell, 2005). The goal of the analysis was to develop and refine abstract concepts, which are grounded in data from the field (as interpreted via collected data in the transcriptions). The coding process resulted in a set of categories, each presented as a subsection in Section 5 of this paper.
1 http://www.libreoffice.org/developers-2/, accessed 18 June 2013. 2 http://hg.services.openoffice.org/DEV300, accessed 18 June 2013. 3 http://incubator.apache.org/openofficeorg/source.html, accessed 18 June 2013. 4 All interviews were conducted during February 2012. 4. Community evolution over time
In this section we report on results related to the first objective. Table 1 presents the main results from our observations concerning community evolution over time as reported in the following sections.
4.1. Characterisation of projects
In this section we present an overarching characterisation of the three projects. For each project we provide an historical overview, describe its governance, and report on project activity.
4.1.1. Organisations and overview of projects
The OO project was established as an OSS project on 13 October 2000 (Openoffice, 2004). Its initial release was on 1 October 2001 and the first stable version (v1.0) was released on 30 April 2002 (Openoffice, 2002). Initial development begun within StarDivision, a German based company that was acquired by Sun Microsystems in mid-1999 (Crn, 1999). Before establishing OO, development and provision of the code base was closed source. OO was governed by its community council, which comprised OO community members who also created a charter for the establishment of the council (Openoffice, 2013). The Sun contributor agreement needed to be signed by developers wishing to contribute, whereby the contributions are jointly owned by the developer and Sun corporation. The Oracle corporation acquired Sun (and thereby also the OO project) on 27 January 2010 (Oracle, 2010). Oracle also used a contributor agreement (almost identical to the Sun contributor agreement) that needed to be signed by developers wishing to contribute to the project. Oracle stopped support for commercial OpenOffice.org on 15 April 2011 (Marketwire, 2011a).
LO is a LGPL-licensed Open Source office productivity tool for creation and editing of digital artefacts in the Open Document Format (ODF), which is its native file format. The Document Foundation (TDF) was established on 28 September 2010 (Linuxuser, 2010) under German jurisdiction. The first beta release of LO was provided on the same date (Pclosmag, 2011). TDF has as its mission to facilitate the evolution of the LO project, which is a fork from the OO project since the date of establishing TDF (Documentfoundation, 2013a). TDF is an independent, meritocratic, self-governing, not-for-profit foundation that evolved from the OO community. It was formally established by members from the OO community in September 2010 and it is supported by a large number of small (and some larger) organisations. It has a steering committee currently consisting of eight members (excluding six deputy members), and there are also four other founding members. Further, there are four official spokespersons. TDF is open to individuals who can and are willing to contribute to its activities and who also agree with the core values of the foundation. Organisational participation is also encouraged, for example by supporting individuals financially to work and contribute in the community. TDF commits itself to give “everyone access to office productivity tools free of charge to enable them to participate as full citizens in the 21st century” (Documentfoundation, 2013b). Further, TDF supports the preservation of mother tongues by encouraging the translation, documentation and promotion of TDF facilitated office productivity tools in the languages of individual contributors. Moreover, TDF commits to allow users to create and maintain their digital artefacts in open document formats based on open standards. In addition, TDF openly seeks voluntary financial contributions (donations) via the project web site for individuals and organisations that want to support the further evolution of the LO project and TDF. Besides from having strong support from volunteer contributors, LO is also receiving support from commercial companies including RedHat, Novell and Canonical (Documentfoundation, 2013c).
Oracle donated the OO project to the Apache Software Foundation (ASF) on 1 June 2011 (Marketwire, 2011b). The project was thereafter established as an (incubating) ASF project on 13 June 2011 after undergoing a proposal and voting process (Apache, 2013a). The new project was in connection with this given the name Apache OpenOffice. AOO is licensed under APL v2 and comprises six office productivity applications. The first stable release of AOO (v3.4) was provided on 8 May 2012 (Openoffice, 2012). Apache OpenOffice became a top-level Apache project on 17 October 2012 (Apache, 2013a). ASF was established on 1 June 1999 under U.S. Jurisdiction (Apache, 1999). The mission of ASF is to establish projects delivering freely available and enterprise-grade products that are of interest for large user communities (Apache, 2013b). Apart from AOO, ASF maintains other well-known projects such as HTTP Server, Struts, Subversion, and Tomcat. Like TDF, ASF is an independent, meritocratic, self-governing, and not-for-profit organisation that is governed by the community members that collaborate within ASF projects since 1999. ASF has a board of directors that is annually elected by members of ASF, and which manages the internal organisational affairs of the foundation according to the ASF bylaws. The board consists of nine individuals, and in turn appoints a set of officers whose task is to take care of the daily operation of the foundation. The decision making in individual ASF projects regarding content and direction is delegated by the board of directors to so called project management committees. Each of these committees can govern one or several project communities. Individuals (unaffiliated and working with companies) that are willing and capable of contributing to ASF projects are welcome to participate. Further, ASF accepts donations and has a sponsorship program for individuals and organisations willing to contribute financially. We also note that IBM is an active supporter and contributor to the AOO project (IBM, 2011). Finally, we note that long before the establishment of the AOO project, researchers indicated that leadership and control in the OO project under Sun governance “is remarkably similar to that of Apache” (Conlon, 2007).
Fig. 1 summarises the evolution of the projects (OO, LO, and AOO) over time, and includes selected major events related to each project. Moreover, it illustrates how OO (black upper bar), LO (dark grey middle bar), and AOO (light grey lower bar) are interrelated and overlap in time.
4.1.2. Project activity
The version history of OO, LO and AOO is shown in Table 2. It can be observed that there has been a continuous flow of new OO releases for more than 10 years. On 25 January 2011 the Document Foundation (TDF) announced the first stable version of LO, which constitutes a fork from OO (Documentfoundation, 2013a). TDF has thereafter regularly provided new releases of LO. Further, the first stable version of AOO was announced on 8 May 2012, which replaced the discontinued OO project.
The developer activity in OO, LO and AOO is presented in Fig. 2, which shows the number of commits for each month from September 2000 to May 2013. We note that activity in the OO project varies, with distinct peaks in connection with the OO 2.0 (September 2005) and OO 2.4 (March 2008) releases. It can also be observed that the activity level decreased dramatically around August 2008, which is just before the release of OO version 3.0. A contributing reason for this significant drop in activity may be that major changes in terms of features had been implemented for version 3 and that subsequent activity was more focused on bug fixing. We can also observe that the activity in LO and AOO varies over time, but with peaks less distinct than those observed for OO.
Fig. 3 illustrates the number of active committers during each month of the projects. It can be observed that there are a large number of committers active early in the OO project, and that the activity decreases considerably shortly after the release of the first stable version of OO (version 1.0) in May 2002. The number of committers increases to a higher level after the release of OO 3.1 in May 2009. We note that there is a discord between number of monthly commits and committers in OO in the interval between January 2003 and January 2009 in that there are relatively few monthly committers contributing a large number of monthly commits. This may be explained by the fact that there are a number of both first and second level releases in the interval, which often co-occur with an elevated level of commits. Further, few committers often provide the majority of commits in OSS projects (see Section 4.2 for more details concerning commitment with the projects). For LO, it can be noted that committer participation peaks significantly in October 2010 and during the subsequent months in connection with the fork from OO. LO participation also peaks in connection with the release of version 4.0 in February 2013. It can also be observed that there was a rise in committer participation in AOO until September 2012.
4.2. Commitment with the projects
In this section we report on the commitment with the projects in terms of SCM contributions. Fig. 4 provides an overview of the commitment with the projects. The figure illustrates the number of committers that have contributed to the seven possible (mutually exclusive) combinations of the three projects. The area of a combination reflects the number of committers and the colour of a combination represents the average number of commits per committer in all projects for the combination. Totally, there have been 795 unique code contributors, who have been active in at least one of the three projects (the sum of committers in all areas). The main observation in Fig. 4 is that the 67 contributors who have committed to both OO and LO have provided the overwhelming majority of the commits (4339 commits per committer). Those committers constitute the backbone in the developer communities of both OO and LO. Further, the 8 contributors to all three projects have provided a substantial amount of commits (1329 commits per committer). Contributors in all other project combinations have had a very limited impact with respect to number of commits (127 commits per committer or less).
Table 3 provides a more detailed picture of commitment to the separate projects for the combinations illustrated in Fig. 4. The table shows the proportion of committers that have contributed to the seven possible combinations of the three projects. The table also shows (in brackets) the number of commits that the committers in the different project combinations contribute in the different projects. It can be observed that the 67 contributors who have committed to both OO and LO have provided the majority of the commits in both OO (92%) and LO (56.4%). Further, the 133
| Table 2 | Version history of OpenOffice.org (OO), LibreOffice (LO), and Apache OpenOffice (AOO). |
|---|---|
| OO | |
| --------- | ---- |
| OO initial | 2001-10-01 |
| OO 1.0 | 2002-04-30 |
| OO 1.1 | 2003-09-02 |
| OO 2.0 | 2005-10-20 |
| OO 2.1 | 2006-12-12 |
| OO 2.2 | 2007-03-28 |
| OO 2.3 | 2007-09-17 |
| OO 2.4 | 2008-03-27 |
| OO 3.0 | 2008-10-13 |
| OO 3.1 | 2009-05-07 |
| OO 3.2 | 2010-02-11 |
| LO 3.3 B1 | 2010-09-28 |
| LO 3.3 | 2011-01-25 |
| LO 3.4 | 2011-04-12 |
| LO 3.5 | 2011-06-03 |
| LO 3.6 | 2012-02-14 |
| LO 3.7 | 2012-05-08 |
| LO 3.8 | 2012-08-12 |
| LO 4.0 | 2013-02-14 |
| AOO 3.4 | 2013-07-23 |
| AOO 4.0 | 2013-07-25 |
| Fig. 2. Number of monthly commits for the OpenOffice.org (black), LibreOffice (dark grey) and Apache OpenOffice (light grey) projects. |
Fig. 3. Number of monthly committers for the OpenOffice.org (black), LibreOffice (dark grey) and Apache OpenOffice (light grey) projects.
Table 3 Proportion of commits for committers contributing to different combinations of projects (number of commits in brackets).
| Project combination | LO prop. [%] | AOO prop. [%] | OO prop. [%] |
|---|---|---|---|
| LO | 37.2 (23,846) | – | – |
| AOO | – | 26.4 (939) | – |
| OO | – | – | 6.1 (16,867) |
| LO & AOO | 0.3 (170) | 32.1 (1140) | – |
| LO & OO | 56.4 (36,152) | – | 92.0 (254,745) |
| AOO & OO | – | 0.2 (8) | <0.1 (1) |
| LO, AOO & OO | 6.1 (3914) | 41.3 (1466) | 1.9 (5121) |
| committers only participating in OO have provided only 6.1% of all commits. This is in contrast with the situation where committers have contributed either only to LO or only to AOO. In these two cases the contributions constitute 37.2%, and 26.4% of all commits, respectively. Further, we note that the 17 committers who have contributed to both LO and AOO (but not OO) have contributed significantly to AOO (32.1%) but very little to LO (0.3%). It may also be considered surprising that only one of the AOO committers has participated in both OO and AOO (but not LO). It is perhaps also unexpected that committers contributing to all three projects are behind 41.3% of all commits in AOO. |
Further, as earlier mentioned, commits have been contributed to the projects under different governance regimes, which have different lengths (SOO: 112 months, OOO: 16 months, LO: 33 months, and AOO: 24 months). Of the 209 committers in OO, 197 committers have been active during the Sun governance of the OO project and contributed 267,011 commits. Further, 81 committers have contributed 9723 commits during the Oracle governance of the OO project.
Fig. 5 illustrates the proportion of all commits as a function of proportion of committers for SOO (solid black trace), OOO (dashed black trace), LO (dark grey trace), and AOO (light grey trace). It can, for example, be noted that for SOO and LO, 10% of the committers (19 and 64, respectively) contribute 90.5% (241,645) and 88.8% (56,905) of the commits. Further, the same proportion of committers in OOO and AOO (8 and 4 committers, respectively) contribute 41.6% (4045) and 54.1% (1922) of the commits, respectively. Hence, for SOO and LO, a relatively small proportion of committers contribute the majority of the commits, whereas a larger proportion of the committers in OOO and AOO contribute the majority of the commits. It should also be mentioned that a large proportion of all committers contribute only a few commits (5 commits or less are made by 21.3% of the SOO committers, 12.3% of the OOO committers, 54.3% of the LO committers, and 34.9% of the AOO committers).
Table 4, which is based on the data illustrated in Fig. 5, shows the proportion of commits for different proportions of committers for SOO, OOO, LO, and AOO. Similarly, Table 5 shows the proportion of commits for the top N committers in the projects for different values of N. For example, 5% of the most active LO committers contribute 78% of all LO commits. It can be observed that the proportion of commits for LO in Table 5 is significantly smaller compared to the proportion of commits for LO in Table 4. This is due to the fact that there are many committers (645) in LO and that the top 5 committers therefore are much fewer than the top 5% of committers. For AOO it is the other way around: the top 5 committers is a much greater proportion of committers than the top 5%, and therefore the proportion of commits for AOO is greater in Table 5.
4.3. Retention of committers
In this section we report on the retention of committers for the different projects. Fig. 6 shows the recruitment of committers, retirement of committers and the current number of active committers in the projects for each project month. Recruitment is represented by the accumulated number of committers who have made their first commit (solid black trace). Retirement is represented by the accumulated number of committers who have made their last commit (dashed black trace). The current number of active committers is represented by the difference between the number of recruited and retired committers (grey trace). It can be observed that LO has by far the highest recruitment rate with approximately 20 new committers each month on average. At the same time, LO suffers from a high retirement rate. This is perhaps not surprising since, as earlier mentioned, half of all LO committers only have provided 5 commits or less. However, we cannot observe any long term trend towards a decreased number of active committers. There has roughly been between 100 and 150 currently active committers since the start of the LO project. SOO had a high recruitment rate during the first two years of the project, but a considerably lower recruitment rate during the rest of the project except for the last few months. From having approximately 75 currently active committers on average during the first two years, the SOO stabilised at around 50 currently active committers during the second half of the project. Noticeable about OOO is that recruitment has been slow except for the first few months. Further, the retirement rate in OOO has been comparably high, especially during the later part of the project. This led to a dramatic drop in currently active committers from the 10th project month and onwards. AOO has had a
| Table 4 | Proportion of commits for different proportions of committers in SOO, OOO, LO, and AOO. |
|---|---|
| Prop. of committers | SOO |
| Top 5% | 86% |
| Top 15% | 93% |
| Top 20% | 95% |
| Table 5 | Proportion of commits for different numbers of committers in SOO, OOO, LO, and AOO. |
|---|---|
| Number of committers | SOO |
| Top 5 | 79% |
| Top 15 | 89% |
| Top 20 | 91% |
| positive trend in terms of number of active committers during the first 16 project months. This is due to a high recruitment rate and a low retirement rate. However, AOO has lately experienced a stagnation in recruitment and an increasing rate of retirement. This has resulted in a halving of number of active committers in AOO during the second project year. We acknowledge that the total number of project months differ between projects (SOO: 112 months, OOO: 16 months, LO: 33 months, and AOO: 24 months). |
The distribution of commits among committers is further explored in the following in order to better explain commitment with the different projects at committer level. Fig. 7 provides details regarding the distribution of commits in LO (dark grey bar colour) and OO (black bar colour) for the 67 committers only contributing to LO and OO. Committers are sorted on the sum of commits in the two projects (in descending order). As stated earlier in connection with Table 2, the black area represents 92% of all commits in OO and the dark grey area represents 56.4% of all commits in LO. However, the LO commits only comprise 12.4% of all commits in Fig. 7, and the OO commits comprise 87.6%. At the level of individual committers, it can be observed that one of the projects often hugely dominates. For example, the top committer in Fig. 7 contributes 89,931 commits to OO, but only two commits to LO. In fact, the top six committers only contribute 0.4% of all their commits in LO.
Similarly, Fig. 8 provides details regarding the distribution of commits for the 17 committers contributing only to LO (dark grey bar colour) and AOO (light grey bar colour). The light grey area represents 32.1% of all commits in AOO, and the dark grey area represents 0.1% of all commits in LO. Given these proportions, it is not surprising that the contribution to the different projects is unbalanced. The LO commits only comprise 13% of all commits in Fig. 8, and the AOO commits comprise 87%. The unbalance is clearly visible at the level of individual committers in Fig. 8. For example, committers 3, 4 and 8 contribute a very small proportion of commits to LO. Only committer 10 contributes a larger proportion of commits to LO.
Fig. 9 provides details regarding the distribution of commits in LO (dark grey bar colour), AOO (light grey bar colour), and OO (black bar colour) for the 8 committers contributing to all three projects. The black area represents 1.9% of all commits in OO, the light grey area represents 41.3% of all commits in AOO, and the dark grey area represents 6.1% of all commits in LO. Like in Figs. 7 and 8, the contribution to the different projects is somewhat unbalanced. The AOO commits comprise 14% of all commits in Fig. 9, and the LO and OO commits comprise 37.3% and 48.8%, respectively. As an example of unbalance for individual committers, the top committer contributes 2261 commits to LO, but only 69 to AOO. One aspect that can contribute to the unbalance in Figs. 7–9 is the fact that projects have different life spans and have accumulated different total amounts of commits. For example, there have been 77 times more commits in OO compared to AOO.
Table 6 Major commitment patterns for committers who have contributed to LO.
| Pattern ID | Commitment pattern | Commits | Committers |
|---|---|---|---|
| LP1 | 33642 (52.5%) | 58 (9.0%) | |
| LP2 | 23846 (37.2%) | 553 (85.7%) | |
| LP3 | 3052 (4.8%) | 2 (0.3%) | |
| LP4 | 2385 (3.7%) | 5 (0.8%) |
Tables 6 and 7 illustrate the major temporal commitment patterns between projects (OO in black colour, LO in dark grey colour, and AOO in light grey colour) for committers who have contributed to LO (Table 6) and AOO (Table 7). In total, 13 commitment patterns were identified for the 645 LO committers. The four most significant of these patterns (LP1 through LP4) are shown in Table 6. These four patterns account for 98.2% of all LO commits and for 95.8% of all LO committers. Similarly, Table 7 shows the four most significant patterns (AP1 through AP4) out of a total of 10 identified patterns for the 43 AOO committers. These four patterns account for 93.4% of all AOO commits and for 74.4% of all AOO committers. Each committer is assigned to one distinct pattern by comparing the dates of the first and latest commit in the projects the committer has been active in. For example, a committer is assigned to LP1 if commitment in OO and LO has been sequential and the committer has not contributed to AOO. This means that for LP1 the latest commit in OO precedes the first commit in LO. Another example is LP4, where the involvement in OO overlaps with the involvement in LO. Hence, for LP4 the latest commit in OO is after the first commit in LO and the committer has not been active in AOO. In connection with each commitment pattern, Tables 6 and 7 show the number and proportion of commits and committers. The tables are sorted on number of commits assigned to a specific pattern in descending order.
In Table 6 it is evident that the pattern accounting for the largest amount of LO commits (52.5%) is LP1, where committers have contributed to OO and LO in sequence but not to AOO. There are also other commitment patterns for committers involved in only OO and LO (LP4 and two other patterns not among the four most significant) which together account for 3.9% of the commits. The second most significant pattern in terms of commits (37.2%) is LP2, where committers have contributed only to LO. This pattern applies for the clear majority (85.7%) of the committers. The patterns LP1 and LP2 are clearly dominating and together involve 89.7% of all commits and 94.7% of all committers. It should also (once again) be pointed out that committers who have been involved in OO before their involvement in LO (LP1) contribute a greater proportion of the commits compared to those who only have contributed to LO (LP2).
In Table 7 it can be observed that the pattern accounting for the largest amount of AOO commits (29.2%) is AP1, where committers have contributed to LO within the period during which they have contributed to AOO. The second most significant pattern in terms of commits (26.4%) is AP2, where committers only have contributed to AOO. When comparing with the LO patterns, we find that there is a more diversified set of commitment patterns that account for significant amounts of commits in AOO. Further, we note that a significant proportion of the AOO commits (41.3%) stem from committers who have previous and in some cases current experience in both OO and LO (AP3, AP4 and another pattern not shown in Table 7).
To sum up concerning recruitment to LO, 553 of the 645 committers in LO (constituting 85.7%) have not been active in OO or AOO, and have therefore been directly recruited to LO. Further, 75 of the 645 committers in LO have also contributed to OO. Of these 75 committers, 66 committers have contributed to OO before they started to contribute to LO and have thereafter not contributed to OO, and can therefore be claimed to have been recruited from OO to LO. These 66 committers are influential in that they together have provided the majority of the LO commits (58.7%). The remaining 9 of the 75 committers have been active in LO and OO in parallel. Further, 25 of the 645 committers in LO have also contributed to AOO, but these committers have only contributed to 2.2% of all LO commits.
For AOO, 17 of the 43 committers (constituting 39.5%) have not been active in OO or LOO, and have therefore been directly recruited to AOO. Further, 8 of the 43 committers in AOO have also contributed to OO before they started to contribute to AOO and have contributed to LO before or during their AOO involvement, and can therefore be claimed to have been recruited from OO and LO. These 8 committers together contribute a significant amount (41.3%) of all AOO commits. We also note that the 17 committers who have only contributed to AOO and LO have mostly contributed to the two projects in parallel and have contributed a considerable amount of the AOO commits (32.1%).
- Insights and experiences from the LibreOffice community
This section reports on results related to the second objective. Table 8 shows the main themes for investigation with associated main results from our observations concerning insights and experiences from the LibreOffice community.
All interviewees are active participants in the LO project, and several of them expressed that they have been active from the start of the project. Our interviewees include participants in the project who were active in the formation of TDF and several have central roles related to the LO project, even though our interviewees also include some contributors with less experience from participation in the project. From this, it would be appropriate to characterise our sample of interviewees as being dominated by experts and thereby to consider our conduction of research interviews as dominated by elite interviews.
Six broad categories emerged from our coding and analysis of the interview transcriptions. Each is presented as a separate section below, with a subheading aimed to characterise the category.
5.1. Considerations for creation of the LibreOffice project
Over time, members of the OO community started to perceive frustration and discontent due to a number of circumstances in the OO project. Concerns amongst community members include perceptions on: vendor dominance, copyright assignment, lack of influence, lack of fun, and bureaucracy in the project. For example, as expressed by a community member: “I started in OpenOffice, and it was fun in the beginning, but over the year you were able to see behind, and I didn’t like what I saw.” Similarly, another community member expressed a view that “it stopped being fun. It stopped being an Open Source project under Oracle”. A different respondent particularly emphasised bureaucracy in the OO project as an inhibitor to contributing: “In the past, I tried once to get involved in OpenOffice by submitting patches, but that was hell of a job to do, because of all the bureaucracy in the project, so that’s why I didn’t follow up on that and just quit with it.” Overall, the essence of these circumstances seems to originate from a lack of trust.
From this, the idea of starting a new branch of the OO project evolved amongst community members. This course of events brought many thoughts among members of the community, as illustrated in a comment raised by one person involved in the creation of LO: “When this whole story with Oracle started to look a bit fishy, you just meet people and you start talking, and you start thinking, and then you start planning.” Further, it is clear that a number of issues were considered before taking action, as illustrated by another person involved: “Before we started we had a lot of discussions. Shall we start? When do we start? How do we start? Which people do we get involved as soon as possible, or a bit later, or whatever?”. Once different issues had been considered it was time to take action, as expressed by a different respondent: “we founded the LibreOffice project, we got people together to agree and, you know, got the initial structure set up”.
Further, the choice of a copyleft license7 was mentioned as an important prerequisite for several contributors to the LO project. Hence, there seems to be consensus amongst contributors in the LO
7 OSS licenses are often broadly categorised as either copyleft licenses (e.g. GPL, which is a strong copyleft license, and LGPL, which is a weak copyleft license) or permissive licenses (e.g. BSD and MIT). The main difference between these two license categories is that copyleft licenses ensure that derivative work remains open source, whereas permissive licenses do not (Brock, 2013). project that permissive licenses should not be used for the project. As expressed by one respondent: “to me licensing is key and a copyleft license, a weak copyleft license, is pretty much mandatory for me to be interested in the project, because otherwise I know where it’s gonna go, pretty soon we will be writing proprietary software”. The importance of avoiding permissive licensing was further emphasised by another respondent: “the permissive license would lose half of our volunteer developers, because they are real volunteers. They are in the project for fun. They don’t want to give away their work to a corporation.” The same respondent also acknowledged that there are contributing companies that understand and act in accordance with fundamental values of the Open Source movement and that contributors accept this: “They easily give away their work to companies like Suse, Redhat, Canonical, that contribute to the project, that are transparent in the way that they behave in the project.” Further, one respondent pointed out that, apart from upsetting the community, switching from a copyleft to a permissive license would require a time consuming IP-clearance process. This process would require rewriting of code just because of the license and potentially stall the actual development of new features in a project.
In essence, interviewees involved in the process of establishing the LO project seem to have considered the establishment of the LO project with its independent foundation (TDF) and use of a weak copyleft license as an inevitable action to take given the perceived dissatisfaction amongst community members in the OO project.
5.2. Perception of LibreOffice
Immediate reaction was requested as we were seeking what respondents associated with LO rather than probing for a description or definition of it. On some occasions this caused respondents to hesitate before replying. Perhaps not surprisingly, some contributors with extensive experience from the project were hesitant in responding to this question, and one even commented: “It’s a hard question, because its not a factual question. I cannot use my mind.”
Overall, contributors gave a variety of ideological and emotional responses, such as: “freedom”, “something I believe in”, “It’s my project”, “a group of friends”. As put by one contributor: “[LibreOffice] is a project I have contributed to shape, and so there is also a lot of emotional participation”. Similarly, other respondents expressed “It has a very deep meaning for me, I guess, having done a lot of work there”, and “It’s my project, the project that I am working on, so, yeah.”
The concept also triggered a number of expressions of excitement, as illustrated in the following comments “Exciting project that is fun to hack on”, “It’s very positive to hear people talk about LibreOffice”, and “It’s cool, it’s home, it’s something exciting”. Further, respondents also associated the concept with personal commitment. For example, as expressed by one interviewee: “It’s a group of friends and people who we work with, I would say.”
In addition, the concept also gave rise to a number of more rational associations. Some of those expressions relate to quality for the software system, such as: “The best office suite in the world” and “[LibreOffice is an] interesting, exciting project with a huge amount of work, but very good, how do people work, how we work and what we manage to do”. Yet, others relate to the development model used in the project: “Community developed office suite”, whereas others were related to the developed system: “Open Source office package”. Finally, some respondents seemed to have been flattered when probed for their association concerning the concept LO, when responding jokingly “I recognise the name”.
5.3. Participation in the LibreOffice project
The extent to which contributions from participants in the LO project are related to their professional activities vary amongst respondents. We note that contributions stem from both volunteer and paid-for activities, and responses revealed that contributors are employed by several different organisations, including self-employed specialists.
Several respondents expressed that working on the LO project is part of their professional activities, as illustrated by the following responses: “I am working for LibreOffice in my professional activities”, “I am paid for working on LibreOffice”, and “It’s my full time job”. Further, some respondents also expressed that their incentives for participation in the project were motivated by a technical need from their professional activities, as illustrated by one respondent: “I wanted to use it to replace Microsoft Access, at what is now my day job”.
For several contributors there is significant congruence between their professional activities and their contributions to the project as volunteers. For example, one of the respondents expressed that “there is a huge overlap of my professional activities”, and another that “it is my professional activity … it’s not all of my job, I have other parts to my job I have to do … I do stuff in my free time as well”.
There were also those expressing that working on the LO project is in symbiosis with a professional job even though not directly part of it: “it is not related, but it is in harmony basically”. Yet others expressed that their incentives for participations were motivated by business opportunities: “I have a small company in [country X], and doing all kind of services, support for LibreOffice and the old OpenOffice, so that makes it logic to contribute in the project too, for me it’s a logic combination”.
Further, there are also contributors participating in the project primarily by volunteer activities. In the words of one respondent: “we do use LibreOffice in the company I work, but mostly the activities I do for LibreOffice is mostly as my hobby”.
Amongst respondents we also identified those for which professional and volunteer activities seem to merge: “For me it’s like a hobby that turned into some occupation, and it’s very hard to draw a line between what I am doing privately and what I am doing as an employee, and it mostly matches the interest from both company and what I would personally do”.
5.4. Motivations for contributing to the LibreOffice project
Several interviewees found it difficult to single out specific issues that motivate them to contribute to the project. For example, as put by one contributor: “That’s a very hard question, isn’t it … I think everyone is just this mixed bundle, all sorts of motivations”. Another respondent expressed that: “There are so many answers to that. It’s kind of hard”.
Respondents expressed a number of different types of motivations for contributing to the LO project. Several comments are of emotional nature, such as: “because it is fun and very rewarding”, “it’s fun to contribute and while you contribute the project gets ahead so it’s even more fun”, and “I want to do something that seems to be useful for people and significant. I think it’s the joy of relationship, and just working with other people and seeing good things happen”. Further, some emotional comments emphasised motivations for contributing to the project in the future: “in the future if it stays fun and the community stays a nice place to be in and, yeah, it’s … you can continue”.
Closely related to emotions, respondents also amplified social rewards and social recognition as enablers for their motivation to contribute. For example, respondents expressed: “Cleaning up ugly things is socially rewarding” and also that “positive feedback is what drives me”.
Similarly, there are also ideological motivations expressed amongst respondents: “I believe in free software because I think that is the proper alternative to proprietary software” and “I care about software freedom”.
There are also intellectual motivations that seem to drive contributors. For example, one respondent motivates participation in the LO project with an argument that having a good office package is “one of the biggest tasks that doesn’t have already a good solution for it in Open Source”. Similarly, another respondent considered establishment of a high quality LO project as “a professional challenge. Because not having any money, you have to be smarter than your competitors”.
For some respondents with a long-term commitment to the LO project, their participation has led to a desire to see the project succeed. As stated by one respondent: “I’ve invested plenty of time in this branch of software, so I really really have a personal desire to see it succeed”. Others expressed a motivation for improving the way-of-working in the LO project as follows: “It may not be readily visible but we still need to add more structure and more processes, and I think I want to continue to do that”.
Visionary goal driven motivations for the future for the LO project were also expressed as follows: “it’s fun. I am convinced it’s the right thing to do. I think it’s the right project, at the right time, with the right people, and the right mind sets”. Similarly, in the words of another respondent: “I think we can change a lot with this project by running it differently and pushing borders and thinking outside the box there”. Further, motivations also seem to stem from frustration concerning a perceived lack of influence in the old OO project, as commented by one respondent: “I was active in OpenOffice.org project in the past, and there were lots of things that I loved of that product, but a lot of things that made me feel frustrated about influence, about things that were not picked up, and on the development side. And, so I am really motivated to work on LibreOffice, to make it better, to see it improve compared to the old OpenOffice, and that is a strong motivation”.
Finally, amongst respondents we observe strong commitment with the project. As expressed by one respondent: “it’s fun, it’s something that I like to do, and it’s not the first free software project that I contribute to. It’s something that I have been doing for good chunks of my life now”. Similarly, for some such strong commitment and motivation for participation is also related to stark emotions: “It’s purely the love”.
5.5. Future outlook for the LibreOffice project
An overwhelming impression from responses is that contributors perceive a positive future for the LO project. Several respondents gave a number of emotional expressions, and we observe an expectation for a more diverse developer community amongst respondents in the future. For example, as stated by one respondent: “I believe that we will stay diversified and that we will be able to embrace more and more, not only individuals, but companies as well”.
Respondents raised the budget for the project as an issue and stressed that there is a “need to strengthen the project”. Other comments concern the way of working and how to organise work in the project, as illustrated by one respondent: “we still need to consolidate the organisation. We still need to increase the number of members”.
Several respondents envisaged a bright future for the LO project, as illustrated by the following comments: “Hereto, it has all the attributes of a very successful project. So, I believe that we will execute on the plan on releases as we have until recently, until now, because we have the time based schedule, that we always deliver on time”, “Whatever happens, it will continue in some way or another, some shape or another. I think that code base, it’s just too many users for it to disappear. It’s there to stay”, and “I think it is a bright future, and it grows, but it takes time”. Further, one respondent also expressed a view on the project in relation to an existing proprietary alternative as follows: “We are going to grow. We are going to take over the market, and we will have a follower called Microsoft behind us”.
However, there were also those predicting a somewhat more modest future for the LO project. For example, in the view of one respondent “we keep running as we are, I think”.
Further, a number of comments also revealed that the evolution for the LO project seemed to have exceeded the expectations of the respondents, as illustrated by the following comments: “while this is a young project, I am surprised by how diverse it is and how healthy it is”, “I think we’re doing very well, and we had a major breakthrough, milestone, when we finally got these German authorities to prove our idea of a foundation. And we’re past this quite important milestone. Yeah, I am very positive about the future”, and “I think we are not yet aware of what is possible with it, and I am beginning to realise how much bigger this thing can get”.
The importance of community and its role for the LO project was amplified by a number of respondents as an enabler for its future success. Several comments signalled a strong identity for members of the LO community as illustrated by one respondent who stressed the importance of community values as follows: “This is a community, not a company, so we don’t have titles”, and commented that there is consequently no need for business cards when working within the community. However, the same respondent suggested that there actually is a need for a business card in certain situations, such as when community members need to communicate with external organisations. Further, the importance of a vibrant community was also stressed by one respondent as follows: “the more rich and diverse and compelling we make our ecosystem, the stronger it is”.
Similarly, another comment stressed the importance of successful governance for a community as follows: “governance is key, if there is no governance at the end there is no project. So, some discipline is necessary, but the discipline can not go to the level of making the others scared to come inside. At the moment they are still a little bit scared. We are trying to make them less scared”.
5.6. Lessons learnt from participation in the LibreOffice project
From responses it is evident that contributors perceive participation in the LO project as positive and rewarding in a number of different ways. We observed a variety of different lessons learnt from participants in the project, and a number of comments touched upon excitement, opportunities with open collaboration, and a positive inclusive atmosphere that seems to promote learning.
Several respondents elaborated on their experiences from participation in the LO community, and attached a number of positive characteristics to the community. For example, as commented by one respondent with a long experience from participation in the community: “it’s a true fun, diverse, vibrant, community project. . . . I started in OpenOffice, and it was fun in the beginning, but over the year you were able to see behind, and I didn’t like what I saw”. Similarly, another respondent stressed the possibility to have an impact by providing value for individuals, organisations and society more broadly: “the thrilling thing about LibreOffice is that it really makes a difference. You can see people using it and appreciating it”.
Further, another respondent stressed the opportunity with open collaboration as an important lesson from participation in the project, as illustrated by the following comment: “I think it really shows that cooperation in an open way is profitable, makes sense, and I think that is a very valuable lesson”. Similarly, another respondent perceived benefits of open collaboration as follows: “It’s things like this [name of a practitioner conference], meeting with people and collaborating with different people with different mentalities, and tolerating each others and each other’s ideas; and yeah, even with completely different approaches to the project and expectations, to get something big out of it, yeah”. Another respondent stressed the inherent nature of sharing experiences when collaborating in a community, involving providing and gaining valuable lessons, as follows: “I think that I’ve, at the end I have really got as much as I have given, because in term of human experiences, just incredible”.
Several respondents stressed the importance of the welcoming environment in the LO project, with particular emphasis on skills development. For example, as expressed by one respondent “I think it’s good for my writing skills and coding skills”.
Similarly, several respondents stressed the welcoming nature and an established practice for mentoring new contributors as something highly appreciated, as illustrated by the following comment: “I am pleased that we have much more welcoming environment for new developers to participate with us, and I am very pleased that a lot of these people have now very quickly become senior advisers in their own right. And that they, themselves, can feel free to mentor other people and bootstrap other new developers up to the same situation. To repeat the process on others that was done to them to make them valuable and respected developers with commit access.” Further, as indicated by another respondent, the mentoring process seems to be founded in each individual’s ability and with a careful consideration in the LO project to acknowledging and appreciating contributions from all contributors: “I think it’s the exceptionally welcoming nature of the LibreOffice community and the speed at which I was recognised for my contributions and my skills and my abilities. It’s not like that in every project, you know. . . . With LibreOffice it happens very fast”.
Finally, another lesson learnt expressed by one respondent clearly stressed the perception of feeling rewarded from contributing to the LO project: “The most important experience was the weeks before we actually switched the upstream, and all the preparation, and then going out public and seeing how in matter of few minutes the IRC channels that we created filled with people who started to download, use and actually build LibreOffice, and those tireless moments we spent on the IRC trying to fix the possible breakages they had and it was just a magic moment to see that the things were actually moving ahead. It’s emotional”.
- Analysis
6.1. Analysis of community evolution over time
From our results we make a number of observations related to our results on project activity. Firstly, there have been regular and frequent releases of stable versions of the software (LO including the former development in OO) for a time period of more than ten years. Other examples of well known OSS projects with release histories extending over many years are Apache web server8 and the Linux kernel9, which have had frequent releases since 1995 and 1991, respectively. We note that, as for LO (and AOO), both these projects are governed by a foundation10 (i.e. third phase governance according to the categorisation proposed by de Laat (2007)). Secondly, there has been substantial activity in LO (including the former development in OO) for more than ten years. Despite some variation between stable releases, our findings suggest a long-term trend towards a sustainable community as we have not observed any signs of a lasting decline in the community activity. As a comparison, there has been stable community activity over many years in the aforementioned Apache web server and Linux kernel projects.
Based on results concerning commitment with the projects we find that a large proportion of the most influential committers in LO have been involved for long periods of time both before and after the fork from OO, which indicates that the developer community has a strong commitment with the LO branch. A strong commitment of contributors over long time periods has been observed earlier in a study on the Debian project where it was observed that maintainers “tend to commit to the project for long periods of time” and that “the mean life of volunteers in the project is probably larger than in many software companies, which would have a clear impact on the maintenance of the software” (Michlmayr et al., 2007). Further, our results show that a relatively small proportion (5%) of the most active LO committers contribute the majority of commits (78%) and that the five most active committers contribute 33% of all commits in the LO project. In comparison, a relatively small proportion (5%) of the most active AOO committers contribute a smaller proportion of commits (33%) and that the five most active committers contribute 60% of all commits in the AOO project. In acknowledging that our analysis of the AOO project is based on a significantly shorter time window than the LO project, we note that both projects have communities of committers larger than “the vast majority of mature OSS programs” (Krishnamurthy, 2002). Results concerning commitment with each project support findings from previous research which show that for OSS projects “the bulk activity, especially for new features, is quite highly centralised” (Crowston et al., 2012).
Results on retention of committers show that SOO and LO have been more successful in recruiting and retaining committers over time compared to OOO and AOO. Results also show that there is no sign of any long term decline in LO in terms of number of currently active committers. Further, results concerning contributions to both the LO and AOO projects show that few new developers (i.e. those who have not contributed to the OO project) provide limited contributions to the LO project (representing 0.3% of all LO commits) and a significant amount (32.1%) of the AOO commits. When considering long-term contributors (i.e. those who have contributed to all three projects) there are still limited contributions except for AOO (representing 1.9% of all commits in OO, 6.1% of all commits in LO and 41.3% of all commits in AOO). Further, the two most dominating commitment patterns for committers who have contributed to the LO project are that committers only commit to LO and that committers have done all their contributions in OO before starting to contribute to LO (together involving 94.7% of all LO committers and 89.7% of all LO commits). In comparison, the two most dominating commitment patterns for committers who have contributed to the AOO project are that committers have contributed to LO within the period during which they have contributed to AOO (together comprising 59.9% of all AOO committers and 55.6% of all AOO commits). Moreover, a clear majority (85.7%) of the LO committers have been directly recruited to LO, whereas less than half (39.5%) of the AOO committers have been directly recruited to AOO. It is not uncommon that
8 http://httpd.apache.org/. 9 http://www.kernel.org/. 10 The Apache Software Foundation (http://www.apache.org/) and the Linux Foundation (http://www.linuxfoundation.org/). developers are simultaneously involved in more than one project (Lundell et al., 2010). However, our results show that a limited number of contributors are simultaneously active in the LO and AOO projects.
6.2. Analysis of insights and experiences from the LibreOffice community
Results from the study indicate a systematic approach in the LO project for mentoring new contributors. The project has adopted a systematic approach and supportive work practices for providing guidance to new contributors. As an example, this is done via mentoring and provision of “LibreOffice Easy Hacks” that are specifically aimed at inexperienced contributors. Efforts made in this project seem to go beyond what is established practice in many other OSS projects. For any project it is important to promote organisational learning and ease introduction of new contributors to a project and its work practices. This has been recognised in previous research (Lundell et al., 2010). Further, our results also show that LO project participants seem keen to encourage and acknowledge contributions from new participants in the community.
Our results clearly show that use of a weak copyleft license is seen as appropriate for the LO project for a number of reasons. One reason is a perceived risk that the source code will not continue to be provided according to core principles of software freedom. This choice of Open Source license for the project has been referred to as adhering to a “keep-open” license (Engelfriet, 2010). In acknowledging that there are a number of factors affecting the attractiveness for a project, it seems evident that the choice of a “keep-open” license is considered appropriate amongst new contributors as the project has managed to attract a significant number of new contributors. Further, an additional indication of the preference for a “keep-open” license amongst those contributors to the LO project that were also contributing to the OO project stem from results in our interviews. This in turn reinforces the observation (see above) that the majority of the contributors to the OO project that decided to continue contributing to one of the projects (AOO or LO) have chosen the LO branch.
An effect of the fork was that a part of the OO community has evolved into a new form as founding members of the LO community stem from the OO community. Over time, the new LO project has managed to attract a significant number of new contributors now managed and governed by TDF. This is in contrast with the approach taken by the AOO project, which adopted an already established structure for governance and work practices (ASF).
There is a complex inter-relationship between community and company values which impacts on opportunities for long-term maintenance and support for OSS projects. A number of respondents express that besides their involvement in the LO community they are also affiliated with various commercial organisations. For some respondents there is also a symbiosis between their different involvements. Further, our results from respondents strongly support several of the motivational factors for individual participation in OSS projects that have been identified in earlier research (Bonaccorsi and Rossi, 2006). In particular, social motivations such as that it is fun to contribute and the sense of belonging to a community are important to LO contributors. Another social motivation observed in the LO community is the opportunity to provide an alternative to proprietary software solutions. Further, we note that technological motivations such as learning and the opportunity of getting contributions and feedback from the community are also present amongst LO contributors. Some respondents, who are also active in small companies, see business opportunities in participating in the LO community. Hence, our study confirms earlier studies concerning individual motivations for participation in OSS projects.
6.3. Implications
The study has revealed a number of insights concerning governance and community evolution. For long-term contributors active under several governance regimes during more than 10 years there have been several changes concerning the way of working in the different communities.
Contributors starting under the OO project (under governance by Sun followed by Oracle), and later active in the AOO project have experienced different corporate governance regimes followed by adoption of the Apache way of working. This transition of the project into governance under the existing ASF has involved a significant change for participants in terms of changed governance and changing conditions for contributors due to adoption of institutionalised practices and with a change from a weak copyleft license to a permissive license.
On the other hand, contributors starting under the OO project, and later active in the LO project have also experienced different corporate governance regimes (Sun and Oracle) followed by adoption of a new way of working implied by establishment of a tailor made foundation (TDF) as a legal framework for maintenance of the LO project. For these contributors, there has been continued use of a weak copyleft license. In this way, our results show that contributors shaped TDF with a view to support their preferred way of working in the LO project.
It should be noted that the choice of the same weak copyleft license as for the base project when establishing the LO project was possible without a prior IPR clearance. Further, this was possible despite the fact that the copyright for the code base in the base project was controlled by a different organisation (Oracle corporation). These circumstances allowed for that the LO project was able to immediately continue development on the same code base. However, when establishing the AOO project there was a need for IPR clearance in connection with transferring copyright of the code base to ASF and change to a new Open Source license. This transfer to ASF involved significant efforts and resulted in a significant time window between AOO project start and the first release of AOO.
From the analysis of the three specific projects investigated (LO, OO, and AOO), it is shown that significant development experiences – both in terms of contributors and their contributions – has been maintained and transferred from the OO project into the two independent projects (LO and AOO).
The importance of establishing a strong sense for the OSS community in the context of large global OSS projects is closely related to the importance of establishing a sense of teamness in global software development projects (Lings et al., 2007). In both Open Source and proprietary licensed software projects there is a need for managing collaboration involving developers with different socio-cultural backgrounds. However, a key difference between Open Source based collaboration in large community based projects and large inter-organisational collaborations using proprietary software in global contexts lies in the possibility to successfully fork an OSS project and establish a new project with a separate governance. The importance of face to face meetings is recognised both in the contexts of inter-organisational collaboration in the field of global software engineering (Lings et al., 2007) and large globally distributed OSS projects analysed in this study. Further, from our analysis in this study we note that the importance of establishing a common vision for an OSS community relates to experiences in the context of global software engineering concerning the importance of gaining “executive support from all the sites” in a globally distributed software development project (Paasivaara, 2011). 7. Discussion and conclusions
7.1. Discussion
The transition and formation of the LibreOffice community seems to be successful. However, we acknowledge the short time period after the fork (33 months) and that our early indications of a successful LibreOffice community after transition from OpenOffice.org need to be confirmed by an analysis over a longer time period at a later stage. As a comparison, a well-known fork with significant uptake and a long-term sustainable community is OpenBSD,(^\text{11}) which was forked from NetBSD in 1995 and still has an active developer community (Gmane, 2013).
Further, when considering Open Source software products in long-term maintenance scenarios for potential adoption, it is critical to understand and engage in communities related to the Open Source software project. For the base project analysed (OpenOffice.org), a governance structure has been established and the OpenOffice.org community was governed by its community council (Openoffice, 2013). Similarly, the investigated branch after the fork (LibreOffice) has also established a governance structure referred to as the Document Foundation (Documentfoundation, 2013a). Despite such explicitly documented governance structures, project participants may decide to fork a project, which happened when the Document Foundation established the LibreOffice project as a fork from OpenOffice.org on 28 September 2010. Our results suggest that this fork may actually be successful. We note that our observation indicates that the LibreOffice project may be an exception to the norm since previous research claims that there have been “few successful forks in the past” (Ven and Mannaert, 2008).
From our results, it remains to be seen to what extent the LibreOffice and Apache OpenOffice projects may successfully evolve their projects and associated communities in a way that can be sustainable long-term. So far it seems that LibreOffice has been the more successful project in terms of growing associated communities. Our results suggest that the choice of Open Source license significantly impacts on conditions for attracting contributions to Open Source projects. Amongst contributors to the LibreOffice project there is clear preference for contributing to an Open Source project which use the same weak copyleft license as the base project. This use of a keep-open license in the LibreOffice project may significantly impact on the willingness to contribute to an Open Source project for which they do not possess the copyright. This may be so both amongst volunteer and company affiliated developers. Our results show strong indications of congruence between professional roles and contributions to the LibreOffice community for community members.
We acknowledge that the LibreOffice project has been established and openly available for external contributions for a longer time period than the Apache OpenOffice project. This can partly be explained by a later start for the Apache OpenOffice project since there has been a state of void between 15 April 2011 when Oracle abandoned OpenOffice.org and 13 June 2011 when Apache OpenOffice was established as an Apache Software Foundation project. Further, we note that the first commits in the Apache OpenOffice repository were contributed in August 2011. Therefore, it is perhaps not surprising that a number of contributors from the OpenOffice.org project became involved in the LibreOffice project, since there was no active OpenOffice.org project to contribute to for several months. However, it should be noted that after August 2011, when the first commits were contributed and Apache OpenOffice became openly available, committers have continued to contribute to the LibreOffice project.
The situation analysed in the paper has an inherent complexity in that it involves three projects for which there are complex interactions, influences, and relationships both with respect to code and community dynamics. Therefore this study challenges previously established categorisations of fork outcomes and also how the concept of fork is defined. This is since the foundation for such categorisations and definitions often consider the relationship between two projects, often referred to as the base and the forked project (Robles and Gonzalez-Barahona, 2012; Wheeler, 2007). Further, this study has shown that individual contributors in related OSS developer communities can contribute to several projects over a period of time, including the base and the forked project.
The analysis of sustainability of Open Source software communities and evolution of two independent Open Source software projects after a fork shows there is potential for successful branching. Our specific emphasis has been to investigate insights and experiences from community members for the project which was established as an outcome of a fork. From this we find that long-term community members seem to manage establishing a new project and a tailor-made foundation for its governance in a way that is appealing to old and new contributors.
In situations such as the one analysed in this study there is no one-to-one correspondence between Open Source software project and Open Source software community. Consequently, when assessing the sustainability of such communities it is important to recognise that individual contributors are involved in multiple projects. Therefore, any such assessment must take into account that community involvement goes beyond any single project.
Irrespective of how relationships between the projects are perceived with transition from the base project to the two new projects, our results from the analysis of the three inter-related projects with associated transitions from the OpenOffice.org project go beyond previously established categorisations of fork outcomes. Our results thereby provide valuable insights for extending the existing body of knowledge concerning forks.
7.2. Conclusions
Our study presents findings from the first comprehensive analysis of Open Source software projects involving a fork. The study reveals a number of important findings related to long-term sustainability of Open Source software communities.
Related to the characterisation of community evolution over time for the three inter-related Open Source projects, the study presents several important findings: First, the LibreOffice project shows no sign of long-term decline, and that as such details circumstances under which a fork can be successful. Second, the majority of contributors to the OpenOffice.org project who continued in one of the succeeding projects chose to continue contributing to the LibreOffice project. Further, LibreOffice has attracted the long-term and most active committers in the OpenOffice.org project, and it is thereby demonstrated that successful transfer and evolution of know-how and work practices can be achieved beyond individual Open Source software projects. Third, OpenOffice.org (under governance of Sun) and LibreOffice have been more successful in recruiting and retaining committers over time compared to OpenOffice.org (under governance of Oracle) and Apache OpenOffice. This suggests that effective governance and work practices that are appreciated by community members is fundamental for long-term sustainability. Fourth, a minority of the LibreOffice committers have been recruited from OpenOffice.org and have contributed a clear majority of the LibreOffice commits. On the other hand, the vast majority of LibreOffice committers have been directly recruited to the project but their commits to the project are in minority. From this we conclude that apart from community efforts for making it easier to contribute to an Open Source software
^{11} http://www.openbsd.org/.
project it also important to address challenges related to long-term retention of contributors.
The study makes a novel contribution by revealing important insights and experiences from members of the LibreOffice community, and provides explanations for why the LibreOffice project has evolved as it has. There is clear preference for use of a copyleft license amongst contributors to the LibreOffice project, both amongst volunteers and those affiliated with companies. The use of such a license in the LibreOffice project is perceived as a prerequisite for entry amongst many volunteer contributors and those affiliated with companies. This suggests that such an Open Source license is preferred amongst contributors in Open Source software projects with a strong community identity. Further, the study shows that it is important that values amongst contributors and other stakeholders are congruent with effects of the particular Open Source license used. Results from the study elaborate tension in a community and details circumstances under which community members need to vary in order to avoid an ineffective collaboration climate in an Open Source software project. Further, the study reveals important motivations for joining and contributing to the LibreOffice project over time, including: a perceived welcoming atmosphere in the community; a sense of supportive and effective work practices; appreciation for independence and control of developed solutions by members of the community; and a strong identity and appraisal of community diversity. Thereby the study has detailed the importance of nurturing Open Source software communities in order to establish long-term sustainable Open Source software projects. From a contributor perspective, the study shows that Open Source software communities can outlive Open Source software projects. In particular, for projects with associated devoted communities with strong conviction for future directions for projects and communities, we find strong indications for that forking can be used as one effective strategy for overcoming perceived obstacles in the current way of working in a project in order to improve the situation.
The findings from our analysis of the LibreOffice project (and the related OpenOffice.org and Apache OpenOffice projects) contribute new insights concerning challenges related to long-term sustainability of Open Source software communities. For software systems with long life-cycles, the success by which an Open Source software project manages to recruit and retain new contributors to its community is critical for its long term sustainability. Hence, good practice with respect to governance of Open Source software projects is perceived by community members as a fundamental challenge for establishing sustainable communities.
References
Ågerfalk, P., Fitzgerald, B., 2008. Outsourcing to an unknown workforce: exploring open sourcing as a global sourcing strategy. MIS Quarterly 32 (2), 385–410.
Apache, 1999. The Apache Software Foundation Board of Directors Meeting Minutes, http://www.apache.org/foundation/records/minutes/1999/board_minutes_1999_06_01.txt (accessed June 2013).
Apache, 2013a. Apache OpenOffice, http://openoffice.apache.org/ (accessed June 2013).
Apache, 2013b. The Apache Software Foundation – Foundation Project, http://www.apache.org/foundation/ (accessed June 2013).
Bach, P., Carroll, J., 2010. Characterizing the dynamics of open user experience design: the cases of firebox and OpenOffice.org. JAIS 11 (special issue), 902–925.
Bacon, J., 2009. The Art of Community. O’Reilly Media, Sebastopol.
Blondelle, G., Arberet, P., Rossignol, A., Lundell, B., Labeze, P., Berrendonner, R., Gauffret, P., Faudot, R., Langlois, B., Maioncello, L., Moro, P., Rodriguez, J., Puerta Peña, J.M., Bonafous, E., Mueller, R., 2012a. Polarsys towards long-term availability of engineering tools for embedded systems. In: Proceedings of the Sixth European Conference on Embedded Real Time Software and Systems (ERTS 2012), Toulouse, France, 1–2 February.
Blondelle, G., Langlois, B., Gauffret, P., 2012b. How Polarsys addresses Long Term Support and develops the ecosystem of Eclipse tools for Critical Embedded Systems. EclipseCon on US 2012, Reston, Virginia, 26–28 March, http://www.eclipsecon.org/2012/sessions/how-polarsys-addresses-long-term-support-and-develops-ecosystem-eclipse-tools-critical-embe
Bonaccorsi, A., Rossi, C., 2006. Comparing motivations of individual programmers and teams to take part in the open source movement: from community to business. Knowledge, Technology & Policy 18 (4), 60–64.
Brock, A., 2013. Understanding commercial agreements with open source projects. In: Coughlan, S. (Ed.), Thoughts on Open Innovation – Essays on Open Innovation from Leading Thinkers in the Field, OpenForum Europe Ltd for OpenForum Academy, Brussels.
Byfield, B., 2010. The Cold War Between OpenOffice.org and LibreOffice. Linux Magazine, http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/The-Cold-War-Between-OpenOffice.org-and-LibreOffice (accessed June 2013).
Conlon, M.P., 2007. An examination of initiation, organization, participation, leadership, and control of success in Open Source software development projects. Information Systems Education Journal 5 (38), 1–13.
Crn, 1999. Sun Microsystems Buys Star Division, http://www.crn.com/news/channel-programs/18804525/sun-microsystems-buys-star-division.htm (accessed June 2013).
Crowston, K., Annabi, H., Howison, J., 2003. Defining Open Source Software project success. In: Proceedings of the International Conference on Information Systems (ICIS 2003), Seattle, WA, USA, 14–17 December. pp. 327–340.
Crowston, K., Howison, J., Annabi, H., 2006. Information systems success in free and Open Source software development: theory and measures. Software Process: Improvement and Practice 11 (2), 123–148.
Crowston, K., Kangning, W., Howison, J., Wiggins, A., 2012. Free/Libre open-source software development: what we know and what we do not know. ACM Computing Surveys 44 (2) (article 7).
de Laat, P., 2007. Governance of open source software: state of the art. Journal of Management Information and Governance 11 (2), 165–177.
Deshpande, A., Riehle, D., 2008. The total growth of Open Source. In: Russo, B., et al. (Eds.), Open Source Development, Communities and Quality. IFIP Advances in Information and Communication Technology, vol. 275. Springer, New York, pp. 197–209.
Dinh-Trong, T.T., Bieman, J.M., 2005. The FreeBSD project: a replication case study of open source development. IEEE Transaction on Software Engineering 31 (6), 481–494.
Documentfoundation, 2013a. The Document Foundation, http://www.documentfoundation.org/ (accessed June 2013).
Documentfoundation, 2013b. The Document Foundation Manifesto, http://www.documentfoundation.org/pdf/manifesto.pdf (accessed June 2013).
Documentfoundation, 2013c. The Document Foundation – Our Supporters, http://www.documentfoundation.org/supporters/ (accessed June 2013).
Engellfriet, A., 2010. Choosing an Open Source license. IEEE Software 27 (1), 48–49.
Fetelson, D.G., 2012. Perpetual development: a model of the Linux kernel life cycle. Journal of Systems and Software 85 (4), 859–875.
Gamalielsson, J., Lundell, B., 2011. Open Source communities for long-term maintenance of digital assets: what is offered for ODF & OOXML? In: Hammouda, L., Lundell, B. (Eds.), Proceedings of SOS 2011: Towards Sustainable Open Source. Tampere University of Technology, Tampere, pp. 19–24, ISBN 978-952-15-2411-0, ISSN 1737-836X.
Gamalielsson, J., Lundell, B., 2012. Long-term sustainability of Open Source software communities beyond a fork: a case study of LibreOffice. In: Hammouda, L., et al. (Eds.), Open Source Systems: Long-Term Sustainability. IFIP Advances in Information and Communication Technology, vol. 378. Springer, Heidelberg, pp. 29–47.
Gamalielsson, J., Lundell, B., Lings, B., 2010. The Nagios community: an extended quantitative analysis. In: Agerfalk, P., et al. (Eds.), Open Source Software: New Horizons. IFIP Advances in Information and Communication Technology, vol. 319. Springer, Berlin, pp. 85–96.
Gamalielsson, J., Lundell, B., Mattsson, A., 2011. Open Source software for model driven development: a case study. In: Hissam, S. (Ed.), Open Source Systems: Grounding Research. IFIP Advances in Information and Communication Technology, vol. 365. Springer, Heidelberg, pp. 348–367.
German, D., 2003. The GNOME project: a case study of open source global software development. Journal of Software Process: Improvement and Practice 8 (4), 201–215.
Gmane, D., 2013. Information about gmane.os.openbsd.cvs, http://dir.gmane.org/gmane.os.openbsd.cvs (accessed June 2013).
Huysmans, F., Ven, K., Verelst, J., 2008. Reasons for the non-adoption of OpenOffice.org in a data-intensive administration. First Monday 13 (10).
IBM, 2011. IBM to Contribute to New, Proposed OpenOffice.org Project, http://www-03.ibm.com/press/us/en/pressrelease/34638.wss (accessed June 2013).
Isaëla, A., Fettelson, D.G., 2010. The Linux kernel as a case study in software evolution. Journal of Systems and Software 83 (3), 485–501.
Izurieta, C., Bieman, J., 2006. The evolution of FreeBSD and Linux. In: Proceedings of the 5th ACM-IEEE International Symposium on Empirical Software Engineering (ISESE’06), September 21–22, Rio de Janeiro, Brazil.
Koponen, T., Lintula, H., Hotti, V., 2006. Defects reports in Open Source Software maintenance process – OpenOffice.org case study. In: Proceedings of Software Engineering Applications (SEApp’06), Dallas, TX, USA, 13–15 November.
Krishnamurthy, S., 2002. Cave or community? An empirical examination of 100 mature Open Source projects. First Monday 7 (6).
Lee, S.-Y.T., Kim, H.-W., Gupta, S., 2009. Measuring open source software success. Omega 37 (2), 426–438.
Lings, B., Lundell, B., 2005. On the adaptation of Grounded Theory procedures: insights from the evolution of the 2G method. Information Technology & People 18 (3), 196–211. Lings, B., Lundell, B., Ågerfalk, P.J., Fitzgerald, B., 2007. A reference model for suc- cessful distributed Development of Software Systems. In: Proceedings of the Second International Conference on Global Software Engineering (ICGSE 2007). IEEE Computer Society, pp. 130–139.
Linususer, 2010. OpenOffice.org Community Announces. The Document Foun- dation. http://www.openoffice.org/press-release/announces-the-document-foundation (accessed June 2013).
Lopez-Fernandez, L., Robles, G., Gonzalez-Barahona, J.M., Herraz, I., 2006. Apply- ing social network analysis techniques to community-driven Libre software projects. International Journal of Information Technology and Web Engineering 1 (3), 27–48.
Lundell, B., 2011. e-Governance in public sector ICT-procurement: what is shaping practice in Sweden? European Journal of ePractice 12 (6), http://www.epractice.eu/files/European%20Journal%20of%20ePractice%20Volume%2012%266.pdf.
Lundell, B., Gamalielsson, J., 2011. Towards a Sustainable Swedish e-Government Practice: Observations from unlocking digital assets. In: Proceedings of the IFIP 11th Government Conference 2011 (EGOV 2011), Delft, The Netherlands, 28 August–2 September 2011.
Lundell, B., Lings, B., Lindqvist, E., 2010. Open Source in Swedish companies: where are we? Information Systems Journal 20 (6), 519–535.
Lundell, B., Lings, B., Syberfeldt, A., 2011. Practitioner perceptions of Open Source software in the embedded systems area. Journal of Systems and Software 84 (9), 1540–1549.
Madye, G., Freeh, V., Tynan, R., 2004. Modeling the F/OSS community: a quantitative investigation. In: Koch, S. (Ed.), Free/Open Source Software Development. Idea Group Publishing, Hershey, pp. 203–221.
Marketwire, 2011a. Oracle Announces Its Intention to Move OpenOffice.org to a Community-Based Project, http://www.marketwire.com/press-release/oracle-announces-its-intention-to-move-openofficeorg-to-a-community-based-project-nasdaq-orcl-1503027.htm (accessed June 2013).
Marketwire, 2011b. Oracle to Contribute to Apache, http://www.marketwire.com/press-release/statements-on-openofficeorg-contribution-to-apache-nasdaq-orcl-1521400.htm (accessed June 2013).
Meyers-Romero, J., Robles, G., Ortuño-Pérez, M., Gonzalez-Barahona, J.M., 2008. Using social network analysis techniques to study collaboration between a FLOSS community and a company. In: Russo, B., et al. (Eds.), Open Source Development, Communities and Quality. IFIP Advances in Information and Communication Technology, vol. 275, Springer, New York, pp. 171–186.
Mens, T., Fernández-Ramírez, J., Degrandts, S., 2008. The evolution of Eclipse. In: Proceedings of the 24th IEEE International Conference on Software Maintenance (ICSM 2008), pp. 386–395.
Michlmayr, M., 2009. Community management in Open Source projects. The Euro- pean Journal for the Informatics Professional X (3), 22–26.
Michlmayr, M., Robles, G., Gonzalez-Barahona, J.M., 2007. Volunteers in large Libre software projects: a quantitative analysis. In: Sowe, S.K., et al. (Eds.), Emerging Free and Open Source Software Practices. IGI Publishing, Hershey, pp. 1–24.
Midha, V., Palvia, P., 2012. Factors affecting the success of Open Source software. Journal of Systems and Software 85 (4), 895–905.
Mockus, A., Fielding, R.T., Herbsleb, J.D., 2002. Two case studies of Open Source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology 11 (3), 309–346.
Moon, Y.J., Sproull, L., 2000. Essence of distributed work: the case of the Linux kernel. First Monday 5 (12), 1–7.
Müller, R., 2008. Open Source – Value Creation and Consumption. In: Open Expo, Zürich, 24–25 September.
Nouws, L., 2011. LibreOffice – the first year and looking forward! In: Presented at ODF Plugfest, Gouda, Netherlands, 2011-11-18, http://plugfest.
Nyman, L., Mikkonen, T., Lindman, J., Fougère, M., 2012. Perspectives on code forking and sustainability in Open Source software. In: Hammouda, L., et al. (Eds.), Open Source Systems: Long-Term Sustainability. IFIP Advances in Information and Communication Technology, vol. 378, Springer, Heidelberg, pp. 274–279.
Openoffice, 2002. OpenOffice.org Community Announces, OpenOffice.org 1.0. Free Office Productivity Software, http://www.openoffice.org/about_us/oooe_release.html (accessed June 2013).
Openoffice, 2004. OpenOffice.org Is Four, http://www.openoffice.org/about_us/birthday4.html (accessed June 2013).
Openoffice, 2012. The Apache OpenOffice Project Announces Apache OpenOffice™ 3.4, http://www.openoffice.org/news/aoo34.html (accessed June 2013).
Openoffice, 2013. Community Council, http://wiki.services.openoffice.org/wiki/Community_Council (accessed June 2013).
Oracle, 2010. Oracle Completes Acquisition of Sun, http://www.oracle.com/us/corporate/press/044428 (accessed June 2013).
Paasivaara, M., 2011. Coaching global software development projects. In: Proceed- ings of the 30th International Conference on Global Software Engineering (ICGSE 2011). IEEE Computer Society, pp. 84–93.
Pclomsag, 2011. Free At Last! LibreOffice 3.3 Released, http://pclomsag.com/html/Issues/201103/page14.html (accessed June 2013).
Raja, U., Tretter, M.J., 2012. Defining and evaluating a measure of Open Source project survivability. IEEE Transactions on Software Engineering 38 (1), 163–174.
Ray, B., Kim, M., 2012. A case study of cross-system porting in forked projects. In: Pro- ceedings of the 20th ACM SIGSOFT International Symposium on the Foundations of Software Engineering, 11–16 November 2012, Cary, NC.
Robert, S., 2006. On-board development – the open-source way. In: IST/ARTEMIS Workshop, Helsinki, 22 November.
Robles, G., Gonzalez-Barahona, J.M., 2012. A comprehensive study of software forks: dates, reasons and outcomes. In: Hammouda, L., et al. (Eds.), Open Source Systems: Long-Term Sustainability. IFIP Advances in Information and Commu- nication Technology, vol. 378. Springer, Heidelberg, pp. 1–14.
Robles, G., Gonzalez-Barahona, J.M., Michlmayr, M., 2005. Evolution of volunteer participation in Libre software projects: evidence from Debian. In: Proceedings of the First International Conference on Open Source Systems (OSS 2005), pp. 100–107.
Rossi, B., Scotto, M., Sillitti, A., Succi, G., 2006. An empirical study on the migration to Open Source software in a public administration. International Journal of Information Technology and Web Engineering (IJITWE) 1 (3), 64–80.
Rossi, B., Russo, B., Succi, G., 2009. Analysis of Open Source development evolution iterations by means of burst detection techniques. In: Boldyreff, C., et al. (Eds.), Open Source Ecosystems: Diverse Communities Interacting. IFIP Advances in Information and Communication Technology, vol. 299. Springer, Berlin, pp. 83–93.
Samoladas, I., Stamos, I., Angelos, L., 2010. Survival analysis on the duration of open source projects. Information and Software Technology 52 (9), 902–922.
Santos, C., Kuk, G., Kon, F., Pearson, J., 2013. The attraction of contributors in free and Open Source software projects. Journal of Strategic Information Systems 22 (1), 45–69.
Sen, R., Singh, S.S., Borle, S., 2012. Open Source software success: measures and analysis. Decision Support Systems 52 (2), 364–372.
Severance, C., 2012. The Apache Software Foundation: Brian Behlendorf. Computer 45 (1), 1–6.
Seydel, J., 2009. OpenOffice.org: when will it be ready for prime time? In: Proceed- ings of the Southwest Decision Sciences Institute Conference (SWDSI), 25–28 Ed.
Shibuya, B., Tamai, T., 2009. Understanding the process of participating in open source communities. In: Proceedings of the 2009 ICSE Workshop on Emerging Trends in Free/Libre/Open Source Software Research and Development. IEEE Computer Society, Washington, DC, USA, pp. 1–4.
Subramaniam, C., Sen, R., Nelson, M.L., 2009. Determinants of Open Source software project success: a longitudinal study. Decision Support Systems 46 (2), 576–585.
Ven, K., Mannenat, H., 2008. Challenges and strategies in the use of Open Source Soft- ware by Independent Software Vendors. Information and Software Technology 50 (9–10), 991–1002.
Ven, K., Huysmans, P., Verelst, J., 2007. The adoption of open source desktop software in a large public administration. In: Proceedings of the 13th Americas Conference on Information Systems (AMCIS 2007), 9–12 August, Keystone, CO.
Ven, K., Van Kerckhoven, G., Verelst, J., 2010. The adoption of open source desktop software: a qualitative study of Belgian organizations. International Journal of IT/Business Alignment and Governance (IJITBAG) 1 (4), 1–17.
Viseur, R., 2012. Forks impacts and motivations in free and open source projects. International Journal of Advanced Computer Science and Applications (IJACSA) 3 (2), 117–122.
Wang, J., 2012. Survival factors for Free Open Source software projects: a multi-stage perspective. European Management Journal 30 (4), 352–371.
Wheeler, D.A., 2007. Why Open Source Software/Free Software (OSS/FS, FLOSS, or OSS) is important. In: Wheeler, D.A. (Ed.), Open Source Software: New Horizons. IFIP Advances in Information and Communication Technology, vol. 319. Springer, Berlin, pp. 294–307.
Wiggins, A., Howison, J., Crowston, K., 2009. Heartbeat: measuring active user base and potential user interest in FLOSS projects. In: Boldyreff, C., et al. (Eds.), Open Source Ecosystems: Diverse Communities Interacting. IFIP Advances in Information and Communication Technology, vol. 299. Springer, Berlin, pp. 94–104.
Jonas Gamalielsson is a researcher at the University of Skövde’s Informatics Research Centre. He has conducted research on open source and open standards in several projects. He has been involved in the Open Source Action (OSA) project (2008–2010), the Nordic (NordForsk) OSS Researchers Network (2009–2012), and the ITEA2-project OPEES (Open Platform for the Engineering of Embedded Systems). Further, he is participating in the ORIOS (Open Source based Reference implementations for Open Standards) project. He has also been involved in the Fifth and Eighth International Conference on Open Source Systems (OSS 2009 and OSS 2012).
Björn Lundell is a senior researcher at the University of Skövde’s Informatics Research Centre. He has been researching the Open Source phenomenon for several years and participated in a number of research projects in different leading roles, including: co-lead for a work package in the EU FP6 CALIBRE project (2004–2006), the project manager in the Swedish National Research Project OSS (2005–2008), and is currently the project leader for the ORIOS project (2012–2015). He is a founding member of IFIP WG 2.13 on Open Source Software, and was program co-chair for the Eighth International Conference on Open Source Systems (OSS 2012).