Article Summary #7: Byfield – Expert Shares Secrets to Saving Thousands with K12LTSP

April 15, 2009

Byfield, B.  (2007).  Expert shares secrets to saving thousands with K12LTSP.  <http://www.linux.com/feature/59614>

This is a short article, but one that clarifies some things I have been reading about regarding the K12LTSP.  It also raises a number of issues I have not read elsewhere.

Summary

Robert Arkiletian is a contributor to the K12 Linux Terminal Server Project (K12LTSP).  The K12LTSP is a Linux distribution that allows one standard desktop computer to run a number of other computers as thin clients.  The clients can be older computers, which don’t even need a functioning hard drive.  Depending on the specifications of the computer which acts as a server, 5-30 or more clients can run off of a single computer.  This setup is familiar to system administrators, but the drive of the K12LTSP is to make this setup simple enough for non-technical teachers to administer.

The K12LTSP site lists a set of minimum requirements for the computer acting as a server.  With three years’ experience administering a lab with 30 clients, Arkiletian recommends a more powerful set of capabilities:

  • A dual processor so that runaway processes can be stopped immediately and dealt with at a later time.  This allows the classroom teacher to maintain a functioning network without significantly interrupting the class.
  • Two hard drives which “mirror each other in a RAID 1 array” (p. 1).
  • 100MB of RAM per client.  This number is interesting, because it is a familiar specification to most teachers.  This suggests that a standard teacher’s desktop computer with 1GB of RAM might be capable of running 10 clients.
  • Two ethernet cards.  One creates a private network for the clients, and one connects to the rest of the network.

For client machines, specifications are significantly lower.  However, some features can make the client more responsive to student needs.

  • Processor speed is unimportant.  Arkletian says that anything less than 100Mhz may cause problems, but a computer would have to be around ten years old to have a processor that slow now.
  • A 4MB video card should be sufficient.
  • 128MB of RAM is recommended, to prevent over-reliance on swapping with the server’s hard drive.
  • A light window manager such as IceWM rather than GNOME or KDE can also allow more efficient use of client and server resources.
  • An ethernet card is needed to connect to the server.
  • A USB port allows students to use memory sticks, and presumably external devices like digital cameras.

One of the primary goals of the K12LTSP is to make system administration responsive to teachers’ needs.  These include technical needs such as simplicity and reliability, and pedagogical needs such as the ability to easily monitor students’ work on the computers.  The Fl_TeacherTool supports teachers in these regards.

  • Teachers can see which terminals are in use at any time.
  • Teachers can see which programs are running on each client.
  • Teachers can click a button to see the desktop of any client on their own screen.  This is a tremendous help in watching for appropriate use by students.
  • At any time, the teacher can take control of any student’s desktop.
  • Teachers can send files to students.
  • Teachers can send active copies of whatever the teacher is working on to students’ desktops, thus acting as individual whiteboards.

Arkiletian sees a number of advantages to using the K12LTSP setup with students.

  • Maintenance is low.
  • Software only needs to be installed on the server computer.
  • Problematic clients can be swapped out easily.
  • Computers that are seven or eight years old can be used as clients long after their standalone service has ended.
  • A computer lab can cost one tenth what it would if workstations were used.  This money can be reinvested in smaller workstation-style labs for specific purposes.

The only limitation Arkiletian mentions is that the clients are limited to “standard computing” (p. 3).  Animation requires too much memory swapping for this kind of setup.

Evaluation and Educational Relevance

The use of OS-based systems in education is hardly mentioned in educational literature.  A search for the keyword “Linux” in the ERIC database brings up just 22 results, and most of these articles only talk about the possibilities of using OS applications in schools.  There is very little in the way of describing actual implementations, and even less about evaluating the impact of these implementations.  This motivates me to write up my experience with OS in education.  It also makes me want to publish these articles in non-technical journals and magazines.  The teachers we want to reach most, educators who are not experts, do not read journals like Computers & Education, Tech & Learning, and Newsweek.  They read things like The Reading Teacher and Journal of Social Studies Research.  Writing for non-technical audiences about the pedagogical benefits of OS implementations is sorely needed.

This article points to the need for visionary technology leaders in school districts.  I am reminded of the band aid story.  A student in a first grade classroom went up to the teacher and said, “I just cut my finger!  Can I have a band-aid?”  As the teacher gave the student a colorful band-aid, another student went up to the teacher and said, “If he gets a band-aid, I want one too!”  All too often, this is the conception of fairness that students have.  When it comes to technology, many educators feel the same way.  If one teacher has a new powerful computer, other teachers feel they should have access to the same technology.  People feel this way regardless of whether they have an actual pedagogical need for the more powerful computer.  A better conception of fairness is one in which everyone gets what they need, when they need it.  We need technology leaders who can apply this kind of thinking to district-wide technology decisions.  For example, we might consider putting thin clients in a language-arts based classroom, and powerful workstations in a computer science lab.  The money saved from putting only the necessary resources in each area can be used to hire a computer science teacher with the expertise to teach students to use the full capabilities of the more powerful workstations.  This question of whether we should make teaching programming a priority is another conversation altogether.  This requires the leadership of technology experts in the district who can accurately match resources to actual needs, and explain these distribution decisions in a friendly manner to non-expert teachers.

The Fl_TeacherTool makes me think of one specific application in my old school.  We had a number of smaller rooms that student groups often used for project work.  These groups were usually not supervised directly.  We hesitated to put computers in these rooms because of the difficulty of monitoring their use.  With the Fl_TeacherTool, I wonder if the server could be placed in a classroom and the clients in the smaller work rooms.  The work rooms would become more productive spaces, and the monitoring would cease to be an issue.

Article Summary #6: Houston – Linux Makes the Grade

April 13, 2009

Houston, M.  (2007).  Linux makes the grade.  Technology & Learning 28(4), 8 pp.

When most people consider why a school or school district might consider implementing a Linux-based technology solution, they think of financial issues.  If you ask the people responsible for these decisions, however, they list a number of other equally significant issues such as reliability, simplicity, flexibility, and security.  Houston describes the experiences some schools have had in implementing Linux-based technology solutions.

Summary

In 2001 the Indiana Department of Education implemented a one-to-one initiative with the goal of having one computer for every student in the Indiana state school system.  They found that despite significant investment in technology, students still spent less than one hour per week using computers.  In making the switch to a Linux-based technology solution, the state saved over $100 million annually on licensing fees.  This money was reinvested in hardware and support throughout the state.  Not only did the state get a significant increase in the number of computers available to students, they also got a more “secure, reliable, and sophisticated” system (p. 1).  Michael Huffman, special assistant for technology in the Indiana State Education Department, said that a Linux-based system is “the only model we’ve come up with that is affordable, repeatable, and sustainable” (p. 1).

A number of developments in the Linux community have made it friendlier to non-expert users.  Linux has graphical user interfaces available that require little understanding of the operating system itself.  These interfaces can be configured to mimic Windows or Mac systems, or they can be customized in ways that go beyond the latest offerings of these proprietary systems.  Linux is known for running free software, but not everyone knows that well-established companies like Red Hat and SUSE offer fee-based support programs for Linux systems.

In 2004 the Saugus Union School District in California implemented a Linux-based system throughout their district.  It was the desire for a flexible system, not financial considerations, that motivated the change.  Jim Klein, head of technology in the district, has this advice for people considering a move to Linux:

Pick up your Windows machine (or Mac, if you are so inclined) that is on your desk and move it across the room.  Make sure that you do not put a chair in front of it, and that you get up and leave your desk to use it. (p. 5)

The Saugus School District ended up with a system of computers that was faster than before, and even the oldest computers in the system were more reliable than most computers had previously been.  The IT staff has spent more time directly supporting teachers, staff, and students and less time focusing on hardware and software issues since the transition went into effect.  They are able to implement new software solutions more quickly, and they are more confident in the security of their system.  “We were able to smile when the latest security vulnerability surfaced, knowing that it wouldn’t affect our systems” (p. 5).

One particular question arises repeatedly in discussions about building an entire school’s technology solution around open source software.  “Are these computers, which don’t easily run the Microsoft OS or applications built to run on Microsoft, actually preparing our students for the workplace in their future” (p. 3)?  David Trask of Vassalboro Community School in Maine uses our understanding of driver education to address this question:

Our kids learn how to use a computer…no matter what the OS or application.  I use the analogy of driver’s ed quite often.  It goes like this:  When you took driver’s ed, did you learn how to drive a Ford?  How about a Chevy?  A Toyota?  Most people can’t remember… why?  Because ya’ learned how to drive a car… regardless of make, model, or size.  Why should computers be any different?  (p. 6)

Evaluation and Educational Relevance

Any entrenched system is difficult to change, and the current technology solution of any school or school district is certainly an entrenched system.  Large systems only change when something makes the change worthwhile, such as a serious problem with the existing system, or a significant benefit of a new solution.  In many cases, including those described in this article, switching from a proprietary technology solution to a Linux or OS solution addresses both of these issues.

One principle in particular can guide us through many of these decisions.  Technology should serve educational goals, and educational goals should not be adjusted to match existing technology.  Effective technology solutions center around a long-term vision, on the order of five to ten years.  With this perspective in mind, Linux and OS solutions make sense for many institutions.  In fact, it can be seen as irresponsible to tie a school to proprietary systems when more reliable and effective open solutions exist.  It is important to document successful and unsuccessful transitions to help technology departments make sound decisions, convince others that their solutions are professional and visionary, and to share expertise across a wide community.

Followup

Two items mentioned in the article are worth investigating further:

Article Summary #5: Douglas – Issues in Software Engineering of Relevance to Instructional Design

March 31, 2009

Douglas, I.  (2006).  Issues in software engineering of relevance to instructional design.  TechTrends 50(5), 28-35.

In this article, Ian Douglas describes how the principles of software development, including OS design models, are relevant to the design and development of instructional materials.  The article identifies areas of current work and leads to ideas for applications of design ideas outside of their native fields.

Summary

Douglas begins by clarifying the difference between software engineering and programming.  He says that many people assume they are the same thing, but that is like saying that instructional design is nothing more than the creation of powerpoint slides.  Software engineering was traditionally a linear process, but has evolved in many development houses to an iterative process involving rapid prototyping.  Most instructional design work, however, is stuck in the linear model.

Douglas describes the capability maturity model (CMM) that was developed at Carnegie Mellon’s Software Engineering Institute to evaluate software development approaches.  This model identifies five levels that an organization may reach.  In the Initial stage, work is done in a haphazard manner with little or no process management.  In the Repeatable stage, a process is specified so that successful development habits can be formed and used repeatedly.  In the Defined stage, the process is documented and standardized.  Someone, or some group, is given responsibility for maintaining the documentation of the process and making sure everyone understands and follows the specified development process.  In the Managed stage, the development process itself is evaluated and steadily improved.  The efficiency of the process is monitored, and areas for improvement are identified.  In the Optimized level, improvements in development process are shared rapidly throughout the organization.  Bidders on government contracts are required to have reached the Defined stage in order to secure government contracts.

The traditional model of software development is represented by the ADDIE acronym:  Analyze, Design, Develop, Implement, and Evaluate.  In closed development models, the only public stage is implementation.  OS is different in that all aspects of the development process may be open to public input, and each iteration ends with a code release, either as a development version or as a stable version.  In closed designs, most iterations are done in-house, and only a few, hopefully stable, public releases are made.

The Agile Manifesto describes models that are meant to be lighter than the ADDIE model.  These methods are said to be adaptive and people oriented rather than predictive and process oriented.  Extreme programming is mentioned as an example of an agile design methodology.  Its four core values are communication, feedback, simplicity, and courage.

Learning objects are educational parallels of object-oriented programming.  In object oriented programming, we aim to make reusable, discrete parts of programs.  This enables the re-use of code, ease of maintenance, and speed of new development.  When actual code is not reusable, we can identify reusable patterns.  Patterns are pieces of design knowledge rather than actual artifacts like code.  If we are not going to reuse actual code, we should at least identify the best design examples, and reuse these designs until they are improved upon.

Douglas describes UML, a unified modeling language that was developed to give software engineers a common way of speaking with each other around design issues.  This common language has facilitated the evaluation of software designs before the coding phase has progressed too far.

Evaluation and Educational Relevance

The capability maturity model (CMM) was developed to evaluate software engineering processes, but it can be used to examine instructional design processes as well (and many other design fields).  Every teacher is an instructional designer, and every school is a collection of designers.  Even if we use packaged curriculum, we still integrate different pieces of packaged curriculum, and design its delivery.  As designers, we can ask ourselves where we and our schools fall on the CMM scale.  In an honest evaluation, most schools would be on the initial level while some individual teachers will be on the repeatable level.  Any school without a central, accessible, and well-used repository of staff-developed curriculum is stuck in the initial level.  Many teachers repeat their best lessons and projects from year to year, but few of these teachers have identified a formal process for the revision and documentation of their curriculum.  Looking at the instructional design industry from a CMM perspective Douglas wrote, “It would be interesting to speculate how many organizations involved in producing instruction would score the equivalent of a Level 5 [Optimized]” (p. 29).

While many teachers may recognize their own informal use of the ADDIE model, few schools have implemented any formal curriculum development model.  It is worth reiterating that even a school which is only choosing a set packaged curriculum is still designing an instructional experience for its students.  Several ideas from the extreme programming model may be relevant to school-based instructional design.  One is the set of values – communication, feedback, simplicity, and courage.  Teachers who have clear communication with their students, colleagues, and administrators are in a more comfortable position to try to improve existing curriculum or develop new curriculum.  Even around complex topics, the progression of learning experiences should be simple.  A non-expert in the field should be able to recognize the development of learning that should take place in well-designed curriculum.  Finally, courage is needed to try to implement new projects.

A larger idea from extreme programming is the concept of collective ownership of that which is developed.  Douglas wrote, “This is a refinement of an earlier concept of ego-less programming, where there is collective responsibility for the system quality irrespective of individual work assignments” (p. 30).  As teachers, we often feel responsible only for the learning in our classrooms.  Schools become significantly more effective when teachers make the transition to thinking of their staff as a whole, and take collective responsibility for pedagogical excellence.

The tiered architecture model that developed out of object oriented programming has interesting suggestions for education.  In this approach, software is broken into a boundary (the interface, a GUI for example), the control (logic and processing), and the data storage.  We can aim to find a similar breakdown of functions in education.  A simple parallel might be viewing the context of instruction as the boundary, and the content, skill, idea, or knowledge as the data to be stored.  The logic is the thinking, the way we encourage students to put new knowledge together with their prior understanding.  This decoupling of pedagogical functions helps because the content changes little, the thinking changes some, and the context changes frequently.  Often times when the context changes we rethink the content and thinking aspects as well.  We may be able to minimize our rethinking of curriculum if we can adopt a similar, layered approach to instructional design, only changing the parts that need to be updated in a new curriculum implementation.  As Douglas suggests, “The currently amorphous concept of the learning object may have to evolve into a taxonomy of learning-related objects with at least a definite separation between learning content and its presentation [italics added]” (p. 32).

Douglas’ description of UML and its effect on making software design more efficient suggests the development of an Educational Markup Language (EML).  Wired magazine ran an article about a business-focused markup language, XBRL, that makes financial data more transparent and usable to everyone from industry experts to the reasonably educated public.  Financial data that took 70 days for regulators to analyze before the required implementation of XBRL took 2 days to analyze after implementation.  One could easily think of a small set of tags that are educationally relevant, from topic tags such as mathematics, exponents, and area to tags that represent sections in a lesson plan such as guiding questions, materials, and state standards.  With the use of this language, one lesson plan could be used in many different contexts, for many different audiences.  This is similar to the manner in which pathways in VUE allow one concept map to be used in many different ways.  A well-implemented scheme such as this seems to be missing from existing lesson plan repositories like Curriki.  The only place I have seen it so far in education is the closed set of descriptors in the ERIC database, the meaning of which most graduate students do not seem to grasp.

Finally, Douglas describes computer-aided software engineering (CASE).  He says that while many developers make automation tools for their customers, they use few automation tools themselves.  He describes high and low versions of CASE.  High-level CASE programs assist in analysis and design, while low-level programs assist in coding and debugging.  A similar kind of distinction could be made in education.  We could have computer-aided lesson planning (CALP).  Most teachers use nothing more sophisticated than a word processor for developing their lesson plans.  High-level CALP would assist in large-scale curriculum mapping and design; low-level CALP would assist in developing daily lesson plans, and lessons around small sets of learning objectives.  A useful piece of software might generate a daily lesson plan from a unit plan, with its only input being how far you got the previous day in the unit.

Conclusion

Douglas offers some concise closing thoughts:

If the barriers of jargon can be overcome, it may become apparent that many of the issues in design-related disciplines are the same, and there is great potential for sharing knowledge.

I would urge instructional designers to look beyond their own journals and conferences for reusable “objects” of knowledge that exist in other domains. (p. 35)

This article offers rich food for thought.

Mid-Semester Reflection

March 11, 2009

The learning I am experiencing in this course is much richer than I had expected.  I expected to learn a lot about OS programs, and their potential use in educational settings.  I also expected to learn a little about the OS community, but I expected that to be background knowledge for the focus on specific programs.  I had no idea how many concepts from the OS community are relevant to education, and how many connections between the two are relatively unexplored or unexamined.  With this unexpected richness, it is worth taking a moment to reflect on the work I have done so far, and the work I plan to do in the remainder of the course.

I will be reviewing an article by Ian Douglas on the relevance of software design issues to instructional design.  Douglas is one of the people I admire, with a deep understanding of technological issues like software engineering and a deep understanding of education as well.  The next few articles will cover the kind of topics that we expected from the outset like the use of Linux in classrooms and districts, and the use of specific OS applications in education.  As I have continued to look over the literature about OS and education, the initial investment in understanding licenses has proven to be time well spent.  I understand the licensing decisions described in numerous articles, and recognize the impacts of less clearly articulated licensing decisions on OS education projects.

I am working through a longer book right now, Opening Up Education (440 pages).  I was not sure I would read the whole thing, but it is proving quite relevant so I will finish it and review it in the next week or two.  I believe the last formally reviewed book will be The Success of Open Source by Steven Weber, although I have picked up a number of other books for continued study (and pleasure reading):  Just for Fun, the biography of Linus Torvalds; Free Software Free Society, essays by Richard Stallman; and The Mythical Man Month by Frederick Brooks.

I will write a literature review to synthesize what I have read and learned, and I will do a small in-class implementation.  I would still like to synthesize some OS concepts in a visual format, probably using VUE, and make a resource list.  The second interview will probably be with a member of the school district’s technology committee, to get another perspective on issues raised in the previous interview.

Finally, I hope to have time to outline an OS project of my own.  I would like to develop a cross-platform reading log, perhaps designed with some educational theory as the groundwork.  The whole project is well beyond the scope of this course, but I would like to lay out the functionality of the project in this course and leave the coding for rainy summer days.

I am enjoying the course immensely, and I hope the rhythm of reading and posting summaries are acceptable to you.

Software Review #3: VUE (Visual Understanding Environment)

March 1, 2009

Brief Description: VUE is a concept mapping program designed by a team at Tufts University. The program is designed to be a flexible learning environment which can manage text, links, images, and other multimedia files. The program also functions as a nonlinear presentation tool.

Strengths:

  • A strong, university-based design team leads the development of VUE. A clear set of design principles guides its development. Development should continue steadily for the foreseeable future, and may be picked up by the OS community.
  • VUE is cross-platform.
  • VUE is inclusive of many types of media. It is designed to organize resources from a variety of repositories – the user’s file system, the Fedora repository, and other digital archives.
  • A growing community exists around the VUE project, which is building a library of concept maps which can be downloaded.
  • As with any software designed for flexible use, there is a learning curve in using the software to its full potential. From initial use, however, the program seems to pull you in to deeper functionality. Thus, the learning curve weakness becomes a strength.

Weaknesses:

  • Any potential weaknesses I can identify so far, such as the inability to upload directly to the web, are being addressed in the next release. It is clear that this work is being actively pursued.

Resources: VUE web site, Sourceforge page

Specifications: Platform independent; requires a java runtime environment.

Installation: VUE installed easily on Ubuntu. I downloaded the Linux Installer file. I unzipped the file, changed its permission to executable, and ran the installer. It gave an error message after installing, but seems to be running fine.

Summary

I wanted to take a look at an example of concept-mapping software. I have used concept maps in my teaching, but have never used digital versions. They have always seemed cumbersome to create, relative to the educational value in creating them. The majority of conceptual learning seemed to occur while creating drafts of their concept maps, after which translating them to an electronic version was simply a technical task. The VUE designers seemed to feel the same way about existing concept-mapping software:

[existing concept-mapping programs] lack both the flexibility and responsiveness required to support critical and creative thinking with digital resources (Kahle, 2003). These tools’ simple mode of presenting digital resources as a static selection of links organized hierarchically may serve to communicate the structure of a course of lecture at a very high level, but this approach does not support the type of meaningful exploration and content manipulation necessary to help students construct important connections between digital resources and the ideas they represent. (Kumar 2006, chap. 1)

In about fifteen minutes, I was able to make a simple map including nodes, links, and labels for each. I then ‘played’ the map as a presentation and discovered the richness of VUE as a presentation tool. The first screen in the presentation is the map as a whole. Clicking on any node enlarges the node. If the node has any links, these other nodes and resources can be reached directly from the presentation, or the user can return to the previous level. This allows, or requires, the user to think through their presentation rather than simply following a default linear progression as often happens in the use of other presentation software. If the user wants to define a presentation order, I believe a pathway can be used to accomplish this. Being fairly new to concept mapping software in general, I was quite satisfied to be able to do this easily. I also recognize that this only begins to scratch the surface of VUE’s functionality.

Map creation window, with many dialog windows open.

Map creation window, with many dialog windows open.

VUE allows users to “search, browse, retrieve content from digital repositories, and upload resources into these systems” (Kumar 2006, chap. 3). Users can also create pathways through the resources on a map. These pathways can be used to control the sequence in which resources and content are viewed, and to control the level of complexity displayed on the map. For users new to the content area, pathways can be used to show only the core content information. For users familiar with the content area, the full richness of the map can be displayed. Multiple pathways within the same map can be used in different ways, by different learners. This flexibility can allow the map to develop in complexity with the user’s growing understanding of the topic. The user can also add new content and resources to the map as they bring their own learning to an existing map, or continue to develop a map they have created. Users can add to the map by searching their own file system, the Fedora repository, and other digital repositories for content. When relevant content is found, it can be dragged directly onto the map to create a new node.

Simple, 15-minute OS Education Concept Map.  Links to an image of Richard Stallman, and the text of the GNU Manifesto.

Simple, 15-minute OS Education Concept Map. Links to an image of Richard Stallman, and the text of the GNU Manifesto.

The current version of VUE is 2.2, and version 3.0 is planned for the fall of 2009. Version 3.0 will implement layers to further facilitate complex map structures. Importing data will be automated from certain sources, and layout will be automated using rules-based styling. A VUE applet is also being developed which will allow the full functioning of maps posted to web sites (Tufts University, 2008).

Conclusion

VUE is a strong example of what a contemporary OS project can look like. With its open design process, clear communication between users and developers, modular design model, and university backing, it is clear that the project will be active in the foreseeable future, and will continue to gain functionality. The project should continue to push the standards of concept mapping software development. It is difficult to imagine using a program like PowerPoint after seeing the flexibility of a program like VUE.

I would like to learn more about the OKI standards that are mentioned in discussions of development, and the OSID implementations that are mentioned (Kumar 2006). Conforming to these standards seem to allow the program to access certain repositories, and allow other developers to build on VUE functionality in their own projects.

References

Kumar, A., Kahle, D. (2006). VUE: A Concept Mapping Tool For Digital Content. Proceedings of the Second International Conference on Concept Mapping. Retrieved February 27, 2009 from cmc.ihmc.us/cmc2006Papers/cmc2006-p84.pdf

Tufts University. (May 2008). Visual Understanding Environment 3.0 (VUE 3.0). Retrieved February 27, 2009 from rit.mellon.org/projects/VisualUnderstandingEnvironment.pdf

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 www.mrgibbs.com/tu/research/articles/pfaffman_opensource.pdf)

Summary

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.

Followup

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 OpenOffice.org 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

Summary

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.

Strengths

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

Weaknesses

Specifications
Platform independent; requires a java runtime environment.

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

Conclusions
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 www.sun.com/software/opensource/whitepapers/Sun_Microsystems_OpenSource_Licensing.pdf

Summary

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.

Followup

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