I've tried to find a link to the report itself, but not come up with anything (which I find strange given that it is commissioned by a public agency).
C|Net has something on this too. They include a list of all the software analyzed: Homeland Security helps secure open-source code | CNET News.com
What might this mean for open source methods in education?
]]>sustainablog: Building an Open-Source Community for Appropriate Technology
WorldChanging: Another World Is Here: Open Source, Development and Design
And I especially like this one:
WorldChanging: Another World Is Here: LinuxChix Africa
Here are links to some stuff I've collected recently (some of is a bit dated that I've had lying around for some time):
Wide Open: Open source methods and their future potential - Excellent report from Demos.
Free/Libre and Open Source Software: Survey and Study - What motivates OSS developers? Learning, of course.
Comparison study of Free/Open Source and Proprietary Software in an African context: implementation and policy-making to optimise community access to ICT Not everyone thinks OSS is practical. But, does this strengthen the argument for using OSS to educate?
Lens on the Future: Open source learning OS ideology in higher education.
Why Developing Countries Need to Use and Create Free Software (and how it promotes Gross National Happiness.) Bhutan snubs the GDP and now focusses on Gross National Happiness - how does OS fit in? Lots about the educational aspects of OS software development.
ThinkCycle: Reaching Out to Solve Real-World Problems And the ThinkCycle web site: ThinkCycle.com
Vores Øl Applying OS methodology in innovative ways (Vores Øl - Danish for 'Our beer').
Information and communication technologies in development education: Preparing educators with open source software and constructivist learning approaches.
Tryggvi Thayer (tryggvi_bt at yahoo dot com)
Introduction. The purpose of this paper is to address the need for better articulated strategies and goals in programs and initiatives that promote the adoption of information and communication technologies (ICTs) for development and development education. More specifically, it addresses the question of how educators in the least developed countries (LDCs) can best be prepared to make optimal use of ICTs in development education to achieve development goals. The author examines some underlying assumptions common in ICT for development programs from a development theory perspective and discusses why these approaches fail to produce the intended outcomes. In response to the issues identified, the author suggests a constructivist approach to educator training using open source software (OSS) to facilitate and promote the development of relevant and specifically tailored computer-based educational tools for development education.
ICTs and development education. ICTs have had a profound impact on the way we communicate, the way we do business, and the way we learn. It is no surprise then the impact that ICTs have had on education. Not only are they an ideal tool to facilitate learning by providing access to learning resources, but they are also an integral part of the environment that we need to prepare today�s learners for. This point is acknowledged in the UNESCO�s Dakar Framework for Action for the �Education for All� (EFA) initiative which clearly states, �Information and communication technologies (ICTs) must be harnessed to support EFA goals at an affordable cost.� (UNESCO, 2000) As such, the EFA goals are focusing not only on inequality in terms of access to education, but also inequality in terms of access to ICTs.
In development education there have been high expectations in regards to the potential of ICTs. The difficulties of development education in general, such as availability of resources and delivery of education to remote areas, seem easily overcome with ICTs. In recent years increasingly cheaper ICTs have made this an even more attractive means of dealing with the educational needs of LDCs. The result has been a proliferation of programs and initiatives that aim to make ICTs available to LDCs for education and development purposes. Despite the efforts of development agencies and other benefactors, research has shown that the results of many past efforts to promote development through the introduction of ICTs are questionable at best. While many quantitative indicators associated with adoption of ICTs may look impressive the intended outcomes in terms of human and economic development seldom reflect the same optimism (Birdsall & Birdsall, 2005).
ICTs as facilitators of change. It is remarkable how little research there is into why past and existing ICT related initiatives that aim to make the technology available to LDCs are not producing the intended outcomes in terms of human and economic development. Looking at the issue from a development theory perspective reveals that ICT initiatives that focus primarily on introducing technology into LDCs, without considering how the technology is to be used, are ignoring lessons of the past. The currently common assumption that ICTs can, in and of themselves, prompt development has been referred to as �leapfrogging development� (Singh, 1999). The hypothesis of �leapfrogging development� is that by implementing cheap off-the-shelf ICTs, developing countries can �leapfrog� over the stages of modernization needed to reach development goals as dictated by modernization theory (Singh, 1999). Although supporters of this type of �leapfrogging� often cite the impact of cellular telephony in developing countries as verification of the effectiveness of this strategy, these claims have not been supported by recent research (Alhassan, 2004). The mistake in the �leapfrogging development� assumption is that in proposing an alternative to the traditional modernization approach to development, �leapfrogging� nonetheless takes the modernization model as its measure of success. As past research has shown, modernization theory does not provide an adequate model for development, nor the evaluation of the effectiveness of a given strategy, because the stages of modernization that the theory is based on are assumed to apply to developing countries without any evidence that this is truly the case (F�gerlind & Saha, 1989).
These considerations lead to the obvious suggestion that programs that promote ICTs for development need to have more clearly formulated strategies and goals. The less obvious conclusion, which is especially relevant for development education, is that the beneficiaries of these programs need to be more involved in formulating these strategies in line with their anticipated outcomes. In the case of ICTs for development education, computers, the Internet, and computer applications are the primary focus of development initiatives. It is unrealistic to assume that existing technology and applications, the majority of which have been created for and by �Western� developed countries, will suit the needs of LDCs. On the other hand, given the time and cost involved in developing computer applications, it must be considered beneficial to be able to build on the experience gained in developing countries. In this context open source software (OSS) may provide an ideal jumping board for adaptation of existing applications due to the open nature of the application development process. The nature of OSS communities also suggest that they may serve as an ideal training environment for educators in developing countries preparing to make use of ICTs in education.
OSS � Free as in �freedom�. OSS 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.
There are many differing opinions about the benefits of OSS for developing countries. While some see it as a cheap alternative to proprietary software (PS), to be evaluated in terms of overall cost, including support and training (Bridges.org, 2005), others focus on the benefits of its flexibility and openness (Ghosh, 2004). OSS and the communities involved in its development are a far more complex phenomenon that includes both of these dimensions and more. What both of these views miss is what has been identified as a crucial element of the attraction of OSS for developers, i.e. �ownership� (Thayer & Walsher, 2005). �Ownership� in this sense refers to users and developers vested interest in, and control over the software, not that it is the property of any individual, group, or organization. Having ownership of the software and the source code means that users and developers are able to adapt the software to their specific needs at the time when they need it and are able to contribute to its development on their own terms. This is especially significant for LDCs since many of these countries are not considered by software companies to be a viable enough market to justify the time and cost of specially tailoring PS.
Another important aspect of OSS communities that is often overlooked is that they are learning communities. A recent study has shown that the most common reason cited for developers� getting involved with OSS development is to advance their own programming skills (International Institute of Infonomics, 2002). OSS communities have constructed their own methods and tools for facilitating learning, including �massive peer review�, extensive documentation, and a number of interactive collaborative tools (Mulgan et al, 2005; Scharff, 2002; Taylor & Riley, 2005). The result is that anyone interested in a specific OSS project can get involved in any number of ways, ranging from coding and debugging to documentation and end-user support, at any time by familiarizing themselves with as much of the development process as they see fit.
OSS and constructivist learning environments. OSS communities have been said to be quintessential constructivist learning environments (Koohang & Harman, 2005). Wilson describes a constructivist learning environment as �a place where learners may work together and support each other as they use a variety of tools and information resources in their pursuit of learning goals and problem-solving activities� (as cited in Hannafin & Hill, 2002). This certainly describes OSS communities that structure themselves around specific issues relating to the software being developed and use several tools to tackle the tasks at hand. But, it must be added that there are many ways of participating in OSS projects. In most projects only a handful of the larger community are actually involved in writing software code, i.e. providing the solutions to problems. The majority of participants are involved in testing software for coding errors and reporting those errors, while others are involved with creating documentation and planning for future development, i.e. identifying and formulating problems needing to be solved. In fact the wide range of opportunities for participation mean that anyone, whether they are a programmer or merely an end user, can contribute in some way. This is relevant for LDCs because it means that they need not have advanced knowledge of software development to play a significant role in OSS projects, merely that they are able to provide constructive feedback to inform ongoing development. OSS, viewed as a learning community, therefore presents itself as a potential model for training future users of technology in a manner that allows them to simultaneously have an impact on the construction of the software itself. As such OSS development environments may provide an attractive means of training educators in LDCs to prepare them to use ICTs in their own educational environments. Using OSS for training can increase educators� sense of ownership in the technology being used by allowing them to tailor the technology to their educational needs, rather than tailoring their education to the software available.
As an educational tool, OSS would seem to be best suited to constructivist learning strategies, because the OSS development process is itself a constructivist process. Such a strategy would inevitably focus on problem solving, which is widely regarded as a key task in constructivist learning environments (Jonassen, 2002). This approach to designing constructivist environments emphasizes the problem solving, but when considering the potential of OSS as an educational tool problem identification and formulation present themselves as learning processes in and of themselves. This aspect of a problem solving approach is as important, and perhaps even more important, than the problem solving itself because it is at this stage where ownership is initially established. For a problem to be solved there needs to be a problem. Of course, it is important that the problem is solved, but once it is the process should be considered as a whole. Considered as a complete process, the contribution of the problem solver is certainly no more than the contribution of the problem identifier. The significance of the contribution of each party would ultimately depend on what the expected learning outcomes are. In OSS projects, not everyone is expecting to learn software development. But, by participating in the many other ways possible, be it producing documentation or merely identifying bugs in the software, participants are engaging in a collaborative learning activity that seeks to increase a general understanding of what the specific software should do and how it should do it.
Constructing learning environments about ICTs for educators. Creating constructivist learning environments around OSS should be a fairly straightforward task since OSS is essentially a constructivist environment to begin with. OSS communities have developed many useful tools, such as concurrent versioning systems, wikis, blogs, and messageboards, that are themselves open source, to support their activities. These tools and other software applications are almost always easily accessible on the Internet, or where Internet connectivity is limited, on CD-ROM. Open source system software is usually distributed on multiple CD-ROMS and includes software needed for day to day computing tasks, for running network services, and for software development, including the previously mentioned OSS collaboration tools. Therefore, a single Linux distribution (ex. Mandrake, Debian, Fedora) will usually include everything required to set up a computer with the services and applications needed to operate, or even simulate, a computer network with all of the features of the Internet. Of course, a connection to the Internet is ideal, but it would be unrealistic to assume that this will always be possible. In the case where it is not possible, the Internet can be simulated using open source web server software, web browsers, and any number of connected computers. All of this software and the OSS collaboration tools can be directly applied to learning environments with little or no change other than necessary translation and localization.
Once a network environment has been set up, users (in this scenario the users are also learners) can begin to familiarize themselves with the computing environment and identifying necessary changes to meet their needs. Using the applications common to OSS environments, such as wikis and messageboards, users/learners can, with little instruction, start documenting their experiences with the software and reflecting on those experiences collaboratively. The obvious starting points would be the translation and localization of the collaboration tools themselves. At some stage in this process it will be necessary for developers to become involved so that the users/learners have the opportunity to see the impact of their work. Nevertheless, they need not be involved at all times. In this manner, users/learners will gradually construct their own learning environment by integrating more and more tools into their work environment that they themselves have adapted according to their proficiency with the technology and their needs.
In this approach problem solving is not the primary goal as far as users/learners are concerned. The primary task of the users/learners in this scenario is the identification of problems that need solving. Who eventually solves the problem is not relevant. The process of identifying and formulating problems, and seeing the results once they are solved, is sufficient to promote ownership in the software being developed. Promoting ownership in this manner will help users/learners overcome any apprehensions initially felt concerning the use of the technology in educational settings and will increase the perceived relevance and usefulness of the technology.
Conclusions. Research has shown that, in the context of development education, problems related to accessibility of ICTs are only one side of the coin. Without qualified educators that have a clear understanding of the technology and that are able to use it effectively, the technology itself is useless. Furthermore, in the case of computers and the Internet, applications need to be tailored to the needs of LDCs. Constructivist learning strategies aim to further knowledge development by promoting ownership of the artifacts involved in well defined problem solving tasks. Although the ultimate goal is the solution of the problem, initial problem identification and formulation can, in and of itself, contribute to a sense of ownership and knowledge development. This type of strategy may be an effective means of training educators in LDCs by involving them in the adaptation, translation, and localization of computer applications to be used in development education. Such an approach to teacher training in LDCs can be a cost effective way of paving the way for the use of ICTs in development training since the collaborative tools and other necessary software are already freely available through OSS communities.
References
Alhassan, A. (2004). Development Communication Policy and Economic Fundamentalism in Ghana. University of Tampere, Tampere.
Birdsall S. & Birdsall W. F. (2005). "The democratic divide," First Monday, volume 10, number 10 (October), Retrieved October 10, 2005 from http://www.firstmonday.org/issues/issue10_10/birdsall/.
Bridges.org (2005). Comparative Study of Free/Open Source and Proprietary Software in an African Context: Implementation and policy-making to optimise public access to ICT. Bridges.org, Cape Town, South Africa.
F�gerlind, I. & Saha, L. J. (1989). Education and National Development: A comparative perspective. Pergamon Press, New York, NY.
Ghosh, R. A. (2004). Why Developing Countries Need to Use and Create Free Software (and how it promotes Gross National Happiness). Presentation given at Thimphu, Bhutan, April 4, 2004. Retrieved October 10, 2005 from http://www.infonomics.nl/FLOSS/papers/20040409/index.htm
Hannafin, M. J. & Hill, J. R. (2002). Epistemology and the Design of Learning Environments. In: Reiser, R. A. & Dempsey, J. V. (eds.). Instructional Design and Technology. Merrill Prentice Hall, Upper Saddle River, NJ.
International Institute of Infonomics (2002). Free/Libre and Open Source Software: Survey and study. University of Maastricht, The Netherlands.
Jonassen, D. H. (2002). Integration of Problem Solving into Instructional Design. In: Reiser, R. A. & Dempsey, J. V. (eds.). Instructional Design and Technology. Merrill Prentice Hall, Upper Saddle River, NJ.
Koohang, A. & Harman, K. (2005). Open Source: A metaphor for e-learning. Informing Science Journal, 8, 75-86.
Mulgan, G., Steinberg, T. & Salem, O. (2005). Wide Open: Open source methods and their future potential. Demos, London, Eng.
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
Singh, J. P. (1999). Leapfrogging Development?: The political economy of telecommunications restructuring. SUNY Press, Albany, NY.
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
Thayer, T. B. & Walsher, P. (2005). Open Source as a model for Collaborative Knowledge Development: A case study. Unpublished paper. EdPA 5056: Case Studies [Graduate Course]. University of Minnesota.
UNESCO (2000). The Dakar Framework for Action: Education for all: Meeting our collective commitments. UNESCO, France.
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
2. How important were elements of open source
a. Collaboration
b. Access to community
c. Access to past exchanges
d. Artifacts - source code, documentation
3. Impact on professional/knowledge development
a. Education/knowledge level at start
b. Did it prompt further formal study
c. Networking (with other developers)
4. Validation
a. Certification
b. Recognition of qualifications
c. "Guru" status
Constructivism and emerging online learning pedagogy: a discussion for formal to acknowledge and promote the informal, Shalni Gulati
Open source development: the case of Linux , John Seeley-Brown
Open Source Everywhere, Wired
Open Source and Academia, Laurie Taylor and Brendan Riley
Open Space Organizations, Michael Herman
Moodle--An Open Source Development Tool for Educators (including 60 languages)Martin Dougiamas
]]>