Apache Cocoon Survey 2003 - Alexandria (UniSG) - University of St ...

Apache Cocoon Survey 2003 [DRAFT VERSION v0.1]

Wolfgang Maass University of St. Gallen [email protected] http://www.mcm.unisg.ch/im

2INTRODUCTION....................................................................................................................................3 3ABOUT APACHE COCOON..................................................................................................................3 4METHODOLOGY...................................................................................................................................4 5EVALUATION AND ANALYSIS.............................................................................................................4 5.1PERSONAL PROFILE OF COCOON DEVELOPERS.......................................................................................................... 4 5.1.1Age........................................................................................................................................................... 4 5.1.2Country.....................................................................................................................................................5 5.1.3Since when are you aware of Cocoon?....................................................................................................5 5.1.4Since when are you contributing to the Cocoon community?................................................................. 6 5.1.5Experienced negative effects....................................................................................................................7 5.1.6What kind of contribution do you deliver?.............................................................................................. 8 5.1.7What is your role in the Cocoon community?........................................................................................12 5.1.8Why are you participating in the Apache Cocoon project?...................................................................13 5.1.9What knowledge background do you have?.......................................................................................... 14 5.1.10Which educational background do you have?.....................................................................................14 5.1.11For how many years have you been implementing?............................................................................15 5.1.12Which programming languages are you able to implement?.............................................................. 15 5.1.13For how many years have you implemented on a professional level?................................................ 19 5.1.14Which software development method are you using?..........................................................................20 5.1.15Please indicate the platforms on which you are an expert.................................................................. 22 5.2ORGANISATION...................................................................................................................................................23 5.2.1What level of expertise do you expect from a Cocoon member?........................................................... 24 5.2.2What kind of programming skills do you expect from a Cocoon member?........................................... 25 5.2.3What was the most difficult lesson to learn in the Cocoon community?............................................... 25 5.2.4What was the easiest lesson to learn in the Cocoon Community?.........................................................26 5.2.5What are the biggest obstacles in working with other members?..........................................................26 5.2.6What is your trust level towards other members during requirements elicitation and implementation?.. 27 5.2.7What are the main kinds of contributions you deliver to the Cocoon community................................. 28 5.3WORKING HABITS.............................................................................................................................................. 30 5.3.1How many hours per week do you generally invest in the Cocoon community in general?................. 30 5.3.2How many hours per week do you invest in the Cocoon community as an official part of your job?.. 31 5.3.3How much revenue does your company earn with Cocoon (in percent)?............................................. 31 5.3.4Are you self-employed?..........................................................................................................................32 5.3.5What is the size of your company?.........................................................................................................32 5.3.6What is your vision for Cocoon for the next five years - in any?...........................................................32 5.3.7Please describe the basic principles for collaboration in the Cocoon community?............................. 34 5.3.8With how many Cocoon members do you actively collaborate?........................................................... 38 5.3.9Topics by importance............................................................................................................................. 39 5.3.10Which type of requirements will dominate in the future (2 years) ......................................................42 5.3.11Which services are used for collaboration.......................................................................................... 43 5.3.12What is the process for bug fixing?......................................................................................................47 5.3.13How are new Cocoon issues identified?.............................................................................................. 49 5.3.14How is the Cocoon roadmap identified?............................................................................................. 53 5.3.15How are architectural issues determined?.......................................................................................... 58 5.3.16Where do you see the biggest needs for improvement in Cocoon?..................................................... 65 6COPYRIGHT AND CONTACT INFORMATION...................................................................................71 7REFERENCES......................................................................................................................................72

Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 2

2 Introduction OSS communities have recently attracted attention for their impact they have on the global software market. This change especially enlivened research on the organisation and motivational structure of individuals (e.g., [1], [2], [3], [4], [5]). Open source software (OSS) communities are virtual work groups consisting of members with skills in software development. They work in temporary, culturally diverse, geographically dispersed, electronically communicating work group ([6]). In contrast to commercial software vendors, members can freely join OSS communities and are unrestricted in their contributions. Virtual work groups have been investigated within firm contexts ([7], [8]) but compared to Linux or Apache communities these groups have been rather small. Also software development by virtual work groups is a long-standing topic but if compared to larger OSS communities these studies also mainly focused on rather small projects [9]. In this sense OSS communities provide unique opportunities to study virtual work groups and distributed software development. On one hand communication and collaboration of OSS communities are as transparent as it can be. On the other hand, global distribution of community members and lack of job contracts with firms make it difficult to investigate communities on an individual level. Therefore most empirical studies on OSS communities concentrate on secondary logging information such as provided by mailing lists, IRC chat logs and code repositories. As a prerequisite for an understanding of how OSS communities communicate and collaborate, we need to receive a better understanding of beliefs, goals, attitudes, skill sets, communication and collaboration behavior in OSS communities. Based on a detailed online questionnaire the Apache Cocoon community was analysed for on individual and group level. More than 60% of the developer community (34 valid responses) responded to this questionaire. The Apache Cocoon community is special in the sense that Cocoon delivers business relevant applications instead of mere infrastructural systems, such as Linux and Apache Web Server. Hence, with software such as Cocoon, the OSS movement enters domains which are traditionally governed by multi-national firms. The goal of this survey is to gain deeper understanding of issues on organisation of distributed of work teams, knowledge management, communication, and collaboration. Therefore an online questionnaire was designed in co-operation with Cocoon members. It was communicated at the "Get-Together" in Ghent in October 2003.

3 About Apache Cocoon [http://cocoon.apache.org] Apache Cocoon is a web development framework built around on top of two software development principles: separation of concerns and component-based web development. With strong foundations in XML-based server-side web application frameworks, the Apache Cocoon Project consists of a group of people that share common values. Cocoon implements these concepts around the notion of 'component pipelines'. Each component on the pipeline specialises on a particular operation. This allows to use a Lego™-like approach in building web solutions, connecting components into pipelines. Cocoon is "web glue for your web application development needs". It is a glue that keeps concerns separate and allows parallel evolution of all aspects of a web application, improving development pace and reducing the chance of conflicts. Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 3

4 Methodology Open Source Communities have recently become targets of several research projects. Some are theoretical but most projects extract and analyse empirical data. The distribution of OSS projects is a strength for the community and a hurdle for researchers. In traditional firms researchers can ask employees in a distinct but small number of locations. Normally this research is backed by high-level management so that participants are "doomed" to answer. This is totally different in OSS communities: people are globally distributed and do not have to follow directives. Hence in empirical studies in OSS communities researchers depend on voluntariness of each member of the community. Following the rules of the game in an OSS community, both parties agree to exchange values. With this report we hope to give back a decent value to the community for their participation in this survey. The methodology we follow is mixture of qualitative and quantitative approaches. Qualitative questions give insights on relations of the social, communication and collaboration structure from which quantifiable variables and questions can be derived in a next step. This approach is important for research domains which are rarely understood. The quantitative part addresses those areas for which existing theories and models can be tested. Mulitvariate analysis is used in parts for the evaluation. In general, this study is to be seen as a first step into the area of community-centered software designs which is best represented by OSS communities. Results raise an enormous body of new questions and directions that have to be addressed in the future. These areas encompass social structures, knowledge flows, communication networks, and distributed collaboration forms to name a few. In summary, this study lays a ground for further research which shall verify or falsify these results and will hopefully expand this interesting and growing research area.

5 Evaluation and Analysis 5.1 Personal Profile of Cocoon Developers OSS communities are distributed networks of experts in software engineering. Sometimes it is assumed that OSS developers are young with moderate expertise working on week ends. For this category of people the general public coined the term "hacker" which overrides the traditional meaning [1]. On the contrary this survey unveils that the Cocoon community consists of highly skilled and experienced people.

5.1.1 Age The average age of Cocoon developers is 31.2 with a standard deviation of 6.17 years.


12

10

8

6

4

2

Std. Dev = 6.17 Mean = 31.2 N = 34.00

0 25.0

27.5

30.0

32.5

35.0

37.5

40.0 42.5

45.0

47.5

@1._AGE

All participants of the survey have been male. As it can be seen by the developer mailing list, a few women are active contributors the community.

5.1.2 Country An interesting finding is that a strong group of the community lives in Europe (73.5%) an in particular in German speaking countries. 30

20

Prozent

10

0 es at St om d te i ngd ni U dK d te ni l an U r e i tz Sw a si a us R agu ar nds ic N rl a he et N ly Ita e ec re G any m er G e c an Fr a ad an C m iu lg Be ia r st Au ali a r st Au

America 20.6% Asia 2.9% Australia 2.9%

Europe 73.5%

5.1.3 Since when are you aware of Cocoon? Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 5

Cocoon was officially started in 1998. Some developers indicated that they have been aware of Cocoon in 1995, 1996, and 1997. Either these are mistakes or indications of interests in this general topic of XML-based content publication. In 2000 the community gained momentum and attention. In 2001 and 2002 the community gained constant attention. Caused by rising publicity it will be interesting to see how the awareness changed in 2003. 4. Since when are you aware of Cocoon?

valid

1995

frequency 1

percentage 2.9

Valid percentages 2.9

Accumulated percentages 2.9

1996

1

2.9

2.9

5.9

1997

1

2.9

2.9

8.8

1998

2

5.9

5.9

14.7

1999

4

11.8

11.8

26.5

2000

12

35.3

35.3

61.8

2001

6

17.6

17.6

79.4

2002

7 34

20.6 100.0

20.6 100.0

100.0

total

5.1.4 Since when are you contributing to the Cocoon community? In 2001 Cocoon received the highest supply by new developers. Also here some developers indicate that they already started with contribution to the Cocoon community in 1995 which is either a mistake or means a contribution in general. Figures on awareness and contribution indicate that the developer community stabilised itself during the years 2000 and 2001. 5. Since when are you contributor to the Cocoon Community?

valid

1995

frequency 4

percentage 11.8

valid percentages 11.8

Accumulated percentages 11.8

1996

1

2.9

2.9

14.7

1998

1

2.9

2.9

17.6

1999

3

8.8

8.8

26.5

2000

5

14.7

14.7

41.2

2001

3

8.8

8.8

50.0

2002

8

23.5

23.5

73.5

2003

9 34

26.5 100.0

26.5 100.0

100.0

total

A significant correlation exists between awareness and contribution (.756, p < 0.01). On average it takes one year from awareness to contribution.


2005

4. Since when are you aware of Cocoon?

2004 2003 2002 2001 2000 1999 1998 1997 1996 1995 1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

5. Since when are you contributor to the Cocoon Community?

5.1.5 Experienced negative effects An assumption was that OSS developers work in their spare time for OSS communities. If this hypothesis would be correct there should be negative effects traceable regarding a developers social environment. As the survey data shows, only very few developers perceive negative effects on their social environment. too little time for friends too little time for friends 40 30 20 10 0 No

Yes

too little time for family too little time for family 35 30 25 20 15 10 5 0 No

Yes


Considering the "spare time" hypothesis it is the question when developers work for Cocoon. A hypothesis was that they work late during the night. A first support of this hypothesis could be found by the fact that 17.6% state lack of sleep as a negative effect caused by participation in the Cocoon community. lack of sleep

lack of sleep 30 25 20 15 10 5 0 No

Yes

No negative effects could be shown on the educational development of Cocoon developers. too little time for education too little time f or education 35 30 25 20 15 10 5 0 No

Yes

5.1.6 What kind of contribution do you deliver? A special feature of OSS development communities is that individual developers decides themselves how, when, and what they contribute. In contrast to traditional software engineering projects, OSS communities do not start from resource allocation and milestone plans but from a mutually shared interest and vision of the architecture and general goals of the community. The footprint of productivity is given by its distribution of delivery types, such as patches, modules, problem reports, documentation, and ideas. Members were asked which type of contribution they deliver frequently (3), periodically (2), rarely (1), or never (0). Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 8

Patches Patches are a common way of supplying small updates to pieces of software where the source code is available (definition wikipedia.org). Only 6% report frequent and 20.6% periodic patch contributions which is consistent with the analysis of CVS activities in Cocoon. The majority indicate that they rarely or never contribute patches. 3 5.9% 2 20.6% 0 23.5%

1 50.0%

Modules Modules are larger conceptual and functional parts of an overall system. Almost 12% indicate to contribute complete modules on a periodical basis. 2 11.8% 1 20.6%

0 67.6%

Joint Analysis of Patch and Module Contribution The correlation analysis shows an expected strong positive relationship between patch and module contribution (.501, 500 employees 500 employees)

On average Cocoon developers work in companies with 6 to 20 employees. There is a clear separation between developers who work in smaller companies (up to 20 employees) and a group of developers working for large companies. It is interesting to note that there are no significant correlations between a role taken in the Cocoon community and the size of the company this developer is working for. Self-employed developers run companies with a typical size of 1 to 5 employees (.606, p < 0.01).

5.3.6 What is your vision for Cocoon for the next five years - in any?


16 14

14 12 10

8

8 6 4

3

2

2

3

3

1

ot he rs

E t. S

en c fe r re

in in te gr

at ed

e

SW

pr

oj e

ct

pa ck ag

es

:S

as st ay

om m

fo rd is

AP ,. . .

is it

ux Li n as

er

ci

al is

ed

co m C

es tA pa ch e bi gg

le ad

in g

pu

bl is

hi n

g

fra

m

ew

or

k

m un ity

0

Remarks:  Cocoon will become the leading web application implementation and integration  platform.  Cocoon is big and complex. Many new projects will start that borrow some Cocoon blocks to fit their particular needs. (e.g. XMLForms) And Microsoft will off course announce a new and revolutionary XML publishing framework  I'd like to see Cocoon become a reference for information interaction, not just publishing, but to include exchanges as seen in applications.  A trendsetting pipelining and workflow framework that is widely recognized as being reliable, usable, and responsive to the community.  Cocoon will become a standard (best practice) for application integration and complex presentation management  Cocoon will be another big player (like .NET or J2EE) but will be famous for integration  Cocoon will become a major player in the IT sector (web applications and web publishing) because of its alternative way doing things which means it will keep on evolving to support a broad range of interactive web and xml publication needs.  we'll move from "XML publishing framework" to a "XML web application framework" that will gain much more visibility. From the ASF point as view as well as from leading commercial software vendors.  Cocoon will become a major web application framework; Cocoon take-up amongst large commercial organisations will become astronomical.  Cocoon will become the leading webapp framework In 1998, Cocoon was started with the vision to develop an XML-based publishing framework. This vision was widened to become more generic. Currently the discussion is whether the objectives of Cocoon should be independent of particular technology standards such as XML. On the other hand, Cocoon has been used for several implementations for various types of applications such as content management, financial data processing, shopping systems and collaboration channels. In the community's discussion this leads to the claim that Cocoon shall become "the leading XML web application framework". Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 33

Most developers still stick to the original vision to become the leading XML publishing framework. The shift towards a web application framework is almost consistently supported amongst committers and PMC members. This emerging but already shared view on the future of Cocoon might stem from long-lasting discussions on the committer and PMC level. In general, it is visible that Cocoon stands at the verge of expanding its vision to the next level. Time will tell whether Cocoon entered the level of evolution or whether it lost its core.

5.3.7 Please describe the basic principles for collaboration in the Cocoon community? The analysis shows that development in the Cocoon community differs from methods described by traditional software development models. Traditional models emphasis the generation and translation of different levels of artefacts, such as business requirements, functional and non-functional requirements, class diagrams and coding. In Cocoon knowledge that is gathered and stored by the community is more important than documents in repositories. The hypothesis is that the underlying paradigm of the Cocoon community can be described as the "neural network metaphor": not everything is stored in one node but everything is redundantly stored in all nodes. By following this metaphor, Cocoon members invest in discussion so that a larger group shares a similar language, joint perspectives and shared knowledge on technologies, and mutually agreed visions. This achieves a "community memory" that could be taken as a prototype for the discussion on "corporate memories". A fundamental difference between the concept of corporate memories and communities of practice on one hand and what is found in the Cocoon community on the other can be seen in how designs are developed. The former puts emphasis on deep and tightly coupled collaboration: objectives, designs, implementations, evaluations, and applications are done in groups. The underlying concept is that knowledge flows best if everything is done in immediate collaboration. Cocoon, and probably OSS in general, breaks with this concept. Objectives incl. so-called random thoughts are discussed in detail whereas designs and implementations of patches and modules are done by single people or very small teams. The evaluation and applications is done in the largest possible group. Why this might be the case is discussed after the presentation of results to the question how Cocoon members perceive the difference between traditional and Cocoon software development. Please describe the differences you see with respect to traditional software development organisations as related to the following topics People 

      

Are more relaxed and friendly than in commercial environments. The community tends to share, advise, teach and otherwise impart knowledge to newer members. In commercial developments it seems a lot of this is left to the individual to self-teach or acquire knowledge of his own volition. People come together on a more personal level than co-workers, because most people work on cocoon in their spare time as well as on company paid time. Dispersed very high diversity (much more use cases are part of design decisions) well, you don't get to chose them having no way to influence who gets to do what (else then doing what you do) there seems to be less time spent in 'politics' much more brilliant people working at the same project friendly, open, loyal, respectful, smart yet self-critical, opionated but fast learners People has a common interest. sometimes in organizations people does not share a common interest. Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 34

The quotations indicate that despite the fact of diversity Cocoon members feel themselves as part of a community with synchronised interests, skills, expertise, communicational and knowledge sharing attitudes. This is what can be found in "family structures". Organisation 

        

The thrust of development is largely directed by long standing core developers that value the technical merit of additions/changes to source, as opposed to having deadlines for functionality implementations where stability, correctness and clean implementations are priorities of a lower order. No company (hardly any) can get together so many highly motivated experts. Applies to analysts, developers, project-managers Open source flat hierarchy, everybody can be part - independently from your position, your knowledge and experience (in contrast to traditional development the thoughts of 'newbies' are very important) meritocracy: you get to say as much as you do, it's up to each individual to find his own balance in there also be assured that the structure is highly dynamic and might even be different depending on the topic at hand Everyone can come and leave as he wants/needs to. You don't *have* to work. Mostly equality. Responsibility without a burden. flat and meritocratic Chaotic in comparison to many organisations. Here is meritocracy and knowledge the most important things

The traditional basic relationship between worker and employer is the exchange of work against financial rewards. By building organisational structures around it firms try to support the efficient and effective leverage of these basic relationship. This model does not hold for organisations that are not based on the concept of work contracts, such as non-profit organisations or scientific communities. Apache communities are based around the basic principle of "meritocracy". Similar to the scientific community, Apache and Cocoon members in particular try to receive merits from the community for their expertise and contributions. The indication of "finding his own balance" might lead to an innovative approach for organisations. In dominating economic theories, the decision on the organisational structure is mainly made by the so-called "management". The management concepts assumes that it is more efficient and effective to organise work by people independent of the actual workers. The concept of "self-organisation" as found in biological systems starts from the opposite assumption that the organisation of work should be done be the workers themselves. The management model adopts a discrete model by which changes are done in packages whereas the self-organisation model typically adopts an evolutionary approach. As a working hypothesis it can be assumed that the applicability and performance of both models depends on intrinsic factors of the working community. 1. If the intended products and services that are to be created by the working community are well-structured and clearly defined (e.g., governmental organisations, retail firms, automotive production) the management model is likely to outperform self-organising organisations. 2. If the products and services are rather unknown and undefined the selforganisational model might out-perform the management model.


Both assumption require further in-depth analysis and evaluation. The considerations behind these two hypothesis mainly depend on the underlying knowledge and communication schemata. Traditional management models are applicable if knowledge can be dissected into functional parts, i.e., it can be modularised and associated to experts. This is possible in domains with a well-established corpus of knowledge, such as in some parts of engineering and production. Interfaces between functional experts can be clearly defined and supported by control and communication channels. The self-organising model is applicable if knowledge on a domain has not already settled. This holds for domains with a high degree of innovation and unstable knowledge. Knowledge typically stabilised around designs for products and services. A functional dissection of knowledge into parts and association to organisational units and workers would lead to artificial barriers that would cause inefficiencies. In summary, these two hypotheses can be metaphorically described as two phases of an annealing process. During the early phase of an annealing process (high entropy) dissection would destroy the crystallisation process (self-organisational phase) whereas after the crystallisation (low entropy) dissection can be done with high precision (management phase). Processes 

   

   

Based on the introduction of ideas based on a user need, usually discussed at length in technical terms in Random Thought threads prior to implementation. Code is contributed for others to examine, experiment and suggest/contribute improvements. There are also strong process interactions with other key apache groups (e.g. Avalon), and weaker ones (e.g. Xalan). This is in stark contrast to client engagement and the elicitation of user needs being the typical drivers of development in a traditional s/w dev org. not really that different ad-hoc no pressure by marketing departments I find it often more structured and organized then in most corporate environments. Accountability and tracability of changes is higher, as is the level of (sometimes unspoken) rules that will be checked upon frequently. And most of the processestablishing is actually driven from a developer-need rather then a manager-follow-up need which makes it more logic to use and follow up upon. (more perceived as a selfsupport then a outside-control thing) you don't tell (or be told by) people what to do as much freeform as possible. less structure and processes allow faster and easier operativity. the community exhibits self-organization where only a few and simple constraints are needed Surprisingly rigid set of processes, but as there are less penalties for not following them as in other organisations, they are adhered to in a "flexible" manner. Process are a little slower because we do not have good communication like to be in the near desk. But it works.

The quotations on processes show that processes do not really matter in the Cocoon community. They are seen to be simple, straight-forward, uncontrolled, light-weight, and therefore efficient. Methods


     

Borrows a lot of ideas from Darwinistic evolution and Extreme Programming. Continuous Integration which is present in the Apache infrastructure plays a strong role as well. In client driven work, the methods may sometimes be dictated by the client, directly or indirectly based on the nature of the project. not really that different ad-hoc voting by lazy consensus, don't stop mistakes but correct them when they are catched (places more entropy into the system, but also allows faster evolution) Do-ocracy.

The clear vision, light-weight organisational structure and processes lead to an evolutionary set of flexible methods. Nearest to the methods found in Cocoon is Agile Programming which also tries to leverage "light-weight" methods and tools even though the communities of OSS and Agile Programming rarely overlap in their discussions. Tools 

      

Minimal reliance on tools that are not within the Apache umbrella. The only things you don't get are the VM, debugger and a source (text) editor. Traditional s/w dev houses tend to endorse tools, particularly if they are sponsored - by nature of cash flow options available to businesses as opposed to the community and its' members', utilisation of commercial tools because they can/may improve time to market where possible are utilised. not really that different None in traditional software development one company mostly decides for one set of tools --> OSS development (like Cocoon) mustn't specialize because you can't expect from a potential user to by software licences for thousands of euros discussion and group-decision only on those tools that are really important for the group for the rest each should be able to pick his own set and benefit from it the same tools are used only freely available and open tools are used (ant, jetty, CVS). no IDE or development tools are required. Here the most important tools are internet related tools to communicate each other.

For collaboration and communication the Cocoon community only agreed on the most important tools such as for software repository (CVS) and bug tracking (Bugzilla). Over the years Apache has implemented a broad variety of tools that is widely used in the Apache community. As earlier analysis shows the organisational model can be also discovered on tool level. The community agrees on basic tools for discussion, voting, archiving, and software evaluation but is unrestricted when it comes to design and implementation which is done by individual developers. Hence any developer needs to accommodate himself to the financial restrictions he is facing while collaboration and communication with other members is done on the basis of least cost and light-weight channels and underlying tools. This strategy balances least-costs with largest-performance approaches. The rules that can be derived are: 1. 2. 3. 4. 5.

centralise communication centralise vision, random thoughts, and general decision making decentralise design, and implementation centralise evaluation decentralise application Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 37

others  When you use an open source framework (e.g. Cocoon) for a project as a third party tool, use a released version and don't make it part of your development effort. Introduce the framework "as is", and never tell your client that you are able to "program around" some features in this framework that the client does not like.  fun - room for jokes - regular get-together movements (not only the annual one in Ghent) - gentle open minded discussions that tend to be very synaps-stimulating  exhibits one of the higher orders of email reply cross-correlation of the entire Apache Software Foundation

5.3.8 With how many Cocoon members do you actively collaborate? On average Cocoon members claim to collaborate with 3.1 other Cocoon members with a clear tendency to work with fewer people than with more. Committers (.524, p < 0.01), PMC members (.566, p < 0.01) and Apache Foundation members (.560, p < 0.01) significantly work with more members than regular developers or users (.288). 50.00%

46.43%

45.00% 40.00% 35.00% 30.00% 25.00%

21.43%

20.00% 14.29%

15.00%

10.71%

10.00%

7.14%

5.00% 0.00% 0.00% 0

1

2

3-9

10-19

20-29

Significant correlations exist to developer who contribute modules (.521, p < 0.01), contribute documents (.554, p < 0.01), and contribute ideas (.597, p < 0.01). When correlated with the main contributions this pattern changes: significant correlations exist to discussions (.467, p < 0.01), votes (.509, p < 0.01) and requirements (.393, p < 0.05). The relation becomes negative if correlated to trust to other people (-.456, p < 0.01) which means that the more people a member works with the smaller is his trust into them. The more hours a member spend for Cocoon the more people he interacts with (.377, p < 0.01). The more revenue a member makes with Cocoon the more people he interacts with (.512, p < 0.01).


5.3.9 Topics by importance The question on important topics was designed to get insights into the relation between technical and commercial aspects of Cocoon. Step-by-step Cocoon becomes valuable for commercial applications that are dominated by traditional software vendors. Hence, the following question tried to extract the communities view on the importance of commercially relevant topics, such as sales and commercialisation in general. 14 12 10

Number

bugs 8

new issues sales

6

commercialisation orga of Cocoon Community

4 2 0 1

2

3

4

5

Rating (1: low im portance, ... 5: high im portance)

Bugs After the implementation of a software patch or module, it is tested by the community. Errors are documented by bugs reports that are stored in a bug tracking tool (Bugzilla). Beside source code documents (managed in CVS), bug reports are the only structured documentation of results in the Cocoon community. This is mandatory because without a clear, well-structured and formalised bug tracking and resolution mechanism the whole product design would become chaotic and would fall into pieces. 12

10

8

6

Häufigkeit

4

2

Std. Dev = .80 Mean = 4.4 N = 21.00

0 2.0

3.0

4.0

5.0


Therefore it is not a surprise that the importance of bug reports are rated height (average: 4.4). New Issues 10

8

6

Häufigkeit

4

2 Std. Dev = .91 Mean = 3.7 N = 21.00

0 2.0

3.0

4.0

5.0

New issues are perceived of high importance but less important than bugs (average 3.7). Sales 14

12

10

8

6

Häufigkeit

4

2

Std. Dev = 1.26 Mean = 1.9 N = 21.00

0 1.0

2.0

3.0

4.0

5.0

Sales is viewed as quite diverse in the community. Some tend to see it as quite important while a large group neglects the importance in general. This diverse opinion is distributed over all kinds of roles. Even self-employed members who make large parts of their business with Cocoon do not feel that sales is of importance to the Cocoon community. This indicates a separation of concerns in the sense that sales belong to external activities and is not supposed to be part of the community. Commercialisation


10

8

6

Häufigkeit

4

2 Std. Dev = .85 Mean = 2 N = 21.00

0 1

2

3

4

5

With commercialisation in general are clearer picture can be extracted. All members see the importance of commercialisation even though they do not rate it very high (average: 2.0). This might have been different a few years ago when commercialisation has not been an issue at all. It can be assumed that commercialisation will receive more attention in the future when large software vendors move into the market of XML publishing or try to take over Cocoon in general or some of its modules. Organisation of the Cocoon community 10

8

6

Häufigkeit

4

2 Std. Dev = .96 Mean = 3.9 N = 21.00

0 2.0

3.0

4.0

5.0

In contrast to commercialisation issues, organisational issues receives major attention (average 3.9). From the data gathered by the questionnaire it is impossible to say which specific organisational issues are meant. It requires further analysis what kind of topics are an issue for the Cocoon organisation. Where do requirements currently come from? In traditional software engineering, requirements are perceived as an important intermediate language between ideas and wishes on user side and software code on the other. Several proposals for representational languages have been proposed. For the object-oriented paradigm UML languages are the state of the art. A keys issue is where requirements come from. In traditional projects requirements are discussed and determined in cooperation with the customer. Dominating software vendors collect main affordances by discussions with their key customers. Resulting solutions try to consider as many key issues as possible. In contrast to these traditional approaches, OSS


communities provide a third and also extreme option. Requirements are discussed by future users but are also implemented by those.9 10

8 Commercial Reqs

Number

6

Personal Reqs 4

Polynomisch (Personal Reqs) Polynomisch (Commercial Reqs)

2

0 1

2

3

4

5

-2 Rating (1: low importance, ... 5: high importance)

The community tends to perceive commercial requirements (average: 3.55) as more central than personal requirements (average 3.14). There is no direct correlation between the perception of the origin of requirements and commercial exploitation of Cocoon which indicates a support for the assumption that Cocoon members perceive Cocoon as a means for the implementation of business applications.

5.3.10Which type of requirements will dominate in the future (2 years)

9

In order to understand this revolution a translation to the automotive industry might be given. Imagine that you discuss with friends how your favourite car would look like and then one friend builds the engine, the other the interior and you build the chassis. Assembled is everything on Friday at the end of the year. Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 42

12

10

8

Requirements from commercial projects

6

Requirements from personal needs

4

Polynomisch (Requirements from commercial projects)

2

Polynomisch (Requirements from personal needs)

0 low

2

3

4

high

-2

The perspective on future sources for requirements are consistent with current perceptions even though that it becomes more fuzzy on the individual level. Overall commercial requirements seem to dominate (average: 4.05) over personal requirements (average: 3.10). Comment: "We are aware of the fact that the higher the visibility will be the more commercial entities will try to influence Cocoon into their direction (the blocks concept will hopefully solve this problem, though)"

5.3.11Which services are used for collaboration Collaboration in distributed work teams depends on communication channels which are wellknown and accepted by all participants. In the case of OSS communities these channels are also required to pose little financial resource needs. 25

20

chat e-mail blogger

15

Mailing-lists w iki Bboards

10

instant messaging w eb site other

5

0 not important

2

3

4

very important


Delta (positive valuation - negative valuation) 100.00% 80.00% 60.00% 40.00% 20.00% 0.00% st in t an m

te

ds

r oa

at

Bb

ch

r ge

si

l ai

eb

iki

m

og bl

w

w

e-

ts

s es

lis

gli n ai

-40.00%

M

-20.00%

ag g in

-60.00% -80.00% -100.00%

The difference between a positive valuation (4 and 5) and a negative valuation (1 and 2) of a collaboration services indicates which the impact of a service. This shows that mailing lists, e-mail, wiki and web sites are important services for collaboration whereas web logs and chat are considered as less and bulletin boards and instant messages as unimportant services. chat 16

14

12

10

8

6

Häufigkeit

4 Std. Dev = 1.20

2

Mean = 1.8 N = 23.00

0 1.0

2.0

3.0

4.0

5.0

Chat (IRC) is a communication service which can be used for synchronous or asynchronous communication. Typically an IRC chat is opened just for being connected with parts of the community. The history of IRC chats are rarely stored so that only people who participated in a session will receive the information. It is an attempt by leading people in the community to supersede chat by more transparent communication channels such as mailing lists or Wikis. Chat is rarely appreciated in the community. Members who use chat also use bulletin boards (.476, < 0.05) and instant messaging (.850, < 0.01). e-mail Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 44

30

20

Häufigkeit

10

Std. Dev = .71 Mean = 5 N = 24.00

0 1

2

3

4

5

E-Mail used for point-to-point communication is a dominant communication channel. Not surprisingly, members who prefer e-mail also prefer to work with mailing lists (.487, < 0.05). web logs 12

10

8

6

Häufigkeit

4

2

Std. Dev = 1.11 Mean = 2.3 N = 23.00

0 1.0

2.0

3.0

4.0

5.0

A web log is an rather old way for communication if you consider T. Berners-Lee first web site as a kind of web log. In general, a web log is used for easy publication of personal information similar to a diary. By cross-referencing web logs a network of friendly web logs is established. These links are directed and therefore indicate social relationships and are more and more used as an indicator of reputation. The popularity of web logs is rising in the community of younger Cocoon members. Cocoon users tend to neglect web logs for communication (-.510, < 0.05) whereas committer and PMC members tend to support the usage of web logs. A strong correlation exists between web log users and Wiki users (.551, < 0.01) and a weaker correlation with instant messaging users (.451, < 0.05). This might indicate that this group of members tend to use more personalised, self-branded and direct communication. Further research is required. mailing lists


30

20

Häufigkeit

10

Std. Dev = .28 Mean = 5 N = 24.00

0 2

3

5

Mailing lists are the dominant communication and collaboration channel in OSS communities. Here we have the rare case of unanimous positive perception. Despite obvious deficits mailing lists provide important structures for distributed collaboration on digital media. It is rarely clear why mailing lists have conquered such a dominant position. wiki 12

10

8

6

Häufigkeit

4

2

Std. Dev = .81 Mean = 4 N = 23.00

0 1

2

3

4

5

The first Wiki was started on May 1st in 1995. The idea of a Wiki rests on the Hypercard concepts. Wikis also become quite popular within the Cocoon community (average 4.0). Wiki usage correlates with the communication channels provided by web logs (.551, < 0.01), mailing lists (.491, < 0.05) and web sites (.439, < 0.01). bulletin boards 16

14

12

10

8

6

Häufigkeit

4 Std. Dev = .67

2

Mean = 1 N = 23.00

0 1

2

2

3

3


Bulletin boards are rarely used by Cocoon members. Members who joined Cocoon early positively correlate with usage of bulletin boards (.437, < 0.05). As already mentioned, bulletin boards usage correlates with chat (.476, < 0.05) and instant messaging (.490, < 0.05). instant messaging 14

12

10

8

6

Häufigkeit

4

2

Std. Dev = 1.10 Mean = 1.7 N = 23.00

0 1.0

2.0

3.0

4.0

5.0

Instant messaging has in general a rather low acceptance in the Cocoon community (average 1.7). Committers (.425, < 0.05) and PMC members (.425, < 0.05) tend to use instant messaging more frequently than others. Instant messaging can be seen as a more convenient successor of IRC chats. Hence, usage of IRC chat and instant messaging strongly correlate (.850, < 0.01). As already mentioned, instant messaging correlates with web logs (.451, < 0.05) and bulletin boards (.490, < 0.05). web site 10

8

6

Häufigkeit

4

2 Std. Dev = 1.20 Mean = 3.4 N = 23.00

0 1.0

2.0

3.0

4.0

5.0

A regular web site is not specifically supported by a sub group inside the Cocoon community. Nevertheless it receives a fairly high value for collaboration support. The Cocoon web site provides more general and persistent information but rarely supports collaboration in the narrow sense. The only significant relation exists to Wikis (.439, < 0.05). This might support the hypothesis that the Wiki communication and collaboration model might merge with the web site domain because work groups demand for interactive, document-centred communication services.

5.3.12What is the process for bug fixing? Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 47

How the bug fixing process is implemented in the Cocoon community was asked for by an open question. In the following, all responses are reported: 1. Response: o Submission of bug report, o possible advice posted by others on solving problem, o uploading of patches/fixes, o corresponding review of patches and o eventual application of patches into the CVS source. 2. Response: o The person that wants to fix it, assigns it to himself in bugzilla and o fixes it or patches are mailed in by non committers. 3. Response: o Discuss in dev mailing list o Bugzilla 4. Response: o reacting to a problem report by taking active steps towards a resolution by discussing, o thinking, o coding, o testing. 5. Response: o Find bug, o fix bug 6. Response: o somebody discovers a bug (automatic test or person); o bug is added to bugzilla; o somebody tries to patch it (in the future virtual hackatons will take place) 7. Response: o pick it up from bugzilla and o do as you please 8. Response: o ask for details; o try to reproduce it.; o maybe discuss it; o try to fix it. 9. Response: o bugs are reported on bugzilla, o then fixed by whomever volunteers. o in case of external patch, a committer volunteers to review it and commit it 10. Response: o Update from CVS, o reproduce bug, o check 11. Response: o no fixes exist, o develop fix, o test against current CVS, o commit From these responses a general pattern can be derived. So the generic procedure seems to be as follows: 1. Somebody discovers a bug (automatic test or person); 2. Submission of bug report, 3. Try to reproduce it. Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 48

4. 5. 6. 7. 8. 9. 12. 13.

Possible advice posted by others on solving problem The person that wants to fix it, assigns it to himself in bugzilla Fixes or patches are mailed in by non-committers Uploading of patches/fixes, Corresponding review of patches Eventual application of patches into the CVS source. Test against current CVS Commit

5.3.13How are new Cocoon issues identified? Issues are important topics which are assumed to be influential for the Cocoon community and software. [1: low … 5: high] Average 5

4

3

2

1

0 discussion on developers mailing list

developer needs

user needs

discussion on users mailing list

Customer needs

discussion PMC needs on PMC level

customer needs


Customer needs 10

8

6

Frequency

4

2

0 1

2

3

4

5

Customer needs are perceived as being important but not really influential for the identification of new Cocoon issues (average: 3.10). user needs

by user needs 10

8

6

Frequency

4

2

0 2

3

4

5

User needs have strong impacts on issues for Cocoon (average: 3.50). developer needs


by developers needs 8

6

4

Frequency

2

0 1

2

3

4

5

Developer needs are considered more influential on issues than user needs. (average: 3.75). PMC needs

by PMC needs 8

6

4

Frequency

2

0 1

2

3

4

5

This data shows little influence of PMC members on new issues. (average: 2.42). Discussion on developers mailing list Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 51

by discussion on developers mailing list 12

10

8

6

Frequency

4

2

0 1

2

3

4

5

Discussions in developers mailing lists are the most influential forum for new issues (3.85). Discussion on user mailing list

by discussion on users mailing list 10

8

6

Frequencey

4

2

0 1

2

3

4

5

Discussion in the user list are of interest. Members who are developers perceive discussions in the user and developer list as important which is indicated by a strong correlation between both lists (.607, < 0.01, average: 3.35). It can be assumed that a section of new issues are Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 52

derived from or tested in the user mailing list before they are discussed in detail on the developers mailing list. Discussion of PMCs

by discussion of PMCs 8

6

4

Frequency

2

0 1

2

3

4

5

Needs of PMC members correlate with the assumption that new issues are derived from discussion on PMC level (.979, < 0.01, average 2.58). Because both variables are rated low it can be concluded that the influence of PMC members on new issues is rather small compared to discussions on developers and users mailing lists. This indicates that the role of a PMC member is not considered as a management function on system decisions but more on other issues such as on the overall needs of the community.

5.3.14How is the Cocoon roadmap identified? A roadmap is a temporal projection of future work in an organisation. Therefore a roadmap gives a framework towards issues and requirements are adjusted or vice versa. A roadmap shall give certain level of stability. The assumption was that similar to the determination process for issues, the Cocoon roadmap is dominated by discussions on PMC level.


Average 5

4

3

2

1

0 discussion on developers mailing list

dedicated persons

by a single person

Apache members

discussion on PMC level

discussion on users mailing list

there is no roadmap

discussion on user mailing list

by discussion on users mailing list 6

5

4

3

Frequency

2

1

0 1

2

3

4

5

The user mailing list is perceived to be of medium influence on the determination of Cocoon's roadmap (average: 2.53). discussion on developer mailing list


by discussion on developer mailing list 16 14 12 10 8 6

Frequency

4 2 0 1

4

5

In contrast to the user mailing list, the developer mailing list seems to be highly important for the determination of the roadmap (average: 4.26). This indicates that the strategy of Cocoon is mainly driven by developer needs. discussion on PMC level

by discussion on PMC level 8

6

4

Frequency

2

0 1

2

3

4

5

The longer a member contributes to the Cocoon community the more he is convinced that the roadmap is determined on PMC level (.548, < 0.05). A heterogeneous group of members Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 55

believe that the roadmap is derived on PMC level. In general, the role of the PMC does not seem to be clear to the community for the determination of the overall roadmap (average: 2.65). dedicated persons

by dedicated persons 10

8

6

Frequency

4

2

0 1

2

4

5

The only significant correlation exists with lurkers (average: 3.72). They see dedicated persons as key for the determination of the Cocoon roadmap (.521, < 0.05). The others are rather undecided. In general, the community perceives certain identifiable members as being key for the roadmap. Apache members


by Apache members 7

6

5

4

3

Frequency

2

1 0 1

2

3

4

5

Members who mainly contribute votes (-.563, < 0.05), problem reports (-.562, < 0.05) and requirements (-.525, < 0.05) tend to believe that the roadmap is not determined by Apache members. In general, the community perceives Apache members as being of medium influence on strategic issues such as the roadmap (average: 2.72). by a single person

by a single person 10

8

6

Frequency

4

2

0 1

3

4

5


Patch contributions correlate with results on whether a single person is influential for the roadmap (-.510, < 0.05). Furthermore, the more members trust in other Cocoon members the more they believe that a single person is important for the determination of the roadmap (.509, < 0.05). there is no roadmap

there is no roadmap 12

10

8

6

Frequency

4

2

0 1

2

3

4

5

Members who mainly deliver patches (-.585, < 0.05), modules (-.526, < 0.05) or problem reports (-.520, < 0.05) tend to deny that no roadmap exists. Overall the community is quite confident that a specific roadmap exists (average: 2.0). -

the Get-Together in Gent helped a lot to identify the road map for the next 12 months there are as many roadmaps as there are developers active the actual one is put down by the effort put in

5.3.15How are architectural issues determined? The architecture of a software system is comparable to the architecture of a building. It determines important logical and functional entities and their interrelations.


Average 5 4 3 2 1 0 discussion on developers mailing list

dedicated persons

by a single person

Apache members

discussion on PMC level

discussion there is no on users architecture mailing list

discussion on user mailing list

discussion on users mailing list 6

5

4

3

Frequency

2

1

0 1

2

3

5

Members who believe that requirements are derived from business needs significantly assume that architectural issues determined by discussion on the user mailing list (.692, < . 001). But they also believe that the architecture is determined by a single person (.545, < 0.05). discussion on developer mailing list


by discussion on developer mailing list 14

12

10

8

6

Frequency

4

2 0 1

4

5

Members who believe that the architecture is derived from discussion on the developer list believe that issues are derived from developers needs (.647, < 0.01) on the developer list (.877, < 0.01) and determine the roadmap on the developer list (.988, < 0.01). This indicates a tightly coupled group of developers which is independent from the PMC level because they deny that requirements are derived by PMC needs (-.662, < 0.01) or by discussion on PMC level (-.612, < 0.05). Furthermore they believe that the roadmap is neither derived from discussion on PMC level (-.680, < 0.05), by Apache members (-.406) nor by a single person (-.594, < 0.05). discussion on PMC level


by discussion on PMC level 6

5

4

3

Frequency

2

1

0 1

2

3

4

5

The group of members who believe that architectural issues are derived from discussions on PMC level correlate with members who do not believe that issues are derived form developer needs (-.542, < 0.05) or from discussion on the developer list (-.583, < 0.05). In contrary they believe that issues are identified by PMC needs (.888, < 0.01) and by discussion on PMC level (.831, < 0.01). They also see that the roadmap is significantly determined by discussion on the user mailing list (.682, < 0.01), on PMC level (.709, < 0.01), by Apache members (.821, < 0.01) and by a single person (.579, < 0.05) but not from the developer list (-.554, < 0.05). These results indicate a dissection between developers and developers with PMC status. These two groups indicate features of social cliques that require further investigation. by dedicated persons


by dedicated persons 10

8

6

Frequency

4

2

0 1

2

3

4

5

People who are lurkers tend to believe that the architecture is determined by a dedicated person (.456, < 0.05). Members who have more trust in other Cocoon members tend to assume that the architecture is the ownership of dedicated persons (.464, < 0.05). Those who believe that the architecture is determined by dedicated persons also believe that the roadmap is determined by dedicated persons (.909, < 0.01), Apache members (.544, < 0.05) or a single person (.599, < 0.05). Overall a large percentage of members believe that the architecture is determined by dedicated persons (average: 4.0). by Apache members


by Apache members 6

5

4

3

Frequency

2

1

0 1

2

3

4

5

Members who believe that Apache members are mainly responsible for the architecture correlate with those who believe that requirements are derived from PMC needs (.669, < 0.05) and by discussion on PMC level (.638, < 0.05). They also correlate with members who see Apache members (.985, < 0.01) and single persons (.656, < 0.01) as responsible for the roadmap In general the community is rather neutral towards the question whether the architecture is determined by members of the Apache Foundation (average: 2.71). by a single person


by a single person 8

6

4

Frequency

2

0 1

2

3

4

5

Members who believe that the architecture is determined by a single person tend to deny that issues are derived from developer needs or by discussion (-.557) on developer level (-.547, < 0.05). Additionally this bias correlates with those who believe that the roadmap is determined by dedicated persons (.692, < 0.01), Apache members (.528, < 0.05), by a single person (.787, < 0.01) or even believe that there is no roadmap (.616, < 0.01). They negatively correlate with the assumption that the roadmap is determined by discussion on the developer mailing list (-.469, < 0.05). In general, the community is dissected into a group that rather denies and a group that supports the influence of a single person on architectural issues (average: 3.17). There is no architecture


there is no architecture 10

8

6

Frequency

4

2

0 1

2

3

5

A strong negative correlation exists to members who believe that issues (-.842, < 0.01) and the roadmap (-.905, < 0.01) is determined by developer needs. They positively correlate with those who believe that the roadmap is determined by discussion on PMC level (.709, < 0.01) or by a single person (.797, < 0.01).

5.3.16Where do you see the biggest needs for improvement in Cocoon?


Frequency

1

2

3

4

ica

lp

fd

se

el o

pe rs

ls

ct s m od e

ro du

ev

rs

cu ri t y

fu

se

ro

s

ns

uc t

tio

pr od

ne ss

ro

bu si

cia

er

m

m

nu m be

co

ce

be

ur

nu m

so

m un

om

/c

en

g

op

ith

ith

ke t in

w

w

at io n

in te gr

at io n

in te gr

ar

m

Average

5

4

3

2

1

0

number of developers

Number of developers

8

6

4

2

0

5


In general Apache members10 correlate with the opinion that the smallest need relates to the number of developers (-.496, < 0.05) whereas developers show no significant correlation. This indicates that the community tends to perceive the size of developers as rather optimal. Members who trust in other members perceive a need in more developers (.492, < 0.05). Replies correlate with number of users (.683, < 0.01), security (.578, < 0,01), and business models (.773, < 0.01). number of users

number of users 7

6

5

4

3

Frequency

2

1 0 1

2

3

4

5

Apache Foundation members tend to deny that more users are an important need (-.580, < 0.05). Members who see the roadmap and architecture determined by dedicated persons (.592, < 0.05) perceive the numbers of users as the biggest need for improvement. In general, an increasing number of users does not seem to be critical for the success of Cocoon (average: 3.11). security

10

A particular correlation exists with those who see Apache members as influential for the roadmap (.876, < 0.01) or the technical architecture (.831, < 0.01). Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 67

Security 10

8

6

Frequency

4

2

0 1

2

3

4

5

Also security is seen as a topic of medium importance (average: 3.11). The importance of security negatively correlates with committers (-.483, < 0.05) and PMC members (-.483, < 0.05). The issue of security is positively correlated with members trust in other members (.581, < 0.05). Integration with commercial products

integration with commercial products 6

5

4

3

Frequency

2

1

0 1

2

3

4

5


It is a more generic belief of developers and PMC and Apache members in particular that the integration into commercial products is an important issue for the future. Overall the integration of Cocoon with commercial products gains less attention (average: 2.79). Integration with commercial products and open source products correlate (.760, < 0.01) which indicates that integration is a general important topic for Cocoon. Integration with open source products

integration with open source products 8

6

4

Frequency

2

0 1

2

3

4

5

Younger members tend to see more importance for the integration with other Open Source products (.530, < 0.05). The same correlation exists with members who expect high expertise of other members (.499, < 0.05) and have more trust in them (.625, < 0.01). In general the community associates fairly high attention with the integration with other Open Source systems (average: 3.16). marketing / communications


marketing/communications 6

5

4

3

Frequency

2

1

0 2

3

4

5

Marketing and communications is perceived as the biggest need for improvement in the Cocoon community (average: 3.33). The variable on marketing and communication does not correlate with roles, roadmap issues or architectural issues but negatively correlates with those who work in Cocoon for public utility (-.577, < 0.05). business models

Business models 6

5

4

3

Frequency

2

1

0 1

2

3

4

The issue of business models is rated low by those who contribute problem reports (-.526, < 0.05) and Apache Foundation members (-.556, < 0.05). Developers and in particular PMC Apache Cocoon Survey 2003, Wolfgang Maass, University of St. Gallen, v0.1, page 70

members are neutral towards this issue. In general, the community rates this issue low (average 2.65). Comments by members: - internationalization - documentation - Stop developing, write documentation - performance - modularity, documentation and test cases

6 Copyright and contact information This work is licensed under the Creative Commons Attribution-NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Contact: Dr. Wolfgang Maass University of St. Gallen [email protected] http://www.unisg.ch/im


7 References [1] S. Koch and G. Schneider, "Effort, co-opertaion and co-ordination in an open source software project: GNOME," Information Systems Journal, vol. 12, pp. 27-42, 2002. [2] G. Hertel, S. Niedner, and S. Herrmann, "Motivation of software developers in open source projects: An internet-based survey of contributors to the Linux kernel," Research Policy, vol. 32, pp. 1159-1177, 2003. [3] G. von Krogh, S. Spaeth, and K. R. Lakhani, "Community, joining, and specialization in open source software innovation: a case study," Research Policy, vol. 32, pp. 1217-1241, 2003. [4] L. Y. Moon and L. S. Sproull, "Essence of Distributed Work: The Case of the Linux Kernel," First Monday, vol. 5, 2000. [5] E. von Hippel, "Innovation by user communities: learning from open-source software," Sloan Management Review, vol. 42, pp. 82-86, 2001. [6] A. L. Kristof, H. P. Brown, and K. Sims Jr., "The virtual team: A acse study and inductive model," in Advances in Interdisciplinary Studies of Work Teams: Knowledge Work in Teams, vol. 2, M. M. Beyerlein, D. A. Johnson, and S. T. Beyerlein, Eds. Greenwich, CT: JAI Press, 1995, pp. 229-253. [7] M. K. Ahuja, D. F. Galleta, and K. M. Carley, "Individual Centrality and Performance in Virtual R&D Groups: An Empirical Study," Management Science, vol. 49, pp. 21-38, 2003. [8] T. L. Griffith, J. E. Sawyer, and M. A. Neale, "Virtualness and Knowledge in Teams: Managing the Love Triangle of Organizations, Individuals, and Information Technology," MIS Quarterly, vol. 27, pp. 265-287, 2003. [9] D. B. Walz, J. J. Elam, and B. Curtis, "Inside a software design team: knowledge acquisition, sharing, and integration," Communications of the ACM, vol. 36, pp. 62-77, 1993.
