O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Foss4Africa Paul Scott keynote

Próximos SlideShares
Carregando em…3

Confira estes a seguir

1 de 34 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Foss4Africa Paul Scott keynote (20)


Mais recentes (20)

Foss4Africa Paul Scott keynote

  1. 1. FOSS in Africa FOSS Africa Convention Indaba Hotel April 2010 Paul Scott http://www.paulscott.za.net/
  2. 2. Casting a larger net <ul><li>Working collaboratively </li><ul><li>African talent
  3. 3. Bandwidth constraints
  4. 4. Cultural constraints </li></ul></ul>
  5. 11. Communication is key <ul><li>How do you collaborate?
  6. 12. We need to use low(er) bandwidth friendly technology
  7. 13. Mailing lists, IRC, Web optimised for low bandwidth
  8. 14. Constant communication to create community
  9. 15. Everyone feels part of the community, no matter what the situation is! </li></ul>
  10. 16. Version Control <ul><li>What is version control?
  11. 17. Must be used in any collaborative effort
  12. 18. Not just for code, docs, wiki and images too!
  13. 19. Must be distributed and provide a central repository
  14. 20. Single point of truth for collab efforts
  15. 21. Able to operate in low bandwidth environments </li></ul>
  16. 22. Marketing <ul><li>Single most difficult thing to do
  17. 23. We have a culture of not thinking the best of ourselves
  18. 24. US and EU projects look to us for the lead (Drupal, Joomla! Etc)
  19. 25. Marketing costs a lot of money
  20. 26. Not many people experienced in tech/FOSS marketing and community building in Africa </li></ul>
  21. 27. Social Media <ul><li>Marketing can be achieved informally too
  22. 28. Search Twitter for #Chisimba! Constant tweets and updates from many sources
  23. 29. Subversion also tweets so stakeholders are made aware of progress constantly and in real time
  24. 30. Facebook group
  25. 31. Flickr group
  26. 32. Blogs, forum and Google Groups </li></ul>
  27. 33. IP / Patents <ul><li>IP laws are becoming restrictive
  28. 34. In SA, software patents are not yet a major risk, but have the potential to be soon.
  29. 35. US and EU patent systems can be limiting, but with careful licensing and distribution channels the risks can be mitigated.
  30. 36. MSN case </li></ul>
  31. 37. The tangible dangers
  32. 38. Licensing <ul><li>GPL is a Free license
  33. 39. Allows works to be used in commercial projects too
  34. 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
  35. 41. Many other Free licenses, all in simple English and minimal legalese </li></ul>
  36. 42. Documentation <ul><li>The bane of a developers' existance!
  37. 43. Self documenting code is the norm in FOSS
  38. 44. Great docs can be generated autoatically from the sourcecode
  39. 45. User manuals are written more slowly, but do appear.
  40. 46. Great way to contribute to FOSS projects if you are not a coder! </li></ul>
  41. 47. Sharing is caring <ul><li>There is very little software that contains proprietary business process within the sourcecode
  42. 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)!
  43. 49. Leverage the FOSS communities and they will help you out. Contribute back for added fun and profit! </li></ul>
  44. 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.
  45. 51. What does Free mean? <ul><li>The freedom to </li><ul><li>run the program for any purpose
  46. 52. study how the program works, </li></ul></ul>and to adapt it to your needs <ul><ul><li>redistribute copies
  47. 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
  48. 54. What are you getting into? <ul><li>Huge </li><ul><li>e.g. IBM > 1 billion $ per year
  49. 55. e.g. 230K projects, 2M contributors @ sourceforge.net </li></ul><li>Well organised
  50. 56. Several business models
  51. 57. User friendly ← written by users for users
  52. 58. Cross-platform ← recompile source code
  53. 59. High development pace ← reuse of best modules
  54. 60. High quality ← peer review, reuse = survival of the fittest
  55. 61. High security ← peer review, Unix origin, modular, encryption </li></ul>
  56. 62. Why FOSS? <ul><li>reduce (license) costs
  57. 63. reduce digital divide
  58. 64. eliminate software piracy
  59. 65. easier license management
  60. 66. easy to localize and customize
  61. 67. better quality (peer review, intrinsic-motivated developers)
  62. 68. increase security (security by design vs security by obscurity)
  63. 69. increase interoperability (open standards)
  64. 70. reduce dependencies from monopolies & foreign software companies </li></ul>
  65. 71. Percieved barriers
  66. 72. Perceived barriers
  67. 73. Perceived barriers <ul><li>Fear, Uncertainty and Doubt about </li><ul><li>features?
  68. 74. quality? (hobbyist programmers)
  69. 75. sustainability?
  70. 76. support?
  71. 77. requirement to participate in the community? </li></ul></ul>
  72. 78. Perceived barriers <ul><li>anti-competitive behaviour </li><ul><li>monopoly abuse
  73. 79. secret formats
  74. 80. secret protocols
  75. 81. data and vendor lock-ins </li></ul></ul>
  76. 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
  77. 83. Not happy with inferior software at work </li></ul></ul>
  78. 86. When to migrate? <ul><li>Time transitions </li><ul><li>at the end of existing contracts
  79. 87. at hardware / software upgrade times </li></ul><li>Consider migrating in phases </li><ul><li>servers
  80. 88. desktop applications </li><ul><li>-> multi-platform
  81. 89. -> web-based </li></ul><li>desktop OS </li></ul></ul>
  82. 90. Key success factors <ul><li>resources to experiment
  83. 91. an evidence-based choice
  84. 92. involvement of both technical and non-technical users in the selection process
  85. 93. choice for a new system which is in all aspects at least as good and easy as the previous one
  86. 94. reporting detailed migration plan to management and get their approval and support
  87. 95. in-house expertise with open source software and communities
  88. 96. contact with the developers and users community </li></ul>
  89. 97. The Open Way <ul><li>avoid local customization without </li><ul><li>contributing back
  90. 98. participating in the community </li></ul></ul><ul><li>establish an 'open source culture' of re-use, collaboration and sharing
  91. 99. share experiences </li></ul>
  92. 100. Acknowledgements <ul><li>Pictures </li><ul><li>Doubt by Elenaa Marie (Flickr)
  93. 101. Lockin, claustrofobia by Laororo (Flickr) </li></ul><li>Slides </li><ul><li>Some slides remixed from Prof. Dr. Frederick Questier
  94. 102. Some slides remixed from Prof. Dr. Derek Keats
  95. 103. Some slides remixed from previous AVOIR slides </li></ul><li>All slides licensed under Creative Commons By Attribution Sharealike </li></ul>
  96. 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 .