Pervasive fun
First Monday

Pervasive fun by Benno Luthiger and Carola Jungwirth



Abstract
The goal of the study on Fun and Software Development (FASD) is to precisely assess the importance that fun has as motivation for software developers to engage in open source projects. A survey carried out both under open source developers and programmers working in Swiss software companies yielded that the fun motive accounts for about 27 percent to 33 percent of open source developers’ motivation.

Fun is a pervasive feature of software development, not only for open source programmers but in the area of commercial software development too: Open source developers that are paid for their work are observed to be very motivated and prepared for future effort, especially if they enjoy their development time. Furthermore, the fun that programmers experience functions as a good proxy for their productivity. Therefore, employers that want to enhance the programmers’ productivity can safely invest in an environment of fun for developers in their company.

Contents

1. Introduction
2. The FASD study: Design and realization
3. The importance of fun for open source developers
4. Fun in the commercial software development area
5. Comparison between open source developers and software developers in the commercial realm
6. Conclusions

 


 

1. Introduction

Open source software is available for anyone to use without legal ramifications or entanglements, because it is legally permitted to be downloaded and used without having any financial obligations to the original provider. The open source movement repeatedly has successfully produced software of extraordinary quality since the concept of open source development came into existence. In fact, over time, the emergence of the open source movement has steadily increased its dynamic and now poses a serious challenge to commercial software. How is the phenomenon to be explained? Did homo oeconomicus become mad when he entered the software area?

To answer these questions, we need to ask about the motivations of actors in the open source area. Research dealing with open source phenomenon has identified a variety of motivations and has been able to give a reasonable theoretical justification for them (e.g. Hars and Ou, 2001; Lerner and Tirole, 2002; Osterloh, et al., 2002; Franck and Jungwirth, 2003; Lakhani and Wolf, 2003; and, Hertel, et al., 2003). What’s missing so far from this research is a quantification of different motivations. We’re able to understand the motivations of contributors to open source projects in theory, but we don’t know how important these motivations are in practice. Possibly we have a misleading impression of open source developers because we assume motivations that are theoretically elegant but insignificant in praxis. Besides the statements about the existence of motivations to engage in open source, we have to come to statements about their relevance in order to get a realistic impression of actors in the open source area.

This paper aims to take a first step to fill this gap. In the FASD study (Fun and Software Development, see Luthiger (2006)) the fun motive is the exclusive concentration. Our ambition is to explain the share of the open source developers’ engagement that can be attributed to fun.

Therefore, the main research question of the FASD study is: How much of the open source developer’s engagement can be explained by a model in which fun and spare time enter as independent variables? In other words, we are trying to determine, assess, and quantify the importance and impact of fun as a motivating force for open source developers.

The assumption behind this research question is that software development is done because it is fun. Open source developers, therefore, program in their spare time, because they consume “fun” with this activity and the developed open source software is a by–product of this activity. This explanation sounds reasonable but is not enough to justify the existence of open source software. The fact that programming is fun may explain that there are persons doing this activity in the first place. However, we have to take into consideration that one can earn money by developing software. If we are dealing with rational software developers, the possibility to earn money is without doubt an additional utility. Consequently, we don’t expect anyone, at least no rational actor, to program in his or her spare time anymore, because having fun and earning money is mutatis mutandis better then only having fun.

Therefore, if we want to explain the existence of open source software by the fun motive, we have to postulate that having fun while programming is somewhat substitutive to earning money with software development. The open source development has to offer better opportunities to enjoy programming then working in the commercial software area. In the FASD study, we want to verify this hypothesis by asking our second research question: Do software developers in open source projects enjoy more fun than programmers working under commercial conditions?

This question can be verified by finding significant differences concerning the experience of fun when comparing open source and commercial software developers; however, an additional question then arises: Are the characteristics of an open source project, which a software developer is participating in his spare time, constitutive for the difference concerning the experience of fun?

In the next sections we will answer these three research questions based on the data gathered in the FASD study. The paper is organized as follows. In the following section (section 2) we briefly describe the design of the FASD study and the sample characteristics. We then report the quantitative findings about the importance of fun (section 3). In section 4 we give details about the data gathered in the control group of commercial software developers. In the next section, we compare the experience of fun of both the sample of software developers and the sample of programmers working under commercial conditions (section 5). We conclude the paper with a discussion of the findings of the FASD study (section 6).

 

++++++++++

2. The FASD study: Design and realization

To measure the importance of fun to explain the engagement of open source developers, we need a model that links fun as independent variable with engagement as a dependent variable. With such a model we can adopt the same methodology Hertel, et al. (2003) used to determine the main motivational factors for team development in an open source project. Thus, instead of asking how important the fun motive is compared with the other possible motivations for an engagement, the variance of engagements among different open source developers is considered. By inquiring into the accuracy of our model (containing fun as independent variable) in explaining developers’ engagement, the quantitative estimate can be identified.

The model that is being sought can be understood as a production function establishing a functional connection between input and output factors. The output factor in this case is the engagement in an open source project whereas the input is the fun the developers have while programming. A customary production function has a concave shape, indicating that an additional unit of the input factor only adds to a sublinear increase of the output. A possibility to model such a decreasing marginal utility is a quadratic function with negative coefficient in the quadratic term.

In addition to “fun” as input factor, it seems reasonable to add the availability of spare time as a second input factor. The phenomenon we want to explain is the free and voluntary engagement of an open source developer. Obviously, such an engagement occurs in their spare time. If an individual developer does not have any spare time, he simply does not have the possibility to engage, independent of the fun he might have while programming. Again, the marginal utility of an additional unit of spare time shall be decreasing, thus, a model is suggested with negative coefficient in the quadratic term. With these considerations, the following production function is arrived at:

equation 1
whereE: voluntary, unpaid engagement
 F: fun
 T: spare time
 a1; a2; b1; b2 > 0

 

equation 2
whereE: voluntary, unpaid engagement
 F: fun
 T: spare time
 a,b > 0

Having the production function, the question arises on how to operationalise the variables in the model. In the FASD study, we used three different possibilities to operationalise engagement of open source developers. First, we asked the respondents about their readiness for future engagement in open source projects. Such a question has been proposed in Hertel, et al. (2003). Second, we ask open source developers about how much of their spare time is dedicated to open source projects. As a third possibility we tried to determine engagement by the number of contributed patches and lines of code. Again, this question was influenced by Hertel, et al.

To determine fun while programming we rely on the flow concept developed by Csikszentmihalyi (1975). Flow is a special form of fun. The flow experience is characterized by the following elements:

  • Concentrating and focusing: a high degree of concentration on a limited field of attention (a person engaged in the activity will have the opportunity to focus and to delve deeply into it).

  • A loss of the feeling of self–consciousness: the merging of action and awareness.

  • Distorted sense of time: the subjective experience of time is altered.

  • Control and a high level of absorption: a sense of personal control over the situation or activity.

  • Clear goals and immediate feedback: expectations and rules are discernable and successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed.

  • Flow of actions: each step leads fluently to the next as if the events are lead by an inner logic.

For that flow can happen, there are some prerequisites that govern the situation:

  • Attention focusing: Attention has to be focused on a limited field of stimulus.

  • Balance between ability level and challenge: The perceived requirements have to be in balance with the person’s ability level, whereas both requirements and the person’s abilities have to be over average (in the actor’s view).

Flow channel segmentation model
Figure 1: Flow channel segmentation model [1].

The last point has been expanded to the flow channel segmentation model by flow research (see Figure 1). This model states that the flow experience is the counterpart of apathy and beyond boredom and anxiety (see Csikszentmihalyi, 1975). According to this model, a person falls into apathy if both challenges and abilities are low. If challenges increase, apathy goes over to worry and anxiety. Having challenges fixed, apathy may change to relaxation and boredom with increasing skills. Boredom changes to control by raising challenges and eventually goes over to flow. With constant challenges, anxiety is replaced by arousal and goes over to flow with increasing abilities.

The flow concept seems to be specifically prolific in the context of computer work in general and programming in particular. Since Csikszentmihalyi presented his seminal concept, an abundance of studies have appeared that measured flow (e.g. Rheinberg, et al., 2002; Montgomery, et al., 2004; Chen, et al., 2000; and, Novak, et al., 1998). In the FASD study, we were heavily influenced by the flow questionnaire Remy (2002) developed to measure the flow experience of computer activities.

To calculate respondents’ spare time we asked some additional questions.

In order to achieve the aims of the FASD study, a questionnaire for an online survey was developed. There were two versions of this questionnaire, one addressing open source developers, the other addressing programmers working in commercial software firms. The questionnaires consisted of 53 questions. The first part of the questionnaire was identical for both versions. The purpose of this part was to measure the flow software developers experience during their work.

In the following part, we asked the open source developers about their readiness for future activities in open source projects, about how many patches and modules they have developed so far, and how much of their working hours and spare time respectively they spend on developing open source software. With these questions, the criterion variables were established, i.e. they function as a measure of developers’ commitment.

In a further part of the questionnaire, open source developers were asked about the reasons why they initially joined an open source project or why they started one themselves. In the concluding part of the questionnaire, we gathered demographic data about the respondents and tried to elicit information about the opportunity cost they have when they work for open source projects in their spare time, e.g. by asking them how much spare time and how many hobbies they have.

In the questionnaire for developers in commercial software firms, we asked them about their willingness to work overtime and about how many checkins they did in the past few days in order to get an impression of their commitment. In a further part of the survey, these developers were asked about their relationship to their employer, i.e. how proud they are of their employer and how well they can develop personally and professionally at their workplace. We further asked them how frequently they feel deadlines, about the project visions behind the software projects they work on and about the project managers’ formal authority and professional competence. Again, gathering demographic data concluded this questionnaire.

The questionnaire we used was standardized containing no open questions. About 80 percent of the questions were formulated as statements; the respondents then indicated their agreement with the statements from “completely unimportant” to “very important” and “is never the case” to “is always the case” respectively on a six–point Likert scale.

By directly comparing the answering behavior of open source developers and programmers working for commercial firms, it is possible to test the hypothesis that the two groups differ significantly concerning the experience of flow. And by asking the commercial developers about deadlines, project visions and formal authority — all characteristic elements of the commercial software development model which distinguish it from the open source model — the factors responsible for a potential difference between them can be identified.

The open source version of the questionnaire was launched on 3 May 2004. We sent mail to the mailing lists of various projects hosted by SourceForge, GNU/Savannah and BerliOS. This questionnaire was available for 53 days until 25 June 2004 and was filled in by 1,330 respondents. For the second questionnaire, six software companies were identified in Switzerland ready to collaborate with the FASD study. The questionnaire for developers working for these companies was open from 20 September until 10 November 2004. A total of 114 software developers answered this version of the questionnaire.

 

++++++++++

3. The importance of fun for open source developers

With the data gathered from open source developers on one hand and the model on the other we are able to calculate the importance of fun as motivational factor to explain the open source phenomenon. However, we have to prepare the data gathered first.

3.1. Engagement and spare time

With questions 40 to 42 [2] of our questionnaire, we were able to calculate the use of time for open source (Table 1). The contributors spend an average of 12.56 hours per week on OSS activities (median: 8 hours per week). This value is 1.5 hours below the value found out by Lakhani and Wolf [3]. During spare time, 7.31 hours are spent (58 percent of the time, median: 4.8 hours) and 5.22 hours during working hours (median: 1.5 hours). This statistical analysis corroborates the impression that the commitment for open source projects mainly happens in spare time. Yet, the share of development of open source projects during working time amounts significant level of 42 percent. However, we have to consider that the professional open source developers may be underrepresented in the FASD study. Professional open source projects can afford their own project infrastructure and, therefore, are not dependent on the open source platforms addressed in our study.

Combining the answers of the questions 40 to 42, a value for spare time was calculated [4]. On average, the respondents have 26.7 hours of spare time per week (Table 1). This value for spare time will be used as input for the second independent variable in the model.

 

Table 1: Time spent for open source (hours per week).
Source: Benno Luthiger, FASD Study, University of Zurich.
 Mean valueStandard deviationValid number
Time spent in general12.56 (100%)14.181228
Time spent spare time7.31 (58%)8.231215
Time spent during working hours5.22 (42%)10.821215
 
Hours per week spare time26.7024.391210

 

Table 2 describes the amount of spare time spent by developers on open source. From this table we can infer that more than one third of developers are paid for spending a majority of their time developing open source software. For the remaining two thirds of the programmers, open source activity takes place mainly in their spare time. Lakhani and Wolf found 40 percent of spare time spent by open source developers [5]. However, they did not specify how much open source engagement occurs during working hours.

 

Table 2: Share of time spent in spare time.
Source: Benno Luthiger, FASD Study, University of Zurich.
  NumberPercentValid percentCumulated percent
Valid0%–10%15311.5%11.9%11.9%
 11%–20%836.2%6.5%18.4%
 21%–30%715.3%5.5%23.9%
 31%–40%483.6%3.7%27.6%
 41%–50%745.6%5.8%33.4%
 51%–60%675.0%5.2%38.6%
 61%–70%493.7%3.8%42.4%
 71%–80%1078.0%8.3%50.7%
 81%–90%1148.6%8.9%59.6%
 91%–100%51838.9%40.4%100.0%
 Total74128496.5% 
Missing 463.5%  
Total 1330100.0%  

 

The frequency distribution (see Figure 2) shows two peaks at the corner points. This distribution suggests a differentiation in professionals and open source hackers. A professional is designated as an open source developer producing less then 10 percent of his open source engagement in his spare time. Such a programmer engages virtually exclusively during working hours. In contrast, a programmer whose open source engagement takes place for more then 90 percent of spare time matches the image we have of an open source hacker. The share of professionals in our sample amounts to around 12 percent whereas open source hackers contribute about 40 percent to our sample.

Share of time spent in spare time
Figure 2: Share of time spent in spare time.

Do these two types differ concerning their engagement for open source? Statistical analysis shows that indeed professionals spend 14.6 hours per week, a significantly higher amount than hackers with 9.7 hours per week (see Table 3).

 

Table 3: Time spent per programmer type.
Source: Benno Luthiger, FASD Study, University of Zurich.
 Mean valueStandard deviationValid number
Professional14.6024.17131
Hacker9.699.54496

 

With questions 29 to 31 [6] we queried different aspects of the readiness for future engagement. A factor analysis showed that these three items can be reduced to one underlying factor [7]. Therefore, we will work with an index “readiness for future effort” built on the values of these three items in the further evaluation.

How is professionals’ readiness compared with hackers? Not very surprisingly, in two of the three items and also in the whole index, hackers show significantly higher values for the readiness then professionals (see Table 4). This shows that hackers are more enthusiastic about their open source activities then their professional counterparts.

 

Table 4: Readiness per programmer type.
Source: Benno Luthiger, FASD Study, University of Zurich.
 Mean valueStandard errorNumber
 
Professional4.660.10145
Hacker5.080.04503
Total4.98***0.04648
 
Professional4.270.11145
Hacker4.410.05499
Total4.38***0.05644
 
Professional3.600.13146
Hacker4.230.06487
Total4.08***0.05633
 
Professional4.160.10148
Hacker4.580.04505
Total4.49***0.04653
 
Remark: *** Difference significant at 1% level

 

The time spent for open source represents actual time and readiness for future effort stands for the forthcoming type of engagement. Correspondingly, with output and productivity we discover aspects of engagement in the past. The starting point for the calculation of output and productivity are the questions about the number of patches (question 38) and classes/modules/files (question 39) produced so far. This part of the FASD questionnaire was influenced by Hertel, et al. (2003), where the respondents were asked about the number of patches (among other aspects). However, the question arises whether this measure (number of patches or number of classes/modules/files) is appropriate in the context of this study. We will discuss this issue below.

To calculate output, we divided the values of the questions 38 and 39 by the number of years the person has been active in open source development (Table 5). To reach a value for productivity, we set this calculated output in relation with the time spent per week for open source (question 40); see Table 6.

 

Table 5: Output per year.
Source: Benno Luthiger, FASD Study, University of Zurich.
 MeanStandard errorNumber
Number of patches per year28.464.551187
Number of classes/modules/files per year73.468.681193

 

 

Table 6: Productivity.
Source: Benno Luthiger, FASD Study, University of Zurich.
 MeanStandard errorNumber
Productivity concerning patches2.550.351168
Productivity7.880.991172

 

3.2. Flow of open source developers

We operationalized the dependent variable “fun” in our model using the flow concept developed by Csikszentmihalyi. By means of factor analysis, we tried to identify the decisive factors which underlie the 28 questions of the FASD questionnaire concerning the flow experience. Both KMO– and Bartlett’s test proved that the data is suitable for factor analysis. After some investigation, we decided to work with only one factor flow/fun. This single factor accounts for 26.8 percent of the original variance. The reliability analysis using Cronbach’s α to assess the quality of the scale resulting from the factor analysis shows a good value for the extracted factor (0.86).

Table 7 shows the extracted factor’s communalities and factor loadings. Factor loadings vary between 0.73 and -0.02. Not surprisingly, the item (Question 27: I completely concentrate on my programming work) showing the highest factor loading has the highest communality too. The items with the least factor loadings have no communalities at all.

 

Table 7: Open source questionnaire: Factor loading of fun factor.
Source: Benno Luthiger, FASD Study, University of Zurich.
Flow/funCommunalityLoading
1I lose my sense of time.0.160.40
2I cannot say how long I’ve been with programming.0.150.38
3I am in a state of flow when I’m working.0.250.50
4I forget all my worries when I’m working.0.290.54
5It’s easy for me to concentrate.0.410.64
6I’m all wrapped up in the action.0.460.68
7I am absolutely focused on what I’m programming.0.480.69
8The requirements of my work are clear to me.0.330.57
9I hardly think of the past or the future.0.140.37
10I know exactly what is required of me.0.270.51
11There are many things I would prefer doing. (-)0.020.16
12I feel that I can cope well with the demands of the situation.0.280.53
13My work is solely motivated by the fact that it will pay for me. (-)0.00-0.02
14I always know exactly what I have to do.0.300.55
15I’m very absent–minded. (-)0.000.01
16I don’t have to muse over other things.0.130.36
17I know how to set about it.0.270.52
18I’m completely focused.0.510.71
19I feel able to handle the problem.0.410.64
20I am extremely concentrated0.510.72
21I’m looking forward to my programming work.0.370.61
22I enjoy my work.0.310.56
23I feel the demands upon me are excessive. (-)0.010.09
24Things just seem to fall into place.0.310.56
25I forget everything around me.0.350.59
26I accomplish my work for its own sake.0.120.34
27I completely concentrate on my programming work.0.540.73
28I am easily distracted by other things. (-)0.130.36

 

The reduction of the 28 variables concerning the experience of flow to one basic factor sets up the basis for further evaluation.

To what extent does the joy of programming correlate with a commitment to open source? The more fun a developer has while programming and the more he is wrapped up in the activity, the more time he spends on open source projects. Table 8 clearly shows that the experience of flow has its strongest effect on the time spent on open source during spare time whereas the correlation with the time spent for open source at the work place is smaller and not significant.

 

Table 8: Correlation of time spent for open source with flow/fun.
Source: Benno Luthiger, FASD Study, University of Zurich.
 Total of time spentSpare timeWorking time
Pearson correlation0.12***0.16***0.03
 
Remark: *** Significant at 1% level

 

The effect of the experience of flow is even stronger on the readiness for future activities for open source (see Table 9). The more fun a programmer has in his activity, the greater is his readiness for future commitment to open source projects.

 

Table 9: Correlation of readiness for future effort with flow/fun.
Source: Benno Luthiger, FASD Study, University of Zurich.
 Readiness for future effort
Pearson correlation0.37***
 
Remark: *** Significant at 1% level

 

Is there a connection between flow experience and the developer’s output and productivity? We expect that flow affects these measures positively: The more fun a programmer has, the more frequently he works for open source and the more productive he is. However and in contrast to the study by Hertel, et al. [8], in which the number of patches correlated positively and with significant values for motivational factors, we only get insignificant results. It is questionable whether the measure we used for the programmers’ performance is useful for a study with a broad focus like the FASD study. Hertel, et al. concentrated on developers of the Linux kernel project. In this community, the interpretation of terms (e.g. “patch”, “class”, etc.) might be more consistent then in the sample we investigated leading to the positive effect of their study.

3.3. Regression analysis

Having prepared the data as described above, we’re ready to carry out the regression analysis. First, we have to guarantee that the data fulfills the prerequisites needed for an OLS (ordinary least square) regression. The collinearity statistics showed that the data exhibited no problems with multicollinearity. On the other hand, the analysis of the standardized residuals proved the existence of considerable heteroscedastic error terms. However, this problem can be tackled using heteroscedasticity–consistent standard error estimators for the OLS regression coefficients (see Hayes and Cai, 2004). Thus, the data gathered meets the requirements for an OLS regression analysis.

We first calculated the regression analysis with the readiness for future effort as dependent variable. As independent variables we filled in the results of the factor analysis and the developer’s spare time both in quadratic form. Table 10 shows the results of the first regression analysis. The factor “flow/fun” contributes significantly only with the linear term. The opportunity costs of the time do not affect the readiness for future effort at all. The model quality amounts to 15 percent.

 

Table 10: Readiness as a function of fun 1.
Source: Benno Luthiger, FASD Study, University of Zurich.
Dependent variableReadiness for future effort
Independent variablesEstimated coefficients
Flow/fun1.122***
 (0.380)
Constant13.671
R20.145
Number of cases917
 
Remarks: *** Significant at 1% level
Standardized beta coefficients in parenthesis.

 

An even better result occurs when using a linear model with the original items instead of the calculated factor as independent variable (see Table 11). Seven of these items contribute with significant values whereby item 20 with a negative sign [9]. If this model is controlled with demographic variables, only the respondent’s age contributes significantly, namely with a negative sign. The older the developers are, the less their readiness for future efforts in open source projects. This seems quite reasonable. This model explains 27 percent of the variance of the dependent variable.

 

Table 11: Readiness as a function of fun 2.
Source: Benno Luthiger, FASD Study, University of Zurich.
Dependent variableReadiness for future effort
Independent variablesEstimated coefficients
21:I’m looking forward to my programming work.0.906***
 (0.284)
22:I enjoy my work.0.442***
 (0.113)
26:I accomplish my work for its own sake.0.261***
 (0.112)
20:I am extremely concentrated.0.280***
 (-0.097)
24:Things just seem to fall into place.0.252***
 (0.094)
27:I completely concentrate on my programming work.0.267***
 (0.090)
2:I cannot say how long I’ve been with programming.0.146**
 (0.072)
Age-0.060***
 (-0.170)
Constant5.954
R20.270
Number of cases1080
 
Remarks: *** Significant at 1% level
** Significant at 5% level
Standardized beta coefficients in parenthesis.

 

Table 12 shows the regression analysis with (spare) time spent as dependent variable. In this regression, the factor “flow/fun” contributes significantly, however, the quadratic term disappears again, whereas the spare time appears with quadratic term. The model quality of this regression amounts to 32 percent. The comparatively high beta coefficient of the spare time indicates that time spent for open source is mainly limited by the amount of spare time available.

 

Table 12: Time spent as function of fun and time.
Source: Benno Luthiger, FASD Study, University of Zurich.
Dependent variableTime spent in spare time
Independent variablesEstimated coefficients
Flow/fun1.210***
 (0.144)
Spare time6.127***
 (0.781)
Spare time2-1.468***
 (-0.403)
Constant8.738
R20.323
Number of cases899
 
Remarks: *** Significant at 1% level
Standardized beta coefficients in parenthesis.

 

In Table 13 we identified a subsample of our sample as professional open source developers. How important is fun for these developers? Table 13 shows that the factor “flow/fun” contributes only with the linear term significantly to the regression. The model quality of this regression is 24 percent which is significantly higher then the model quality of the regression calculated for all open source developers (Table 10). The professionals’ readiness for future effort seems to be highly determined by the joy of programming.

In this study, professionals have been designated as those open source programmers that work on open source in their working hours for at least 90 percent of the time. If these programmers work in their spare time on open source, this engagement is exclusively determined by the availability of spare time. The factor “flow/fun” doesn’t contribute significantly to this model. What is astonishing with this regression is the fact that it explains 83 percent of the dependent variable’s variance (see Table 14). In addition, a regression analysis has been calculated for the whole time professionals spend on open source projects. However, this regression did not show any significant contributions. Thus, it appears that professionals’ time spent for open source is determined by other factors than the joy of programming.

For the sake of completeness, the regression analysis has been calculated with output and production as dependent variables. However, for both of these regressions, the model quality was negligible (below one percent).

 

Table 13: Professionals’ readiness as function of fun.
Source: Benno Luthiger, FASD Study, University of Zurich.
Dependent variableReadiness for future effort
Independent variablesEstimated coefficients
Flow/fun1.383***
 (0.493)
Constant12.956
R20.243
Number of cases109
 
Remarks: *** Significant at 1% level
Standardized beta coefficients in parenthesis.

 

 

Table 14: Professionals’ spare time spent as function of fun.
Source: Benno Luthiger, FASD Study, University of Zurich.
Dependent variableTime spent in spare time
Independent variablesEstimated coefficients
Spare time1.173***
 (0.745)
Spare time20.168***
 (0.224)
Constant1.344
R20.830
Number of cases130
 
Remarks: *** Significant at 1% level
Standardized beta coefficients in parenthesis.

 

3.3. Conclusions

The results obtained in this section allow for the following interpretation:

  1. Fun matters: With a model using this motivational factor we are able to explain between 27 percent and 32 percent of the engagement of an open source developer.

  2. The availability of spare time does not matter if we ask open source developers for their readiness for future efforts. In contrast, the availability of spare time is of great importance if we look at the amount of time actually spent on open source projects. This understandable result indicates the validity of the data gathered in the FASD study.

  3. The joy of programming does not wear off: each additional unit of fun is transferred linearly into additional commitment. This statement can be deduced from the fact that the flow factors contribute only with linear terms significantly to the regression.

These results show that it is possible to quantify the importance of the motivational factor “fun.” Both the developers’ engagement for open source (as readiness for further work or as amount of time spent) as well as the fun they enjoy can be determined. Using this data, then, we can look at the variation in the developers’ engagement and calculate the portion caused by the variation of the developers’ joy of programming. Thus, this method provides an explanation of a considerable amount of the open source developers’ engagement.

But the outcome proves that “fun” does not account for all of the open source programmers’ engagement. Our result conforms to the assumption that a multitude of motivations coexist to justify an individual developer’s engagement for open source (see Franck and Jungwirth (2003) or Lakhani and Wolf (2003) for example). It would be interesting to have quantified other motivational factors as reputation or altruism with similar methods.

Our data shows further that the open source phenomenon is mainly done with free time. Of the 12.6 hours a software developer works on average per week, 7.3 hours (58 percent) account for the developer’s spare time. However, a considerable amount of 5.2 hours (42 percent) is done during working time. Furthermore, we have to take into consideration that our data is biased and professional open source developers are underrepresented in our sample. We therefore assume that the paid development of open source software has caught up with free time open source development.

Does this mean that fun becomes less important as paid development increases? Our data shows clearly that the engagement of paid software developers is guided by other factors than fun. This can be deduced from the fact that the amount of time professionals (in our sample of open source developers) spend for developing open source software is completely independent of their joy of programming. However, this conclusion only holds if we look at the engagement in the form of hours worked for open source. If we look at their willingness to engage for open source, “fun” becomes even more significant. In the case of open source developers in general, the fun motive accounts for 15 percent of the variance in the developers’ readiness (see Table 10) whereas in the case of open source professionals, this number rises to 24 percent (Table 13).

It can be assumed that enjoying the work increases motivation and, thus, fun has a positive effect on the developers’ productivity. If this assumption is true, the importance of fun does not diminish. Indeed, based on the conclusion drawn earlier, fun should even become more relevant in commercial software development.

In our study, one object of measurement was developers’ productivity. However, the data gathered for productivity shows little correlation with the joy of programming: Less then one percent of developers’ productivity can be explained by developers’ experience of flow. It was concluded that the way developers’ productivity was operationalized is not well suited to the area of this study. We will discuss the problem of measuring productivity of software developers in the next section.

 

++++++++++

4. Fun in the commercial software development area

In the previous section, the importance of fun for open source developers was examined. It was shown that the joy of programming plays an important role even for those developers that are paid for their open source engagement. In this section, the importance of fun in the commercial software development area will be investigated.

The questionnaire for commercial software developers corresponded to the open source questionnaire concerning the flow part, but differed concerning the questions about open source activities. Instead, commercial developers were asked about their relation to their employer (e.g. how proud they are of their employer, etc.) and their project situation (e.g. the frequency of deadlines, how strongly the feel the formal authority of the project manager, etc.).

This questionnaire was filled by 114 software developers working in six Swiss software companies. This response rate is too small to make the sample representative. Therefore, the results presented in this section have to be taken with caution.

4.1. Flow of commercial developers

The preliminary analysis of the questionnaire data filled by commercial software developers showed that some items must be excluded in order to obtain acceptable values for the factor analysis. The anti–image correlation matrix showed poor values for items 13, 15, 16 and 26 [10]. After having excluded these values, the KMO value rose to a satisfactory level of 0.847. Again, only one underlying factor was sought: flow/fun. This single factor accounts for 35.2 percent of original variance. The reliability analysis using Cronbach’s α to assess the quality of the scale resulting from the factor analysis shows a good value for the extracted factor (0.91).

Table 15 shows the extracted factor’s communalities and factor loadings. Factor loadings vary between 0.77 and 0.41. Thus, the data from the commercial questionnaire has significantly less variance in the factor loadings. This is consistent with the fact that the calculated factor flow/fun from the commercial questionnaire explains significantly more of the items’ variance (35.2 percent) then the extracted factor flow/fun in the open source questionnaire (26.8 percent).

 

Table 15: Commercial questionnaire: Factor loading of fun factor.
Source: Benno Luthiger, FASD Study, University of Zurich.
Flow/funCommunalityLoading
1I lose my sense of time.0.290.54
2I cannot say how long I’ve been with programming.0.210.46
3I am in a state of flow when I’m working.0.390.63
4I forget all my worries when I’m working.0.270.52
5It’s easy for me to concentrate.0.420.65
6I’m all wrapped up in the action.0.520.72
7I am absolutely focused on what I’m programming.0.540.74
8The requirements of my work are clear to me.0.340.58
9I hardly think of the past or the future.0.170.41
10I know exactly what is required of me.0.160.41
11There are many things I would prefer doing. (-)0.280.53
12I feel that I can cope well with the demands of the situation.0.280.53
14I always know exactly what I have to do.0.210.45
17I know how to set about it.0.390.63
18I’m completely focused.0.590.77
19I feel able to handle the problem.0.280.53
20I am extremely concentrated0.440.67
21I’m looking forward to my programming work.0.280.53
22I enjoy my work.0.310.55
23I feel the demands upon me are excessive. (-)0.200.44
24Things just seem to fall into place.0.540.73
25I forget everything around me.0.550.74
27I completely concentrate on my programming work.0.560.75
28I am easily distracted by other things. (-)0.240.49

 

How does the joy of programming correlate with other factors that determine work conditions of commercial software developers? Table 16 shows the correlations of flow components with the index “Engagement at work place”. This index consists of the questions 29 to 31 [11]. Not surprisingly, this engagement correlates highly with the fun that developers experience at their workplace.

 

Table 16: Flow and engagement at work place.
Source: Benno Luthiger, FASD Study, University of Zurich.
 Correlation coefficientSignificance level
Engagement at work place
Flow/fun0.402***0.000
 
Remark: *** Significant at 1% level

 

Table 17 shows the correlations of the flow factor with the index “Relation to the employer” built with the questions 32 to 35 [12]. Again, this correlation is highly significant (although less then the previous). The better the relation to the employer, the more he enjoys his work. Or put the other way round, the more fun a software developer has while programming, the better the image of the employer.

 

Table 17: Flow and relation to the employer.
Source: Benno Luthiger, FASD Study, University of Zurich.
 Correlation coefficientSignificance level
Relation to the employer
Flow/fun0.244**0.015
 
Remark: ** Significant at 5% level

 

A rather surprising impression results from the correlations of the flow factors with the questions concerning the project situation (questions 38 to 42, see Table 18). The flow factor correlates significantly positive with pressures from deadlines. We conclude that software developers experience fun with the pressure of deadlines. This contradicts the findings by Amabile, et al. (1976). They concluded that deadlines affect adversely the intrinsic motivation of the individuals involved. It seems that the pressure imposed by deadlines does not impair developers’ fun in the context of a software project. On the contrary, deadlines seem to be perceived as challenges leading to higher concentration, such that the programmer ultimately experiences flow and fun.

However, the significant correlation between the feeling of a project vision and the flow factor meets our expectations. It makes sense that an understandable project vision has a direct impact. By means of a project vision, it is possible to clarify uncertainties in the daily routine, which spurs project work and helps developers to concentrate.

 

Table 18: Flow and project situation.
Source: Benno Luthiger, FASD Study, University of Zurich.
 Correlation coefficientSignificance level
38: How often do you feel deadlines?
Flow/fun0.271***0.006
39: How often are the projects supported by a clear project vision?
Flow/fun0.345***0.000
 
Remark: *** Significant at 1% level

 

4.2. Fun and productivity

In the open source survey we tried to assess developers’ productivity by counting the number of patches or modules developed per time unit. In the survey for the commercial developers, the recent number of checkins was requested. However, in both cases, the numbers gathered from the sources showed no significant correlation with fun that developers experienced. There are two possibilities to interpret this outcome. Either we can conclude that in fact there exists no such relation between fun and developer productivity or we can infer that such a relation exists, although the productivity measures used in this study may not be appropriate.

If the first interpretation is true, this would mean that a developer would have fun while programming without being successful in solving problems as well as the reverse case, where a developer is very productive without enjoying his work. This does not seem possible. A person experiences flow if his capabilities match the challenges posed by the task at hand. If the programmer is not able to accomplish the task, if she fails, she will be frustrated by her work, far from enjoying it. In on the other hand if the programmer easily completes the work at hand, she will not be able to sustain concentration over a longer period to be productive; indeed she will be bored. Our interpretation, therefore, for the fact that we have not been able to show any correlation between fun and productivity is that we used a poor measure to assess productivity of developers.

If the term “productivity” is considered to be a capacity to solve problems — a reasonable interpretation in the area of software development — it becomes understandable why our measures were poorly suitable. To fix a bug in a program it possibly needs only one small change in the code. However, this might be a bug that is very subtle and hard to find. New features to implement may need changes in very different areas in the project or can be implemented in a concise peace of code depending on the technology used. Inexperienced developers possibly need a number of checkins until the module runs error free whereas expert programmers attain new application functionality faultless at the first push. Depending on the circumstances and the problem to solve, high numbers reflect high productivity or exactly the opposite.

Having shown that the measures used are not adequate, the question arises what a good measure would look like. Based on our experience with the FASD study, it is obvious that productivity is an interaction between professional skills, tools used and the complexity of tasks to complete. With constant skills and tools used, a person is more productive if the number of tasks achieved per time unit is of higher complexity. With given skills and fixed difficulty level, a person’s productivity will improve if the programmer can use efficient tools compared to a situation where she has to use archaic tools. With appropriate means and fixed task complexity, productivity will increase with growing capabilities.

According to Asendorpf (1996) capabilities are “character attributes that allow achievements.” [13] These capabilities consist of social and genetic components but they can also be acquired by education and experience, i.e. human capital investments. By the tools used in the case of software development we mean the combination of hardware infrastructure (performance of computer processors, transferrate of data communication, etc.) and the programs used for the development process (e.g. code editors of integrated development environments, version and configuration management, etc.). Therefore, to predict productivity one method would be to review an individual’ experience and education as well as the tools at hand. The task to achieve and its complexity are exogenously given.

Now, what connection exists between productivity in this interpretation and fun? From our point of view, productivity is related to fun via the factor “motivation”. However, motivation does not exist in our list of factors constituting a person’s productivity. This makes sense: In our opinion, motivation results from a match between a person’s capability and the challenge and complexity of the task at hand [14]. A person with insufficient capabilities is challenged and not able to complete an assignment in a timely fashion. An individual not completely challenged to the extent of their capabilities on the other hand will be bored and for this reason not able to completely exhaust her achievement potential. Thus, the element “motivation” relates the factor “capability” with the aspect “task complexity”. For an individual to be productive, she not only has to have sufficient tools and capabilities but her capabilities have to match the task’s complexity.

As shown by the research on flow phenomenon, flow experience implies a correspondence between abilities and challenges (see Figure 1). But if both motivations as well as flow experience indicate an optimal match of capabilities and challenges and if this correspondence determine a person’s productivity (presupposing the availability of suitable tools and given the person’s abilities), this implies nothing else than the fun enjoyed while working is a proxy for productivity. Thus, both the original question of how the joy of work affects the productivity and the derived question of measuring productivity become futile. Fun as such can be used as the sought–after measure for productivity.

If this deduction is true that fun is a measure for a software developer’s productivity, the findings that a satisfied and confident programmer experiences more fun gains additional importance: an employer’s investment in programmers’ satisfaction and pride should pay off with increased productivity. Thus, the following recommendations for software companies can be made:

  1. Foster the developers pride in the firm: Assist programmers in their professional training, pay attention that internal processes are professionally and efficiently implemented and develop a pleasant atmosphere in the work place.

  2. Provide project visions: Show programmers which problems can be solved by new software and what increases in value for the firm and for society are created as a result.

  3. And above all: Develop a clear understanding of your programmers’ capabilities and potential and try to offer developers appropriate challenges.

 

++++++++++

5. Comparison between open source developers and software developers in the commercial realm

After having analyzed both datasets separately, a comparison will be provided in this section. The objective of this analysis is a verification of the hypothesis that open source developers enjoy more fun while programming compared to commercial software developers. In addition, provided that this verification succeeds, an attempt will be made to identify the elements of the open source model which are responsible for this difference.

First, the possibility of a systematic bias must be discussed. Although both datasets are responses of questionnaires that are very similar, partially even identical, chances are that the results are biased systematically. Subsequently, if the existence of significant differences can be proven between the two samples, these differences are not caused by a characteristic diversity of the samples, but are the result of systematic biases provoked by the study design.

Indeed, looking at the two samples and how they were gathered, there are some differences that possibly support a notion of systematic biases. The open source survey took place in spring 2004 whereas the commercial survey was carried out six months later. The open source questionnaire was addressed to a global audience and was answered primarily in English whereas the respondents of the commercial survey were German–speaking software developers in Switzerland. The programmers in the open source sample were truly self–selected whereas the commercial developers were prompted by their employers to participate.

Luckily we have the means to bypass these differences by comparing not only the two samples but the professionals and the open source hackers within the open source sample. If this comparison gives the same result as the first, we have some inclination then to disregard the impact of systematic biases.

5.1. Comparison of age and gender

Open source programmers are 28.7 years old on the average, developers in commercial software firms are about five years older (33.7 years, see Table 19). This difference is highly significant (α < one percent).

 

Table 19: Comparison of age.
Source: Benno Luthiger, FASD Study, University of Zurich.
Comparison of age
 MeanNumber
open source programmers28.721274
commercial software developers33.65113
Total29.121387

 

The share of female programmers in the open source sample amounts to two percent. In the commercial software area, however, the share of female developers is six times higher and amounts to 12 percent (see Table 20). Again, this difference is highly significant.

 

Table 20: Comparison of gender distribution.
Source: Benno Luthiger, FASD Study, University of Zurich.
Gender
 Open sourceCommercialTotal
male1270
(1259)
98.1%
99
(110)
87.6%
1369
 
97.3%
female24
(35)
1.9%
14
(3)
12.4%
38
 
2.7%
Total12941131407
 
Remark: Expected values in parenthesis.

 

5.2. Comparison of project situation

Besides the flow experience we asked questions concerning the project situation in both surveys thus making it possible to compare answers. The comparison shows clearly the differences between the two software development models. However, Figure 3 shows that as soon as money comes into play the differences get less accentuated.

As expected, deadlines play virtual no role in open source projects whereas in commercial software projects, they are very noticeable. The difference diminishes somehow when we compare hackers with open source professionals but is still highly significant. As expected, open source projects are backed more often by clear project visions, in comparison to commercial software projects. Again, commercial open source programmers perceive less project visions than their volunteering counterparts. The comparisons concerning the desired amount of project visions and the professional competence of the project leader are pronounced (see Table 21).

 

Table 21: Project situation: Comparisons.
Source: Benno Luthiger, FASD Study, University of Zurich.
T–test for equality of means
Project situationOpen source vs. CommercialHacker vs. Commercial
deadlines-2.203***
(-21.311)
-0.779***
(-5.573)
project visions: actual0.826***
(7.010)
0.354***
(2.780)
project visions: desired0.211*
(1.935)
-0.060
(-0.570)
professional competence-0.038
(-0.357)
-0.213*
(-1.898)
 
Remarks: *** Significant at 1% level
* Significant at 10% level
t values in parenthesis.

 

Comparison of project situation
Figure 3: Comparison of project situation.

5.3. Comparison of fun

To compare the flow experience of the two samples, the flow factor resulting from the factor analysis is reconsidered, by analyzing data from the two samples. Additionally we can calculate the mean of all 28 flow items and compare that value. Figure 4 makes apparent that open source developers show a higher value for both the flow factor and average value. Table 22 proves that this difference is highly significant indeed (α < 1%).

Comparison of flow experience of software developers
Figure 4: Comparison of flow experience of software developers.

 

Table 22: Flow experience of open source and commercial developers: Comparison.
Source: Benno Luthiger, FASD Study, University of Zurich.
T–test for equality of means
Flow factorDifferenceSignificancet value
Flow/fun0.383***0.0013.475
 
Remark: *** Significant at 1% level.

 

To control for systematic biases, the flow experience of professional open source developers and open source hackers enjoy must be compared. This comparison corroborates the findings of the first comparison. Again, the open source hackers show a higher value for the flow/fun experience compared with the programmers paid for their work (see Figure 5 and Table 23).

Comparison of the flow experience of open source developers
Figure 5: Comparison of the flow experience of open source developers.

 

Table 23: Flow experience of hackers and professionals: Comparison.
Source: Benno Luthiger, FASD Study, University of Zurich.
T–test for equality of means
Flow factorDifferenceSignificancet value
Flow/fun0.360***0.0013.283
 
Remark: *** Significant at 1% level.

 

Obviously, the context of where software development is done has an impact on the joy of work. Therefore, it can be concluded, the motivational factor “fun” can explain why software developers engage in open source projects for free. They work in their spare time because it generates fun, i.e. it is much more fun to program for free then to develop software under commercial conditions.

5.4. What makes the difference

The results in the previous subsections confirm our hypothesis: The same activity — software development — generates less fun when it is practiced under commercial conditions. Thus, a fundamental question arises — which condition causes this difference? Which feature of the open source development model makes programming in this context more fun? And is this feature constitutive for the open source development model or is it possible to apply it to the commercial software development model too?

 

Table 24: Characteristic differences of software development models.
Source: Benno Luthiger, FASD Study, University of Zurich.
Featureopen sourcecommercial
project vision (+)+?
formal authority (-)-+
financial incentives (?)-+
deadlines (-)-+
optimal challenge (+)+?

 

In Table 24, some characteristic differences of the two software development models have been identified. A plus sign in parentheses marks that the attribute is expected to positively affect the joy of programming, and a plus sign in the columns indicates that the attribute exists for the respective development model.

Open source projects [15] are usually driven by a clear project vision. The project leader knows the reason why he has founded the project and chosen the appropriate open source license. He has a clear concept of the project goals. In addition, he has good reasons to communicate the project goals to other persons, e.g. the actual and potential developers in the project. A convincing project vision is very well suited to convince potential contributors to engage as well as to coordinate the contributions of the different participating programmers and to align them to the shared goal. Project visions can play a role in commercial software projects too. However, in a software company, it is, first of all, the formal authority of a superior that ultimately decides which activities a programmer will work on and how this work is evaluated. Thus, the project vision doesn’t have the same coordinating function as in open source projects.

The hierarchical structure of commercial software companies makes another difference. Hierarchies establish formal authorities. The owner of formal authority can demand a certain type of behavior from employees. This is not possible for project leaders of open source projects. The latter have to persuade contributors by their professional competence in an objective dispute if they are not satisfied with the contributions of participating developers.

Besides hierarchies and formal authorities, commercial software companies can provide financial incentives that distinguish them from open source projects — software developers are paid for their work. This possibility is not available for open source projects based on voluntary cooperation.

Usually commercial software projects are part of a commercial production and exploitation process: the software has to be delivered at a certain time with specific functionality. Therefore, deadlines are an inevitable part of commercial production processes. In contrast, each participant in open source projects can easily evade any deadlines. As in other aspects of voluntary cooperation, deadlines come into effect only by voluntary agreement.

A last distinctive feature of the two development model is related to challenges to software developers. In an open source project a developer can control challenges by self–selecting involvement in specific projects. Thus, an optimal challenge can be derived. In commercial projects on the other hand project engagement is determined by the needs of the firm, not the individual. A given project, therefore, has only limited possibilities to take into consideration a developer’s potential — his abilities, experience and expertise — as well as his interests in professional and personal evolution.

How can we verify that the described distinctive features really cause the difference concerning an experience of fun? If a feature has an effect on the flow experience, this should be indicated by appropriate correlations. In the case of deadlines for example we expect that developers experience less flow due to more “suffering” from deadlines. The same holds for formal authority: with a greater formal authority, there is correspondingly less fun. We expect a positive effect from “project vision” and “optimal challenge”: the more sensible the project vision and the better a match between abilities and challenges, there is correspondingly more joy in programming. Concerning the effect of financial incentives we cannot predict the sign of correlation; indeed we do not have data to compute any correlation in this area. We are able to test some other factors using answers about developers’ feelings about open source projects (questions 32–35 in the open source survey) and employees’ relation to the firm (questions 38–42 in the commercial survey). The feature “optimal challenge” was calculated from commercial developers’ answers to items 33 and 35 [16]. The optimal match of abilities and challenges is considered as a given in open source projects, at least for developers that aren’t paid for their involvement; hence we have no data to calculate such a correlation for open source developers. Table 25 shows the significant correlations.

 

Table 25: Correlations of distinctive features with flow/fun.
Source: Benno Luthiger, FASD Study, University of Zurich.
FeatureSample
open sourcecommercialall
Frequency of deadlines0.103***
(930)
0.256**
(88)
0.057*
(1018)
Frequency of a clear project vision0.339***
(929)
0.358***
(86)
0.354***
(1015)
Importance of the project leader’s professional competence0.169***
(927)
-0.034
(88)
0.152***
(1015)
Formal authority of the project manager-0.115
(101)
-
Optimal challenge-0.270***
(102)
-
 
Remarks: *** Significant at 1% level
** Significant at 5% level
* Significant at 10% level
Number of values in parenthesis.

 

Interestingly, the feature “deadlines” is significantly correlated with fun. Against our expectations, however, the sign of this correlation is positive for both the open source as well as the commercial sample, meaning that software developers that feel “deadlines” also experience more fun while programming. This contradicts the findings of DeMarco and Lister (1987) and Amabile, et al. (1976). Whether the project manager’s formal authority in a commercial software project is strongly sensible or not does not affect the developer’s experience of fun while programming. More in line with our expectations are other results. A comprehensible project vision correlates strongly significant with fun as does “optimal challenge.” The project leader’s professional competence has a positive impact on the developer’s joy of programming in the open source context; however, this is not the case in a commercial software project.

Therefore, we can conclude from this comparison: Software development is significantly more fun when it takes place in the context of an open source project than when it is carried out under commercial conditions. However, the reasons for this difference are not deadlines, but differences based on the project’s vision and the challenge of the work at hand. Because there is a correlation between a high frequency of deadlines and fun, the sheer existence of deadlines in commercial programming makes this sort of work more fun than less deadline–dependent open source development. Therefore, difference in the experience of flow between open source and commercial development hinges largely on project visions and optimal challenges. As shown in Table 21 (and Figure 3), open source projects have definite project visions and present unique challenges to programmers; hence open source is positively correlated with fun.

 

++++++++++

6. Conclusions

The analysis in the preceding sections shows that open source is mainly a part–time job. An open source developer participates on average for 12.6 hours per week in open source projects; 58% of this activity occurs in his spare time. From the 1,330 developers that participated in the survey, two–thirds work fully or partially for free for open source projects. In all probability, however, these numbers underestimate the share of paid contributions to open source. The open source platforms investigated in this research are very well suited to support open source projects started and driven by hobbyists. Professional open source projects on the contrary are able to operate their own project infrastructure and, therefore, are most likely underrepresented in the study sample. Based on this consideration, we may infer that paid contributions to open source have perhaps caught up with voluntary efforts.

In the previous section we were able to show that fun plays an important role in establishing an open source developer’s engagement. With the joy of programming, 27 percent of the readiness of open source developers for future efforts can be explained. If the time a developer spends on open source activities are accounted for (allowing for the total amount of spare time available), the joy of programming accounts for 33 percent of a developer’s engagement. It is notable that fun matters for all kinds of programmers as a motivational tool. Thus, this study proves that it is possible to quantify the importance of a specific kind of motivational tool that leads a software developer to engage in open source activities. It would be interesting if other motivational tools behind open source could be quantified in an analogous manner.

The comparison between the data gathered from the surveys demonstrates that open source developers experience more fun while programming than programmers working under commercial conditions. This result is derived both from developers working in their spare time (hackers) as well as those open source developers paid for their efforts. We conclude that this difference is not caused by a systematic bias in the study design but a consequence of the production conditions that govern the work of developers.

With the results of this study, therefore, we are able to adjust the image of open source as product of unselfish and perhaps somewhat weird hackers. Software developers that want to consume a homo ludens payoff act absolutely rational if they look for software projects and project situations that promise a lot of fun. Our data proves that freely working on open source projects offers greater opportunities to experience fun. Therefore, open source software can be understood, at least partially, as the by–product of activities that generate fun. A development model for open source needs to optimize for fun.

Neither deadlines nor the existence of formal authorities account for the difference concerning the fun experience between open source and commercial software development models. If the joy of programming is tied to project visions and optimal challenge — both factors that can be influenced be employers — wouldn’t it be possible to make software development under commercial conditions as fun as open source projects? To answer this question, we have to discuss the elements characterizing the open source development model: how important are they for the experience of fun and how could they be realized under commercial conditions? Briefly, the advantage of open source is that open source software is produced by an open community of developers with a low entry barrier, where producers are at the same time users of software and where a given programmer’s status in the community is achieved not by formal authority but through meritocracy. Two additional important characteristics are that open source software is released early and often and that the programmers are involved on a voluntary basis.

The openness of a programming community would be difficult to achieve in commercial projects. Under commercial conditions, programmers are paid for their work and, thus, have some kind of contractual relationship to the employer. Therefore, the community of programmers in a firm is not unlimited but restricted to the legal boundaries of the company. However, the nature of the programming community (if it is open or closed) alone does not govern the experience of fun.

The characteristic that developers of open source projects are most times actively using the applications they develop is true for commercial projects probably only on rare exceptions. This fact has implications for “project vision” and, as our study shows, subsequently on the joy of work. For a “prosumer” the project vision results immediately from his requirements. In cases where the user is not equivalent to the producer, there is an increased need for an explicit and understandable project vision.

The absence of a formal hierarchy that characterizes open source projects is not viable for commercial projects. Beyond a doubt, the negative effects of such hierarchies can be mitigated, for example if the company has shallow hierarchies and where these hierarchies are created through transparent processes that are driven by merit (economic) mechanisms. Moreover, as our study shows (see Table 25), the existence of formals authorities seems to have no effect on the ability of employees to experience fun.

Open source projects distinguish themselves by high release frequencies. For a software developer, it is satisfactory to see his contributions quickly integrated into productive applications. On the other hand it is frustrating to find a given contribution dumped by a project leader because of insufficient quality. However, this is a matter of a given project’s quality management and is independent of the specific nature of a project (open source or commercial).

The last feature characterizing open source projects — the voluntary engagement of software developers — is not applicable to commercial projects. However, if engagement in a specific project is voluntary, it’s the programmer who decides which project to be involved in. A crucial factor for his engagement is the challenge he will find in the project. He does not need complete information about the project nor his capabilities. This voluntary involvement allows a programmer to select, by trial and error, a project that fits him the best. This is possible because there’s a kind of marketplace. Open source projects actively seek developers who are willing to contribute, those able to pick a project and to leave it freely at their discretion.

This kind of voluntariness is not viable for commercial projects [17]. However, could it be possible for a firm to establish a kind of internal marketplace to engage programmers on a voluntary basis for specific projects? In such a corporate environment, programmers are required to participate in projects but have a choice of which projects that most suitably fit their skills and experiences. This sort of corporate atmosphere probably could only work only for companies of a certain size where there are an abundance and variety of projects to establish this sort of marketplace. If this marketplace was successful so that all projects were eventually populated by competent and creative programmers, it would be possible then to enhance the experience of programming, that is to generate a higher level of fun on the job.

Again, this analysis boils down to “project vision” and “optimal challenge” as vital factors encouraging joy in software development. Logically commercial projects offer fewer possibilities for developers to contribute their maximum potential in optimal ways. It is also understandable that in the corporate environment project visions are not always apparent. It is both challenging and expensive to formulate understandable project visions and create optimal challenges for developers, but it is not impossible. However given the potential productivity payoffs, in the long term it might be in the best of the firm to find ways to enhance fun in projects comparable to open source conditions.

Hence we can ask a different question. What would it take for an employer to enhance a workplace so that programming became fun? Ultimately, would programmers enjoy their work so much that they would contribute significantly to firm’s financial success?

Based on the knowledge we gathered from this study we would answer in the affirmative. In general it is true that employees that like their work contribute positively to the working climate; they are more motivated on the job and are absent less. Specifically, fun indicates that a given developer’s abilities match tasks optimally; a programmer having fun is at the same time productive. Because fun is a pervasive feature of software development, fun can be leveraged even for software development under commercial conditions. End of article

 

About the authors

Dr. Benno Luthiger works as software engineer and specialist for open source in the IT Services of the ETH Zurich. He studied physics and cultural anthropology. In his PhD research, Benno Luthiger analyzed the motivations of open source contributors. His research interests are social movements and technical innovations.
E–mail: benno [dot] luthiger [at] id [dot] ethz [dot] ch

Dr. Carola Jungwirth is Assistant Professor at the University of Zurich, Chair of Strategic Management and Business Policy. Her research comprises different aspects of governance in OSS communities, leadership without legitimation, and incentives for investments in human capital. She has published various papers in reviewed national and international journals and serves as referee for various national and international journals.
E–mail: carola [dot] jungwirth [at] isu [dot] unizh [dot] ch

 

Notes

1. From Novak and Hoffman, 1997, p. 11.

2. Question 40: “Please estimate the time you spend for the development of open source software (average hours per week)”; Question 41: “Of the total time spent for the development of open source software, how much in percent is part of your spare time?”; and, Question 42: “How much (on average, in percent) of your spare time do you spend on activities concerning open source projects?”

3. Lakhani and Wolf, 2003, p. 10.

4. We calculated spare time as follows: spare time =q40*q41/q42.

5. Lakhani and Wolf, 2003, p. 9.

6. Question 29: “I’m looking forward to further development activities for open source software”; Question 30: “I’m prepared to increase my future commitment in the development of open source software”; and, Question 31: “With one more hour in the day, I would program open source software.”

7. The computed factor can explain 67 percent of the variance of the original items. The value of Cronbach’s α is 0.74.

8. Hertel, et al., 2003, p. 27.

9. Question 2: “I cannot say how long I’ve been with programming”; Question 20: “I am extremely concentrated”; Question 21: “I’m looking forward to my programming work”; Question 22: “I enjoy my work”; Question 24: “Things just seem to fall into place”; Question 26: “I accomplish my work for its own sake”; and, Question 27: “I completely concentrate on my programming work.”

10. Question 13: “My work is solely motivated by the fact that it will pay for me”; Question 15: “I’m very absent–minded”; Question 16: “I don’t have to muse over other things”; and, Question 26: “I accomplish my work for its own sake.”

11. Question 29: “At the beginning of the week, I look forward to the work ahead”; Question 30: “I don’t mind working overtime for my job”; and, Question 31: “I plan my future career in the IT area.”

12. Question 32: “I’m proud to work for the firm”; Question 33: “I can develop personally and professionally working for the firm”; Question 34: “There is a pleasant atmosphere at the firm, and the firm pursues the right objectives”; and, Question 35: “At the firm, the role model and the processes are implemented professionally and with success.”

13. Asendorpf, 1996, p. 137: “Persönlichkeitsmerkmale, die Leistungen ermöglichen.”

14. Additionally, there might be cultural and health reasons that affect a person’s motivation.

15. The following descriptions apply to open source projects that result from voluntary cooperation. They are less true for open source projects with developers that are paid for their project work.

16. Question 33: “I can develop personally and professionally working for the firm”; and, Question 35: “At the firm, the role model and the processes are implemented professionally and with success.”

17. See Barnett, 2004, p. 8f.

 

References

T. Amabile, W. DeJong, and M. Lepper, 1976. “Effects of externally imposed deadlines on subsequent intrinsic motivation,” Journal of Personality and Social Psychology, volume 34, pp. 92–98. http://dx.doi.org/10.1037/0022-3514.34.1.92

J.B. Asendorpf, 1996. Psychologie der Persönlichkeit: Grundlagen. Berlin: Springer.

L. Barnett, 2004. “Applying open source processes in corporate development organizations,” at http://vasoftware.com/sourceforge/request_info-dl.php?paper=9, accessed 7 October 2004.

H. Chen, R.T. Wigand, and M. Nilan, 2000. “Exploring Web users’ optimal flow experiences,” Information Technology & People, volume 13, pp. 263–281. http://dx.doi.org/10.1108/09593840010359473

M. Csikszentmihalyi, 1975. Beyond boredom and anxiety. San Francisco: Jossey–Bass.

T. DeMarco and T. Lister, 1987. Peopleware: Productive projects and teams. New York: Dorset House.

E. Franck and C. Jungwirth, 2003. “Reconciling rent–seekers and donators: The governance structure of open source,” Journal of Management and Governance volume 7, pp. 401–421. http://dx.doi.org/10.1023/A:1026261005092

A. Hars and S. Ou, 2001. “Working for free? — Motivations of participating in open source projects,” Proceedings of the 34th Annual Hawaii International Conference on System Sciences, volume 7, pp. 1–9.

A.F. Hayes and L. Cai, 2004. “Using heteroscedasticity–consistent standard error estimators in OLS regression with applications to moderated multiple regression,” at http://www.jcomm.ohio-state.edu/ahayes/hcse.pdf, accessed 20 January 2005.

G. Hertel, S. Niedner, and S. Herrmann, 2003. “Motivation of software developers in open source projects,” Research Policy, volume 32, pp. 1159–1177. http://dx.doi.org/10.1016/S0048-7333(03)00047-7

K.R. Lakhani and R.G. Wolf,, 2003. “Why hackers do what they do: Understanding motivation effort in free/open source software projects,” at http://opensource.mit.edu/papers/lakhaniwolf.pdf,accessed 6 October 2003.

J. Lerner and J. Tirole, 2002. “Some simple economics of open source,” Journal of Industrial Economics, volume 52, pp. 197–234.

B. Luthiger, 2006. “Spass und Software–Entwicklung: Zur Motivation von Open-Source–Programmierern,” at http://www.dissertationen.unizh.ch/2006/luthigerstoll/diss.pdf, accessed 13 July 2006.

H. Montgomery, P. Sharafi, and L.R. Hedman, 2004. “Engaging in activities involving information technology: Dimensions, modes, and flow,” Human Factors, volume 46, pp. 334–348. http://dx.doi.org/10.1518/hfes.46.2.334.37345

T.P. Novak and D.L. Hoffman, 1997. “Measuring the flow experience among Web users,” at http://www2000.ogsm.vanderbilt.edu/, accessed 10 October 2002.

T.P. Novak, D.L. Hoffman, and Y.–F. Yung, 1998. “Measuring the flow construct in online environments: A structural modeling approach,” at http://www2000.ogsm.vanderbilt.edu/, accessed 10 October 2002.

M. Osterloh, S. Rota, and B. Kuster, 2002. “Open source software production: Climbing on the shoulders of giants,” at http://www.iou.unizh.ch/orga/downloads/publikationen/osterlohrotakuster.pdf, accessed 10 April 2006.

K. Remy, 2002. “Entwicklung eines Fragebogens zum Flow–Erleben,” Fakultät für Psychologie und Sportwissenschaft, Bielefeld: Diplomarbeit.

F. Rheinberg, R. Vollmeyer, and S. Engeser, 2002. “Die Erfassung des Flow-Erlebens,” In: J. Stiensmeier–Pelster and F. Rheinberg (editors). Diagnostik von Motivation und Selbstkonzept. Göttingen: Hogrefe.


Editorial history

Paper received 28 November 2006; accepted 20 December 2006.


Contents Index

Creative Commons
License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 License.

Pervasive fun by Benno Luthiger and Carola Jungwirth
First Monday, volume 12, number 1 (January 2007),
URL: http://firstmonday.org/issues/issue12_1/luthiger/index.html





A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2017. ISSN 1396-0466.