An annotated list of videos for use with the instruction of Philosophy
| Aesthetics
Epistemology Ethics Business Ethics Computer Ethics Logic — Informal Logic — Formal Metaphysics Philosophy of Art Philosophy of Education Philosophy of Religion Political Philosophy Social Philosophy |
The Drupal Open Source Project was started in 2001, and has a large community surrounding it.
‘Drupal’ comes from the Dutch word “druppel” or water droplet. (Legend has it that the project was originally going to be named drop.org but a typo in the domain application form (“dorp”) led to its final, more appealing name.)
Drupal is immensely popular, and is downloaded over a million times each year. Follow this link to see who is using Drupal.
Contents |
Open Journal Systems (OJS) is an open source “journal management and publishing system” developed by the federally funded Public Knowledge Project. Other PKP projects include Open Conference Systems (OCS), Open Monograph Press (OMP), and Open Harvester Systems (OHS).
OJS provides support for the various phases of publishing an on-line journal, including submission and peer review, publication, indexing and archiving. The software is customizable – follow this link for some screenshots of existing journals using OJS.
Contents |
LAMP is an acronym standing for Linux, Apache, MySQL, and PHP. Examples of LAMP applications include: WordPress, MediaWiki, Omeka, etc.
The acronym has several permutations, including WAMP (Windows instead of Linux) and MAMP (Mac instead of Linux). To install the PHP, Apache, and MySQL package on your computer, follow these links:
An open source operating system very similar to UNIX. The GNU project, begun in 1983, by Richard Stallman, lead to the creation of Linux, and is widely believed to have started the Open Source Movement.
An open source HTTP Web server, capable of running locally (i.e. on your Mac or PC) and on a server.
An open source, relational database which organizes data into tables and uses a standard query language (SQL) to access it.
A common server-side scripting language which uses SQL to access database rows, convert into objects, manipulate them, and dynamically generate HTML on the client machine.
Contents |
How to choose whether an open source solution is right for your institution. Listed below are studies that tackle this question, and provide a framework for evaluation.
Rafiq (2007) conducted an international study to measure the LIS community’s perception of OSS adoption in libraries. He distributed his online questionnaire via international library discussion groups and listsrvs. He found that his respondents (68% from developing countries) were in general, positive about OSS in libraries. Concerns were mainly related to support, documentation, and implementation difficulty for library staff.
Writing for Educause, Trappler (2009) is also cautious about OSS, noting that this option can provide a “viable alternative,” though it does not always save money or resources (para 1). He warns educators to be aware of the licensing agreements, and read them as carefully as a proprietary software license.
Trappler warns that the complexities of some OSS may require “in-house support,” and that it is not a “panacea” (para. 16). One advantage he notes is that it is much easier to try out OSS than proprietary software, and he encourages educators to always include OSS bids to expand competition with proprietary vendors.
According to Trappler, evaluating the “features, functions and maturity levels” of OSS products is vital to the selection process. If an OSS solution is chosen, an institution can benefit by becoming part of an OSS community, and sharing support functions. When “appropriately managed” OSS can be more effective and less costly than proprietary software (para 30-35).
Ven, Verelst & Manaert (2008) echo Trappler’s cautions. Targeting ten Belgian organizations which had adopted OSS, their study recorded and analyzed face-to-face interviews with key employees. Points discussed were cost advantages, source code, maturity, vendor lock-in, and external support. The authors conclude that organizations should not base their decisions to adopt OSS on what other organizations are doing or the “claims in the literature.” Rather, decisions should be made according to the specific needs and capabilities of the organization (p.58-59).
Contents |
There are several studies that focus specifically on open source digital library software, and it is important to see if this subset of OSS has any specific evaluation concerns.
Goh et al. (2006) conducted a comparative study of four OSS digital library packages and compiled a checklist to evaluate such programs. The framework they developed breaks down the products into five criteria for evaluation: (1) content management; (2) user interface; (3) User administration; (4) system adminstraction; and (5) other requirements. Each of these major sections is further broken down into features, and each evaluator checks a box if the feature is available. Scores are weighted and tallied and then compared.
The recently published case study by Kucsma et al. (2010) investigates Omeka as a web publishing tool. The authors worked on a project for METRO whose goal was to build a directory of 30 digital collections. Three different digital collection management systems were considered: WordPress, Omeka, and Content DM. Omeka was chosen because it was attractive, easy to install, extensible, and was compatible with web and OAI-PMH standards. (p. 1). While METRO has a long history with ContentDM, the product was not selected because, as the author write, it lacks many of the “characteristics of a modern digital exhibition tool” (p.2). WordPress was not chosen because of its lack of collection building tools and they was not enough time to write a plug-in. The authors provide a good synopsis of Omeka’s functionality and describe the plugins they employed in the process. In general they liked their experience building this collection of collections with Omeka. The weaknesses were primarily with Omeka’s administrative functions. The authors found the “Item Add” function clumsy and time consuming and complained about the lack of support for controlled vocabulary in tag fields. They admitted that these were fixable, but would hesitate using Omeka for a large scale project before the issues were addressed. Search and retrieval functions were found to be weak, by library standards. In general, they found Omeka’s control over data to be “loose.” (p. 8). They also found that documentation of the core processes had lagged behind. The incomplete Codex was felt to be slowed down development of new plugins. Of the many strengths, the authors point out Omeka’s exhibit building ease.
Contents |
The Open Source development cycle tends to be quite different from the proprietary model. Software is developed faster, and defects are tracked by the community. Developers work together to find resolutions and address needed enhancements. The studies below describe the process.
According to Ahmed et al. (2009), OSS does not follow proprietary vendors’ “traditional life cycle of software development,” and in general delivers software more quickly and depends on user involvement in “bug/defect detection.” (p. 175). Discounting concerns about the quality of OSS, the authors use statistical analysis to conclude that the OSS community’s use of group forums is more effective when it comes to tracking and resolving software defects than are propriety vendors’ use of maintenance teams. This empirical study of 619 group forums and project defect tracking systems found a positive correlation between group forum messages and defect resolution. The authors conclude that in an OSS project, “defects are not simply accepted” but rather the project’s “support network” collaboratively works to quickly resolve them. (p. 177). Closed software has a more traditional method of managing its software, and its “profit oriented vendors” generally assign maintenance teams to support maintenance releases (p. 174), while OSS has a “well-defined community with common interests” who in general contribute without “being employed, paid, or recruited.” The authors assert that by having many interested developers working on a common project, the quality of the software is greatly improved and defects are resolved faster. (p. 174).
Contents |
This page reviews some interesting studies on Open Source demographics which provide insight into the make up of the community, as well as motivational factors which hold it together.
One question which von Krogh & von Hippel (2003) try to answer is why so many excellent developers contribute so freely to open source development. Their introductory article to Research Policy’s special edition on Open Source compiles a succinct review of four articles which concern the motivations of open source contributors (p. 6). Other more recent studies seem to bear out the findings von Krogh & von Hippel summarize.
Maas’ case study (2009) focuses on determining the factors that motivate members of OSS communities to collaborate. He chose the Apache Cocoon open source development community because it was an established group of around 60 active developers who do a variety of work, including development, bug patches, and documentation. He used an online survey with 42 questions designed to reveal both demographical and motivational information about the community’s members (p. 66). The average age was found to be 31.2 years. Mass divided the workers into two distinct clusters – those 37 years or older with many years of technology experience, and those from 19-31 years old, with less experience. He found the first group less anxious to learn new technologies, but more actively involved in the project’s day to day work. The younger members he found more interested in watching what is being done, and learning how to do it. This group was comparatively more interested in new technologies and “self-realization” (p. 68).”
The questionnaire revealed that on average, each developer works 3.1 hours a week on the project, and a surprisingly high percentage (74%) are paid by their regular jobs to participate. A common characteristic of both groups was resistance to bureaucracy, which members find a “distraction” from software development (p. 67). Maas concludes that a mature OSS project is able to attract highly trained experts in the field. Though members of Apache Cocoon project tend to work alone or with only a couple other developers, they have a great deal of trust in the skills of their peers, whom they expect to be highly skilled and altruistic (p. 69).
In their survey analysis, Lakhani & Wolf (2003) find that developers simply enjoy working on OSS projects, and while the experience may help further their careers, it is primarily the creative and intellectual stimulation which drives them to participate (p. 3). The authors provide a fine literature review on intrinsic and extrinsic motivations (p 4-8). One interesting piece of data from the survey reveals that 87% of the respondents did not get paid directly for their work, and yet 55% reporting working on the project during their regular jobs. Of these, more than half indicated supervisor awareness, and “tacit or explicit consent” (p. 9).
Contents |
Three acronyms,
OSS
(Open Source Software),
FSM
(Free Software Movement) and
FOSS
(Free Open Source Software), and the term “
software libre
,” have been used to describe the open source software movement, which is widely believed to have started in 1983 when Richard Stallman
founded the GNU Project and formulated and implemented his “GNU Public License” that defined the rights of users to review source code, make changes to it, and redistribute it, either in the original or modified versions, at no cost (von Krogh & von Hippel, 2003, p. 3). In 1985, Stallman created the
Free Software Foundation
, and he is still the acting president of this “copy-left” movement set up to protect the rights of software users. (Stallman, 1983, para. 1-4).
| But as von Krogh & von Hippel (2003) note, the OSS movement had earlier roots. The “communal hacker culture” of the 1960s and 1970s, especially prevalent around MIT and in ARPANET, was based on the free exchange of software. Stallman was a part of this culture, and when he saw proprietary software packages starting to be developed, he found it “morally” wrong (p. 4). The term he used was “software hoarding.” (Williams, 2002). |
In contrast to FSF, the
Open Source Initiative
(OSI) was founded in 1998, and differs from FSF in that it is less political and confrontational, and focuses instead on the superiority of open source software. (
History of the OSI
, para. 16-18). While the two groups have similar goals and work together on many projects, OSI focuses on the “practical benefits” of the various licensing agreements that have subsequently evolved (von Krogh & von Hippel, 2003, p. 4).
O’Reilly
(1999) notes how this has lead to many different offshoots, including some that might be “anathema” to members of FSF, such as the “gated open-source community” model, which licenses out software rights only to its large (paying) user base, and reaps benefits from it users’ modifications, documentation and defect resolution. Another model is to freely distribute source code, and allow modifications and redistribution for noncommercial use, but when used commercially, a different license is required. This is the model which Sun’s Java project follows (p. 36).
In its website, the OSI lists ten criteria which software must comply in order to be considered open source. These are:
As
O’Reilly
(1999) notes, giving programmers access to source code and the right to create derivations allows them “to help themselves, and encourages natural product evolution as well as preplanned product design.” He sees this methodology as clearly superior when creating customized software (p. 34). Coders are encouraged to look under the hood, find bugs and fix them. They are invited to add on to the code, create extensions or plug-ins, or take the code base and re-tool it into something new.
| OSS is thoroughly dependent upon a development community. The “key determinants of a project’s success” is not the product itself, but rather the support of the user community. The project must attract a “passionate core of users” who are anxious to expand and extend it, and who are willing to devote their time and energy, often with little or no financial compensation. The “glue” that holds a development community together is cooperation rather than money (O’Reilly, 1999, p.36-37). |
