1. Introduction

Practices in production and development that favour access to the end product’s source materials are frequently labelled by the term ‘open source’. These methodologies are commonly applied to the peer production development of software source code that is shared online for public collaboration and reuse as open source software (OSS). A concept map of OSS methodology is provided in Figure 1. Before ‘open source’ became widely adopted, developers and producers used a diversity of terms to convey the same idea, being ‘free software’ the mostly used expression. The name ‘open source’ rose in popularity with the global spread of the Internet that provided access to diverse production models, communication paths, and interactive communities.

OSS may be used, studied, and modified by everyone without restriction, even for commercial use or development. Copy and redistribution are also permitted with the only restriction being that further recipients will have to hold former rights. To secure these rights, not only the binaries but also the source code1 must be made available to the recipient along with a legal license granting the above permissions.

OSS could be under a GPL-type license, meaning that derivative works must be licensed the same way, or under the more permissive BSD-type license, which sets minimal restrictions on how the software can be redistributed even just enabling privative redistribution. The broader terms ‘restrictive’ and ‘permissive’ licenses are sometimes found in the primary literature on open source licensing to refer to GPL-type and BSD-type licenses.

Open source and free software describe almost the same category of software, but they are placed on fundamentally different values. According to Stallman (2007) open source is a development methodology focused just on how to make software better but free software is a social movement drawn by an ethical imperative to respect the users’ freedom. The understanding term ‘Free Libre Open Source Software’ (FLOSS) is commonly used to describe the joint characteristics between free software and open source. It emphasizes the loose component of the free software with the Spanish term ‘libre’, avoiding confusion with the no-payment meaning of free.

It becomes apparent at first glance that OSS is a shared resource, a long-enduring knowledge common that would benefit from the interdisciplinary approach that is characteristically in the commons research community. The current paper analyses social and governance aspects of OSS, focusing on sustainability reporting of OSS from a social responsibility approach. To that end, it has two main objectives.

The first objective is to discuss and explain the lack of institutional recognition OSS is suffering in corporate reporting, specifically with the financial reporting framework view of what an asset is. This view heavily relies on traditional private property regimes and exclusive rights to the appropriation of benefits. However, OSS is a digital common pool resource, whose key problems are not subtraction and overconsumption but contributions to its code from the community members. Consequently, it doesn’t fit into traditional views of financial reporting as defined by accounting standard-setting bodies. Because of this impediment, it becomes impossible to report OSS value on financial statements.

Growing institutional recognition should be achieved for OSS through corporate reporting. It fosters and determines the behaviour of individual, communities and organizations that revolve around creation and reuse of OSS. We claim a reporting model based on social responsibility framework may be suitable to fulfil corporate reporting about OSS. At the same time, it may strengthen self-governance mechanisms. We also advocate that contributions to OSS are a higher stage of socially responsible activities. They represent the construction of a high-value shared resource freely available to the whole society, and not just restorative activities focused on repairing the harm caused or revealed by the economic activity, as it is usual in other industries.

Once the need of a reporting framework has arisen, our second goal is to identify the principal stakeholders in an open source project and the main indicators in order to measure open source projects performance. A Delphi process was employed in order to provide the basis to this objective. Results might be useful for those open source projects pursuing adequate communication of their environment and results, and interested in improving their self-governance mechanisms as well.

2. Open source software and corporate information

The open source model has resulted in a large and efficient ecosystem of software innovation, freely available to society. Because open source assets are developed collectively, there is no single source for cost estimates of how much it has taken to develop the technology. Even large projects with company backing do not have these cost estimates due to the collaboration of multiple external developers and to the reuse of code in their projects. There is a great value on open source developments, but the current legal framework for financial reporting doesn’t allow reporting on them like on other assets. Thus, financial statements could be insufficient to assess properly the performance and the value generation potential (García-García and Alonso de Magdaleno 2013).

Driver (2010) estimated that by 2012 around 80% of software products firms would use OSS. Another report by Hammond (2009) presented a conservative estimation of 46% of firms included in a global survey that were using or developing OSS. Therefore, there are little doubts about the general interest for a wide audience of finding indicators and metrics to evaluate OSS projects. Daffara (2012) estimates the contribution of open source to Europe’s economy as being around 450 billion euros per year, taking into account direct cost savings but also other benefits like reduced project failure and lower costs for code maintenance. Communities, foundations or public and private companies developing OSS acknowledge the community upon they are dependant in their annual reports, noting the importance of contributions to develop and encourage the project and ensure its adequate evolution. Nevertheless, despite the many gains attributed to open sourcing, no meaningful information about it is being disclosed in annual reports.

There are also some notable projects that make available tools and metrics to understand collaborative production of OSS, aiming at creating models for measuring sustainability of OSS projects: Ohloh,2 FLOSSMetrics3 or FLOSSmole4 collect and freely provide data with information and metrics about OSS development coming from several thousands of software projects. In addition, several techniques have been created to define an evaluation process for OSS focusing on features like the maturity, the durability and the strategy of the organization around the OSS project itself, but also adding functional aspects to the evaluation procedure: Open Source Maturity (OMM) models from Capgemini, Navica and QualiPSo, Qualification and Selection of Open Source software (QSOS), Open Business Readiness Rating (OpenBRR), Open Business Quality Rating (OpenBQR) and Model for Open Source Software Trustworthiness (MOSST) from QualiPSo. These sorts of processes, products, resources and quality metrics matter and are important to build trust in the development process of organizations using or producing OSS, but are not the ultimate answer to assess the economic and social value of OSS.

2.1. Legal framework for financial reporting

Although the financial reporting framework is able to deal with cooperative production through legally incorporated organizations, it is not ready to cope with the more challenging commons-based peer production. Conditions imposed by this framework in order to recognize the existence of an asset and its value are the key factors to shape the institutional acceptance of OSS and any other digital common at reporting level.

Under the standard framework of accounting standards for financial reporting used in any given jurisdiction, general volunteer activity is not reflected on financial statements. Current accounting framework ignores activities carried out by users and outside of formal productive contexts. Consequently, commons-based peer production value could not be recognized or reflected on financial statements; even though this volunteer activity encloses not only individuals but also corporations contributing software into the open source movement.

Following Bauwens (2005), commons-based peer production are those processes that:

  • Are geared to produce use value for a community of users through the free cooperation of producers who have access to distributed capital.
  • Are governed by the community of producers themselves, and not by market allocation or corporate hierarchy.
  • Make this use value freely accessible on a universal basis, through new common property regimes.

Assets, also known as economic resources, are the fundamental concept in accounting and financial reporting. IASB (2001) defines an asset, physical or intangible, as a resource controlled by an organization as a result of past events and from which future economic benefits are expected to be collected. In addition to this, intangible assets are specifically defined as identifiable non-monetary assets that cannot be seen, touched or physically measured, which are created through time and/or effort and that are identifiable as a separate asset. According to International Accounting Standard 38 (IASB 1998) the three critical attributes of an intangible asset are separate identifiability, control and future economic benefits.

Particularly, an entity must control an item’s future economic benefit to be able to consider the item as its asset. The classical view of control over assets is based on scarcity: To enjoy an asset’s benefits, an entity generally must be in a position to deny or regulate access to that benefit by others. The entity having an asset is the one that can exchange it, use it to produce goods or services, exact a price for others’ use of it, use it to settle liabilities, hold it, or perhaps distribute it to owners (FASB 1985). Outstandingly, peer production generated assets face the problem of the control over them. Under open licenses there is one organization that keeps some minor legal control over the asset. But it doesn’t hold any real control about its uses and economic exploitation; any organization that freely receives the asset can use it to generate income.

Despite the main essence of an asset being its future economic benefit, the traditional view is built around viewing them as private goods. In consequence, superfluous attention is placed on the past transaction or event that gave rise to an asset. Nevertheless, the means of procurement should not have an effect upon whether the assets fulfil critical attributes. Under IASB (2001) an asset is recognised in the balance sheet when it is probable that the future economic benefits will flow to the entity and the asset has a cost or value that can be measured reliably. In accordance with FASB (1985) anything that is commonly used to produce goods or services, whether tangible or intangible and whether or not it has a market price or is otherwise exchangeable, also has future economic benefit. That is to say any resource with the capacity to give rise to cash inflows or a reduction in cash outflows (savings), at the present time, is an asset, rather than whether or not it was acquired at a cost. Hence, the problem with OSS valuation on the current financial reporting framework is not the absence of a registered transaction but the lack of exclusionary rights to an economic benefit.

But even though a registered transaction is not a required attribute, historical cost accounting is considered more conservative and reliable in order to enter an asset in the accounts. Historical cost accounting records the value of an asset as its acquisition value because it is objective and verifiable. Fair value accounting, in contrast, records the value as a current amount at which an asset could be exchanged between knowledgeable and willing parties in an arms length transaction (IASB 2011); fair value is estimated using valuation techniques if market prices for identical or similar assets are not available, with recurrent measurements to capture changes in values over time. At the present time, there are not any valuation techniques suitable to commons based peer production assets. However, higher volatility on assets under the fair value approach and conservative accounting principles make fair value limited by historical cost, thereby requiring a past transaction that does not indeed exist for OSS.

It is self-evident that the traditional view of assets has become unable to deal with shared resource systems. OSS is clearly an asset, so far as one can see it embodies future economic benefits to any entities employing it in their regular business or activities. Regrettably, accounting standards are based on a traditional private-goods-centric view of assets, which sets exclusive control as a mean to profit through competitive advantage. How this biased viewpoint spreads through whole standards-setting processes is shown by two meaningful and generally accepted by default accounting principles: (1) assets definition is identical even for not-for-profit entities, which are not headed for surplus through competitiveness but for common good; and (2) no future economic benefit can simultaneously be an asset of more than one entity, so an asset would be expected to appear in only one set of single entity financial statements. Those scholars interested in a comprehensive research about shared resource systems and financial reporting may have a large field of research available in order to enlighten the relationship.

Regardless of how the above could be suitably solved, there would still exist a strong technical deterrent: a value is needed to recognise an asset in a balance sheet. Once historical cost valuation is simply discarded due to the absence of a previous transaction, the fair value approach requires accurate valuation techniques since market-based values are not available. But there is not a suitable procedure so that OSS full potential value could be accurately measured. Although some techniques based on measures such as programming effort or savings have been developed in recent years, they are only partial measures not capturing the wide scope of OSS as a shared resource system. Again, scholars may be challenged by thorough research on techniques from which realistic and objective valuation, useful for financial reporting, could arise.

Until both referred problems are solved, commons-based peer production won’t fit in the financial accounting framework. Thus, what may be an organizations’ most valuable asset is removed from financial statements, and a whole ecosystem of commons-based innovation might be left aside from the entities’ valuation and performance.

2.2. Sustainability and self-governance

The term ‘tragedy of the commons’ was coined to describe the economic processes that destroy natural common resources by over-exploitation. These processes first described by Hardin (1968) apply whenever a good is rivalrous (consumption of the good by one individual will reduce availability of the good for consumption by others) but non-excludable (no one can be effectively excluded from using the good). This type of resource is frequently called ‘common pool resource’ (CPR) and creates the ‘free rider’ problem, when someone consumes a resource paying less than the full cost. Free riding can lead to the non-production or under-production, or to the excessive use of a CPR. The classical economic view offers two ways to deal with this matter: privatizing the CPR to an owner with a direct interest who can govern its use, or imposing regulation from outside the system; neither of which has been necessary on OSS.

Commons-based peer production concept is a necessary background to fully understand the whole set of complex incentives and motivations driving current business models in OSS and their associated sustainability alternatives. It describes a new model of socio-economic production in which the creative energy of large numbers of people is coordinated by means of the Internet into large, meaningful projects mostly without traditional hierarchical organization and often, but not always, conceived without financial compensation for contributors (Benkler 2002, 2006). According to Tapscott and Williams (2006) individuals participation in peer-production would be explained by a wide range of intrinsic and self-interested reasons, basically because they feel passionate about their particular area of expertise and enjoy creating something new or better.

Software is not a classical CPR because is not rivalrous; there is no cost to the actual users or developers if an extra user gain access to it. But an open source project is clearly a CPR; it succeeds or fails according to contributions from its members. Software can’t be destroyed by overconsumption, however present and potential contributors are the real scarce resource in an open source project, which could drive to overproduction or underproduction of code. Von Hippel and Von Krogh (2003) consider OSS development to be a ‘private-collective’ model of innovation: privately funded with collective benefit. Developers contribute to OSS because they collect private benefits not available to free riders. Several authors have addressed these private benefits: own satisfaction (Raymond 1999), career improvement through higher reputation (Lerner and Tirole 2002) -although this benefit have been disputed by Bitzer et al. (2010)- or mixed internal and external motivations like fun, altruism, reciprocity, career prospects, or self-development (Hars and Ou 2002; Lakhani and Wolf 2003; Roberts et al. 2006; Oreg and Nov 2008). While this research explains why developers contribute to the production of OSS it is not clear how communities lead these efforts to reach the final objectives in an individual project.

In this line of thought, O’Mahony (2003) argues that OSS share some features of CPR problem in that the regulation of behaviour in a manner that maximizes collective gains is of concern; OSS would be non rivalrous, but vulnerable to use that could threaten its availability to all through proprietary appropriation. Hence, communities would develop mechanisms to govern themselves and manage their work, especially when it is distributed in commercial markets or becomes the basis for standards. In general terms, self-governance is the result of collective action combining knowledge and will on the one hand, and supporting and consistent institutional arrangements on the other hand (Wagner 2005). When applied to OSS, self-governance arises from the gathering of programming skills of developers, and the will of a community powered by ethical or business reasons; this collective action is supported by a legal framework embodied in software licenses and community codes of conduct, and by technical artifacts allowing collaborative software development over the Internet.

It has been a decade since Weber (2004) stated: ‘The open source process is an ongoing experiment. It is testing an imperfect mix of leadership, informal coordination mechanisms, implicit and explicit norms, along with some formal governance structures that are evolving and doing so at a rate that has been sufficient to hold surprisingly complex systems together’. Still we don’t have enough evidences about the self-governance structures, although Schweik and English (2007) found that they were mostly informal and quite flat because they were viewed as a barrier to free creativity and innovation. Nevertheless, ideal mechanisms should be similar to those included in the theoretical framework built by Ostrom (1990) studying CPRs that follow an alternative path to avoid destruction by means of agreement and self-generated governance. If we assume that OSS is a type of CPR produced by means of common-based peer production, we should focus on the creation of new code and its relationship with the free rider issue. It pays back for a contributor to wait for new software or feature to be developed for someone else, rather than worth the cost of developing themselves, or to create a competitive advantage by not contributing modified or new created code back to the community.

Some attributes of CPRs and appropriators are frequently associated to an increased likelihood of self-governance arising from consensus (Ostrom 1992). Some of them could be also applied to OSS and contributors:

  • Indicators: Reliable and valid indicators of the condition of contributions should be frequently available at a relatively low cost.
  • Predictability: The flow of contributions should be relatively predictable.
  • Salience: Contributors should be dependent on the CPR for a major portion of their livelihood.
  • Common understanding: Contributors should have a shared image of how the resource system operates and how their actions affect each other and the resource system.
  • Trust and Reciprocity: Contributors trust one another to keep promises and relate to one another with reciprocity.
  • Autonomy: Contributors are able to determine access and harvesting rules without external authorities countermanding them.
  • Prior organizational experience and local leadership: Contributors should have learned at least minimal skills of organization and leadership through participation in other local associations or learning about ways that neighbouring groups have organized.

Furthermore, an adequate communication may affect the level of cooperation and enhance the relationship within the community of CPRs users (Poteete et al. 2010). As regards OSS contributors, there is not reason to think it would be different.

Whatever reporting framework to be adopted on OSS, it must conform to these attributes. Certainly, OSS is a high valuable asset for organizations, although it cannot be reported and valued on financial statements due to shortcomings set forth in Section 2.1. Hence, a lack of institutional recognition for OSS as a shared resource might arise.

2.3. Social responsibility and sustainability reporting

The discussion around open source and free software terms outstandingly resembles the debate around the social role of business, which has been dominated by the concept of corporate social responsibility (CSR). The ‘open source’ term was coined as merely an instrumental definition to deal with the dual meaning of the term free at ‘free software’ in the business realm.5 Both terms describe the same set of software but they stand for views based on fundamentally different values: while open source is a practical development methodology focused on how to make software better, free software is an ethical imperative that pays attention to software users’ essential freedoms (Stallman 2001).

Business developing OSS project their shadow on the social scene in a similar way to not-for-profit organizations. This clearly remind us the moral management model developed by Carroll (1991), wherein business is expected not only to do well at economic and financial levels but to do good at social level: first, doing what is right and fair (ethical level), and then contributing financial and human resources to the community and improving quality of life (philanthropic level). It also drives the discussion on reporting OSS assets to sustainability or social responsibility reporting.

Both concepts –open source and free software- and their set of values could be integrated in different levels of classical Carroll’s CSR pyramid as seen on Figure 2, thus closing the gap between their philosophies. Open source values are the basic building block, a development methodology with a high level of operating efficiency. Free software values and their engagement to sharing and cooperation are the uppermost piece of the pyramid, a shared resource which everyone can use and improve. In the middle of the pyramid, legal responsibilities embody the particular obligations determined by open source license terms and other legal commitments, while ethic responsibilities comprise those activities and practices. OSS projects are not only expected to obey the law as society’s codification of acceptable and unacceptable behaviour, they are also expected to obey the set of particular rules that are endorsed in their own legal artifacts (i.e. licenses, trademark policies, copyright assignment and corporate existence). Projects adopt the language of the law to organize their operations, adding a legal layer to the structural sovereignty of these projects (Coleman 2012). Ethics values of OSS become the driving force of the legal artifacts produced by communities, thus they might reflect higher behaviour standards than that currently required by legal framework. Their roots are grounded in the values and philosophy that are standard in the hacker community. Hacker ethics were first described by Levy (1984): sharing, openness, decentralization and improvement to quality of life were core to hackers and free software developers. According to Coleman and Hill (2005) they are reinforced in the communities through the sustained collaborative development of code, and discussions and decisions about licenses and project policy. Open source focus on business performance by stressing practical benefits has often been interpreted as a denial of the ethics of software freedom. However, these ethical foundations were not eliminated by the corporate acceptance of OSS, moreover its success in the commercial sphere has the effect of rendering visible these underlying ethics to a broader audience (Coleman 2012).

Once the relationship between OSS and social responsibility becomes apparent, benefits other than mere reporting should be analysed. Several studies show that mandatory disclosure of sustainability information leads to an increase in the social responsibility of business leaders and to a prioritization of sustainable development while establishing social legitimacy (Godfrey 2005; Margolis et al. 2007; Ioannou and Serafeim 2011). As seen by Porter and Kramer (2011) these findings suggest that sustainability reporting can change organizational behaviour and provide higher economic value through competitive advantage. Therefore, voluntary sustainability reporting may enhance the economic value produced by an open source project.

A sustainability or social responsibility report is an organizational statement that discloses information about economic, environmental, social and governance performance. Since organizational capacity to prevail is based on performance in these four key areas, a growing number of organizations are using this sort of non-financial reporting not just as an accountability tool but to drive strategy, unlocking new sources of revenue and growth (Lungu et al. 2011).

On the open source model of operation and decision-making sustainability reporting might also serve as a tool for engaging with stakeholders. A stakeholder is any individual or entity that may affect or be affected by organizational practices or processes. Within the OSS domain several major groups of stakeholders could be identified (see section 4 for a specific OSS list); their different agendas, approaches and priorities are intrinsic features of a collaborative and open methodology. Stakeholder management seeks to integrate groups into managerial decision-making by establishing a dialogue that helps to address the question of responsiveness to the generally unclear signals received from the environment (Garriga and Melé 2004). Hence, sustainability reporting may gather the multiplicity of legitimate interest of all stakeholders in order to secure useful input to organizational and self-governance processes, enabling a strong assessment of the shared resources performance and becoming key to support continuous improvement over time in the open source community.

In broad outline, scholar research has attempted to link management practices to financial performance. Margolis et al. (2007) conducted a meta-analysis of 192 effects revealed in 167 studies during 35 years. They found an overall small positive effect of social responsibility over financial performance. On the one hand, the association was stronger for charitable contributions, revealed misdeeds and environmental performance and when social responsibility was assessed more broadly through observer perceptions and self-reported social performance. On the other hand, association was weakest for corporate policies and transparency and when social responsibility was assessed through third-party audits and mutual fund screens. Nevertheless, no financial penalty for sustainability reporting was found.

Although it is clear that social responsibility generates some kind of financial return, it is not so clear the mechanism through firms obtain the return. Two different views have tried to explain this mechanism. Jones (1995), Preston and O’Bannon (1997), Waddock and Graves (1997), Margolis and Walsh (2003) and several other studies have shown that both views could be at work. Based on Cheng et al. (2014) these are the most frequently found mechanisms:

Institutional reporting to members of the community and society is a key objective in order to create institutions to governing the commons and to take advantage of socially responsible activity. In the next section, we examine stakeholders and indicators in order to evaluate sustainability in open source developments, because we believe non-financial reporting is clearly suitable to empower attributes that encourage self-governing forms.

3. Methodology

We have used Delphi methodology in order to extract and summarize the knowledge from a group of experts. Delphi is developed to reach a consensus from an expert panel for researching complex issues where knowledge is limited. It does not offer the rigour of statistical testing or quantitative analysis, but it provides a scientific methodology that is well suited to issues that require the insights of subject matter experts, because it allows the respondents to revaluate their answers (Grisham 2009). Delphi involves expert panel, repeated rounds, opportunity for respondents to rethink their answers and anonymity of the experts. The experts answer questionnaires in two or more rounds; when a round has been finished an anonymous summary is fed back to participants in order to encourage them to revise earlier answers in the common belief that the range of answers will decrease and converge towards a consensus. Experts do not interact with each other, therefore situations where the group is dominated by the prevailing views of outstanding participants can be avoided. Measures of central location and dispersion of the final rounds determine the degree of consensus.

What is an expert does not have a clear and undisputed meaning in academic literature. However, there should be clear that an expert is an individual possessing great knowledge from personal proven experience over the field of study (Linstone 1999; Goodman 2006). Expertise is paramount to Delphi method, not being a statistical technique it does not depend on selecting a representative sample but on a set of individuals with a deep knowledge in the issue under research (Okoli and Pawlowski 2004). Accordingly, the criteria for selection of the experts become qualitative-critical (based on their knowledge) but not quantitative-critical (total number of experts). Literature suggests a range of experts from ten to thirty for each group formed around an issue, performing better in heterogeneous groups but tending towards the upper range in homogeneous groups, depending on the professional and social diversity of their members (Okoli and Pawlowski 2004; Peffers and Tuunanen 2005; Gallego Pereira et al. 2008).

A target of at least ten experts was set in order to maximize success in our research. We were aware that this figure placed the study in the lower bound of the range considered in academic literature. However, professional heterogeneity was controlled to counterbalance this handicap.

Delphi questionnaires were sent to twenty-six Spanish open source experts, who were selected by their involvement in OSS projects and communities. According to a survey led by the UNU-Merit in 2002, Spain had the third largest community of OSS developers (6.7% of total worldwide developers);6 in 2009, Global Open Source Software Potential Index listed Spain as one of the top-ten countries with the highest level of open source activity;7 Spanish National Open Source Software Observatory declared in 2010 that Spain was among the most active countries in the EU in terms of OSS adoption.8

Participants were classified into three categories based upon professional affiliation: practitioners, civil servants and faculty members. Response rate was fourteen questionnaires in the first round and twelve questionnaires in the second and third rounds. The expert panel was composed of nine practitioners (six were affiliated to private companies and three associated to not-for-profit entities), three civil servants from technological institutes and two faculty members; all of them belonging to different institutions and regions. The open federal nature of Spain and large cultural variations between its various parts make this sample of experts broader than it may appear. The study was conducted between January and July 2012.

In a first step most important organizational stakeholders were identified. Stakeholders are individuals and organizations that are actively involved in the project, or whose interest may be positively or negatively affected as a result of project execution or project completion. Initial identification was based on usual stakeholders in any kind of organization. In order to better focus their identification and influencing factors, they were confirmed by review of most notably previous research works and business strategy reports (Krishnamurthy 2005; Riehle 2007, 2011; Aslett 2008, 2010).

In the first round, the experts were asked to rank the pertinence of each stakeholder on a 5-point Likert scale ranging from ‘Strongly Disagree’ to ‘Strongly Agree’. They were allowed to propose any other stakeholder or remark about them that they considered properly. Members were also pledged to suggest any relevant indicators for each stakeholder in the questionnaire.

In the second round, we added new indicators to the panel proposed ones, largely based on institutional characteristics of stable local CPR management identified by Ostrom (1990, 2005) and on our previous work (García-García and Alonso de Magdaleno 2012). Indicators were arranged into several classes intending to reflect a set of core measurable aspects for any open source development: organizational profile, community profile, activity in the community, persistence of collaboration, support and role of community and community success (see Results section for a full list). For each class, experts were asked to rank the importance of each indicator on an ordinal scale from the most to the least important. They were as well requested for validation of the remarks contained in first round. A third round was later conducted in order to feedback second round results.

The main data collection tools were questionnaires designed by the researchers in each of the three rounds. Each one had been previously tested with a reduced set of experts that didn’t take part in Delphi panel. Questionnaires were submitted by email as forms with closed and open-ended questions to be answered at locked fields in Open Document Text files (*.odt). Given their vast expertise and experience in open source software domain we supposed that it wouldn’t constitute a response barrier while offering more flexibility in the questionnaire design over web survey tools.

Building consensus is an essential component of any Delphi process and is usually estimated through measures of central tendency and dispersion. Although arithmetic mean -the average of a set of values- is commonly considered the descriptor that best summarizes a statistical distribution, the median -middle value of a sorted set- rather than the mean is preferred as representative of the group’s responses in Delphi, since single extreme answers could pull the mean unrealistically. Even though when dealing with Likert scales the median is constrained to the actual categories in the data and can only fall in one of these categories, hence smaller changes in the distribution of values are not faithfully displayed. Interpolated median (IM) provides a way to adjust the median to avoid influence of great scale granularity of response categories.

We use the following formula in order to calculate the IM, according to Young and Veldman (1972) and Kiess and Green (2009):

where L is the lower limit of the interval containing the median, W is the width of the interval containing the median, N is the total number of frequency, CF is the cumulative frequency corresponding to the lower limit of the interval that contains the median and F is the frequency in the interval containing the median.

Frequency distribution, first and third quartiles of previous round answers were provided to the experts in order to compare and think over initial reply. Any qualitative remarks or proposals were also anonymously conveyed to contribute to clarify their responses.

4. Results

A. Stakeholders

Initial stakeholders proposed by researchers had great acceptance among experts. Table 1 contains the results of the Delphi process related to Likert evaluation. Interpolated median (IM), standard deviation (SD), first quartile (Q1) and third quartile (Q3) are shown for each stakeholder.

All but two proposed amendments to the initial listing of stakeholders were rejected in the second round of evaluation. The first modification to the initial listing was to put universities and research groups together with allies in technological development [OSA3 group]. Second amendment was related only to micro and small-sized enterprises;9 firm owners and shareholders [IS1], and management leadership or government bodies [IS2] should be joined together because the same individuals would play their roles.

The greatest disagreement, in accordance with the larger values of SD, was related to the relevance of economic actors including development to hardware or software products [OSA1], financial donors [OSA5], competition (OS or privative) [OSB3] and civil society [OSB5].

Relative to OSA1, experts agreed this is a very heterogeneous group where many of the actors simply collect the code and assimilate it to their products. Usually, small-scale developers or hardware assemblers without technical of financial capacity to make code contributions, they behave as ‘free-riders’ taking advantage of OSS licenses. Some experts suggested they should be merged with customers and software users [OSB1]. Nevertheless, the suggestion did not reach consensus on the second round due to the potential offered to be contributors in the near future.

The cause of disagreement was very similar to the group civil society [OSB5]. Although the full society benefits if software is developed as a digital common, civil society is a heterogeneous group, with scattered interests and poor organization. Consequently it is not easily defined as a stakeholder to an OSS development. A few experts felt civil society representation should be attributed to governments as guarantors of the general interest or common good. Hence, stakeholders OSB4 and OSB5 should be merged. However, majority decision was to keep then separated in order to distinguish wealth creation for society from government role as a major decision-maker.

Groups competition (OS or private) [OSB3] and financial donors [OSA5] were the groups with larger disagreement; indeed, the latter were also the group with the lowest IM valuation. However, both were clearly recognized as stakeholders; no member of the panel asked for their deletion. Competitors have a dual behaviour. On the one hand, they monitor the development of competing products by comparing software features and communities. On the other hand, they could be seeking collaboration. OSS philosophy allows for competitors to play a collaborative role joining forces in order to obtain a commoditized code of software that could provide a basis for own future developments. Privative software firms are usually involved in this collaboration when the license imposes minimal restrictions on the redistribution of covered software (permissive licenses); companies in this case should be included as components of the OSA group (outside stakeholders financing or taking active part in development efforts).

Despite not being considered irrelevant, the lowest rating of group financial donors [OSA5] was explained by experts as the result of two main reasons:

  • Financial donors are mainly focused on getting a freely available software product. They are not drawn into development stages, their role being similar to those contributing to crowdfunding projects.
  • Financial statements of not-for-profit or business in charge of project management should be enough to meet funders’ information needs, focused on ensuring OS project is properly funded.

Whether it is based on not-for-profit or on a firm, OSS development is dependant on financial funding almost as much as it depends on code contributions. Major OSS projects often hire coders to supplement voluntary contributions. Keeping their community alive and active also requires monetary funding. Thus, we firmly believe that the role of financial donors in OSS is worthy of further investigation in both not-for-profit and business entities. Clearly, their role is more significant in the former than in the latter since business entities mainly use equity investment to finance their activity.

Greatest agreement, according to the lower values of the SD, was reached for firm owners and shareholders or project members [IS1], independent contributors [OSA2] and other OSS communities [OSB2]. It is not surprising the data is showing the fundamental social interaction between insiders and outsiders that outlines the commons-based peer production processes. CPR nature of OSS is also present in these three stakeholders, but only at contribution level. This result is consistent with our landscape, which assumes an open source project is a CPR that succeeds or fails according to contributions from its community.

The panel of experts also agreed that stakeholders groups and relevance could be slightly modified depending on the following attributes of the OSS project:

  • Aimed at addressing the needs of a specific industry or market (vertical market software) or the needs of a wide range of industries or markets (horizontal market software).
  • Mainly developed for internal use or for wide external circulation.
  • Main actors features: transnational corporation, micro or SME firm, and not-for-profit entity.
  • Software license: permissive license (BSD type) or restrictive license (GPL type).

B. Sustainability indicators

Communication requirements of each stakeholder group, based on their interest and influence, should help implement the sustainability reporting strategy of an open organization. In order to put it into practice, key performance indicators with corresponding parameters, objectives and measures will have to be defined on future stages of our research. Experts in the first round were asked to generate indicators for each proposed stakeholder. In the second round, these indicators were aggregated to further indicators proposed by researchers and based on previous studies. Then, experts were asked to rank the importance of indicators from the most to the least important. Full list of categories and indicators is on Table 2, where the indicators are arranged by descending order of preference in each category.

In order to facilitate a deeper understanding and interpretation, groups of indicators are depicted through box-and-whisker plots on Figure 3. For each one indicator first (Q1) and third (Q3) quartiles are represented by the bottom and the top of the box, and the second quartile (Q2; median value) is represented by the band inside. The ends of whiskers at each box represent the lower and higher values still within 1.5 interquartile range (Q3-Q1). Any data not included between the whiskers is plotted as an outlier with a small circle. At each group indicators are shown from top to bottom in order of decreasing relevance for the experts.

In accordance with the median values and the interquartile range, greatest consensus on the major importance was reached for indicator ‘How community is involved in product design, production, delivery or service’ from category ‘Support and role of community’. Then, ‘Frequency of contact with the community’ from category ‘Persistence of collaboration’, together with ‘Generation of professional networks to ensure continuity and future support’ and ‘How often community collaborates on development’ from category ‘Community success’ ranked second. Importance on median values but with a wider interquartile range than previous indicators was also showed by ‘Sources of funding, main donors and monetary value of donations’ and ‘Project roadmap’ from categories ‘Organizational profile’ and ‘Community profile’, respectively.

In view of the results these indicators could be considered sufficiently representative of their category information needs. This result is also consistent with the values and economic operations of OSS: and activity fully-dependent of a wide community of developers and users and a freely available knowledge that allows local business to be created and empowered, expanding information technologies industry beyond large oligopolistic corporations. The set of indicators displays a great concern about operative and strategic goals of development, even about financial issues although donors hadn’t scored well in previous stakeholder analysis. We do not feel confident to speculate on this latter result, apart from noting that it is probably related to going-concern assessments about the financial capacity to carry out project activities more than related to transparency issues. Again, further research is needed on the relationship between OSS and financial issues to support this guess.

A clear consensus in priority was not reached for the rest of categories. Thus, we must assume that all indicators are valid enough for information needs on each category. However, we did find consensus on the allocation of some indicators to the lower places. Consequently, they could be labelled as limited relevance indicators and not be taken into account.

‘Potential to obtain a paid employment related to the project’, ‘Information about community members (including corporate members)’ and ‘Information about how community members differ from other communities (strengths, weakness, opportunities and threats analysis)’ are clearly assigned to lower positions on community profile ranking. Both ‘Numbers of versions released’ and ‘Conversion from external collaborator to paid employee’ are the last of the ‘activity in the community’ and ‘persistence of collaboration’ lists, respectively. ‘Participation in digital literacy campaigns’ and ‘Processes to generate and communicate promotional and self-spreading campaigns’ are latest on ‘support and role of community’ category. The apparent relegation of this seven indicators shows a set of guidelines to avoid when making a report on OSS sustainability: potential for gainful employment, identity and differentiating features of community members, release history, use in digital literacy campaigns and advocacy and dissemination campaigns are remarkably little valued according to their potential to meet information needs of stakeholders.

The manifest relegation of indicators is remarkable related to gainful employment because it is contrary to the signalling hypothesis developed by Lerner and Tirole (2002). According to this hypothesis individual contributors may use OSS as an opportunity to signal their talents to peers, prospective employers and the venture capital community. In this way, contributors would be expecting direct benefits for themselves when sharing code to an OSS project. Signalling hypothesis has been accepted for years as the main explanation for individuals’ contributions in view of its coherence with economic theory. Nevertheless, it has been recently challenged by Bitzer et al. (2010) and Lee and Kim (2013) who didn’t find support for it in empirical analysis. Their alternative hypotheses are based on ethical and social motivations to build an open and freely available digital commons, regardless of present or future compensations. Our finding is coherent with this new vision that makes contributors less utilitarian and more socially responsible. Nonetheless, whatever motivates contributors to donate software code free of charge, it just deserves a more comprehensive research whose results will be of great concern to any type of OSS social reporting.

The low relevance given to digital literacy and OSS promotion campaigns is also inconsistent with the commonly accepted values of OSS. Experts’ comments allow us to explain this fact by appealing to the proper function of the software development role. Digital literacy and OSS promotion campaigns would be functions attributed to user groups, NGOs, educational authorities or governments but not to software development entities.

Except as aforesaid as low scored indicators, the remainder ones should be taken into account to report OSS social responsibility and sustainability.

5. Conclusions

This article advocates OSS for digital commons and focus on the issue of sustainability. Knowledge commons are not traditional physical commons, humans must intervene to create them. There is a wide and rich literature studying commons in environmental resources but they face a fundamental difference with digital commons. The former are an existing scarce resource that could be destroyed by over-exploitation. The latter are created and improved through contributions from a community, but they are virtual assets that cannot be over-harvested. Institutional design is essential to overcome the destruction of natural commons through self-governance processes that manage collective action. We can assume that it would be also paramount when dealing with knowledge commons.

OSS creation and improvement are totally dependent of the flow of code contributions but essential to this is the institutional recognition required in order to extend corporate contributions. Although financial valuation is not allowed under current accounting framework, it becomes plausible to report contributions and project performance within the framework of social responsibility. This type of reporting might be able to increase the institutional recognition of OSS development activities, furthermore it might strengthen the capacities to execute collective action and self-governance processes.

Our work tries to close the gap between the informational needs of self-governance structures in a collective action environment and the current framework for corporate and financial reporting by formally specifying the role of OSS as a CPR and the code contributions as a socially responsible activity. To this end, we performed a search for stakeholders interested in OSS developments, and a core set of indicators for sustainability and social responsibility reporting. Study was based on Delphi methodology.

Stakeholders were divided into groups according to their relationship to the OSS project. Outsiders were subdivided into those financing or taking active part in development, and those unrelated to financing or development efforts. Indicators were grouped into six categories according to their qualities. A broad consensus among experts was reached on stakeholders, especially on those related with the production process. However, economic actors including the OSS development to their hardware or software products, competitors, financial donors and society didn’t reach the same levels of agreement as others did.

Evaluation of indicators showed that those reflecting an economic model based on openness and collaboration with great concern about operative and strategic goals offered the best results. Regarding the rest of indicators, all of them deliver satisfactory results in order to be included in sustainability reports; with the exception of indicators linked with gainful employment, digital literacy and OSS advocacy.

It is highly probable that entities developing OSS -either not-for-profit organizations or business corporations- may not know or use the term ‘social responsibility’, but the creation of a body of common knowledge freely available to society means they have a responsible engagement to their economic activities. Economic actors involved in development are certainly carrying out a social responsible activity. When standing code contributions are made by business, their inclusion on sustainability reporting might be paramount to support future code flows and fair valuation. A suitable reporting framework might bring institutional recognition to OSS so that a positive attitude towards code release and social support to OSS may be created.

This paper opens new horizons in reporting OSS relevance and managing collaborative communities developing and improving a CPR. It offers fundamentals of starting and building a simple social responsibility report. We are aware that most open source projects and communities might be reluctant to spend resources collecting data and publishing reports without seeing tangible results. However, a long-term benefit may arise from drawing attention of stakeholders to the realities of collective action, self-governance issues and sustainability of the OSS project. As for this matter, experts from the business field pointed out in their commentaries the similarities between the indicators and the information collected in order to address quality measures. Hence, if sustainability reporting were aligned with quality standards for software life cycle processes (ISO/IEC 12207), process improvement and capability determination (ISO/IEC 15504), external services management (ISO/IEC 20000-1), IT code of good practices (ISO/IEC 20000-2) or even with general quality standards (ISO 9001), synergies would be generated since there is some kind of parallelism between our proposed indicators and general quality management performance indicators. Business and not-for-profit organizations concerned with a compelling sustainability reporting could also enhance their quality management systems; or vice versa, those entities engaged with quality management systems could be facing an opportunity to start with OSS sustainability reporting and enjoy its benefits.

Therefore, we firmly believe that an appropriate sustainability reporting framework for OSS development activities is an area to explore which would open up new lines of project management and institutional recognition; aiming straight both for industry benefits and common good through a better CPR self-governance.