Education for a Digital World Advice, Guidelines and Effective Practice from Around Globe, 2008a

8 – Exploring Open Source for Educators: We’re Not in Kansas Anymore – Entering OS
most daily, you need to stay current with developments
in freely sourced software. The closer the freely
sourced and proprietary software programs are in
terms of look, user friendliness, features and functions,
the smoother the transition and the quicker the
adoption. In addition, if the new open source option
can approximate or better the old product while delivering
desired, voiced needs for upgrades, the more
assured the transition.
• Software viability—Here you review what version
was being considered, how long the program has
been around, and how robust a user community
and/or commercial community has been built around
the product. Certainly, products like Moodle, ATutor,
and Sakai are safer bets. Experience has shown
that the longer-lived and more robust the communities
are, the more successful the freely sourced software
will be.
• Implementation and support costs—Remember that
while the source code is free, you have to have the expertise
to deal with it. This includes not only necessary
hardware purchases, but the skill to implement
and support the software in your group or institution,
or the cost of any necessary outsourcing.
• Level of customization desired—Unlike proprietary
software, freely sourced software is highly customizable.
You must know what you want from the software
application. If customization is desired, key questions
include: is there existing, budgeted expertise in our
organization to accomplish customization through
modifying programs? or would this work need to be
outsourced, and at what cost?
• Software succession history—Generally, when organizations
undergo a rapid succession of software
transitions that involve significant changes/challenges,
resistance to adoption of any new software will increase.
Your transitions must be managed for the
relative comfort of your users.
• Risk assessment—This involves an examination of
how much risk is acceptable in a transition to freely
sourced options. This may be measured by reliance
on reputation, availability of warranties, or assumption
of liability for the software. If low risk is desirable,
then a group or institution can experiment with
more established applications, or those with warranties
and/or vendor support. If a program plays a critical
role, then high software viability, usually at a
higher cost, must be sought. The level of risk assumption
you are willing to make will affect whether
your group or institution will be comfortable with
newer, less tried-and-true programs, or a blue-chip
program like Moodle or ATutor.
NEEDS ANALYSIS
First you need a team or individual in your group or
institution best positioned to do a software review. This
is probably the person(s) responsible for buying, maintaining,
and monitoring your technology. You want to
look at the applications you are currently running in
your organization. Determine which ones are the most
expensive, have the most associated costs for upgrades,
maintenance, etc. Which ones do your people complain
about, or wish were better? For which ones do people
request alternatives? When you’ve established a base list,
examine these programs for the functions and features
your users need, the ones they don’t use, and the ones they
wish the programs had. Use this to create your wish-list
of functions and features for a freely sourced alternative.
This list will form the foundation for a software analysis
grid when you review your software options.
• Outputs: Needs analysis report—formal or informal;
wish lists of software functions and features.
• Resources: Technology employee time for analysis.
• Costs: Employee wages for needs analysis time.
RESEARCH AND ANALYSIS
Now it’s time to find out if there is anything in the freely
sourced world that could meet most of the features and
functions on your wish list. Build a research team: invite
a technology expert(s) with programming experience
from your group or institution to work with your needs
analysis group (they could be one and the same) as well
as one or more potential end users who are demonstrated
early adopters of technology. End users might be
clerical staff, instructors, teachers, accountants, etc. Always
keep in mind exactly who will end up using the
software. Ultimately, they will have to be satisfied with
the new software. Sometimes your team may only consist
of two or three people, and that’s fine to start, but
you will need to increase your participants in subsequent
stages. Feedback from the end users is vital. If the
interface—the front end of the application—is too challenging
to use or user un-friendly, or clearly outweighs
other benefits, look for something else, have it developed
or wait until it is developed. Keep in mind, many user
communities will take requests that build up over time
to drive the direction of software development.
Have the team research possible alternatives for use
in your organization in light of the needs analysis conducted
and your wish list(s). Part of this process should
assess viability of freely sourced alternatives including
existing hardware and potential costs of new hardware
or outsourcing. It should also generate estimates of
106 Education for a Digital World