Robert Viseur
email: robert.viseur@umons.ac.beceticrobert.viseur@cetic.be

From Open Source Software to Open Source Hardware

The open source software principles progressively give rise to new initiatives for culture (free culture), data (open data) or hardware (open hardware). The open hardware is experiencing a significant growth but the business models and legal aspects are not well known. This paper is dedicated to the economics of open hardware. We define the open hardware concept and determine intellectual property tools we can apply to open hardware, with a strong focus on open source licenses and practices. We next conduct some case studies in order to determine which licenses and business models are used by open hardware companies. We show some strong similarities with open source software and propose new opportunities for future works.

Introduction

The open hardware concept covers new practices for hardware creation inspired by open source licenses and development models. The concept is not totally new. Bruce Perens (co-author of the Open Source Definition) already discussed the concept in the book "Open sources: voices from the open source revolution" published in 1999, and describes open hardware from open source model. Open source later gives rise to new initiatives such as open access (in the scientific field), open data (for data owned by companies, produced by research or published by public sector) or free culture [START_REF] Lessig | Free Culture -The Nature and Future of Creativity[END_REF][START_REF] Lindman | Open Source and Open Data: Business perspectives from the frontline[END_REF].

Open, or open source, hardware is known by popular projects such as LEON3 (free processor compatible with SPARC v8 specifications) or Arduino (free electronic board for prototyping and do-it-yourself works). There also were some recent articles in popular newspapers or conferences for professionals. In 2010, the sector was estimated at $50 millions, for 13 main companies and 200 active projects [START_REF] Torrone | Million dollar baby -Businesses designing and selling open source hardware, making millions, O'Reilly's foo camp east[END_REF]. The potential growth was estimated at one billions dollars in 2015. However, business models and legal aspects of open hardware have not been studied in detail.

The paper is organized as follow. We define the open hardware concept and determine intellectual property tools that we can apply to hardware. We then conduct eleven case studies in order to determine business models and licenses that companies use for their projects. Finally we discuss our results and propose future works about open source hardware.

Definitions

The concepts of "free software" and "open source" were defined by two well-known organisms: the Free Software Foundation (fsf.org) and the Open Source Initiative (opensource.org). Such organisms do not exist in the open hardware field, so several definitions can be found. Fortunately a more complete definition was recently created by the participants of the Open Hardware Summit (openhardwaresummit.org). The definition is named "open source hardware definition" and can be considered as reference. It defines 12 criteria and clearly draws on the Open Source Definition.

Note that two kinds of open hardware projects can be found: the "open source IP" and the "open source designs". The projects of "open source IP" are electronic components such as cores (DSP, cryptography, etc.), controllers (Ethernet, I2C, VGA, etc.) or processors (LEON3, OpenRISC, etc.). The projects of "open source designs" are more or less complex designs such as specialized boards (OGP1), prototyping boards (Arduino, Beagleboard, etc.), electronic devices (Ben Nanonote, OpenMoko, etc.) or machines (Makerbot, Reprap).

Intellectual property and business models

The open source hardware consists of some items to protect: (1) the source code for electronics (e.g.: VHDL or Verilog source codes), (2) the source code for associated softwares (e.g.: development tools, SDK, etc.), (3) the schematics, the design files and the technical drawings (what we named "hardware design"), (4) the aesthetic value, (5) the documentations, and (6) the brands.

Several intellectual property tools can be applied (see inpi.fr and [START_REF] Messerschmitt | Industrial and Economic Properties of Software: Technology, Processes, and Value[END_REF]). The source codes are protected by copyrights and sometimes by patents. The technical innovations on machines can also be protected by patents. The aesthetic value of a machine can be protected by industrial design rights. The documentation are covered by copyrights. The name can be protected as a trademark. Note that it exist a legal protection for the topographies of semiconductor products (europa.eu). Some similarities with open source softwares can be found, for example for the protection of source codes (electronics and associated softwares).

The open source software licenses are based on copyright. They allow the authors to fix the softwares user's rights and obligations. Patents can sometimes cover the software [START_REF] Messerschmitt | Industrial and Economic Properties of Software: Technology, Processes, and Value[END_REF]. The free and open source licenses can include clauses about patents (such as documentation or automatic license) and trademarks.

Two families of open source licenses exist: the academic licenses and the copyleft licenses. The fist one (e.g.: BSD, MIT, etc.) allows the user to change the license of the software (a proprietary license can be applied). The second one (e.g.:

LGPL, GPL, etc.) requires the conservation of the license. There are a lot of open source licenses, and some of these licenses are incompatible between them [START_REF] Montero | Les logiciels libres face au droit[END_REF][START_REF] St | Understanding Open Source and Free Software Licensing[END_REF]. That is a problem in the software developments based on reusable components and, by extension, with open source hardwares (e.g.: IP cores sharing).

The licenses strongly influence the business models. The license determines the possibilities for creating value and capturing revenues by modulating the appropriability conditions [START_REF] Muselli | Le rôle des licences dans les modèles économiques des éditeurs de logiciels open source[END_REF]. Free software companies generally create revenues with the distribution of softwares, the services and the software edition [START_REF] Elie | Économie du logiciel libre[END_REF][START_REF] Viseur | La valorisation des logiciels libres en entreprise[END_REF]. The software editor sells add-ons for its open source software or applies dual licensing model [START_REF] Muselli | Le rôle des licences dans les modèles économiques des éditeurs de logiciels open source[END_REF][START_REF] Välimäki | Dual licensing in open source software industry[END_REF][START_REF] Viseur | La valorisation des logiciels libres en entreprise[END_REF]. The dual licensing model implies the software is published under both copyleft and proprietary licenses. The proprietary version benefits from its license, simplifying the reuse in other proprietary developments, or technical differentiation (more features) [START_REF] Viseur | La valorisation des logiciels libres en entreprise[END_REF]. Some licenses are specific to open hardware field, for example the TAPR Open Hardware License and the CERN Open Hardware License (www.ohwr.org; www.ohwr.org). TAPR OSH also exists in a Non Commercial version.

Methodology

We aim to identify emergent practices and determine which business models and licenses are used by companies. We conducted eleven case studies by analyzing organizations with commercial activities in the open hardware field. We presented a draft with partial results in an international conference about free softwares in order to give feedback from more specialized audience.

We mainly used information from the projects Web site or information from projet's owners (presentations, interviews, etc.). We then searched documents published or relayed by newspapers, specialized in computer science or not. We also collected public documents highlighting particular aspects of projects such as relations between companies, relations between companies and communities or important events (conflict, license change, etc.).

We refer to Troxler about the business models of fab labs, Malinen, Mikkonen, Tienvieri et Vadén about open source hardware developers' motivations, and Baldwin, Hienerth and von Hippel about the way from innovations by users to commercial products [START_REF] Baldwin | How user innovations become commercial products: a theoretical investigation and case study[END_REF][START_REF] Malinen | Community created open source hardware: A case study of "eCars -Now![END_REF][START_REF] Troxler | Commons-Based Peer-Production of Physical Goods: Is There Room for a Hybrid Innovation Ecology?[END_REF].

Results

Most of the business models in open source hardware have an equivalent in open source software, except for the distribution of manufactured third party products, and the manufacture and the sell of products, which are inapplicable for softwares. We find, as we would expect, some open source software licenses: BSD, GPL and LGPL. They are used for source codes (electronics and softwares). They sometimes cover hardware design (it is not the intended use for that kind of license).

Hardware design is also covered by Creative Commons licenses (creativecommons.org). The chosen license is often CC-BY-SA. That one allows to copy, to distribute and to modify the work, with a commercial goal or not. It requires to name the original author (BY, for Attribution) and to keep the same license (SA, for Share Alike). That version of Creative Commons applies the copyleft principle (as GPL does with open source software).

One project use a license written for open source hardware (TAPR OSH, for OGP1). The use of licenses forbidding commercial use is uncommon. No one reference to protection of the topology of semiconductor products was found.

Note that the license is not always clearly indicated. When the source code is available, it is often hosted on shared platforms such as Github (github.com), Google Code (code.google.com) or Sourceforge (sourceforge.net).

Discussion

The use of Creative Commons licenses for protecting hardware design raises the question of the protection which is really provided. Indeed, it is not the intended use for that kind of license: Creative Commons licenses were written to cover cultural contents (musics, books, movies, etc.). Moreover a CC-BY-SA license brings freedom to users but that freedom can be canceled by a patent covering the product. The free software and open hardware licenses often prevent or limit this by including clauses about patent, and requiring documentation or automatic patent license.

The use of GPL probably causes less difficulties for open source hardware companies. The companies revenues also come from the manufacture and the sell of products developed in a collaborative way and published under free licenses. The manufacture implies the quality control of the industrial process and the ability to manage the distribution of products. Those capacities can be reached with difficulty by a community. However the customers critical mass and the attraction power of popular brands allow to benefit from economies of scale, to offer lower prices and to invest in new products developments. Moreover quality control allows to face poor quality copies (e.g.: Arduino Asian knockoffs).

The forks are well known in the software field [START_REF] Viseur | Forks impacts and motivations in free and open source projects[END_REF]. They are a consequence of the four freedoms given by free and open source licenses which allow to create a new project by forking source code and community. Malinen and al. note that forking is harder with open source hardware because of the need of physical copies [START_REF] Von Hippel | User toolkits for innovation[END_REF]. However forking is still possible with smaller open source hardware projects. Two studied open hardware projects had been forked: OpenSPARC and Arduino. The OpenSPARC fork is a "friendly" fork. That one was made to simplify product. Several forks was made with Arduino. They were motivated by trademarks issues and by the desire to offer lower price version of products.

Future works

The relation between companies and users (sometimes gathered in communities) is not well known. Some companies, such as Arduino, created business ecosystems, playing the role of leader and receiving positive externalities. Other projects seems more closed. Their owners seem less wanting to exploit the returns from collaborative development than benefit from open source hardware label and capitalize on the commercial attractiveness of documented materials which simplify the developers' work. The interactions between open hardware companies and developers should be further studied. That research could be based on questionnaires sent to the projects leaders or on activity in the collaborative tools.

Table 1 .

 1 Examples of business models for open source softwares and hardwares

	Business model	Example (OSH)	Example (OSS)
	Distribution of designs	Opencores (OpenTech)	Red Hat, Novell (SuSe)
	Dual licensing edition	Gaisler (Leon3)	Trolltech (QT), MySQL
	Services (support, porting,...)	Gaisler	IBM, Novell, Linagora
	Online services (Cloud, SaaS,...)	Bug Labs	Nexedi (ERP5 Free
			SaaS), OpenERP (OpenERP
			Online)
	Distribution of manufactured third	Farnell	-
	party products
	Manufacture and sell of products	Smart Projects (Arduino)	-


Jarkko Moilanen
email: jarkko.moilanen@uta.fi

Emerging hackerspaces -Peer-production generation

Keywords: hackerspace, makerspace, fablab, community, open source, motivation, survey, fabbing, peer-production, movement, sustainability

This paper describes a peer-production movement, the hackerspace movement, its members and values. The emergence of hackerspaces, fablabs and makerspaces is changing how hacker communities and other like-minded communities function. Thus, an understanding of the nature of hackerspaces helps in detailing the features of contemporary peer-production. Building on previous work on 'fabbing', two different sets of results are presented: (1) empirical observations from a longitudinal study of hackerspace participants; and (2) a theoretical description of hacker generations as a larger context in which peer-production can be located. With regard to (1), research data has been collected through prolonged observation of hackerspace communities and two surveys.

Introduction and motivation

Hackers form a global community, which consists of multiple micro-communities [START_REF] Barber | Hackers profiled -who are they and what are their motivations[END_REF]. The autonomous micro-communities are constantly on the move; evolving, mixing, forking, hibernating and dying. The hacker community exists both in the real and the virtual worlds, although the latter is often emphasized. The diversity and autonomy of hacker communities can be described through the different type of activities that hackers participate in. For example some hackers are more prone to do network related hacking while others might be more interested in social hacking. In the broadest sense hackers see the society as a system which can be hacked. Not all hackers are interested in the same set of technologies or programming languages. Some might be more interested in phones, hardware, games or biohacking.

Over the past years hackers around the world, mostly in Europe and North America, have begun to move hacker networks and communities out of the virtual into the real world. They have begun to form hackerspaces, hacker communities which have both virtual and real world bodies. The history of hackerspaces begins already in the 1990's. Farr [START_REF] Farr | Respect the Past, Examine the Present, Build the Future[END_REF] has defined three development waves in hackerspace history. During the early 1990's "[t]he First Wave showed us that hackers could build spaces" [START_REF] Farr | Respect the Past, Examine the Present, Build the Future[END_REF]. Examples of hackerspaces of the 90's are L0pht, New Hack City (Boston and San Francisco), the Walnut Factory and the Hasty Pastry. The second wave occurred during the late 1990's and European hackers (especially in Germany and Austria) began building spaces. The second wave also initiated early theoretical discussions about the development of hackerspaces. The second wave was about "proving Hackers could be perfectly open about their work, organize officially, gain recognition from the government and respect from the public by living and applying the Hacker ethic in their efforts" [START_REF] Farr | Respect the Past, Examine the Present, Build the Future[END_REF]. The third wave started after the turn of millennium. The amount of active hackerspaces in 2010 was 254 [START_REF] Moilanen | Hackerspaces, members and involvement[END_REF] and currently there are over 500 active hackerspaces around the world 1 and a few hundred under construction.

This proliferation of hackerspaces can be seen as a significant change in hacking and the formation of hacker communities. Hackers are setting up new kind of communities, with features unknown in earlier hacker communities. Since the hackerspace movement is relatively new, a simple and compact definition of "hackerspace" is still missing even among the persons who are involved in the movement. Different hacker communities use different names: fablab, techshop, 100k garage, sharing platform, open source hardware and so on. The variety of names for the new 'do-it-yourself' communities expresses the variety and diversity of the movement, which might be best described as a "digital revolution in fabrication [... which] will allow perfect macroscopic objects to be made out of imperfect microscopic components" [START_REF] Gershenfeld | Fab: the coming revolution on your desktop -from personal computers to personal fabrication[END_REF]. Scientific attempts to clarify the differences of various 'do-it-yourself' hacking communities are still rare. A shared understanding of how to use the different descriptions and names of the movement is still missing, but some attempts toward a consensus exist.

Methodology and research questions

The hackerspace community has gone through several discussions about what a hackerspace is. Consensus has not been reached, but the discussions have brought up some criteria for what being a hackerspace means. Firstly, a hackerspace is owned and run by its members in a spirit of equality. Secondly, it is not for profit and open to the outside world on a (semi)regular basis. Thirdly, people there share tools, equipment and ideas without discrimination. Fourthly, it has a strong emphasis on technology and invention. Fifthly, it has a shared space (or is in the process of acquiring a space) as a center of the community. Finally, it has a strong spirit of invention and science, based on trial, error, and freely sharing information. 2The five criteria have been tested by conducting a yearly survey of hackerspace communities. So far, the survey has been conducted twice, in July 2010 and June 2011. In addition to questions on the criteria, the survey contains questions which aim to provide more information about the values, interests and motivations of members of different hackerspaces around the world. The overall research setting contains elements of social anthropology and ethnographic methods such as observation. The author has been an active member of the hackerspace community both locally and internationally since 2009. The information gathered by living and working as a part the community is used in directing and conducting the research.

The research was inspired by discussions that have been going on through the hackerspaces mailing list (http://hackerspaces.org/wiki/Communication) for ages. The discussions have included several questions such as "What is a hackerspace? How can it be defined? Should some of the spaces listed in hackerspaces.org be removed or not? If so, based on what criteria?" The result has been almost always the same. Hackerspaces can and should not be defined rigidly, because that would create artificial boundaries and that is not a part of hacker culture or values. Discussions have involved business aspects, too. Some hackerspaces are more oriented toward business than others. It has been debated whether so called commercial hackerspaces should be seen as hackerspaces or not. Consequently, an interesting research question is the attitude towards donations (money, devices, equipment) coming from companies. Does the desire to be independent rule company donations out? What about governmental support? Is that more acceptable? Thus, questions on funding were added to the initial set of questions, that can be grouped under four headings: 1) What kind of hackers/people participate in hackerspaces? 2) What is the motivation to participate and 3) what do people do in hackerspaces? Additionally, 4) What is the bigger context of hackerspaces?

The latest survey was launched on June 16th, 2011 and was closed on June 30th, giving two weeks time to participate. A message about the research and a link to the online survey was posted to hackerspace discussion list (http://lists.hackerspaces.org/mailman/listinfo/discuss), the diybio list (http://groups.google.com/group/diybio/topics) and some other minor hacker oriented lists. The survey was not advertised in social media in order to avoid biased participants. If twitter or other social media would have been used in launching the survey, some non-hackers would have most likely taken the part. A reminder was posted a few days before closing.

The longitudinal survey discussed in this paper continues 2012 as P2P Foundation project, which can be found from http://surveys.peerproduction.net. All information collected with surveys will be anonymized and open sourced under Commons license.

Results

The survey in 2011 seems to confirm most of the results found in 2010. No dramatic changes were found. (A comparison of the basic numbers from both surveys is presented in table 1.) Two hundred and fifty (250) participants (25 females, 223 males, 2 'no answer'; mean age = 31 years, range: 13-62 years) from 87 hacker communities in 19 countries took part in the study; in 2010 there number of participants was 201. The majority of the respondents were from active hackerspaces (90,4%). Similarly, the most of the respondents were members in only one hackerspace (90,8%). About 48% of the participants lived in Northern America, 39% in Europe, over 9% in Australia and 3,6% in Southern America. One participant was from Asia (China). None of the participants were from Africa. Compared to the stats of the survey in 2010, the percentage of European respondents dropped by nearly 9%, and hackers from Australia found the survey this year (8,7% up). The low amount of Asian respondents might be partly explained by limitations in access to web content (for example in China).

Members -age, gender and education

The gender and age distributions of hackerspace community members follow the results found in FLOSS related surveys [START_REF] Aalbers | Motivation for participation in an open source community[END_REF][START_REF] Mikkonen | The Protestant ethic strikes back: Open source developers and the ethic of capitalism[END_REF]. In 2010, the typical member was a 26-29 years old male (94%) with college level or higher education. In 2011, the typical member is a 27-31 (35%) years old male (90%) with college level or higher education (64%). It must be noted that even though 90% of respondents were male, this does not necessarily imply that the same applies to hackerspaces in general.

When respondents are grouped by age, gender does not vary much (see Fig. 2). In both genders, 26 -35 year old members are the majority (women 58%, men 52%). The minors (under 18 years old) are rare and only men. With regard to education, the only significant change between 2010 and 2011 is the increase in the amount of hackers with a Master's Degree. In 2010 it was 14% and this year it was over 20%. (Detailed comparison in table 2.)

Members -membership

Based on the survey results, most hackers are members of just one community (nearly 91%). Compared to the results in 2010, memberships in two communities has dropped by nearly 7%. The trend seems to be that respondents are members in fewer hackerspace communities. This can be seen when comparing multi-community membership counts in 2010 and 2011 (see Fig. 4). This might suggest that hackers have found their 'home' and are more engaged and committed to one local hacker community. This could be partly explained with the disappearance of some hackerspaces, causing membership concentration to strong and active hackerspaces. However, at this point this is just speculation and can't be confirmed from the data. Another possibility is that simply the raised participant count in 2011 has caused the change.

Members -interests

Members interests were inquired about in one question: "In general my interest with the hackerspace is MOSTLY about …". Respondents were given list of predefined groups of interest areas such as software hacking, networks and building objects. Respondents were informed to choose max. 3 options, but some selected all.

In the 2011 survey one new option was added: in 2010 the social aspects of hacking communities were not present on the list. Since then the need for that option has become clear. The term 'social aspects' refers to events and meeting people -the term was clarified to respondents in parenthesis. Respondents were also given an opportunity to choose 'Other' and give some sort of clarification. Figure 5 presents a comparison chart. Nevertheless, it seems to be clear that hacker communities are about building things. Option 'other' included several topics and areas as identified by the respondents. To mention just a few: learning, biohacking, biology, biotech, energy, diybio, robotics, 3D printing, chemistry, science & math, foundry work, fabrication techniques not available at home, podcasting, fibre-crafts and chemistry & physics. Among the above topics, the term 'Learning' appeared several times, which suggests that learning in general is important for participants. Also robotics and biology related hacking were mentioned several times. This suggests that hackers are getting more and more active in DIYbio (referring to communities focusing on biology), a fact that has also caught the attention of the press [see for example 4, 13, 17].

Members -Motivation

The participants were asked to tell how significant different reasons for contributing in hackerspaces are. The question included eight claims and options were presented using a five-point Likert scale (see Table 3). Altruism, community commitment, meeting other hackers in real world and having fun seem to be the most important factors of motivation. About 80% (last year 77%) of the participants seem to be contributing to community without expecting something in return. About 75% feel that commitment to community is one of the most important sources of motivation. For nearly all (95%) meeting other hackers and hacker-minded people and having fun (98%) are the most important reasons to participate in hackerspace activity. In other words, the social factor of peer production communities seems to be the key element.

When compared to results in 2010, no major changes can be found (Fig. 6). Attitude towards earning money and reputation building have become slightly less negative.

Members -time spent on hackerspace related activities

Survey participants were asked to tell how much time they spend on hackerspace related activities in a week. The answers were given in free text format, not as predefined options (which could have been better). The responses were grouped into 2-hour periods and a few answers were dropped away: it seems highly unbelievable (and even impossible) that someone would use 300 hours or more on hackerspace activities in a week.

Roughly, the respondents use the same amount of time as in 2010 (2011: 10,6 hours and 2010: 9,7 hours). The histogram in Fig. 7 seems to suggest some changes. In 2010, two options -4-6 hours and 10-12 hours -were most common, while other amounts were less popular. In 2011, the distribution is more even. It seems that respondents use either a little time (2-4 hours) or a lot of time (18 hours or more) in hackerspace related activities. The values in the middle got lesser hits. This might suggest that there are two groupings: 'the mass' (a few hours) and enthusiasts (high amount of hours).

Members -activity

The respondents participate in community related activities for about 10 hours per week. What kind of things do they do? The answer to this question was sought by asking: "In general my projects in the hackerspace are about ..." which was followed with 7 predefined Likert scale options. The given options were: Software development / hacking, Hardware development / hacking, Website/Web-app development, Management (financial or otherwise), Organize events/nights/sessions etc., Administrative tasks (email lists, servers, etc.) and Mobile device related hacking.

Results (see Fig. 8) suggest that hackerspace members are mostly involved in projects related to software development (over 55%) and hardware development (over 65%). The least popular project contents are Mobile device related hacking (6%) and Organizing events (less than 10%). Even though the amount of female respondents in the surveys was rather low, some cross tabulation using gender as one factor can be informative. I must stress that gender is not the issue here; it is used just for the sake of research. Keep in mind that hacker ethics does not want to use bogus criteria (such as gender, age or education) in evaluating people. The intention was to find out if there are differences between the genders; what men like to do and what women like to do. The results indicate that women are more often involved in website development (Fig. 10) and organizing events (Fig. 9). Men are more prone to software and hardware hacking. Women have strong interest in software development and a little less in hardware related projects. Mobile device hacking was not popular among respondents and it is dominated by men. Both genders are equally disinterested in management and administrative tasks.

Community -amount of members

A few of the questions in the surveys were about the local communities in which the respondents were members. For instance, respondents were asked to give estimated amount of members in their local community. This does not correlate directly to reality, since some respondents might be less aware of the status of their community. In other words, answers are probably mostly given by 'gut-feeling'. Furthermore, it is somewhat unclear how people understand the term "member", who is included and who is not. The question included predefined drop-down options: 1-10, 10-20, 20-50, 50-100, 100-200 and 200 or more. These options were constructed based on the 2010 survey results, in which respondents were free to give any number. According to the results 40% of local communities have 20 -50 members (see Fig. 11). The second most common size is 50 -100 members. It must be noted that these figures include all kind of community statuses: planned, building and active.

Community -funding

The topic of funding was added to the survey in 2011. Discussions related to sources of funding have been constantly on the agenda inside hackerspace communities and therefore attitudes towards different funding sources are interesting. The survey participants were given a list with the following possible funding sources (with Likert scale options): company donations (money), company donations (devices, equipment, etc.), membership fees, governmental sources (aid from different programs which help building and maintaining volunteer activities) and donations from individuals (money or other resources). The results (Fig. 12.) suggest that company donations (money) are less disagreeable than governmental support, but only slightly. Membership fees seem to be the most approved source of funding. Device and other equipment donations from companies and all sorts of donations from individuals gained a lot of support. It must be noted that in some cases, if company donations are accepted, they must be without strings attached. The policy is required in order to maintain community independence from external forces. Nevertheless, it is clear that money or other kind of support in any form coming from individuals is preferred over company or governmental sources.

Discussion and conclusions

According to the survey results the typical hackerspace member is a 27-31 (35%) years old male (90%) with college level or higher education, committed to one hackerspace; he uses in average ca. 10 hours per week in hackerspace related projects, which are commonly software or hardware related. Altruism, community commitment, meeting other hackers in the real world and having fun seem to be the most important factors of motivation. Compared to the motivation models discussed in research on open source development [for example 3], hackerspace communities have a strong 'social motivation factor'. The members in the communities have a high interest towards meeting other hacker-minded people in real life. Most communities aim to have a physical space that functions as a community center. They are also known to arrange a lot of real life activities which are often related to learning, education and of course having fun. Having fun is one of the most important motivation factors and having fun is a fundamental part of social life.

Women seem to have found peer-production communities (hackerspaces, makerspaces, fablabs, diybio, etc.). Peer-production communities are still 'man caves', but the amount of women in hacking seems to be rising at least through the hackerspace movement. The emergence of biohacking was also visible in the survey.

Hackerspaces can be seen as hacker versions of 'third places' as defined by Oldenburg [START_REF] Oldenburg | Celebrating the third place: inspiring stories about the "great good places" at the heart of our communities[END_REF]. According to Oldenburg 'third places' refer to social settings or surroundings separate from the 'first place' (home and other similar settings) and 'second place' (workplace) [START_REF] Oldenburg | Celebrating the third place: inspiring stories about the "great good places" at the heart of our communities[END_REF]. The third places are 'anchors' of community life that facilitate and foster broader, more creative interaction. These places serve as focal points of community life which has eroded due to commercial chains and unifunctional zoning policy [START_REF] Oldenburg | Celebrating the third place: inspiring stories about the "great good places" at the heart of our communities[END_REF]). Third places are needed to reconnect to each other and strengthen community ties. To become a successful third place, a place must be locally owned, independent and small-scale and be based on steady-state business [START_REF] Oldenburg | Celebrating the third place: inspiring stories about the "great good places" at the heart of our communities[END_REF]. Furthermore, the places should be highly accessible, within walking distance, free or cheap and involve regularity. When these criteria are compared to the characteristics of hackerspaces, the similarities become obvious.

All hacker and other computer related groups or clubs can not be called hackerspaces. Some groups or places that look like hackerspaces don't even want to be labeled as such. Some hackerspaces avoid using the word itself in the group's name or in the descriptions of the group. Reasons for avoiding the word vary, but the most common is related to the uncertainty of how 'others' will react to any description that includes or refers to the word 'hacker'. This fear of the opinions of others is an example of how communities are shaped, defined and identified also by people that are not members of the communities. The identity is not carved in stone, but constantly evolving. Yet some features can be listed even though the features are not universally agreed upon in the community. The reason for some level of diaspora may lie in the desire not to define hackerspaces rigidly, which in turn is derived from the values of hacker ethic.

Since a shared understanding of how to name the 'fabbing' movement is still missing (not the least in the academic context) and in order to put the movement in a larger context, I suggest that it could be seen as a continuum to the different hacker generations mentioned above. As discussed above, 'fabbing' is bigger than just hackerspaces and therefore I have labeled this new hacker generation as 'peerproduction' (see Fig. 13.) in order to include the different forms described by Troxler [START_REF] Troxler | Commons-based peer-production of physical goods -is there room for a hybrid innovation ecology?[END_REF].

While the above mentioned hacker generations are acknowledged by some scholars (see for example 23 -24] the descriptions provided so far are missing the latest development, namely peer-production.

The description of peer-production movement as a hacker generation needs more research and thought. Nevertheless, hackerspaces as instances of peer-production have a clear identity and constitute a large, growing and global movement. Hackerspaces and previous hacker generations share some values such as altruism and believe in hacker ethic. As the survey results indicate, hackerspace members are if not obsessed then at least focused to hardware hacking, which was fundamental part of 'hardware hacking' generation. Peer-production generations adapts that obsession and extends it with social aspects. Peer-production generation overlaps with the Open Source generation as well. Both value sharing, collaborative work, openness and transparency. Open source has become part of the main stream in software development. Companies have become part of the open source communities, started to form ecosystems and the border between working hours and contribution has become fuzzy. Hackerspace communities have chosen the other way. They want to stay as independent as possible from external forces such as companies and governments. This might indicate that freedom is more valued than resources. Valuing freedom over resources and restraining external (often business related) influences, does not exclude creating new business. Some of the fundamental parts of 3D printing device development (such as RepRap and Ultimaker) have started from peer-production communities.

Yet, hackerspaces are different kind of communities compared to communities formed by previous hacker generations at least in two aspects. Firstly, hackerspaces focus on social aspects in virtual and physical world. Hackerspace communities organize events, which are about having fun and learning. Examples of virtual events are monthly organized hackathons 3 , in which people gather together to solve technical problems to create something new in collaboration. Physical world events are often educational in nature focusing on different technical issues and skills such as programming languages, soldering skills, 3D printing and biohacking. Furthermore, these events are often open to public. That indicates will to educate 'others', those who are not yet members of the community. Reasons for this free-time based education might be to lure in more members and share the gained knowledge and skills. Secondly, they aim to build and maintain physical spaces which function as community centers. Hackerspaces and alike have taken a significant role in how hackers and hacker-minded people organize themselves and activities.

Fig. 1 .

 1 Fig. 1. Age division 2011.

Fig. 2 .

 2 Fig. 2. Age groups by gender 2011.

Fig. 3 .

 3 Fig. 3. Respondents' education in 2011.

Fig. 4 .

 4 Fig. 4. Hackerspace membership 2010 and 2011

Fig. 5 .

 5 Fig. 5. Interests in 2010 and 2011 in comparison

Fig. 6 .

 6 Fig. 6. Member motivations in 2010 and 2011 in comparison

Fig. 7 .

 7 Fig. 7. Time spent on hackerspace related activities per week -2010 and 2011

Fig. 8 .Fig. 9 .

 89 Fig. 8. In general my projects in the hackerspace are about ..." (2011)

Fig. 10 .

 10 Fig. 10. Doing website related development by gender in 2011.

Fig. 11 .

 11 Fig. 11. Member count in local hacker community (estimated) in 2011

Fig. 12 .

 12 Fig. 12. Opinion about sources for hackerspace funding and resources.

Fig. 13 .

 13 Fig. 13. Suggested view of hacker generations. Source: Modified from Taylor [24], peer-production added by the author. Beginning of peerproduction generation is debatable. Hackerspaces emerged in small scale around 1995, but breakthrough happened around 2001-2002 and after that other forms of peer-production emerged. Phone-phreakers generation as a movement ends at 2006 because last "phreakable" MF-signalled N2 carrier was replaced with a T1 carrier.

Table 1 .

 1 General view of 2010 and 2011 survey statistics.

	Basic statistics	2010	2011	Change
	Participants	201	250	49
	Men	185	223	38
	Women	12	25	13
	Mean age	30	31	1
	Age range	15 -53	13 -62 -
	Amount of different	72	87	15
	communities
	Geographical	2010	2011	Change
	distribution
	From Northern	48,0%	48,0% 0,0%
	America
	From Southern	0,0%	3,6%	3,6%
	America
	From Europe	47,5%	38,6% -8,7%
	From Asia	4,0%	0,4%	-3,6%
	From Australia	0,5%	9,2%	8,7%
	Amount of different	20	19	-1
	countries

Table 2 .

 2 Respondents education 2011 and 2010.

	Education level Percentage	Percentage
		2011	2010
	Less than high school	3%	3%
	High School/GED	8%	6%
	Some College	22%	27%
	2-Year College Degree	10%	9%
	(Associates)
	4-Year College Degree	32%	32%
	(BA,BS)
	Masters Degree	21%	14%
	Doctoral Degree	3%	5%
	Other	1%	5%

Table 3 .

 3 Motivation for taking part in hackerspaces -2011.

Number is based on hackerspace list given in http://hackerspaces.org/wiki/List_of_ Hacker_Spaces which is maintained by the community.

Naturally, not all members of all hackerspaces agree on the above criteria.


Androklis Mavridis
email: amavridis@csd.auth.gr

Dimitrios Fotakidis
email: dfotakidis@yahoo.gr

Ioannis Stamelos
email: stamelos@csd.auth.gr

Open Source Migration in Greek Public Sector: A feasibility study

Open Source software has been recently recognized by governments as a viable and cost effective solution. However, transition to open source is not a plug-and-play process but one that requires deep knowledge of open source dynamics and of organization's operations, budgetary constraints, capacities, ethics and political agenda. As with any IT transition, there are uncertainties and risks that need to be handled in order to maximize the gains for the organization and for the society through the provided services. In this paper we present a feasibility study conducted in 15 Greek public sector organizations with the aim to discover the value this transition brings to a typical public sector organization.

Introduction

The benefits of Open Source Software (OSS) within public sector (PS) have been highlighted by numerous studies [START_REF] Kovacs | Open source software for the public administration[END_REF], [START_REF] Richter | A Comparative Analysis of Open Source Software Usage in Germany, Brazil, and India[END_REF], [START_REF] Waring | Open source software implementation in the UK public sector: evidence from the field and implications for the future[END_REF], [START_REF] Wong | Free/Open Source Software: Government Policy, Asia-Pacific Development Information Programme e-Primers on Free/Open Source Software[END_REF] focusing on the the fast growth of OSS projects and open standards which offer usable solutions able to support organizations in supplying high quality services to society. However the OSS migration is not a risk free plug and play process. According to [START_REF] Gosh | OSOR Guidelines, Public procurement and Open Source Software[END_REF], the uncertainty of the quality of the OSS applications [START_REF] Immonen | Trustworthiness Evaluation and Testing of Open Source Applications[END_REF], the dynamic nature of the majority of OSS projects [START_REF] Katsamakas | Why most open source development projects do not succeed?[END_REF] and the lack of technical support [START_REF] Singh | Users of Open Source Software -How do they get help?[END_REF] are some of the obstacles faced by integrators. Furthermore, while there is an acknowledged demand for financial transparency that advocates the use of OSS, there is still lack of awareness of the feasibility and viability of OSS in the PS environment. In [START_REF] Van Der Wal | Central Values of Government and Business: Differences, Similarities and Conflicts[END_REF] authors argue that the majority of public sector shows little interest in financial performance. To discover the value of OSS migration and to shed light to the uncertainties that affect its viability, we conducted a feasibility study in fifteen municipalities in Greece, where we calculated the value generated from three scenarios of OSS adoption namely minimal, basic and massive based on the number and type of the adopted software solutions. To do so, Real Options Analysis was employed as a decision making tool able to capture the uncertainties faced by integrators and calculate their impact on the anticipated revenues.

The paper is structured as follows. In section two we provide background information on the Real Options Theory and tools, followed by the proposed approach. In section three we analytically present the results of the study and finally we share some ideas for further research in section four.

Background and proposed approach

We argue that the value of an OSS is generated and both affected by its project's dynamics [START_REF] Mavridis | Real Options as tool enhancing Rational of OSS applications selection[END_REF]. As the OSS evolves over time, uncertainties related with its provided qualities such as usability, availability and maintainability, may be introduced or resolved. However, to what extend these uncertainties will affect the anticipated value is subject to organization's capacities, competencies, resources and constraints. Hence, selecting the right OSS solutions (the more profitable) depends on organization's resilience to these uncertainties. In this respect, finding the more profitable migration scenario is not simply a matter of accumulating the value generated from the number of OSS solutions to be adopted but of identifying which OSS solutions maximize and/or maintain their values over time. Real options analysis is a valuable decision making tool capable of exploring the volatility of the anticipated OSS value in order to provide reasoning about the viability of the migration scenario. Real Options Analysis (ROA) is based on the analogy between investment opportunities and financial options. A real option is a right, but not an obligation, to make a decision for a certain cost within a specific time frame. A project is perceived as an option on the underlying cash flows (value) with multiple associated investment strategies to be exercised if conditions turned out to be favorable. As option is an asset that provides its owner the right with out a symmetric obligation to make an investment decision such as growth, exit, wait, and learning etc. If conditions to investing arise, the owner can exercise the option by investing the strike price defined by the option. A call option gives the right to acquire an asset of uncertain future value for the strike price. There are two option mechanisms, namely the call and put. A call option gives the buyer of the option the right to buy the underlying asset at a fixed price, called the exercise price, at any time prior to the expiration date of the option: the buyer pays a price for this right. If at expiration, the value of the asset is less than the strike price, the option is not exercised and expires worthless. If, on the other hand, the value of the asset is greater than the strike price, the option is exercised. The net profit on the investment is the difference between the gross profit and the price paid for the call initially. In a similar manner, a put option gives the buyer of the option the right to sell the underlying asset at a fixed price, again called the strike or exercise price, at any time prior to the expiration date of the option. The buyer pays a price for this right. If the price of the underlying asset is greater than the strike price, the option will not be exercised and will expire worthless. If on the other hand, the price of the underlying asset is less than the strike price, the owner of the put option will exercise the option and sell the stock a the strike price, claiming the difference between the strike price and the market value of the asset as the gross profit. Many authors appreciated the applicability of ROA in IT investments like in [START_REF] Amram | Real Options: Managing Strategic Investment in an Uncertain World[END_REF], [START_REF] Erdogmus | Valuation of Learning Options in Software Development under Private and[END_REF] while others employed ROA in software engineering practices such as in [START_REF] Ozkaya | Quality-Attribute Based Economic Valuation of Architectural Patterns[END_REF], [START_REF] Shaw | In ffi search of a unified theory for early predictive design evaluation for software[END_REF], [START_REF] Sullivan | Software De-sign as an Investment Activity: A Real Options Perspective[END_REF]. Following the same logic, we argue that an OSS migration scenario can be expressed as a call option, where the owner (the PS organization) has the right but not the obligation to make the selection within a given time frame. Before proceeding to the analysis we translate the traditional ROA variables to fit to our context of use. Intuitively we have:

1. Current Value (Net Present Value) of migration scenario (So): The accumulation of the costs of the operational proprietary software are the cash flows generated from the adopted OSS. 2. Exercise Price (X): Total Cost of Ownership (TCO) of the adopted OSS. 3. Time to Expiration (T): The time frame decision makers have to select the optimum migration scenario. 4. Volatility of the Underlying Asset Value (σ): The percentage of the cash flows fluctuations due to uncertainties introduced from the dynamics of the adopted OSS. 5. Risk Rate (r): The Cost of capital Our approach employs three consecutive steps. The first step commences with the discovery of the uncertainties. In the second we calculate the expected cash flows and their associated volatilities in the form of (%) standard deviation, and finally in the third step we calculate the call options for each OSS candidate and we compare the results. We present this steps in detail through our presentation of the case study.

Feasibility Study on the Migration to OSS in Greek Public Sector

Study Preparation

We examined 85 of the 325 (26.15%) municipalities in Greece where we recorded all proprietary applications currently in use and categorized these according to their provided functionalities and domain:

• Administrative Applications

Table 1: OSS applications capable of substituting the currently installed closed source applications

We then proceeded to a closer examination of fifteen municipalities (average in population size and in IT department staffing), to obtain the necessary financial data for our ROA application. For each scenario we calculated the installation and maintenance costs as shown below (all calculations are in Euros): We proceeded with calculation of costs of the currently operational proprietary software for a twenty years period. As stated before, these costs will be attributed to the cash flows generated from the adopted OSS. Similarly for each scenario we have: What we can infer is that the third scenario is the one with the lowest cost of waiting. Nevertheless, the second scenario is the one that should be preferred as not only provides the highest Net Present Value but also a lower cost of waiting (option premium) in comparison to the first scenario.

Conclusions

We have presented an options based approach for the valuation of the OSS migration in a PS organization. The application of ROA addresses some fundamental issues, like the lack of accountability and risk averseness inherent in PS environments. The method provides an alternative view to the OSS migration process in the uncertain Open Source Software realm. By perceiving the OSS migration as a risky investment, a more accurate calculation of the anticipated value of OSS employment to PS environments can be achieved. It is our intention to extend this study to other public sector organizations and to examine the suitability and applicability of simulation techniques i.e. Monte-Carlo in volatility calculations.

Table 2 :

 2 Installation and Maintenance costs for scenario 1

Table 3 :

 3 Installation and Maintenance costs for scenario 2

Table 4 :

 4 Installation and Maintenance costs for scenario 3

  inactive until its expiration. In our context Time Value is the amount of money the PS organization will loose by waiting to see how the uncertainties associated with the migration scenario will evolve over the time to expiration. Calculating the option premiums for the three scenarios we have:

				Option Premium
			Scenario 1	36,694.10
			Scenario 2	26,576.26
			Scenario 3	8,143.09
	OSS Software	Installation Cost	Maintenance Cost	Total
	Open Office		2,000		0	2,000
	SCRIPTUM		12,000		5,000	17,000
	Linux		11,000		5,000	16,000
	ERP		15,000		5,000	20,000
	OrangeHRM		15,000		5,000	20,000
	Total		55,000	20,000	75,000
	OSS Software	Installation Cost	Maintenance Cost	Total
	Open Office		2,000	0	2,000
	SCRIPTUM		12,000	5,000	17,000
	ERP		15,000	5,000	20,000
	OrangeHRM		15,000	5,000	20,000
	Total		44,000	15,000	59,000
	OSS Software		Installation Cost	Maintenance Cost	Total
	Open Office		2,000	0	2,000
	SCRIPTUM		12,000	5,000	17,000
	Total		14,000	5,000	19,000
	Years	Proprietary	Installation and	Total
			Purchase Cost	maintenance cost
	2011	103,500.00	32,500.00	136,000.00
	2012	0.00	34,125.00	34,125.00
	2013	0.00	35,831.25	35,831.25
	2014	36,225.00	37,622.81	73,847.81
	2015	0.00	39,503.95	39,503.95
	2016	0.00	41,479.15	41,479.15

http://www.soarcorp.com/black_scholes_calculator.jsp

http://www.soarcorp.com/black_scholes_calculator.jsp

Table 7: Cash flows from migration scenario 3

Applying Real Options Analysis

From the collected information we where able to calculate the total budget assuming a two year period within which all employees will operate the adopted OSS solutions: These option values represent the additional value that comes from the right not to implement immediately the migration scenario but only upon favorable conditions. Going a step further Option Value C 0 depends on two variables, the Intrinsic Value (IV) and the Time Value (TV), as such, C 0 = IV + TV,

The intrinsic value (IV) of an option is the value of the option if exercising it now and is given as: IV = S 0 -X, Intrinsic value can be defined as the amount by which the exercise price of an option is "in-the-money". It is actually the portion of an option's price that is not lost due to the passage of time. While Time Value or "Option Premium" give as: TV = OV -IV, is the real cost of owning a stock options contract. It is the part of the price of an option which the seller of the option gets to keep as profit should the stock remain


Etiel Petrinja

Giancarlo Succi

Two evolution indicators for FOSS projects

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Software projects evolve according to different evolution processes. The Free Source Software [9] projects or the Open Source Software projects (FOSS) evolution differs in several aspects from closed source software (CSS) projects [START_REF] Paulson | An Empirical Study of Open-Source and Closed-Source Software Products[END_REF]. The success of closed source software projects is usually correlated with the number of copies of the software product soled [START_REF] Yiftachel | Resource allocation among development phases: an economic approach[END_REF]. FOSS projects are often considered successful if there is a large number of users of the FOSS product [START_REF] Crowston | Towards a portfolio of FLOSS project success measures[END_REF]. As proposed by DeLone and McLean in their Model of Information systems Success paper [START_REF] Delone | Information Systems Success: The Quest for the Dependent Variable[END_REF] the number of FOSS users can represent the 'Users satisfaction' factor that is included in their model. The number of users depends on the quality of the software product and on the quality of the development process that is followed inside the FOSS community [START_REF] Crowston | Towards a portfolio of FLOSS project success measures[END_REF], [START_REF] Petrinja | Introducing the OpenSource Maturity Model[END_REF].

The number of FOSS projects has been growing rapidly in the last decade [START_REF] Hippel | Open Source Software and the 'Private-Collective' Innovation Model: Issues for Organization Science[END_REF]. The aim of the presented research was to identify characteristics of successful FOSS projects focusing on the number of downloads of FOSS products and the vitality of the development process. Based on those characteristics we defined two indicators of the future evolution of the FOSS project. The success of a software product is a common dependent variable of the research of software projects, and due to its dependency on several aspects, it should be modelled as a multidimensional factor. The number of downloads should be considered as a metric indicating the interest of users into a FOSS product, not necessarily its real usage. Not all downloaded projects are used and there is also a large number of users of FOSS products that have not downloaded them but obtained them as part of a software bundle; for example in one of the Linux distributions. Taking in consideration these two deviations, the number of downloads of FOSS projects is still a factor that is well correlated with the number of users of a FOSS product. The research presented in this paper was based on a empirical study of several thousands FOSS projects stored in the SourceForge repository. The characteristics of FOSS projects were identified by defining and validating two indicators of FOSS project evolution based on a set of thirty measurements. Two models were studied: one is focused on the interest of users in the FOSS product, the second is explaining the potential future survival of the FOSS project by inserting new revisions (working increments of the project) into the project's versioning system. Another important characteristic of FOSS projects is the sustainability. It depends on a large number of product and process aspects. The two indicators, presented in this paper, can provide evidence of the sustainability of the FOSS project. An growing number of users and a high probability of new revisions being published is correlated with the sustainability of the project. The data collected about the projects stored in SourceForge were used for building and validating the two models following a statistical approach.

Section two provides background information reviewed for the study. Section three contains information about the measures collected, the sources of information used, the building of the two evolution indicators, and their validation. In section four we discuss the results and consider the limitations of this study. Finally, in section five we conclude the paper.

Background

The quality of a FOSS product is an important factor considered when adopting it or planing to start contributing to the project. The open availability of project data has supported a large set of FOSS studies. Many of those studies were focused on software measurement and especially on the measurement of its quality. Scacchi [START_REF] Scacchi | Understanding free/open source software evolution[END_REF], McConnell [START_REF] Mcconnell | Open-source methodology: Ready for prime time[END_REF], Alshayeb and Li [START_REF] Alshayeb | An Empirical Validation of Object-Oriented Metrics in Two Iterative Processes[END_REF] published observations of the results of studies comparing Closed source software projects and FOSS projects showing the differences and similarities between the two development approaches.

The Lines of Code (LOC) and their variation through time was a metric often considered and analysed [START_REF] Godfrey | Evolution in open source software: A case study[END_REF], [START_REF] Paulson | An Empirical Study of Open-Source and Closed-Source Software Products[END_REF]. Crowston and Scozzi [START_REF] Crowston | Open source software projects as virtual organizations: Competency rallying for software development[END_REF] analysed the FOSS development process and proposed transitions between different phases of the FOSS development process. Several studies were conducted by statistically analysing a large sample of projects. Capiluppi et al. [START_REF] Capiluppi | Evidences in the evolution of OS projects through Changelog analyses[END_REF] conducted a horizontal study of 404 FOSS projects focusing on the change of the size of alive projects. They observed that only a small percentage of projects is in a growing phase. Similar studies analysing large samples of FOSS projects were done by Koch [START_REF] Koch | Software Evolution in Open Source ProjectsA Large-Scale Investigation[END_REF] that identified a relationship between the size of the project, the number of participants, and the distribution of work in the development team. Robles-Martinez et al. [START_REF] Robles-Martinez | Studying the evolution of libre software projects using publicly available data[END_REF] studied the MONO project by taking in consideration the lines of code, the commits, and the authorship of contributions.

Projects available on SourceForge were used for FOSS studies published by for example Grewal et al. [START_REF] Grewal | Location, Location, Location: How Network Embeddedness Affects Project Success in Open Source Systems[END_REF], Koch [START_REF] Koch | Software Evolution in Open Source ProjectsA Large-Scale Investigation[END_REF], or Capiluppi et al. [START_REF] Capiluppi | Evidences in the evolution of OS projects through Changelog analyses[END_REF]. Raja and Tretter [START_REF] Raja | Defining and Evaluating a Measure of Open Source Project Survivability[END_REF] have used the data of 290 projects available on SourceForge to build and validate a model of FOSS projects survivability. Their study allowed them to propose a stable model to define the survivability of a FOSS project. The model is based on three factors: the organization of the project, the resilience of the community, and its vigour. We have adopted a similar approach to build our models, however along the three factors we have included in the study several other FOSS software and process metrics.

Various publicly available data sources were used for studies of FOSS. The source code stored in versioning systems is one of them. Code level studies done by Godfrey and Tu [START_REF] Godfrey | Evolution in open source software: A case study[END_REF] and Robles et al. [START_REF] Robles | Beyond source code: The importance of other artifacts in software development (a case study)[END_REF] are often based on concurrent versioning system tools as CVS, Subversion, and recently GIT or Mercurial. Mishra et al. [START_REF] Mishra | Software quality assurance models in small and medium organisations: a comparison[END_REF] proposed a quality model that analyses factors contributing to code quality, such as the number of developers, or the mix of talents involved in a FOSS community. Other studies include data from the issue management system as the number of issue contributors, the time necessary to solve an issue [START_REF] Raja | Defining and Evaluating a Measure of Open Source Project Survivability[END_REF], etc. Mailing lists [START_REF] Robles | Beyond source code: The importance of other artifacts in software development (a case study)[END_REF] and the information available on web pages are also an important source of information for studies on FOSS projects Koch [START_REF] Koch | Software Evolution in Open Source ProjectsA Large-Scale Investigation[END_REF].

Crowston et al. [START_REF] Crowston | Towards a portfolio of FLOSS project success measures[END_REF] proposed a framework for measuring the success of FOSS projects. The exact number and type of users of FOSS products is not well-known as it is in commercial projects, where customers are usually well profiled. Crowston et al. [START_REF] Crowston | Defining Open Source Project Success[END_REF] proposed to insert an automatic feedback collection mechanism directly inside the software product. This functionality has been implemented in the last years in projects as Firefox, Ubuntu, Libre Office, and others. Grewal et al. [START_REF] Grewal | Location, Location, Location: How Network Embeddedness Affects Project Success in Open Source Systems[END_REF] identified user and technical criteria for inferring the success of FOSS projects. In part similarly to our approach Polancic et al. [START_REF] Polancic | Comparative Assessment of Open Source Software Using Easy Accessible Data[END_REF] proposed a framework for evaluating OSS projects based on simple metrics.

The FOSS development process was studied by Taibi et al. [START_REF] Taibi | OpenBQR: A framework for the assessment of OSS[END_REF] and Petrinja, et al. [START_REF] Petrinja | Introducing the OpenSource Maturity Model[END_REF]. They proposed evaluation models as the MOSST and the OMM models based on FOSS product and process metrics. Deprez and Simons [START_REF] Deprez | Comparing Assessment Methodologies for Free/Open Source Software: OpenBRR and QSOS[END_REF], and Petrinja et al. [START_REF] Petrinja | Comparing OpenBRR, QSOS, and OMM Assessment Models[END_REF] have compared the models used to assess the FOSS development process and identified the critical aspects of the analysed models. Some of the issues identified were the subjectivity of the assessment process, and a difficult interpretation of some metrics. In the study presented in this paper we use a set of metrics to propose evaluation models that are based on a statistically significant sample of FOSS projects and are not biased by a subjective interpretation of factors.

Analysing project evolution

Based on a sample of project data extracted from concurrent versioning systems and web pages available on the SourceForge repository, we sudied which characteristics influence the number of downloads of a FOSS product, and which factors can be used to predict the evolution of the FOSS project. Based on identified characteristics we proposed two evolution indicators. We inferred the evolution of projects by counting the number of new revisions inserted into the versioning system. The number of downloads is indicating the user's interest in the project. New revisions indicate the further evolution of the FOSS project and therefore the interest in the project by the FOSS community. The two aspects shows the expansion or restriction of the development process. We considered the increase of the two aspects as an indication of improved quality of the FOSS project. We defined a dichotomous value for both characteristics and calculate them for each FOSS project included in the study. The Equation 1shows the definition of the download increment factor and the Equation 2shows the revisions indicator. In both cases k represents the time period. We decided to choose one year as the studied time period, in particular we used the data available for year 2011. For building the model and calculating the metrics we used all the data available for the considered projects from when they have started. Some projects included in the study exist already for more than ten years.

DownloadsIncrement(D

i ) = 1 if k (Downloads k -Downloads k-1 ) > 0 0 otherwise (1)
Revisions(R i ) = 1 if Revisions k > 0 0 otherwise (2)
The generalized linear model (GLM) is in statistics the generalization of the linear regression approach. It allows linking the variance of each factor included in the model (independent variables) to be linearly connected with the predicted value (the dependent variable). The dependent variable can be calculated using the Equation 3. The predicted value is the sum of the independent factors multiplied by a weighting factor β summed with an intercept constant.

P redictedV alue = i β i * IndependentF actor i + Intercept (3)

Data sources

The SourceForge project repository contains currently nearly 360.000 projects and exists already for more than a decade. In spite of the high number of projects only a small percentage of those projects is still alive and evolving. The large majority of them is represented only by a name, and a brief description of an idea to be implemented inside the project. Half of the projects in Source-Forge adopted the Subversion versioning system and the other half is using the CVS. The GIT, the Mercurial, and the Bazaar versioning systems are not yet largely used inside SourceForge. Out of the 150.820 projects using Subversion only 66.674 have at least one revision inserted into the versioning system. In several cases the projects that are inserted into SourceForge have also an external database and versioning system. The projects are not always promptly synchronised between the two repositories. A retrieval of external project data and comparison with the data available in SourceForge could provide an interesting indications of the life cycle of those FOSS projects. We limited our study just to the data stored in different data sources all composing the SourceForge system.

We have decided to considered just the projects stored in the Subversion system. We have collected different data as the number of revisions and the date when they were inserted, for each of the 66.674 projects with at least one revision. Another important source of information about the projects were the SourceForge web pages presentations available for each project. We have spidered the pages collecting metrics as: the name of the project, the staring date, the status of the project, the issues reported and solved, the developers involved in the process, the number of downloads, the time distribution of the downloads, and others. Joining all the data collected we have limited the number of projects useful for our study. The number of projects with all the characteristics necessary for our study stored in SourceForge was 5.905. We have performed several analyses on these data and we have additionally limited their number for some studies. For the two studies reported in this paper we have considered only projects that exist for a period longer than 1 year when calculating the download increase factor and for a period longer than 3 years for building the model related to the revisions and survival of the FOSS project. The factors included into the study are simple project metrics that do not need additional explanations. Three composed factors: vigour, resilience, and organization have been calculated following the equations proposed by Raja and Tretter [START_REF] Raja | Defining and Evaluating a Measure of Open Source Project Survivability[END_REF].

Building the two models

We aimed to predict if the number of downloads in the considered period will be higher from the preceding period. We predicted this characteristic (dependent variable) from a set of factors characterising FOSS projects (independent variables). For building the model we adopted the General Linear Model (GLM). We used the R statistical evaluation tool to automate the GLM calculation. After restricting the projects to the one that exist for more than one or three years we have obtained a sample (with 760 projects) as inputs for building the downloading evolution model. Based on the number of downloads extracted from the SourceForge repository for the years 2010 and 2011 we calculated the downloading delta factor assigning a 1 if the number of downloads was higher in 2011 than in 2010 and 0 if the number was lower. For improving the correctness of the accuracy, and the precision of the proposed model it is important that the number of projects that have increased the number of downloads (having the download increase factor 1) and those that did not (having the download factor 0) should be equal. In our initial sample of projects the number of projects that did not increase the number of downloads was larger than the number of projects increasing the number of downloads. We had to limit the number of the first type of projects. We randomly selected projects from the first group to reach the number of projects in the second group. We have prepared both a modelling and a hold-out validation sample following the stratified sampling approach. We first selected all projects that exist for more than one year and divided them into two strata based on the increment of the number of downloads. We used two-thirds of the sample for building the model and one-third for validating the model.

We have considered 30 different factors for building the download increment model and 12 factors for building the model of the liveliness of the project by predicting the future revisions of FOSS projects. Due to space constraints we are unable to present in details all the metrics considered. However just few of the factors proved to be significant for building the two models. Four factors were dichotomous (with values 0 or 1) the other represented continuous metrics. In the continuation of this section we present basic statistics of the factors included in the final versions of the models developed.

The two dichotomous factors that were included into the download increment model were ActivityRev2011 and ActivityDowDelta2010. The first indicates either there were new revisions for the project in year 2010 and the second indicates if there was an increment of the number of downloads in the year 2010 in comparison with the number of downloads in the year 2009. The two continuous factors included into the model were: the number of new revisions inserted into the versioning system during the year 2010 (Rev2010) and the number of new opened issues in the year 2011 (OpenedIssues2011). The majority of characteristics of projects stored in SourceForge is strongly skewed to the right.

The 'step' function available in the R statistical tool was used to find the optimal combination of factors that should be included into the model. The 'step' function proceeds stepwise to identify the GLM model that has the lowest Akaike Information Criterion (AIC) number. The AIC factor indicates how well the data values predicted with the help of the parametric model fits the measured data. Better the model, better the predicted data, therefore smaller the difference between the predicted and the measured data. The optimal linear model for predicting downloads increment contained 9 different factors (activ-ityRev2010, ActivityRev2011, activityRev2011delta, closedissues2010, average-closuretime2010, openedissues2011, closedissues2011, averageclosuretime2011, and activityDow2010Delta). We limited the number of factors to four by loosing less than one percent of the prediction power of the model. We limited the number of metrics that have to be collected to improve the usability of the model. The statistical data characterising the factors included into the model are presented in Table 1. We see that the mean value of revisions in 2010 is 103 per project. There are some projects with zero revisions and one with 3431 revisions. The number of issues reported in the year 2011 for our sample of projects is not very large; the larger is 86 and the mean is just 2.6 issues. The percentage of projects that have more revisions in 2011 then in 2010 in our sample is 65 percent. The DownloadDelta Checker for 2011 is balanced for the correctness of the prediction as discussed previously.

We have designed the final GLM model by considering the prediction power of singular factors. We obtained a list of β factors for each of the 30 factors considered for predicting the downloading increment. The prediction power of factors were: projectLongevity (0.54), revisionsTotal (0.518), revisions2010 (0.575), revisions2011 (0.602), activityRev2010 (0.625), activ-ityRev2011 (0.682), activityRev2011delta (0.595), vigorAverage2010 (0.589), vigorAverage2011 (0.607), openedissues (0.501), closedissues (0.501), openedis-sues2010 (0.587), closedissues2010 (0.595), averageclosuretime2010 (0.586), resi-lence2010 (0.570), openedissues2011 (0.616), closedissues2011 (0.595), average-closuretime2011 (0.6), resilence2011 (0.597), organization (0.509), downloads (0.505), downloads2009 (0.501), downloads2010 (0.505), activityDow2010Delta (0.736), recomendedBy (0.506), createdbynumber (0.502), closedbynumber (0.504), averageclosuretime (0.516), averageclosuretimeabsolute (0.509), and numberOf-Contributors (0.509).

If for the download increment model we consider just one factor, we are able to predict correctly the percentage of projects shown in the brackets. We see that the increase of the number of downloads in year 2010 comparing it with the number of downloads in the year 2009 (activityDow2010Delta) factor is able to predict correctly the increase in the year 2011 in 73 percent of cases. With the combination of additional factors we tried to obtain a better prediction of the downloading model. We run the stepwise calculation of the optimal prediction model and obtained a model with four factors that are shown in Table 6. We see that the activityDow2010Delta has a strong influence in the prediction model. This is evident from the size of the β factor (1.83). The other factors have a smaller influence. Nevertheless the β factors of the Revisions 2010 factor and the OpenedIssues 2011 factor are small, they can still contribute considerably to the value of the prediction, if the number of revisions or the number of newly reported issues is large.

Before building the revision prediction indicator we have first analysed the prediction power of 12 factors singularly: projectLongevity (0.57), revision-sTotal (0.59), revisions2010 (0.74), activityRev2010 (0.71), vigorAverage2010 (0.69), openedissues2010 (0.50), averageclosuretime2010 (0.50), downloads2009 (0.50), downloads2010 (0.50), createdbynumber (0.50), closedbynumber (0.52), and averageclosuretime (0.50). In brackets is shown the percentage of correctly predicted revision activity. We see that the number of revisions in the previous year and the checker of revision activity in the year 2010 have a high prediction power. Applying the step-by-step calculation of the optimal set of factors for best constructing the GLM revision model we identified four factors: the projectLongevity, the revisions2010, the activityRev2010, and the vigorAver-age2010. The activityRev2010 is a dichotomous factor (values are 0 if there is no revision in a specific year or 1 if there is at least one revision), the other three factors are continuous metrics. We have subsequently trimmed the number of factors for simplifying the model. With the trimming the model has loosed less than one percent of its prediction power. Table 3 shows the descriptive statistics for the two factors used to build the model and Table 4 the descriptive statistics of the sample used for validating the revision model. Table 5 shows the mutual correlations between the four factors used to define the download increment model. We calculated the Pearson correlation coefficient. We can consider the factors weakly correlated if the correlation is smaller than 0.4. As we can see in Table 5 all mutual correlations fulfil this requirement. All the tests were highly significant with the p value that was smaller than 0.00001 in all cases. We can consider the factors independent and therefore it is not superfluous including them all into the same prediction model. Table 6 shows the β weights for the factors included into the download incrementing model. The biggest the β weight the largest is the influence of the related independent variable to the dependent predicted value. We see that the download delta checker from the previous year (2010) and the revisions checker from year 2010 have a strong influence on the predicted variable. Using Equation 3 and the calculated weighting factors we can now write explicitly the linear equation of the model for predicting the increment of the downloads of a FOSS project as follows:

Increaseof downloads = -1.904 - 0.001 * (Revisions2010) + 1.481 * (RevisionsChecker2011) + 0.035 * (OpenedIssues2011) + 1.833 * (DownloadDeltaChecker2010)
Similarly as for the download model we have calculated the weighting factors for the revisions model. The Equation 2 can be used to predict the probability that the project will have new revisions in the following time period (in the year 2011 in our case).

Increaseof Revisions = 1.201 + 451.49 * (V igorAverage2010) -

* (Revisions2010)

We can test the statistic significance of the weighting factors β by calculating the Wald statistics and checking the values obtained. In Table 7 we see the β values, their standard error, the Wald statistic, the p values, and the exponential factors of the β values which show how strongly each factor contributes to the change of the predicted value. We see that the p-values for all factors are marginal therefore the factors are statistically significant.

To be able to predict the increase of the downloads or the insertion of new revisions we have to define the threshold value of the prediction Equation 3 for which the model will predict the increase. We predicted the threshold value by drawing the receiver operating characteristics (ROC) curve for the prediction model and finding the point where the successful prediction of the model was reached. This value is optimal when the sum of the probability of a correct prediction of the model (the sensitivity of the model) and the correct prediction of the missing of the required conditions (the specificity of the model) is maximized. The ROC curve helps to graphically identify the maximum of both values (sensitivity and specificity). In the case of the model for download increment prediction this value is 0.43. After computing the Equation 3for the values of a specific FOSS project, if the value is higher than 0.43, the model predicts that the number of downloads in a specific year will be higher than in the previous year.

Validating the models

With the selection of only weakly correlated factors we guaranteed the discriminant validity of the two proposed models. The concurrent validity of the models can be tested by checking the goodness-of-fit of the two models and by comparing the measured and the predicted values. The goodness-of-fit of the model shows how well the prediction model identifies the correct values. Several tests exist that consider the difference between the observed and the predicted values. We have used three different tests. The -2 Log Likelihood ratio is a statistical test for comparing the fit of the model to real data. For the model predicting the download increment the Log likelihood ratio is 224. The second test we have used was the Cox and Snell R 2 which gave for the download model the value 0.18. Which shows that the model has not a strong prediction power. The third test was the Nagelkerke R 2 test which gave for the download model the value 0.24. Based on the results of these tests we can not expect a high prediction power of the proposed download prediction model. We can see exactly how precisely the model can predict the values by using first the sample of FOSS projects used to build the model. Afterwards we will use the hold-out validation sample that was composed by one third of the initial sample.

Table 8 contains the measured and the predicted values about the increase of the number of downloads between the years 2010 and 2011 for 760 FOSS projects. We can see the percentages of correct and missed predictions. The overall prediction precision is 75 percent and it is far from mere guessing (which would be the case if the percentage rate would be 50 percent) but it is still not very precise. The -2 Log Likelihood ratio for the revision download model is 177.56, the Cox and Snell R 2 value is 0.63, and the Nagelkerke R 2 value is 0.83. The three likelihood tests gave good results for the revision model showing that the model fits well to the measured data. Table 9 shows the results of the prediction and the measurement of the data used to create the Revision prediction model. The number of FOSS projects included in this test was 880. The predictions shown in the classification table 8 are biased while we have used the same data to build the prediction model. By applying the download prediction Equation 3 on the validation sample of 379 FOSS projects we have obtained the results presented in Table 10. The percentages are comparable to the data used for model creation, they are just slightly lower.

By applying the new revisions prediction Equation 2 on the validation sample of 423 FOSS projects we have obtained the results presented in Table 11.

Discussion

The further evolution of the FOSS project from the point of view of the user and from the point of view of the community provide two indications of the success of the project. It is important to take in consideration that FOSS users are sometimes also FOSS developers and that almost always the developers are also users of products they have contributed to develop. The results of the validation show that the two prediction models can provide hints on the further evolution of the FOSS project. The equation for predicting an increased download number is less precise than the equation for predicting the availability of new revisions related to a FOSS project. One reason for this can be a higher uncertainty of the number of downloads in comparison with the number of new revisions. FOSS products are downloaded by individuals that are not always part of the FOSS community and it is therefore more difficult to predict precisely if their number will increase. On contrary the availability of new revisions depends on the past development and stability of the development process.

If the project is downloaded by a growing number of users it means that the community implements functionality that is needed and considered useful by a growing number of users. A larger number of users can afterwards provide new bug/issue reports, forum entries, or even code contributions. A growing number of downloads is a good indicator for the future development of a FOSS project. We were able to predict the future availability of new revisions more precisely than downloads. The proposed revisions prediction equation is precise and can identify projects that will stop evolving and the one that will have new revisions in the coming time period. Having an indication of the future availability of new revisions can be an important factor when deciding to download and start using a FOSS product. If the project is not going to be improved further with new revisions, the new bugs/issues reported might not be addressed and the new features proposed will never be implemented.

We can compare our results with the results reported by [START_REF] Raja | Defining and Evaluating a Measure of Open Source Project Survivability[END_REF]. They achieved accuracy of 92.78 percent for predicting the survivability of projects they have included into their training and testing samples. We obtained a similar precision (93 percent) for the prediction of new revisions and a lower precision (75 percent) for the prediction of an increase of downloads. Our testing and training samples were between three to four times larger than the one used by [START_REF] Raja | Defining and Evaluating a Measure of Open Source Project Survivability[END_REF]. A large sample allows us to be more confident when generalizing the results of our study.

The factors included into the two equations show also which aspects of the FOSS project influence the further evolution of the project. An increased downloading of the FOSS product depends on new revisions in the analysed time period. If there are no new revisions inserted into the versioning system most probably the number of downloads will decrease. If the project was downloaded in 2010 more often than in 2009 it will be probably downloaded more often in 2011 than in 2010. The majority of this type of projects are in a growing phase and they are attracting an increasing number of new users. The temporal existence of these type of projects was statistically shorter than the average existence of analysed FOSS projects. It means that they are new and they are growing. A large number of new issues reported by the user base is triggered by a larger number of users and downloads. The submission of new revisions depends on the number of revisions in the previous time period and the average vigour in the previous time period. The vigour is obtained from the number of revisions in a specific time interval and it shows how strongly the project is evolving.

Limitations

The construct validity is focused on the dependent and the independent factors and how accurately they are able to model the hypothesis. Most of the measures analysed are simple as the number of downloads, the number of revisions, or the number of issues reported. Problematic could be the assumption that an increased number of downloads or the submission of new revisions indicates a higher quality of the FOSS project. The number of users of a FOSS project is not equal to the number of downloads, however an increased download rate leads to an increased number of users. The same is true for the number of revisions. The total number of revisions is not an absolute indicator of the quality of the project, nevertheless it is indicating an evolution trend of the project. Another factor used was the number of issues which are usually bug reports or new feature requests. We did not distinguish between the two, however this was not an issue for our study, since both contributions indicate an interest of the users in the project. The factor organization and the factor resilience where not included into the final versions of the two models only the vigour factor is used for predicting new revisions. The validity of the three factors was demonstrated by Raja and Treter. Based on simply measured factors we have calculated four dichotomous measures about the change of downloads or revisions. These four measures do not present construct validity issues.

The internal validity is related to the link between the dependent and the independent variables. If the independent variables changes also the dependent variable should change. We have done rigorous testing of the factors included into the two models and the internal validity proved not to be an issue for this study.

The external validity is focused on the applicability of the results of the study to FOSS projects not included into the study. All projects used for the study have been extracted only from the SourceForge repository. This could prevent the applicability of the two equations on projects developed in other environments. However SourceForge is one of the largest and oldest FOSS projects repository and the quality of data available is good. The two models have been designed based on several hundreds of relevant projects and validated with two completely separate hold-out validation samples. Therefore we are confident that if the basic data necessary for the prediction is extracted diligently, the models should be valid also on FOSS projects contained in other FOSS repositories. An extended study replicated also on other FOSS repositories could anyway benefit the external validity of the proposed models.

Conclusions

In this paper we have presented an analyse of a large set of FOSS projects and identified two prediction equations. One for predicting the increase of product downloads and one for predicting the further development of the project with new revisions being submitted to the source code versioning system. The two indicators can provide a hint on the sustainability of the FOSS project. Based on simple project metrics users can understand if the project will evolve in the near future. The two predictions can be useful for the FOSS community that is developing the project and also for potential new users of the FOSS product. The community can benefit from the information about a potential risk of a diminishing number of downloads and can take preventive actions. A new user can decide to start using a product if there is a good chance of its further evolution proved by the probability of new revisions published in the future. The study presented in this paper is building on top of several other studies focused on predictors of FOSS projects sustainability and success. Some of the methods we have adopted for our study could be applied to similar research domains as for example the prediction of bug/issues in FOSS projects. A higher number of users and a growing number of revisions is intuitively correlated with the sustainability of the FOSS project. Further investigations are, however, neces-sary to quantitatively confirm this correlation. We have built the two models by collecting data from the web pages and the source code versioning system of the SourceForge repository. Thousands of projects have been analysed and subsets of the projects were used to design two samples for modelling the prediction equations and two samples for validating the predictions. The download increment prediction equation achieved a 75 percent correctness of predictions and the new revisions contribution equation achieved an average of 93 percent of correct predictions. Both models have been tested according to guidelines and best practices available in the literature for developing new software measurements.

Table 1 .

 1 Descriptive statistic data of the factors used for building the download incrementing indicator

		Revisions 2010	OpenedIssues	Revisions	DownloadDelta
			2011	Checker 2011	Checker 2010
	Mean	103.20	2.6	0.65	0.51
	Median 18.00	0.00	1.00	1.00
	Std Dev 252.99	8.17	0.48	0.50
	Min	0.00	0.00	0.00	0.00
	Max	3431.00	86.0	1.00	1.00
	N	760	760	760	760

Table 2 .

 2 Descriptive statistic data of the factors used for validating the download incrementing indicator

		Revisions 2010	OpenedIssues	Revisions	DownloadDelta
			2011	Checker 2011	Checker 2010
	Mean	127.10	3.77	0.67	0.51
	Median 23.00	0.00	1.00	1.00
	Std Dev 276.02	20.44	0.47	0.50
	Min	0.00	0.00	0.00	0.00
	Max	2444.00	352.00	1.00	1.00
	N	379	379	379	379

Table 3 .

 3 Descriptive statistic data of the factors used for building the revisions indicator

		Revisions 2010	Vigor	average
			2010
	Mean	101.50	107.90
	Median	6.50	10.95
	Std Dev	294.37	296.09
	Min	0.00	0.00
	Max	3431.00	3431.00
	N	880	880

Table 4 .

 4 Descriptive statistic data of the factors used for validating the revisions indicator

		Revisions 2010	Vigor	average
			2010
	Mean	109.2	120.10
	Median	5.0	8.297
	Std Dev	368.63	386.26
	Min	0.0	0.0
	Max	4337.0	4337.0
	N	440	440

Table 5 .

 5 Correlation table of the factors used for constructing the download incrementing model

		Revisions 2010 OpenedIssues	Revisions	DownloadDelta
			2011	Checker 2011	Checker 2010
	Revisions 2010 -	0.364	0.276	0.157
	OpenedIssues	0.364	-	0.169	0.150
	2011
	Revisions	0.276	0.169	-	0.305
	Checker 2011
	DownloadDelta	0.157	0.150	0.305	-
	Checker 2010

Table 6 .

 6 General linear model coefficients for the download incrementing model

		Estimate	Std. Error z value	Pr(> |z|)
	(Intercept)	-1.9040894 0.1774413	-10.731	<2e-16
	Revisions 2010	-0.0009697 0.0003615	-2.683	0.00730
	Revisions Checker 2011 1.4808722	0.1935980	7.649	2.02e-14
	OpenedIssues 2011	0.0351792	0.0135808	2.590	0.00959
	DownloadDelta Checker	1.8329578	0.1749270	10.478	<2e-16
	2010

Table 7 .

 7 Wald statistic for the download incrementing indicator

		β	St. Er.	Wald df	Sig.	Exp(β)
	(Intercept)	-1.9040894 0.1774413 115.2 1	0.0	0.1489582
	Revisions 2010	-0.0009697 0.0003615 7.2	1	0.0073 0.9990307
	Revisions Checker 2011 1.4808722 0.1935980 58.5	1	0.0	4.3967788
	OpenedIssues 2011	0.0351792 0.0135808 6.7	1	0.0096 1.0358053
	DownloadDelta Checker	1.8329578 0.1749270 109.8 1	0.0	6.2523523
	2010

Table 8 .

 8 Classification table for the download incrementing indicator

	Predicted increase of downloads
	Measured increase
	of downloads Yes	No	%
	Yes 294	85	77
	No 107	274	72
	% 73	76	75

Table 9 .

 9 Classification table for the Revision prediction indicator

	Predicted new revisions
	Observed new
	revisions Yes	No	%
	Yes 378	63	86
	No 1	438	99
	% 99	87	93

Table 10 .

 10 Validation table for the download increasing indicator

	Predicted increase of downloads
	Measured increase
	of downloads Yes	No	%
	Yes 113	78	60
	No 36	152	81
	% 76	66	70

Table 11 .

 11 Validation table for the new revisions prediction indicator

	Predicted new revisions
	Observed new
	revisions Yes	No	%
	Yes 166	35	83
	No 6	216	97
	% 97	86	90