June 4, 2005

The final paper...

Abstract: This paper explores the nature of open source software development communities. It is suggested that these constitute environments for knowledge development and examines recent proposals that methods employed by open source communities are transferable to a wide range of collaborative activities, including education, which is the primary focus of this paper. The methodologies used are a review of recent literature and a case study of an open source software developer. The analysis of the evidence gathered uses a framework for developing collaborative groups developed by Garmston & Wellman. The results reveal that open source collaborations display all of the characteristics of the framework used, but that there are significant additional factors that need to be considered. In conclusion recommendations are made for future research to better understand the complex and diverse open source movement.

Open Source as a model for collaborative knowledge development: A case study
Tryggvi Thayer and Patrick Walsh

Abstract

This paper explores the nature of open source software development communities. It is suggested that these constitute environments for knowledge development and examines recent proposals that methods employed by open source communities are transferable to a wide range of collaborative activities, including education, which is the primary focus of this paper. The methodologies used are a review of recent literature and a case study of an open source software developer. The analysis of the evidence gathered uses a framework for developing collaborative groups developed by Garmston & Wellman. The results reveal that open source collaborations display all of the characteristics of the framework used, but that there are significant additional factors that need to be considered. In conclusion recommendations are made for future research to better understand the complex and diverse open source movement.

Résumé

Dans ce mémoire, nous explorons la nature des communautés qui contribuent au développement des logiciels libres ; il s'agit d'un milieu au sein duquel a lieu le développement des connaissances à la lumière d'idées récentes, selon lesquelles les méthodes employées par ces commautés d'usage de logiciels libres, pourraient être transférées à un domaine vaste d'activités basées sur la colloboration, y comprise l'éducation. Dans ce contexte, l'éducation fait l'objet principal de notre étude. Les méthodologies utilisées consistent en une lecture critique d'ouvrages récemment publiés ainsi qu'une étude d'un cas d'un individu qui a développé des logiciels libres. Lors de notre analyse des données recueillies, nous nous servons d'un cadre de développement de groupes de colloboration, créé par Garmston & Wellman. Les résultats révèlent que la colloboration dans le domaine des logiciels libres  est conforme à toutes les composantes du cadre de développement mais qu'il y a des facteurs supplémentaires significatifs que l'on doit prendre en compte, et par conséquent une recherche avancée est nécessaire pour mieux comprendre la complexité et la diversité du mouvement des logiciels libres.

Introduction

Although not a new phenomenon, the open source movement has been generating interest far beyond its roots in software development. It is being recognized as a viable methodology for innovation and collaboration in fields such as biology, pharmacology and last but not least, education. The purpose of this paper is to compare the educators’ anticipations of open source methodologies to the actual nature of open source communities and the way they function. The authors draw recent literature pertaining both to open source software development and the identification of transferable characteristics of open source. We present a case study of an individual software developer who is the original author and coordinator of a software project released as open source. The analysis of the case study data employs a framework for developing collaborative groups since this would appear to be the primary interest for educators in open source communities. Finally, some conclusions are drawn concerning the transferability of open source methodologies.

Background: The Spread of ‘Open Source’

“Open source” (OS) traditionally refers to an open collaboration model for developing computer software. Although there are several variations on the guiding principles, the essentials are that a software development project is open to anyone who wishes to contribute and that the resulting source code, i.e. the human readable blueprint of the software, is freely distributed and may be modified by anyone wishing to do so. This differs greatly from the closed proprietary model that treats its source code as closely guarded intellectual property to be revealed to no one outside the organization. To describe these differences, Raymond (2000a) has defined what he calls the “cathedral” and “bazaar” models of software development. The former describes the software development model used by most large software companies, while the latter describes the OS model. Raymond argues that the “bazaar” model will produce superior software since the level of transparency and broad collaboration allows for quicker detection and resolution of coding errors.

Beyond the issues of openness and collaboration, there are many different ‘versions’ and understandings of OS software and its development. The differences are most obvious in the variety of licensing models used by the software developers. While some licenses require that the licensed source and any software derived from it be made freely available and may not be sold, others require that the source code be made freely available, but place no constraint on what can be done with products derived from the code, i.e. it may be modified or packaged and sold, as long as the source code is also distributed. Furthermore, the collaborative methods used can differ greatly. In some instances there are no constraints placed on who contributes and how, and moderation of the process is left entirely to the community as a whole. In other instances, projects are managed by a self-organizing or self-appointed hierarchy that has the final say about what new contributions are included in the source code and what is not. In fact, the variety of methods found in the OS community has prompted Raymond to suggest that OS is a complicated cultural phenomenon which is difficult to generalize and that OS projects may in fact be sui generis dictated entirely by a project’s group dynamic (Raymond, 2000b). Nevertheless, it has become clear in the period since the mid 80s when the OS movement emerged, that this type of open community is able to produce exceptionally high quality software that rivals proprietary software, and in so doing, to expand the knowledge of software development communities in an open and collaborative manner. It is this knowledge development aspect of the “bazaar” model of collaboration that has attracted practitioners in other fields to the OS movement and to explore what, if anything, of the methodology is transferable to other knowledge domains.

On the surface, the OS model would seem to lend itself to educational settings. Taylor and Riley (2005) suggest that the OS model coupled with Open Systems ideology, i.e. ensuring standards and interoperability, can be used to identify suitable pedagogical methods that apply not only to school-based educational settings, but also academic publishing. The primary aspects of these ideologies that their pedagogical model draws on are related to the collaborative and “massive peer review” processes involved. Scharff on the other hand suggests that the artifact produced plays a more central role when he states, “The creation and refinement of a software system is the central activity in an open source project.” (Scharff, 2002, pg. 20).

It has been claimed that “…there's a big difference between open-source software development and open-source collaboration.” (OhMyNews, 2005). It would indeed seem that the approaches adopted by Taylor and Riley on the one hand, and Scharff on the other, address these two different OS models. While Scharff’s focus on the source code as an essential artifact central to the notion of OS emphasizes outcome, in line with the open source software model, Taylor and Riley emphasize process, in line with the open source collaboration model. But, the value in Scharff’s contribution is in that he sees the OS development process as not only contributing to the construction and development of an artifact, but simultaneously as a knowledge development activity.

An OS software developer

Education and professional history. P first acquired a B.A. in anthropology and history in 1993. Prior to and during his studies he worked at a public library as a typist and library page. Through this work he became familiar with library databases that he used to conduct bibliographical searches for patrons. He also served on the Operations Committee of the library. A few years after completing his college degree he was went to work at a government office where he received training in computer administration and consequently worked as a computer systems administrator. He later returned to college to pursue a B.S. degree in computer sciences. While studying he worked for a couple of colleges on web and software development and systems administration. Finally, after completing his degree in computer sciences he accepted a position with a university library, where he is currently employed as a web applications programmer.

From proprietary environments to open source. P first encountered OS software while studying towards his degree in computer sciences. OS software was used extensively in the program as a learning tool since access to the source code provided students with the opportunity to examine and study what developers were doing and how. Despite these first encounters, at the time P used mostly proprietary tools in his professional work. In the first years of his professional career he developed expertise in the use of Microsoft software development tools specifically for developing software solutions for Microsoft’s platforms. During this period he often had to deal with the difficulties of using closed non-customizable tools, but had little choice but to continue using these tools due to the investments that his employer had made in Microsoft platforms.

When P went to work for the university library, he continued to work with proprietary systems. The difference between his new work and his previous work was that much of the software development was outsourced. This posed new difficulties. The company that was responsible for the library’s software development placed little priority on the library’s projects because they were small in relation to other clients’ projects. Since the work was done using proprietary tools and was not open to the library staff, as is the norm with companies that use proprietary development tools and environments, the library staff was entirely dependent on the software development company for any changes or additions to their software. Furthermore, the software developed for the library had to conform to the proprietary standards of the company whose software development tools the library’s contractor used. This meant that the library was not always able to get software that conformed to their needs.

At this point P suggested that the library look into using OS software to develop it’s own software in-house. The project was accepted and a committee was established that included software developers, among them P, and library scientists to oversee the project. The primary goals of the project were to:

•     Cut development and software licensing costs,

•     speed up the development process,

•     gain professional ownership of the software used in the library.

Following the launch of this project, P made a conscious decision in his professional career to move from developing software for proprietary environments to OS. He considers this to have been a risky move since OS, being open and free, offers limited job security. He felt that his career in the university offered more flexibility in this regard and more security than many other information technology careers and was therefore a risk worth taking. He was nonetheless forced to consider how this would affect his future and what aspects of the OS model he would need to focus on to ensure a reliable future. For P this is the ownership issue. He sees his involvement in this specific OS project not only as benefiting library professionals, in that they gain ownership of the computer based tools that they use, but that he also gains ownership of a complex and meaningful project. And this is something that he can personally point to and claim as his own for his own personal fulfillment and to promote his strengths in any future career moves.

Open sourcing a library information tool. The software project is described in the Project Charter,

“The goals of this project are 1) to create a database (tentatively called LibData that can drive the core portions of our web site, namely those portions that list the resources and services we offer, and 2) create an authoring suite for customized presentations of library resources.” ( http://staff.lib.umn.edu/libdata/ )

The project was launched in the summer of 2002. In November of 2003, the software was released as OS under the GPL license as version 1.01. In March of 2004 a significantly revised version of the software was released as version number 2.0. As of the last update in March, 2005, the version number of the current release is 2.20. The software is currently being used in 8-10 libraries throughout the US. It is difficult to accurately estimate the use, since anyone is free to use the software without notifying the author. But, P has personally responded to help requests and assisted with implementation at the number of libraries mentioned. All of these libraries have helped to identify bugs and made feature requests, but it has for the most part been up to P to carry out the necessary programming. P thinks that this will be changing in the near future, as some of the libraries currently using the software are setting up their own teams to further develop the software to suit their own needs. But, he stills sees a central role for himself in leading the overall project.

Development progress after OS. P likens the development process of his software to theories of evolution, in that there is not a steady development cycle. Rather, that there are intermittent periods of increased activity, with lulls in between. Nevertheless, there is continuous activity throughout and the development process is incremental. P maintains that the development process has been collaborative, even though he has been responsible for carrying out most of the actual software development work, and that the software would not be what it is today had it not been released as open source.

Analysis

A central theme that we set out to observe in this case study was analyzing the types of collaboration that was present in OS systems. More specifically, we wanted to identify how the collaboration found in OS systems served as a model of learning that could be applied across disciplines over and above the OS software development system. In discussing how to tie in the idea of studying open source systems to learning/ development into these other systems, we identified Garmston & Wellman’s (1999) framework as a means of cross-reference. These norms are:

•     Pausing

•     Paraphrasing

•     Probing for Specificity

•     Putting ideas on/off the table

•     Paying attention to self/others

•     Presuming positive intentions

•     Pursuing a balance between advocacy/inquiry

These norms were developed for the purpose of developing collaborative groups, particularly for adult learning organizations. However, in reviewing these norms, we found some interesting correlations to that found in OS organizations. In many respects, OS systems are the quintessential reflection of collaborative learning organizations.

Pausing. The first norm of Garmston and Wellman (1999) is pausing, or “listening to others’ ideas with mind and body.”  In an OS organization, it is very important that collaborators review the work of other contributors to understand the meaning of each contribution. It is essential that you suspend judgment into the context of the contributions are being forwarded in the forum. The forum may be an artifact such as a computer program, an open forum where mutual ideas are heard and reflected on, or a web log that allows asynchronous entries to the concept being improved.

This pausing norm requires that people internalize the contribution before responding.  In an OS organization, this is a built-in characteristic that nearly purely depicts this norm at work in a dynamic process that builds knowledge through collaboration. It is inherent to the process.

Paraphrasing. The second norm is paraphrasing, or using “paraphrases that summarize and organize,” clarifying content and emotion. Some phrases that lead to a higher level of abstraction are things like, “So, your concern is.”, “We all seem interested in…” and “It appears that a major goal of this is to…” It is really not as important to have the exact wording as it is to get into the idea that you are validating another’s contribution. In face-to-face organizations, this may well involve the nonverbal communication aspect.

In OS organizations, paraphrasing is critical to understanding. It is difficult to improve a concept that shows promise without understanding the intentions as well. OS doesn’t describe the process that is happening at random, rather the process that is systematically leading to refinements in the artifact. The object of our interview states that “usually there is some kind of behavioral residue…I’m not sure what could be developed…without leaving something…some intentionality.” In order to collaborate to produce this “residue”, it is important that fellow contributors have mutual desires to create something of value to the entire group. Paraphrasing “residue” is evident throughout OS organizations whether it is a Wikipedia ( http://www.wikipedia.org ) entry or advancement of a computer source code.

Probing for Specificity. Garmston & Wellman define this concept as the “asking questions” norm. Aspects of this norm include: finding agreement on the meaning of terms; clarification of facts and ideas; formulating explanations, hypotheses and conjectures; analyzing implications/consequences and generally probing to produce common beliefs and values to create common beliefs and values within the organization.

In OS organizations, this type of collaboration is going on continuously.  In many ways, it is the central component of an OS organization that has an advanced peer review process for software development, as well as the parallel in the academic universe. Everyone is a contributor; everyone is a peer reviewer. Former head of policy at the British Prime Minister’s office, Geoff Mulgan, has co-authored a paper on use of Open Source methods outside of the computer world with Tom Steinberg (Mulgan, Steinberg and Salem, 2005), for the purpose of improving academic peer review and drafting legislation, and even media regulation.

Putting/Pulling Ideas On/Off the Table. The fourth norm involves the process of offering and withdrawing solutions for consideration. Specifically, ideas are offered with intention providing relevant information for others to consider for appropriateness. In this stage, the sender provides facts, inferences, ideas, opinions and suggestions, as well as the reasoning behind these statements. It is the primary stage of advocacy for potential solutions.  

In the OS world, it is a synthesis of the interactions and collaborations that lead the project to a point where solutions appear possible. Upon these offerings, the sender may sustain, modify or remove their proposals in response to collegial dialogue. In this sense, the sender has the right to keep an idea alive or may also remove it from further consideration. This process is not done in a vacuum, rather involves careful consideration of the dialogue from the learning group. Our interviewee speaks to this idea when discussing his project, “Everything has been …a carefully controlled mistake…there is nothing in here where I say, this is wonderful and it’ll never change. It’s really an ongoing process.”  

Paying Attention to Self and Others. In this norm, Garmston and Wellman (1999) contend that contributors maintain awareness over the thoughts and feelings of themselves and others. Careful attention is paid to patterns of communication and usage. All of this is done under the overarching concept of the group task—working to maintain the mood and relevance of everyone’s contributions.     

When in academia, it is a common practice to develop ideas at least moderately in isolation. An open source environment, by definition, does not accommodate well to this type of study. It is imperative that the process is “open” and “free”. When it fails to produce this OS environment, it fails to continue as open source. There are checks and balances that exist that keep the project trending towards a common outcome. Outlandish, divergent solutions are considered, but ultimately must stand on their own merit. The behavior of the group helps to keep a project on task. In the case of the development of Linux, the founder, Linus Torvaldsen, is ultimately the one who decides if the project benefits from the suggestion or not.  If so, he includes it.  If not, it either continues in the beta form or is discarded.

Presuming Positive Intentions. The sixth norm addresses the demeanor that participants must have toward others’ contributions in an OS organization.  The process is generative rather than destructive. To build collaborative OS organizations, there has to be managed risk for contributors to put their work out there for others to review.  This element of the peer review process in OS systems engenders people to feel confident to contribute to the development of the project by assuming positive intentions from all involved.

In doing so, there are a few aspects that need to be discussed as components of this norm. Not only do collaborators act as if others mean well, they must also use those pausing and reflecting skills discussed above to restrain from impulsive feedback that, particularly in electronic or asynchronous environments, almost always engenders emotional response. The context of the contribution can easily be missed. Therefore, this is a particularly important function for OS organizations to master.

The inquiry methods established must be carefully constructed.  Instead of saying, “What in the hell do you mean by that?”, one may ask, “I’m not sure if I see what you are trying to do here. Could you elaborate about ….?” In effect, the context of each contribution has to be considered as well meaning and intentioned. As a representation of open source systems, Ulmer (1998) suggested the metaphor of the garage band. Using this metaphor, each “band” member can create an individual part that operates within the overall project, yet expressing different ideas and methods.

Pursuing a Balance Between Advocacy/Inquiry. In many learning organizations, the development that takes place within an organization is characterized by winners and losers, competition, political clout and propping up some ideas while attacking others. In Open Source environments, this is antithetical to the process. It is not simply about gaining power in the environment through your ideas, but gaining power for the product through the process--sans the individual. This participative equity generates good feeling, which begets power for the process.  

Likewise, the final norm is emphasizing the need to balance the idea of forwarding your own ideas versus inquiring about others. It is important for people to have the confidence to advocate for your own ideas, yet equally important for members of the organization to step back and inquire about others’ opinions, work on others’ ideas and explore the context by suspending judgment. Disagreement is acceptable, but only in the context of openness and respect, “I am seeing your point of view, wondering if it becomes stronger if…?” When discussing suspension as a means of creating dialoguing groups, Bohm (1996) states,

“When we practice suspending our judgments we learn to hold our opinions lightly. We consciously open ourselves to hearing and understanding each person's point of view. We create a space between our judgments and our reactions so that we can hear the other person in a new way.  Our academic training and our jobs develop our proficiency in being critical - our ability to listen for what can be judged and challenged… Such suspension of judgment is a key to building a climate of trust and safety in the group.”

    

Summary of analysis. This distinction between groups that discuss things (discussion) and groups that interact reflectively (dialogue) is critical to consider. Discussion within groups is reductive in nature. The purposes of these conversations are to take a whole collage of ideas and simplify things into only one, or few, of the numerous potential solutions. Open source systems, which operate in a similar fashion to Bohm’s dialogue groups, are meant to take ideas and give power to them by expanding them to be mutually inclusive of a group process.

Perhaps the central tenet of the entire framework is to process by looking through the eyes of others, rather than through oneself. Therefore, the Garmston & Wellman framework has unique parallels to the Open Source movement across settings. In the Norms framework, it is the goal of the organization to portray these values.  In the Open Source movement, it is inherent to the process. By definition, organizations lacking this “process” are not Open Source.

Limitations of the current study

The time constraints for this project had an impact on the selection of the subject of the case study. Ideally a project such as this would include case studies of several software developers having been involved in different types of software development projects and at different stages in the lifespans of such projects. Although an attempt was made to compile a list of developers to randomly select subjects from, attempts to establish contact with communities of developers proved unfruitful. A different approach was therefore taken that involved directly contacting software developers working for the University of Minnesota who were known to be involved in OS software development. Of the two suitable candidates identified only one responded to attempts to set up times for meetings and interviews. The individual who participated in this study has been directly involved with only one rather small and fairly recent software development project with a limited target audience.

Conclusions

Our evidence certainly makes a case for OS as a source of methodologies for promoting knowledge development in collaborative environments. Nevertheless, there are key factors that have to be considered in any attempt to mimic this type of collaboration. The first and foremost is that any OS collaboration involves an artifact being constructed. It is highly unlikely that OS methodologies will prove conducive to knowledge development if there is not clear consensus among participants about what the group intends to construct. Secondly, there needs to be an explicit intention to collaborate along the lines of the Garmston & Wellman framework. Thirdly, there is a need for leadership, but that leadership positions be filled by peers who are just as willing and able to participate in the work related to the construction of the artifact as others. Lastly, that the collaboration be based on incremental progress. This notion of incremental progress is central to the OS model because it allows for rapid realization of the development process and ongoing active peer review.

As was mentioned previously, OS projects are very likely sui generis in that each project creates its own culture based on values related to the specific artifact being developed and the purpose for creating it. In our case study it was revealed that our interviewee identifies the ownership issue as the key characteristic of OS for him personally. While this is not necessarily the case in all OS projects, it is reasonable to assume that it is common when we consider that most OS projects are intended to compete directly with proprietary closed source software. The examples are numerous; Linux vs. Unix, OpenOffice vs. Microsoft Office, MySql vs. Microsoft SQLServer, Oracle and others. This would seem to bear some relevance in the case of education. In a rapidly changing society where lifelong learning and continuous professional development are not only ideals but a necessity, the need to have some sense of ownership of one’s own learning becomes a very salient issue.

It is obvious that OS is a multifaceted phenomenon that can reveal many insights into the nature of highly effective collaborative organizations and the knowledge development that goes on within them. There is an obvious need to gather further data on OS communities because of their complexity and diversity. There is also a need for practical information on the transferability of OS methodologies. We conclude with some relevant questions that emerged from our analysis that could be addressed in the future:

•     Is there an identifiable subset of key characteristics that have to be in place to mimic an OS community, or do all of these characteristics need to be established?

•     Can OS models be implemented in a classroom?

•     Is there a conflict between the hierarchical leadership models displayed in OS collaboration and traditional leadership models in educational environments?

References.

Bohm, D. (1996). On dialogue . Routledge. Laguna Hills, CA.

Garmston, R. & Wellman B. (1999). The Adaptive School: A Sourcebook for Developing Collaborative Groups, Christopher Gordon, Norwood, MA.

Mulgan, G., Steinberg, T. & Salem, O. (2005). Open source methods and their future potential . Demos, London, Eng.

OhMyNews (2005), It's a Wiki, Wiki World. Retrieved May 2, 2005 from OhMyNews web site: http://english.ohmynews.com/articleview/article_view.asp?article_class=4&no=210781&rel_no=1

Raymond, E. S. (2000a). The Cathedral and the Bazaar . Retrieved May 2, 2005 from web: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Raymond, E. S. (2000b). Homesteading the Noosphere . Retrieved May 2, 2005 from web: http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/

Scharff, E. (2002). Open Source: A conceptual framework for collaborative artifact and knowledge construction . Retrieved May 2, 2005 from web: http://www.isse.ucar.edu/scharff/thesis.html

Taylor, L. and Riley, B. (2005). Open Source and Academia . Computers and Compostion Online. Retrieved May 2, 2005 from web: http://www.bgsu.edu/cconline/tayloriley/intro.html

Ulmer, G. (1998). Instructions . Retrieved may 2, 2005 from web: http://www.nwe.ufl.edu/elf/conf98/instructions.html .

Zonk. (2005). Open Source Methods Useful Way Beyond Software. Retrieved May 2, 2005 from web: http://politics.slashdot.org/article.pl?sid=05/04/21/1419202&from=rss

Posted by thay0012 at June 4, 2005 11:58 AM