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
• contractual concerns: a purchase contract being
signed with a company that did not create the product
purchased; minimization of copyright for programmers;
• product support concerns: discomfort of software
companies with providing warranties for products
they did not create; short track records and unknown
staying power of small new software companies with
regard to the provision of long-term product support;
• product standardization concerns: due to the collaborative
nature of source code, functionality, enhancements,
and application alterations can be added at
will and marketed as a different or newer versions of
the program so, “The multiplicity of products and
versions can result in incompatible systems and inconsistent
products”.
While Potter’s (2000) concern about application alterations
or proliferation of versions can seem worrisome,
once a freely sourced program is running on your
system, under your administration, only the people you
(or your system administrators) designate have the permission
to access and modify the source code. If you
want to switch to a newer version, you are free to do
so—but are not compelled to do so. No one else will be
able to tinker with the code you’ve installed on your
hardware unless given such permission and no one can
force you to upgrade through contractual or licensing
obligations. This does not mean that an unscrupulous
programmer could not hide something in the source
code to allow him or her to go in and modify the program
without your knowledge, but that is highly unlikely
if you’ve selected a reputable program with robust
user and programmer communities. In these communities,
people constantly scrutinize the code. Such issues
would be quickly discovered and the program panned in
reviews, blogs, or other formats.
Another barrier to adoption can be the perceived
portability of data from existing software to a freely
sourced option. Often many of the difficulties in migrating
an instructor or institution’s data to a new platform
are attributed to the software, and at one time that
was true. In the past, proprietary commercial programs
ensured portability of content between their versions,
with little reference to others. For example, with regard
to learning platforms, many institutions developed
courses, media, or data without reference to design
documents or data tagging, perhaps never envisioning
they would contemplate migration to a different software
provider. A course designed by one instructor was
often significantly different in structure from that designed
by another. Materials showed little consistency in
design or layout. 12 Since the standards movement, the
issues of portability and interoperability have become
central considerations when selecting software. Consequently,
consistent course design and layout have gained
importance in the educational environment. More frequently,
instructors or other developers are being
trained in ways to build standards compliant courses.
It’s far easier to build a software program to move content
to a new environment when the parts are common,
properly identified, and in the similar locations. Even if
you don’t have the technological expertise within your
institution to build the necessary migration software,
with standard compliance, good design and foresight at
the outset, that process can be outsourced for a reasonable
price.
These are not the only obstacles to free and open
software—other threats loom. Recently there have been
movements afoot to effectively and legally prohibit reverse
engineering of software. Potter (2000) discusses
recent drafts of the Uniform Computer Information
Transactions Act (UCITA) saying:
Currently, reverse engineering is legal for reasons
of “interoperability” between computer systems.
Prohibiting reverse engineering inhibits the development
of open source [and free software] because
for … [freely sourced software] products to be of
any value, they must be compatible with other
computer applications. The way to establish compatibility
is to reverse engineer the other developer’s
code … advocates are concerned that the
UCITA will allow proprietary developers to “establish
secret file formats and protocols, which
there would be no lawful way for [programmers]
to figure out”.
Furthermore Potter (2000), identified problems with
legal drafts of the UCITA that would entrench implied
warranties into software licences. Traditionally, freely
sourced software does not provide warranties unless
expressly specified by an individual or company. This
has been a benefit as it lowers the risk of lawsuits. Consequently,
this creates low entry barriers to new software
designers and companies. With no prerequisites of insurance
or legal representation to limit liability, anyone
and everyone can contribute to programming the soft-
12
This is still true of institutions in the early stages of online
course development as their emerging understanding has not
yet extended to the need for templates, structures, and data
tagging to ensure future portability and interoperability
with other platforms.
Education for a Digital World 101