This document discusses strategies and policies for implementing free and open source software (FOSS) in higher education institutions. It outlines perceived barriers to FOSS adoption like dependence on proprietary software defaults and lack of in-house expertise. The document recommends establishing a FOSS task force to create awareness and build capacity. It also suggests developing FOSS-friendly policies around purchasing, standards, and licensing. Overall migration plans should involve stakeholders and choose software that is at least as good as previous systems.

1. Strategies & Policies
for the implementation of
Free & and Open Source Software
in Higher Education Institutions
Paul Scott
University of Western Cape
Prof. Dr. Frederik Questier
Vrije Universiteit Brussel
Attribution
Non-commercial
Share alike
License
(except figures)
Presented at Universidad 2010 1
Havana, Cuba

2. Who are we?
Paul Scott
University of Western Cape, South Africa
Head of free software innovation unit
Architect and lead developer of Chisimba
Frederik Questier
Vrije Universiteit Brussel, Belgium
Professor learning technologies
Dokeos / Chamilo e-learning platform 2

3. Overview
Free & Open Source Software
What?
Why?
Barriers?
Strategies and policies for implementation
3

4. Por un mundo mejor
"The most fundamental way of helping other people,
is to teach people how to do things better
or how to better their lives.
For people who use computers,
this means sharing the recipes you use on your computer,
in other words the programs you run."
Richard Stallman
Free Software Foundation.
4

5. Free (Libre Open Source) Software
FLOSS
The freedom to
run the program for any purpose
study how the program works,
and to adapt it to your needs
redistribute copies
improve the program, and release your
improvements to the public.
These freedoms require access to the source code
Source code: if encrypt(password) == encryptedpassword, then login=1, end
5
Compiled code: 001001011101010011001100001111011000110001110001101

6. The free software world
characteristics
Huge
e.g. 230K projects, 2M contributors @ sourceforge.net
e.g. IBM > 1 billion $ per year
Several business models
Well organised
User friendly ← written by users for users
Cross-platform ← recompile source code
High development pace ← reuse of best modules
High quality ← peer review, reuse = survival of the fittest
High security ← peer review, Unix origin, modular, encryption
6

7. Why FLOSS?
reduce (license) costs
reduce digital divide
eliminate software piracy
easier license management
easy to localize and customize
better quality (peer review, intrinsic-motivated developers)
increase security (security by design vs security by obscurity)
increase interoperability (open standards)
reduce dependencies from monopolies & foreign software companies
7

8. 8

9. Who believes software
is better Free and Open?
9

10. Who is using FLOSS?
10

11. Why are you not using FLOSS?
11

12. Perceived barriers?
Following the herd?
12

13. Perceived barriers?
pre-installation of closed software
13

14. Perceived barriers?
Fear, Uncertainty and
Doubt about
features?
quality? (hobbyist
programmers)
sustainability?
support?
requirement to
participate in the 14
community?

15. Perceived barriers?
anti-competitive behaviour
monopoly abuse
secret formats
secret protocols
data and vendor lock-ins
15

16. Perceived barriers?
transition costs
limited in house expertise
plethora of choice?
16

17. Who can break the monopoly?
Education
“We teach MS because that is what companies use”
Companies
“We cannot use FLOSS because our employees don't know it”
Employees
Growing number starts using FLOSS at home
Not happy with inferior software at work
17

18. 18

19. Institutional FLOSS taskforce /
expertise / innovation center
Create awareness
Involve all stakeholders
including highest management
Expertise & capacity building
Resources for experimentation & innovation
Provide support – sustainability
Documentation
Training → certification
19

20. Policies
Purchasing policies
FLOSS, except if no good alternative
Ask
argumentation
which alternatives considered
Build or buy?
Open standards
Open courseware
Free & Open Licenses 20

21. 21

22. How to handle
the plethora of choice?
define requirements
indicators of high quality & sustainability
mature, stable software
active community
availability of support & documentation
need/possibility to change the code?
need/possibility to participate in the community?
22

23. When to migrate?
Time transitions
at the end of existing contracts
at hardware / software upgrade times
Consider migrating in phases
servers
desktop applications
→ multi-platform
→ web-based
desktop OS 23

24. Key success factors
for migration & implementation
resources to experiment
an evidence-based choice
involvement of both technical and non-technical users in
the selection process
choice for a new system which is in all aspects at least
as good and easy as the previous one
reporting detailed migration plan to management and get
their approval and support
in-house expertise with open source software and
communities
contact with the developers and users community
24
Constant communication with all stakeholders

25. Advantages of being a
contributing community member
co-decide the direction of development
create extensions
user requested
research driven innovation
more contacts with other educational institutions
programming projects for students
better knowledge of the system
better trouble solving
possibilities for grants
25

26. The open way
avoid local customization without
contributing back
participating in the community
establish an 'open source culture' of re-use,
collaboration and sharing
Provide FLOSS repositories / CDs
share experiences
26

27. Questions? Thanks!
27

28. Acknowledgements
Sources
Pictures
Doubt by Elenaa Marie (Flickr)
Lockin, claustrofobia by Laororo (Flickr)
Pain Curve, creative commons by P. Scott
Social networking, creative commons by F. Questier
28