http://flosscom.net/templates/xplike.plesk.blue.2/images/logo.jpg

Learning Resources in Free / Libre Open Source Software (FLOSS)

Introduction

FLOSS communities provide users with various types of learning resources, the “common” ones like manuals, tutorials, or wikis, but also resources that might not be considered as learning resources at a first point like mailing lists and forums. One unique aspect of all of them is that they are jointly generated by user and developer and after generation continuously updated and improved.

The text at the main section, by now, only provides a very brief overview on learning resources.

There are a number of interesting questions that might be addressed at this page, like:

• What is the concept of “re-use” of information (e.g. forum posts) and how could it be translated to education?
• What is the concept of “collaborative content creation / production” and how could it be translated to education?
• What is the concept of “peer review” and how could it be translated to education?

Please feel also invited to participate at our survey on learning resources and FLOSS tools and how they are related to learning. Just follow this link to take it.

Main Part

Below you can find an initial “main part”. However, we encourage you to rework it as you see it fits and to make it of more practical use.

See also this slideshare presentation and this one which both provide an idea on the learning resources in FLOSS.

Scacchi (2002) identified 8 types of what he defined as “software informalisms” with each having sub-types. With his 8 type classification Scacchi provides an overview of the information systems within the FLOSS communities and their purposes. According to Scacchi these software informalisms are used for (software) product requirement definition, sense making, continuous discourse, and accountability. As noted by Scacchi the requirements for a FLOSS product are, unlike for traditional software products, not pre-defined, but specified through developer and user discourse that reference or link:

• “email or bboard (forum) discussion threads,
• system vision statements,
• ideas about system functionality and the non-functional need for volunteer developers to implement the functionality,
• promotional encouragement to specify and develop whatever functionality you need, which might also help you get a new job, and
• scholarly scientific research publications that underscore how the requirements of domain-specific software (e.g., for astronomical imaging), though complex, are understood without elaboration, since they rely on prior scientific/domain knowledge and tradition of open scientific research.”(Scacchi 2002)

From the learning point of view the 8 informalisms might help in understanding the type of “Learning Resources” that users in FLOSS in general use. Following it will be briefly referred to the each informalisms, to subsequently have a look at them from a “Learning Resource” point of view.

The software programme itself might be seen as an analogue to the content of a course in formal education. But unlike in education, or even in formal software development, there is no such think as a “Requirement Specification” document for FLOSS products. Instead users and developer are in a constant re-negotiation of the software’s features, functions or design (Scacchi 2002).

“…it appears that the requirements for open software are co-mingled with Design, implementation, and testing descriptions and software artifacts, as well as with user manuals and usage artifacts (e.g., input data, program invocation scripts). Similarly, the requirements are spread across different kinds of electronic documents including Web pages, sites, hypertext links, source code directories, threaded email transcripts, and more. In each community, requirements are described, asserted, or implied informally. Yet it is possible to observe in threaded email/bboard discussions that community participants are able to comprehend and condense wide-ranging software requirements into succinct descriptions using lean media [39] that pushes the context for their creation into the background. (Scacchi 2002)

Community communications

Mailing lists and forums are the common place for community communications to discus about the requirement of the software or known bugs, but also other organizational aspect and they are also the main place to provide support to users. Chats, instant messagings or voip are also used but for more ad-hoc discussions. The advantage of communications in mailing lists and forums is that other user can later on read through these.

In FLOSS messages often do not consist of questions and answers only, but also include the “path” leading to the answers. This might include parts of the code discussed together with references or links to other messages or software websites. Following Scacchi this provides “some sense of context for how to understand messages, or where and how to act on them.”

Hemetsberger & Reinhardt (Hemetsberger & Reinhardt 2006a) suggests that members of FLOSS communities learn and build collective knowledge through the use of ‘technologies’ and the establishment of discursive practices that enable virtual re-experience. Following the problem solving processes, or other type of argumentation lines, are important learning resources of FLOSS communities that enable other users’ re-experience. With this users get access to “knowledge that is often tacit in nature but visible and observable in the common practice of and interactions among competent practitioners”, which is “also highly contextual and, therefore, cannot be externalized and taught independently from its context.” (Brown & Duguid 1991)

Community members are well aware of the role of mailing lists and forums and consequently expect that these resources are used first, before individual support might be provided .

Scenarios of usage as linked Web pages

To explain the functioning of the software “community participants create artifacts like screenshots, guided tours, or navigational click-through sequences (e.g., “back”, “next” Web page links) with supplementary narrative descriptions in attempting to convey their intent or understanding of how the system operates, or how it appears to a user when used...participants may publish operational program execution scripts or recipes for how to develop or extend designated types of open software artifacts.” (Scacchi 2002). As a use case live demo versions are also commonly available where users can log in at the front and back-ends to experience the software in practice.

HowTo Guides

How to guides are also provided that explain how the software functions. Additionally communities might dispose about FAQs, knowledge bases or wikis. (Meiszner 2007). Further valuable “How To Guides” are also the community forums.

External Publications

All of the 4 cases that were examined by Scacchi, and 50% out of the 80 communities that were reviewed by Meiszner (2007) provided also external publications. These publications might consist of technical articles, books, news feeds, blog postings, or professional and academic articles.

“Academic articles that are refereed and appear in conference proceedings or scholarly journals…serve a similar purpose as professional articles, though usually with more technical depth, theoretical recapitulation, analytical detail, and extensive bibliography of related efforts. However, it may be the case that readers of academic research papers bring to their reading a substantial amount of prior domain knowledge. This expertise may enable them to determine what open software requirements being referenced may be obvious from received wisdom, versus those requirements that are new, innovative, or otherwise noteworthy.”(Scacchi 2002)

Open Software Web Sites and Source Webs

Community websites have the advantage to provide the community with an information infrastructure for “publishing and sharing open descriptions of software in the form of Web pages, Web links, and software artefact content indexes or directories. These pages, hypertext links, and directories are community information structures that serve as a kind of organizational memory and community information system. Such a memory and information system records, stores, and retrieves how open software systems and artefacts are being articulated, negotiated, employed, refined, and coordinated within a community of collaborating developer-users” and it might “include content that incorporates text, tables or presentation frames, diagrams, or navigational images (image maps) to describe their associated open software systems. This content may describe vision statements, assert system features, or otherwise characterize through a narrative, the functional and non-functional capabilities of an open software system…Web content that describes an open software system often comes with many embedded Web links. These links associate content across Web pages, sites, or applications.”(Scacchi 2002)

A characteristic of FLOSS is also the access to its source code. The source code can be usually accessed at the project’s website or at repositories like e.g. sourceforge.net.

Software bug reports and issue tracking

One of the most obvious and frequent types of discourse that appears with open software systems is discussion about operational problems with the current version of the system implementation. Bugs and other issues (missing functionality, incorrect calculation, incorrect rendering of application domain constructs, etc.) are common to open software, much like they are with all other software. However, in an open software development situation, community participants rely on lean communication media like email, bug report bboards, and related issue tracking mechanisms to capture, rearticulate, and refine implicit, mis-stated, or unstated system requirements”(Scacchi 2002).

Traditional software system documentation

Open software systems are not without online system documentation or documentation intended to be printed in support of end-users or developers. Scacchi noted that a general problem of this type of documentation is that it is usually outdated, but that FLOSS software documentation, unlike the documentation of traditional software, benefits from the fact that it can be updated by the community (user/learner generated content).

This could explain why many FLOSS communities introduced wikis (Meiszner 2007) as this might be more convenient for constant changes and updates.

Software extension mechanisms and architectures

“The developers of software systems in each of the four communities seek to keep their systems open through provision of a variety of extension mechanisms and architectures. These are more than just open application program interfaces (APIs); generally they represent operational mechanisms or capabilities.”(Scacchi 2002)

Advantages