Category: Open Source

Philosophy Videos

From CUNY Academic Commons



       An annotated list of videos for use with the instruction of Philosophy




Business Ethics

Medical Ethics

Computer Ethics

Logic — Informal

Logic — Formal


Philosophy of Art

Philosophy of Education

Philosophy of Religion

Political Philosophy

Social Philosophy



From CUNY Academic Commons


The Drupal Open Source Project was started in 2001, and has a large community surrounding it.

Drupal Logo

‘Drupal’ comes from the Dutch word “druppel” or water droplet. (Legend has it that the project was originally going to be named 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.

Sample sites using Drupal


Open Journal Systems

From CUNY Academic Commons



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.


Related Links

  • The OJS Site on the Public Knowledge Project’s Website provides both practical and technical information about Open Journal Systems. Here you may download the product, or simply do some investigation. A sample journal is provided so you can take a test-drive.

Related Pages


LAMP Application

From CUNY Academic Commons

Photo courtesty of FHKE (Flickr), Creative Commons



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.

Evaluating Open Source Solutions

From CUNY Academic Commons



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.

Impressions and Concerns about Implementation

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.

Economics of Open Source

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.

In House Support

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).

Gauging an Organization’s Specific Needs and Capabilities

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).


  • Rafiq, Muhammad. (2009). LIS community’s perceptions towards open source software adoption in libraries. International Information & Library Review, 41(3), 137-145.
  • Trappler, Thomas J. (2009). Is There Such a Thing as Free Software? The Pros and Cons of Open-Source Software. EDUCAUSE Quarterly, 32(2), 10 pp.
  • Ven, K., Verelst, J., & Mannaert, H. (2008). Should you adopt open source software? IEEE Software, 25(3), 54-59. doi:Article

Related Pages

Open Source – Digital Libraries

From CUNY Academic Commons



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.

Comparing Digital Library Packages

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.

Omeka Case Study

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.


Related Pages

Open Source – Defect Tracking and Resolution

From CUNY Academic Commons



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.

Studies on Bugs and their Fixes

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).


  • Ahmed, F. et al. (2009). Defects in open source software: The role of online forums. Proceedings of World Academy of Science: Engineering & Technology, 40, 174-178.

Related Pages

Open Source – Demographics

From CUNY Academic Commons



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.

Demographics and Motivation in Open Source Communities

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).


Related Pages

Open Source Movement

From CUNY Academic Commons



Three acronyms,
(Open Source Software),
(Free Software Movement) and
(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

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).

Roots of the Open Source Movement

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).

Open Access Initiative

Logo courtesy of OAI

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).
(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).

OSI’s Ten Criteria for Open Source

In its website, the OSI lists ten criteria which software must comply in order to be considered open source. These are:

  1. “Free Redistribution” – no restrictions on the sale or sharing can be stipulated in the license;
  2. “Source Code” – the source code must be included so that everyone can read and modify it;
  3. “Derived Works” – any modifications to the source code can be distributed under the same terms of the license;
  4. “Integrity of The Author’s Source Code” – a license may be constructed to restrict modifications only if it “allows the distribution of ‘patch files’ with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code.” Also, a license may require that the modified versions be named differently from the original;
  5. “No Discrimination Against Persons or Groups” – license cannot discriminate;
  6. “No Discrimination Against Fields of Endeavor” – license cannot restrict the use of the software to a certain field;
  7. “Distribution of License” – additional licenses are not necessary when the program is redistributed;
  8. “License Must Not Be Specific to a Product” – if the program is part of a larger distribution, the license should guarantee the right to extract and use as desired;
  9. “License Must Not Restrict Other Software” – license cannot “insist that all other programs distributed on the same medium must be open-source software”; and
  10. “License Must Be Technology-Neutral” – license cannot require that the software be used with a specific technology (The Open Source Definition, n.d., para. 1-10).

Open Source Development Model

Logo courtesy of LibrePlanet

(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.

The Open Source Community

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). 


Related Pages

  • Freedom in the Cloud – cited by Matt Gold in Why I Left Facebook, from his The Lapland Chronicles Blog.