1.
FOSS in Africa FOSS Africa Convention Indaba Hotel April 2010 Paul Scott http://www.paulscott.za.net/

2.
Casting a larger net <ul><li>Working collaboratively </li><ul><li>African talent

3.
Bandwidth constraints

4.
Cultural constraints </li></ul></ul>

11.
Communication is key <ul><li>How do you collaborate?

12.
We need to use low(er) bandwidth friendly technology

13.
Mailing lists, IRC, Web optimised for low bandwidth

14.
Constant communication to create community

15.
Everyone feels part of the community, no matter what the situation is! </li></ul>

16.
Version Control <ul><li>What is version control?

17.
Must be used in any collaborative effort

18.
Not just for code, docs, wiki and images too!

19.
Must be distributed and provide a central repository

20.
Single point of truth for collab efforts

21.
Able to operate in low bandwidth environments </li></ul>

22.
Marketing <ul><li>Single most difficult thing to do

23.
We have a culture of not thinking the best of ourselves

24.
US and EU projects look to us for the lead (Drupal, Joomla! Etc)

25.
Marketing costs a lot of money

26.
Not many people experienced in tech/FOSS marketing and community building in Africa </li></ul>

27.
Social Media <ul><li>Marketing can be achieved informally too

28.
Search Twitter for #Chisimba! Constant tweets and updates from many sources

29.
Subversion also tweets so stakeholders are made aware of progress constantly and in real time

30.
Facebook group

31.
Flickr group

32.
Blogs, forum and Google Groups </li></ul>

33.
IP / Patents <ul><li>IP laws are becoming restrictive

34.
In SA, software patents are not yet a major risk, but have the potential to be soon.

35.
US and EU patent systems can be limiting, but with careful licensing and distribution channels the risks can be mitigated.

36.
MSN case </li></ul>

37.
The tangible dangers

38.
Licensing <ul><li>GPL is a Free license

39.
Allows works to be used in commercial projects too

40.
All we ask is that if you make enhancements THAT DO NOT CONTAIN YOUR BUSINESS MODEL (i.e. NON differentiating software), please share them and make the world a better place

41.
Many other Free licenses, all in simple English and minimal legalese </li></ul>

42.
Documentation <ul><li>The bane of a developers' existance!

43.
Self documenting code is the norm in FOSS

44.
Great docs can be generated autoatically from the sourcecode

45.
User manuals are written more slowly, but do appear.

46.
Great way to contribute to FOSS projects if you are not a coder! </li></ul>

47.
Sharing is caring <ul><li>There is very little software that contains proprietary business process within the sourcecode

48.
There is no reason not to release most source into the public domain. Who knows, you may even get some improvements free (as in beer)!

49.
Leverage the FOSS communities and they will help you out. Contribute back for added fun and profit! </li></ul>

50.
&quot;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.&quot; Richard Stallman Free Software Foundation.

51.
What does Free mean? <ul><li>The freedom to </li><ul><li>run the program for any purpose

52.
study how the program works, </li></ul></ul>and to adapt it to your needs <ul><ul><li>redistribute copies

53.
improve the program, and release your improvements to the public. </li></ul></ul><ul><li>These freedoms require access to the source code </li></ul>Source code: if encrypt(password) == encryptedpassword, then login=1, end Compiled code: 001001011101010011001100001111011000110001110001101

54.
What are you getting into? <ul><li>Huge </li><ul><li>e.g. IBM > 1 billion $ per year

55.
e.g. 230K projects, 2M contributors @ sourceforge.net </li></ul><li>Well organised

56.
Several business models

57.
User friendly ← written by users for users

58.
Cross-platform ← recompile source code

59.
High development pace ← reuse of best modules

60.
High quality ← peer review, reuse = survival of the fittest

61.
High security ← peer review, Unix origin, modular, encryption </li></ul>

62.
Why FOSS? <ul><li>reduce (license) costs

63.
reduce digital divide

64.
eliminate software piracy

65.
easier license management

66.
easy to localize and customize

67.
better quality (peer review, intrinsic-motivated developers)

68.
increase security (security by design vs security by obscurity)

69.
increase interoperability (open standards)

70.
reduce dependencies from monopolies & foreign software companies </li></ul>

71.
Percieved barriers

72.
Perceived barriers

73.
Perceived barriers <ul><li>Fear, Uncertainty and Doubt about </li><ul><li>features?

74.
quality? (hobbyist programmers)

75.
sustainability?

76.
support?

77.
requirement to participate in the community? </li></ul></ul>

78.
Perceived barriers <ul><li>anti-competitive behaviour </li><ul><li>monopoly abuse

79.
secret formats

80.
secret protocols

81.
data and vendor lock-ins </li></ul></ul>

82.
It comes down to <ul><li>Education </li><ul><li>“ We teach MS because that is what companies use” </li></ul><li>Companies </li><ul><li>“ We cannot use FOSS because our employees don't know it” </li></ul><li>Employees </li><ul><li>Growing number starts using FOSS at home

83.
Not happy with inferior software at work </li></ul></ul>

86.
When to migrate? <ul><li>Time transitions </li><ul><li>at the end of existing contracts

87.
at hardware / software upgrade times </li></ul><li>Consider migrating in phases </li><ul><li>servers

88.
desktop applications </li><ul><li>-> multi-platform

89.
-> web-based </li></ul><li>desktop OS </li></ul></ul>

90.
Key success factors <ul><li>resources to experiment

91.
an evidence-based choice

92.
involvement of both technical and non-technical users in the selection process

93.
choice for a new system which is in all aspects at least as good and easy as the previous one

94.
reporting detailed migration plan to management and get their approval and support

95.
in-house expertise with open source software and communities

96.
contact with the developers and users community </li></ul>

97.
The Open Way <ul><li>avoid local customization without </li><ul><li>contributing back

98.
participating in the community </li></ul></ul><ul><li>establish an 'open source culture' of re-use, collaboration and sharing

99.
share experiences </li></ul>

100.
Acknowledgements <ul><li>Pictures </li><ul><li>Doubt by Elenaa Marie (Flickr)

101.
Lockin, claustrofobia by Laororo (Flickr) </li></ul><li>Slides </li><ul><li>Some slides remixed from Prof. Dr. Frederick Questier

102.
Some slides remixed from Prof. Dr. Derek Keats

103.
Some slides remixed from previous AVOIR slides </li></ul><li>All slides licensed under Creative Commons By Attribution Sharealike </li></ul>

105.
Online : http://www.chisimba.com Email : [email_address] We are grateful to the IDRC, USAID, the Department of Science and Technology, UNESCO and Sun Microsystems for financial and other support to the AVOIR project. We are also grateful to those organizations who had enough confidence to contract us to develop applications even though we were then unproven .