Archive for February, 2009

Article Summary #4: Pfaffman – Transforming High School Classrooms with Free/ Open Source Software

February 25, 2009

Pfaffman, J.  Transforming High School Classrooms with Free/ Open Source Software:  It’s time for an open source software revolution.  (2008).  High School Journal, 91(3) 25-31.  Retrieved December 10, 2008 from the WilsonSelectPlus database.  (Also available at


Pfaffman argues that open source (OS) software can meet many educational needs, particularly in the science classroom.  Despite the quality and availability of OS applications, many educators are unaware of the meaningful role that OS can play in the classroom.  He also argues that the OS development model parallels the development of scientific knowledge.

Pfaffman offers several reasons why teachers do not more readily adopt OS solutions.  Some teachers do not know about OS software, while others think that using OS software without paying for it is stealing.  Pfaffman summarizes the confusion about licenses:

Understanding a license that forbids restrictions on redistribution is difficult to understand when most software is distributed with a license forbidding redistribution.  (p. 26)

Open source software is about much more than money, and Pfaffman describes these benefits in a straightforward manner.  He points out that free speech benefits everyone, not just reporters, and in a similar way open software benefits everyone, not just programmers.

Most of Pfaffman’s arguments focus on the strengths of OS software, but he describes one particular complaint about proprietary software in schools.  When a school chooses to use a piece of proprietary software in the classroom, it turns teachers into “unwitting sales agents” (p. 27) for software companies.

For example, when teachers require students to turn in assignments using a proprietary file format like Microsoft Word’s, this implicitly suggests that in order to be a successful student one must buy, know, use, a particular software program.  (p. 27)

He goes on to say that the use of proprietary software in schools adds value to the software.  Thus, educational discounts are more marketing investment than corporate altruism.

Significant parallels can be drawn between the OS community and the scientific community.  Both communities work to build a collection of shared knowledge, and people in both fields strive to have their work adopted by their respective communities.  Significant advances in both fields are made by amateurs, usually when they are connected to a network of supportive peers.  For example, in OS it is said that ‘Given enough eyes, all bugs are shallow.’  In astronomy we might say, ‘Given enough eyes, all astronomical events are observable.’  Pfaffman is trying to help science teachers see a connection between their field and the OS community, and he is also arguing that exposing our students to OS software deepens their understanding of how science is carried out.

Pfaffman makes a number of general observations about educational technology, and then argues that OS can offer ways to address these issues.  He points out that we have not yet convincingly established a direct connection between computers and educational achievement.  He cites several studies which show marginal differences in achievement when computers are used with students.  The critical factors, he says, are a minimum level of access that must be attained for computers to make a difference, and a coincident rethinking of pedagogical strategies to make sure that technology serves curricular goals.  Pfaffman argues that the simplicity, affordability, and reliability of OS systems can allow districts to more easily manage larger numbers of computers, which increases the resources available for technology-related professional development.

Pfaffman describes two ways to adopt OS solutions in education, the first of which is to adopt entirely open systems.  This usually means a Linux operating system and a set of open applications.  He describes the thin client model and suggests that this approach increases the longevity of existing hardware, and requires fewer full systems.  This is based on an efficient use of processing power, and simplifies configuration and maintenance issues.  Pfaffman also describes the OpenOffice suite, and points out that many people are so accustomed to thinking of Word as the word processor that they are unaware of the existence of other, equally capable word processors.  “Many people are unaware that each of these programs is merely an instantiation of a particular class of programs” (p. 29).

A number of interesting science-specific programs are described.  Kalzium is one.  The OpenScience Project has developed two tools, JMOL and Jchempaint, which model molecules in 2D and 3D.  Pfaffman also describes the Physics Education Technology (PhET) project, which is a set of about 50 physics simulations.  There are also several astronomy-related projects such as Stellarium and Celestia.  Freemind is mentioned as a concept mapping tool.

In closing, Pfaffman argues that using OS software on a regular basis will improve our ability to meet students’ educational needs, and also help them think more critically about the software they use.

Evaluation and Educational Relevance

This article will become an anchor text in my work involving OS in education.  Pfaffman speaks insightfully and directly about the core issues that classroom implementations of OS solutions deal with.  He mentions a variety of resources and projects that seem worthy of further investigation, and cites recent research.  Peer-reviewed research relating to open source in education is a burgeoning field, and these leads are valuable.


The following resources and projects mentioned in Pfaffman’s article seem worthy of further research:

  • Stardust@home project (p. 28) – A project which trains amateurs to help scan comet dust for remnants of old stars.
  • GalaxyZoo – Trains users to recognize galaxies, with the goal of classifying one million galaxies collectively.
  • Conduct a study on OS in education and submit to peer-reviewed and popular journals, to increase the visibility of educational OS solutions
  • Edubuntu
  • K12 Linux Terminal Server Project (K12LTSP) – thin client model
  • OpenScience Project, JMOL, Jchempaint
  • Physics Education Technology project (PhET)
  • Stellarium, Celestia, KStars
  • Freemind
  • Articles
    • Becker, H.J.  (2000).  Findings from the teaching, learning, and computing survey:  Is Larry Cuban right?  Educational Policy Analysis Archives, 8 (51).
    • British Educational Communications and Technology Agency (BECTA).  (2005).  Open source software in schools:  A study of the spectrum of use and related ICT infrastructure costs.  Coventry, UK:  BECTA.
    • Considering changing your school’s computer system to open source software?  one school’s conversion to Linux has been a complete success.  (2003).  Canada’s SchoolNet.
    • Cuban, L.  (2001).  Oversold and underused:  Computers in the classroom.  Cambridge:  Harvard University Press.
    • Dynarski, M. Agodini, R., Heaviside, S., Novak, T., Cary, N., Campuzano, L., et al.  (2007).  Effectiveness of reading and mathematics software products:  Findings from the first student cohort (Tech. Rep.).  Washington, D.C.:  U.S. Department of Education, Institute of Education Sciences.
    • Migrating to 90 per cent cheaper than to Microsoft Office 12.  2005.  Computerworld, 11(23).
    • Perkins, K., Adams, W.  Dubson, M., Finkelstein, N., Reid, S., Wieman, C.  2006.  Phet:  Interactive simulations for teaching and learning physics.  The Physics Teacher, 44, 18.
    • Pfaffman (2007).  Transforming Instruction without Training:  A Case Study of the K12 Linux Terminal Server Project.  Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2007.  363-366.
    • Sandholtz, J. and Reilly, Brian.  (2004).  Teachers, Not Technicians:  Rethinking Technical Expectations for Teachers.  Teachers College Record, 106(3), 487-512.

Book Review #2: Raymond – The Cathedral & The Bazaar

February 23, 2009


The Cathedral and the Bazaar by Eric Raymond is an examination of the culture behind the Open Source (OS) movement. In the 1970’s Brooks Law was developed, which stated that adding more developers to a late project only makes the project later. Before Linux was proven successful, it was unfathomable to most software industry insiders that such a large number of volunteer developers could produce a complex, reliable piece of software like an operating system. From his position inside the OS movement, Raymond set out to identify the specific reasons that the OS community was able to organize itself well enough to develop software that was more reliable than that of tightly-controlled corporate software development divisions.

Raymond describes the OS community as a “gift culture” (p. 80). In a gift culture, status is earned not by accumulation of wealth or strength, but by how much is given away. How much a programmer is able to give away also depends on the skills they have developed, their ability to solve problems creatively, and their ability to work collaboratively with others.

The difficulty of expressing emotions accurately over the internet has led to a respect for humility within the OS community. Boasting is frowned upon, in favor of allowing individuals’ work to speak for itself. A programmer who works steadily at mundane but necessary tasks, while occasionally throwing in a flash of creativity, earns more respect than the originator of a significant project who then brags about it.

There are a number of specific concepts that make the OS community effective. One adage is “Given enough eyeballs, all bugs are shallow” (p. 30). Bugs in complex applications can be subtle and nondeterministic. The OS community has attracted a large number of users who are also able to describe bugs in a way that is helpful to the core developers. A user may report “The program closed unexpectedly when I opened a jpeg file, and it seems to relate to a file type declaration at line x in source file y”. A developer can fix this much more quickly than a developer on a closed source project who only hears from a user, “The program closed unexpectedly when I opened a jpeg file.” Also, a difficult bug might be easy for 3 in 1000 developers; having a large number of developers makes it more likely that someone on the development team will know how to fix each bug that comes along. It might not always be the same developer who fixes all the difficult bugs, but these bugs will likely match someone’s skill set.

Raymond lists five conditions for deciding whether an open source solution may be developed for a given situation:

  1. Reliability/ stability/ scalability are critical.
  2. Correctness of design and implementation cannot readily be verified by means other than independent peer review.
  3. The software is critical to the user’s control of his/ her business.
  4. The software establishes or enables a common computing and communications infrastructure.
  5. Key methods (or functional equivalents of them) are part of common engineering knowledge. (p. 146)

These criteria provide a solid framework for evaluating whether to keep a piece of software closed or make it open, and for deciding whether it is reasonable to pay for a piece of closed source software or whether funding an OS solution might be better.

Educational Relevance

First of all, reading The Cathedral and the Bazaar makes me want to program again! As a competent programmer who will never work full-time as a developer, the OS community is perfect for me. I can contribute meaningfully to an existing project based on my skill set, or I can develop a project and let others more proficient in certain aspects of programming polish the project. This is a great context in which to apply my strengths, a deep understanding of educational issues and a competent understanding of software development.

While enjoying the cultural and historical parts of the book, the list of criteria mentioned above is one of the most significant pieces I will take away from this reading. Let’s apply this reasoning to the problem of managing student data at the class, school, and district level. What we want is a reliable, customizable, secure database program that will allow us to track student learning. In Sitka, this is currently handled by Schoolmaster. Schoolmaster is a proprietary program, and districts pay for software licenses and support contracts to use it. The educational problem that Schoolmaster addresses, how to handle student data, meets all the criteria for an OS solution. The reliability, stability, and security of a program that handles sensitive student data is critical. With such a large program and a large number of users, it seems difficult for a small development team to iron out all bugs before a major release. The proper handling of data is critical for day-to-day educational functioning. New York City famously sent thousands of students to summer school unnecessarily one year due to an incorrect electronic scoring system on a city-wide benchmark exam. A common communication structure in the handling of student data would ease the transitions of students between school districts, even between vastly different parts of the country. Finally, it is doubtful that the ways SchoolMaster addresses the problem of managing student data is so profound that they are the only ones able to engineer an effective solution to the problem.

How do we make an OS solution to the problem of managing student data at various levels? This is a perfect situation for Richard Stallman’s proposed ‘software tax’. A federally-sponsored development project would allow schools to spend their money on tech support people rather than on a Schoolmaster contract. These people would be able to handle the administration of an OS student data management system in much the same way that server technicians administer Apache. But rather than be limited to supporting just Schoolmaster-related tasks, they would also be able to contribute to supporting other technical solutions in the district as well. None of this would necessarily put SchoolMaster out of business. If they accept the open solution, their people are in a position to develop expertise in the new system quickly. If Schoolmaster fights the OS solution, they run the serious risk of serving a dwindling user base. At some point, Raymond argues, it becomes quite feasible that the MIS person for a publicly traded company becomes liable when their company becomes overly dependent on a proprietary solution that is critical to fundamental operations. In a similar manner, district decision makers will not be looked upon favorably if their choice of a proprietary data management causes the district to become overly dependent on one company’s solution. Raymond also points out that it is critical for businesses to realize when it is right to open up their own software solutions. Open up too early, and competitive advantage is given away before a strong market position can be established. Open up too late, and your market position is taken over by an OS solution provider.

The OS community thrived in early academic computing. It sputtered when software companies threw gobs of money at star developers in the university labs in the 70s and 80s. The community regrouped in spectacular form in the 90s to develop Linux. This success has not yet been realized in education. Open source educational technology is a field ripe for fresh thinking, thinking that applies the ideas that led to the success of Linux to technological solutions in education.

Open Source Interview Questions

February 20, 2009

I will interview our district technology coordinator on Monday.  These are the guiding questions I am planning to use.

  1. What is your job?  What is your background?
  2. What familiarity do you have with open source (OS)?
    1. How do you use OS personally?
    2. What have you learned about the OS community and how it works?
    3. How do you use OS professionally?
  3. What educational problems (administrative, teacher, and student-focused) does OS currently provide effective solutions for?
  4. Let’s consider a program like Schoolmaster.  In The Cathedral and the Bazaar, Eric Raymond lists five criteria that indicate a piece of software should be open:
    1. Reliability, stability, and scalability are critical;
    2. Correctness of design and implementation cannot be readily verified by means other than independent peer review;
    3. The software is critical to the user’s control of his/ her business;
    4. The software establishes a common computing and communications infrastructure;
    5. Key methods (or functional equivalents of them) are part of common engineering knowledge.
      If we think about the educational issues that Schoolmaster addresses, should a program like this remain closed-source, or should an OS solution be developed?
  5. If most educational software were OS, how would your job change?  Would this be a change for the better, or for the worse?
  6. One of the fears people have if the school district were to replace its computer fleet with an OS-based system is that students would be less prepared for the job market than their peers who have access to proprietary software at school.  Is this a realistic fear?
  7. In 10 years, what changes do you see for the use of technology in schools?  Specifically, do you see the same dependence on proprietary solutions that we currently see?
  8. What is your favorite tech toy?

Software Review #2: jMemorize

February 18, 2009

Brief Description
jMemorize is a flashcard-based learning program.  The user creates a set of flashcards, and the program sets up an optimal review schedule based on the Leitner system.


  • The program manages learning in a way that emphasizes the cards that need the most attention, while steadily reinforcing other cards.
  • Any content can be placed on the cards.
  • The system can easily be replicated on paper.
  • Statistics are shown to indicate the number of cards that have been learned, the number that remain unlearned, and the number that have become expired.


Platform independent; requires a java runtime environment.

The Leitner system is a simple but effective way to use flashcards efficiently.  The system works like this:

Leitner system

Leitner system

  • Label four envelopes with the numbers 1 through 4.
  • On day 1, run through the entire stack of flashcards.  Every card you get right goes into envelope 2.  Every card you get wrong goes into envelope 1.
  • On days 2 and 3, run through the stack of cards in envelope 1, always placing cards that you get right into envelope 2.
  • On day 4, run through the stack of cards in envelope 2.  Every card you get right goes into envelope 3.  Every card you get wrong goes back to envelope 1.
  • On day 5, run through the stack of cards in envelope 3.  You will probably get most of these right.  If you do, they go into envelope 4.  If you get any wrong, they go back to envelope 1.
  • On day 6, repeat the cycle starting with envelope 1 for the next 3 days.
  • By the time most cards have made their way to envelope 4, you have probably learned the material contained in the card set pretty well.

jMemorize allows the creation of a set of flashcards, and then manages the presentation of cards according to the Leitner system.  The program uses additional logic to enhance the system, for example by expiring cards if they have not been reviewed in a given period of time.

The interface is quite simple.  Once a set of cards has been created, it is simple to add a new card.  When it is time to review the cards, you can choose whether to see the entire card set or only the cards that have not yet been learned.  A constantly-updated bar chart shows how many cards have been learned, how many remain unlearned, and how many have expired.

Create Card screen

Create Card screen

This program requires honesty.  The user does not enter an answer for each card when reviewing.  Instead, the user is asked to click whether their answer was correct or incorrect after each answer is shown.

I was amazed to find this piece of software and learn about the Leitner system for the first time.  I have often seen students who have been given a set of flash cards to study, with no explicit instruction on how to work their way through them.  I have started to use the system with several students now, and I will continue to share the strategy with other teachers.  This is much different than the over-simplified advice to “make two piles, one of cards you know and one of cards you’re working on.”

jMemorize is an effective piece of software for motivated learners.  Many language-learning programs are a polished version of this, with specific content pre-loaded.  This software can serve the needs of older, self-directed learners.  For example, the program could be very helpful in an AP Biology class that requires a significant amount of memorizing.  Card sets can be exported with or without their associated learning history, so a class project to build a card set could be carried out in a straightforward manner.  This set could then be given to subsequent classes at the beginning of a semester.  A wiki at the jMemorize web site has a small collection of card sets, and I imagine it would be fairly straightforward to have a set such as this added to the collection.

This is a piece of software I will return to when I teach a high-level class that requires a significant amount of memorization.  In the mean time, I will use the Leitner system with younger students who are struggling to memorize their multiplication facts.

Article Summary #3: Sun Microsystems – Free and Open Source Licensing

February 17, 2009

Sun Microsystems.  Free and Open Source Licensing.  (December 2006).  Retrieved January 29, 2009, from


Sun Microsystems is a for-profit company which has done significant work in support of the open source (OS) community.  Sun is involved in many OS projects, and one of their white papers aims to make sense of the growing array of OS licenses that developers can choose from.  The Open Source Initiative (OSI) was created to steward a common definition of open source, and one of its main activities is to evaluate new OS licenses.  As of 2006, OSI had approved almost 60 different licenses.  Sun supports efforts to simplify the OS licensing decision making process, and this paper supports simplification by helping elucidate the similarities and differences between the various licenses.  In this paper, Sun argues that an OS license should be chosen based on the kind of developer community that will be built around the project.

In categorizing the different OS licenses, Sun examines the impact each license has on the development community.  OS licenses have an important effect on others by controlling what can be done with the open software.  Sun considers three aspects of the development community, and examines what it calls the “virtuous cycle” that develops between them.  These three aspects are the Source Code Commons, the Developer Community, and the Software Works themselves.  The strictest licenses create continuous interaction between all three parts of this cycle.  Less strict licenses allow developers to leave the cycle at various points.

Three categories of OS licenses are identified.  Category A licenses are the least restrictive.  These licenses, such as the Berkeley Software Distribution (BSD) and Apache Version 2 licenses, allow developers to do just about anything they want with the software.  There is no limit placed on derivative works; they may be released under whatever license the developer wishes.  Sun calls these “market-creating” licenses because new markets can be created around software released under category A licenses.  These licenses give developers the most control, but do not require developers to give anything back to the commons.

Category B licenses also allow developers significant freedom, with a requirement to contribute back to the commons in some way.  Any new code bundled with code under a category B license, which is then combined into a single binary file, must carry the same license as the code from the commons.  Any other files packaged with the same project have no such licensing requirements.  The Mozilla Public License (MPL), GNU Lesser General Public License (LGPL) and Sun’s Community Development and Distribution License (CDDL) exemplify category B licenses.  These licenses balance the desire to give developers freedom to create new works based on OS code, with the need to continue giving back in part to the source code commons.  Sun calls these “community-fostering” copyleft licenses.

Category C licenses are the most strict, and provide the most protection for the end user.  When a developer uses source code carrying a type C license, all code in the project must then carry that same license.  This is exemplified by the GNU General Public License (GPL).  These are strong-copyleft licenses, which Sun calls “project-based”.

While offering a disclaimer that it is not providing legal advice, Sun offers some guidance on how to choose an OS license:
“The key to making decisions about open source licensing for software development is to understand what kind of community is desired and then to move in the direction of the licensing that is most likely to promote that type of community.”

Sun does not advocate for the use of any particular license, but rather “takes a license-neutral, context-based approach to free and open source licensing” (chap. 6).  The paper does state, however, that Sun is moving away from using category A licenses, and tending to favor category B and C licenses.  Sun’s work “favors strength within the community and a culture of contribution to a source code commons” (chap. 6).  One final quote shows Sun’s apparent enthusiasm for category B licenses:
“Category B licenses have the capacity to hold in balance the ability to attract a variety of interest to a community with the strength and longevity of a source code commons.  They allow developers to create software inventions based upon the commons and license them as they see fit, but at the same time they compel developers to improve the commons from which their works are derived: any changes to the commons itself must be returned” (chap. 4).

Educational Relevance

Educational software developers may be tempted to give only brief thought to the particular choice of an OS license, once the decision has been made to go with open source.  However, the choice of license has significant impact on such issues as who will use the code and software, for what purposes it may be used, longevity, and other considerations.  The desire to earn some money, whether a modest or extravagant amount, and the opposite desire to make software completely open, can blind developers to more subtle community-building issues that are described in this paper.

Consider a simple piece of educational software, such as a program that assists in memorization.  Users can input questions and answers, and then run through those questions in various orders and study modes.  The program tracks which questions are being learned effectively, and gives growing emphasis to the more difficult questions while steadily reinforcing the learned pieces.  Should the software be released under a category A, B, or C license?

Release under a category A license would allow a textbook company to use the software to support their particular textbooks, and perhaps profit from sales of the software itself.  Any improvement the company makes to the software would not necessarily make its way back to the original software.  Release under a category B license would allow this same use by textbook companies, but it would require those companies to make publicly available any improvements they make to the original software.  This would free other textbook manufacturers to bundle the same software with their textbooks, thus enhancing the effectiveness of all textbooks.  In this manner, the program itself evolves every time a company chooses to develop it further.  Complementing these benefits to the source commons is the right companies have to bundle the program in a proprietary project specific to their line of textbooks.

A category C license would require that any software developed by the textbook company, packaged with the memorization software, would have to be released under the same license.  This seems good in that it requires any related software to be open-source as well, but it may simply make textbook manufacturers avoid the software in the first place.  Limiting the amount of use the software sees may relegate it to a life of obscurity, regardless of the quality and usefulness of the software itself.  Choosing a strict OS license makes the program and all of its derivative works publicly available, but it does not necessarily make the program better or more attractive to potential users.

If the open source educational software community becomes more established, category C licenses might be an easier choice.  I do not like the thought of companies running commercially with open source educational software and returning nothing to the commons, so category A licenses seem to be an easy non-choice.  Given the present state of open source educational software, I would lean toward using category B licenses to leverage the interest of educational companies until a larger body of high-quality, high-visibility software is available.


  • OSI issued a document called the Report of License Proliferation Committee and draft FAQ in 2006.  This document enumerated the problems associated with license proliferation, and recommended steps to improve the situation.  Among those steps were to identify a set of “recommended” licenses, and a set of “redundant” licenses.  This helps developers look at a small set of widely-used licenses which are developing a common interpretive framework.  Most developers will find a license that suits their needs in this small set, and there should be fewer new licenses created.
  • At some point, a closer examination of category B licenses would be meaningful.
  • For now, this is enough of an examination of licensing issues.  The next articles will focus specifically on the ways that OS solutions have been applied to education.