Open Source Software as a Knowledge Ecology

Lanzara, G. F., & Morner, M. (2003, July). The knowledge ecology of open-source software projects. In 19th EGOS Colloquium, Copenhagen.

I stumbled upon this paper during a Google Scholar search for “Knowledge Brokers Free and Open Source Software” and while I was expecting to learn more about the role of knowledge brokers in FOSS I did not.   What this paper is about, however, is understanding knowledge making in FOSS from a perspective that explains how balance is achieved in these heterogeneous, interactive, emergent systems.  The authors through an exploratory study of artifacts in the Linux and Apache communities show how this is accomplished through the processes of variation, selection, and stabilization, explaining how selection resolves tension between variation, which feeds innovation, and the stabilization necessary for ecological systems.  For instance, in examining source code the characteristics of openness, frequent releases, modular design, and recombination were noted as forms of variation.  Openness relates to ability to modify source code for different purposes.  Frequent releases allow for multiple versions of the code to exist and modularity allows for parallel development and supports recombination.   These methods permit experimentation and innovation.  However, there is a need for manageability of the variation.   Selection is the manageability process and is accomplished using methods such as style guides for code contribution and commit approval by core members.  Lastly, stabilization of technical knowledge in the form of source code is facilitated by standardized interfaces between modules, documentation of code, and multiple versions.  The paper also examines the variation, selection, stabilization process using mailing list data to examine organizational knowledge and licenses for institutional knowledge.

In thinking about this paper I remembered Nardi and O’Day’s [1] information ecology concept and while it has been a while since I read it, it did seem that there were similarities to that paper.  However, what was missing in Lanzara and Morner was a discussion of localization and the role of keystone species.  An initial thought pertaining to these differences is that Lanzara and Morner didn’t really discuss variation in terms of different knowledge producing groups.

[1]NARDI, Bonnie; O’DAY, Vicki. Information Ecologies: Using Technology with Heart : Chapter Four: Information Ecologies. First Monday, [S.l.], may. 1999. ISSN 13960466. Available at: <>. Date accessed: 31 Jul. 2013. doi:10.5210/fm.v4i5.672.


On boundary objects and knowledge boundaries: Carlile’s study of boundary objects in new project development

Carlile, P. R. (2002). A pragmatic view of knowledge and boundaries: Boundary objects in new product development. Organization science, 13(4), 442-455.

Through field work examining new product development within an automobile parts company, Carlile discusses the problems that arise during knowledge sharing across boundaries.  These boundaries are between units where there are different knowledge bases, in this case functional units at the company.   He explains how what makes problem solving efficient within functions creates issues in problem solving across boundaries.   Which in terms of his pragmatic view of “knowledge in practice” pertain to knowledge as being localized, embedded, and invested within functional units.   It is though understanding those characteristics that one can see how three types of knowledge boundaries arise:  syntactic, semantic, and pragmatic.  Through vignettes he ties the types of knowledge boundaries—syntactic, sematic, and pragmatic—to the types of boundary objects that are needed to traverse those boundaries and finally to the characteristics of successful boundary objects.

First, he begins by describing the types of knowledge boundaries.  The syntactic approach to knowledge boundaries refers to different functional units needing to have a common language to communicate.  During the explanation he describes how for a long time the dominant approach to addressing boundary spanning in organizational theory and new product development research was to make more information available.   However, this approach alone did not address issues of novelty that arise from differences in interpretation for what is needed for the task.   As an aside, in the article while he mentions many authors who have studied semantic boundaries, I also thought of the work by Boland and Tenkasi [1] describing the importance of perspective making and perspective taking as being at the semantic boundary.   While the semantic approach focuses on “differences in kind” it does not address issues of dependency which leads to the third type of boundary, pragmatic.  At the pragmatic boundary difference, novelty, and dependence are all present and what is needed is transformation of knowledge across boundaries.

By understanding the three boundaries, one can then understand how the characteristics of “knowledge in practice”—localized, embedded, and invested – contribute to each of the knowledge boundaries.   Localism refers to the how problems are solved for a given practice.  Efficiency in an organization comes from developing knowledge bases that help address common problems functional units face.  However, this leads to practices that are not the same across functional units complicating communication across the units, a syntactic boundary.   The next characteristic, embedded, relates to how it is difficult to express knowledge outside of practice or the tacitness of knowledge and therefore how people from different knowledge domains will have difficulty communicating knowledge outside their discipline.   This is the semantic boundary.  Lastly, because knowledge is invested in practice, people want to do things according to what they already know, but faced with a dependency on knowledge from another group and the novelty of the situation, for success they must be willing to transform their existing knowledge, thus the pragmatic boundary.

What is most interesting however is Carlile’s study of boundary objects in new product development and through relating Star’s [2] four categories of boundary objects to how they can be used at the knowledge boundaries he describes the characteristics of the types boundary objects.  Star in studying heterogeneous problems solving enumerated four types of boundary objects: repositories, standardized forms and methods, objects of models, and maps of boundaries.   Repositories are stores of information that have common meaning across functional units.   Standardized forms and methods provide a shared approach for addressing problems across boundaries.  Objects or models are detailed representations that different groups can use during problem solving and maps of boundaries express the dependencies across groups.   In his explication of the relationship between knowledge boundaries, boundary objects, and characteristics of boundary objects, Carlile combines objects and methods and maps of boundaries.  It is important to understand that the types of boundary objects build upon each other subsuming characteristics of less versatile boundary objects in this order: repositories; standardized forms and methods;  and objects, models, and maps.

To understand the characteristics of boundary objects that can be used at the different boundaries, one can look at the purposes of each type of boundary object.  Repositories contain information that can be used across groups to solve problems.   In this way they address the syntactic boundary and must be adequately representative among units to be useful.   Standardized forms and methods help define a shared approach to problem, to be useful they must express differences and dependencies.   So, while they represent information much as repositories do to address communication issues, they also enable learning between groups to occur by helping identify differences and dependencies.  However, to address those dependencies and the consequences thereof the pragmatic boundary must be addressed, which requires transformation of knowledge.   Objects, models, and maps are the only category of boundary object that can satisfy that purpose by supporting representativeness for communication, learning through definition of differences and dependencies, and providing a process for helping different groups mutually transform knowledge.

[1] Boland, R. J., & Tenkasi, R. V. (1995). Perspective making and perspective taking in communities of knowing. Organization science, 6(4), 350-372.

[2] Star, S. L. (1989). The Structure of 111 «Structured Solutions: Boundary Objects and Heterogeneous Distributed Problem Solving. Distributed Artifcial Intelligence, 2, 37-54.

Cross-project Coordination in OSS

Chua, C. E. H., & Yeow, A. Y. K. (2010). Artifacts, actors, and interactions in the cross-project coordination practices of open-source communities. Journal of the Association for Information Systems, 11(12), 3.

Authors are concerned with cross-project coordination which pertains to interactions across multiple projects in pursuit of individual project goals.   Within-project coordination refers to  interactions within a project to realize shared project goals.  What is a notable difference here is the shared versus individual goals, which influence the coordination.  Shared goals lead to a more routinized coordination versus independent goals which lead to more emergent coordination.

Methodologically they perform a cross-case analysis of projects that are mods to JA2, an open source commuter game community.  Through using the ordering system lens they examine coordination among three different types of mods—code, data, and game– and JA2.   What they found were general steps in coordination among the three types of mods: awareness, merger, cascade.  However, the interactions and artifacts used differed depending on the type of mod.  For instance, in the case of code awareness building was done through the forum and versioning system while in the case of data it was the main forum and other forums.  And, the interactions were different also for code, downloading and reading code was used, but in data there was a need for boundary spanners.

Calls for future work:

  • More study of cross-project coordination at other sites
  • Examination of coordination difficulties
  • More theorization on the issue of materiality and how it affects coordination.

Boundary spanning in OSS

Today I read:

Barcellini, F., Détienne, F., & Burkhardt, J. M. (2008). User and developer mediation in an Open Source Software community: Boundary spanning through cross participation in online discussions. International Journal of Human-Computer Studies, 66(7), 558-570.

This paper looks at user-developer collaboration during the design process in the Python open source community.  Specifically the authors wanted to understand how boundary spanners mediated the collaborative process between users and developers.  This paper is relevant to my research interest as it is looking at a community where people with different knowledge are collaborating and how that is aided.  Python is a community with developers and users from types of application domains, e.g., web development, gaming, finance.

To understand how boundary spanning occurred cross-participation on the general discussion list, python-list, and the developers’ list, python-dev, was analyzed.   More specifically, cross-participation behavior pertaining to  a specific Python Enhancement Proposal, which is a formal process for proposing changes to the language, was analyzed.   Cross-participation is when the same people post to the same topic on both lists.  The thought here being that cross-participation would reflect boundary spanning behavior.

Some of the major takeaways that seem applicable to my work is that they found users tended to communicate on python-list so there was a need to link up user-provided information– e.g., scenarios, end-user info–with developers.  The cross-participants acting as boundary spanners performed this role by being able to share application-specific and development-specific information between worlds.    And, the boundary spanning function was performed by people who held different roles in the community and it was emergent.  The authors speak of this as “role emergent design.”  What is interesting from a socio-technical perspective is what are the  characteristics  of the community that enable this emergence.

Getting involved in AnkiDroid

This semester I am logging my own experiences as a contributor to an open source project in  an attempt to understand what kinds of thinking processes I engage in while working on various tasks.  Eventually I want to study open source software communities to identify the tasks and resources in projects that used within a problem-based learning structure can help students not only learn computing skills, but problem solving skills in general.  The project I’ve chosen is called AnkiDroid.  It is a flash card tool for Droid devices built upon Anki, a desktop flashcard program.  I chose AnkiDroid for a number of reasons:

  1. I have an interest in using technology for learning.
  2. I wanted to create a mobile flashcard program for learning Tang Soo Do terminology last year, but the learning curve for developing for the iPhone was too steep.
  3. The program was active
  4. They wanted contributors
  5. Learning materials looked organized
  6. There were tasks I could help with
  7. To help with my own motivation for contributing besides my studies, it was important to be involved in a project that I had interest in and felt I’d eventually have ideas for new functionality.

I’ve only just gotten started, but the project looks interesting.  I like the idea of being able to study anywhere.  The software uses a spaced repetition algorithm to aid in more efficient study, allows embedding images and sound, includes statistics for tracking progress, and many other features.  Below is the AnkiDroid quick overview video.