Strategies and Policies for the implementation of Free & and Open Source Software in Higher Education
0 likes3,793 views
Strategies & Policies for the implementation of Free & and Open Source Software in Higher Education, Presented at E-learning Africa 2010
More Related Content
What's hot (20)
Viewers also liked (20)
Similar to Strategies and Policies for the implementation of Free & and Open Source Software in Higher Education (20)
More from Frederik Questier (20)
Recently uploaded (20)
Strategies and Policies for the implementation of Free & and Open Source Software in Higher Education
- 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 Presented at 1 E-learning Africa 2010 License (except images) Lusaka, Zambia
- 2. 2
- 3. 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 Research and Innovation Director Chamilo 3
- 4. Overview Free & Open Source Software What? Why? Barriers? Strategies and policies for implementation 4
- 5. For a better world "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. 5
- 6. 6
- 7. 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 7 Compiled code: 001001011101010011001100001111011000110001110001101
- 8. The free software world characteristics FLOSS exists for all tasks 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 8
- 9. 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 9
- 10. 10
- 11. Bridging the digital divide "Africa can bridge the digital divide by adopting open source thus narrowing the effect of techno-colonialism" “Need for technology that is controlled by local communities and not by foreign companies, that is public property and empowers people to be self-reliant” 11 www.FOSSFA.net
- 12. Who believes software is better Free and Open? 12
- 13. Who is using FLOSS? 13
- 14. Why are you not using FLOSS? 14
- 15. Perceived barriers? Following the herd? 15
- 16. Perceived barriers? pre-installation of closed software 16
- 17. Perceived barriers? Fear, Uncertainty and Doubt about features? quality? (hobbyist programmers?) sustainability? support? requirement to participate in the community? 17
- 18. Perceived barriers? anti-competitive behaviour monopoly abuse secret formats secret protocols data and vendor lock-ins 18
- 19. 19
- 20. 20
- 21. 21
- 22. 22
- 23. Perceived barriers? Liability Who can we sue? 23
- 24. Perceived barriers? transition costs? plethora of choice (e.g. >313 Linux distributions) limited in house expertise? 24
- 25. 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 25
- 26. 26
- 27. 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 27
- 28. Policies Purchasing policies FLOSS, except if no good alternative Ask argumentation which alternatives considered Open standards Open courseware Free & Open Licenses 28
- 29. Example proposal FLOSS policy X wants to encourage the use of Free Libre Open Source Software (FLOSS) in the partner institutions. X will only fund the implementation and training of FLOSS, unless proprietary software is demonstrated to be significantly superior and necessary for the required tasks. Whenever X funds are to be used for proprietary software, reasons must be provided (including a list of FLOSS alternatives considered) and approved by X. In the case hardware funded by X comes with proprietary software pre-installed, it must be demonstrated that the maximum is done to convince the manufacturer or supplier to only deliver FLOSS. Suppliers that are willing to provide hardware with FLOSS are to be preferred above those that don't. Software developed with X funds must be published under a FLOSS License, where possible, in order to maximize its usefulness for other developing countries. X advises new development projects to include a work package around FLOSS awareness creation, expertise building, policy definition, training, support and implementation. 29
- 30. 30
- 31. 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? 31
- 32. 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 32
- 33. 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 Constant communication with all stakeholders 33
- 34. 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 34
- 35. 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 35
- 36. Questions? Thanks! 36
- 37. Acknowledgements Contact Thanks to VLIR-UOS for funding our E-learning Africa participation Pictures Doubt by Elenaa Marie (Flickr) Lockin, claustrofobia by Laororo (Flickr) Pain Curve, creative commons by P. Scott Liability, copyright by Proffman Poland (www.proffman.pl) Social networking, creative commons by F. Questier Contact: [email protected] http://www.paulscott.za.net http://www.chisimba.com [email protected] http://questier.com 37 http://www.chamilo.org