6B: Building and managing communities in the developing world
(Problem solving: difficulty getting engagement)
Michael Drane (Drano)
- Interhealth International
- HR information system called Iris
- Poor connectivity, cultural, …
Alec Smecher (Public Knowledge Project)
- Attracting developers in developing world
- Small project with big impact
Michael Downey (OpenMRS)
- Medical record system
- Struggle with balancing high “developer” world with e.g. bandwidth needs
- Keeping software small
Ryan Singer (Market strategy and partner strategy), Bitcoin Entrepreneur
- Worked with OpenOffice.org community
- $3-400 billion in remittances; average fees high. Rich stealing form poor.
- Bitcoin as a low-cost alternative. Latin America, Africa, Asia…
- Primary challenges are BizDev; finding local partners (importers are best)
Heather (JCP: Java Community Process)
- Seeing Latin America, Russia, Middle East, Africa, Asia participation growing
Thuy Tu: Civil Engineering
- What kind of work; what risks you take
- Recent experience in Belize. Got a random offer about handling recycling. Wondering whether to take it.
- Microfinance software vendor
- New to technical world
- Student at University of Washington - Business Administration
- 15 years’ experience (10-12 professionally)
- Finding it depressing, frustrating, fun to hear group raising familiar issues
- Seeing more interest in problem-solving
- Half of us here are involved in humanitarian FOSS; half from independent/mega/large companies
Let’s try to talk about specific places rather than euphemistic “developing world”.
- Sub-Saharan Africa
- Central/Latin America
- Various parts of Asia?
- Hangouts, Skype, etc. can be too demanding. How do you engage?
- Synchronous communication has been bad. Asynchronous or low-fi (IRC) more successful.
- Using meet-ups / workshops to fill the void left by asynchronous (email etc.)communication
- Local meet-ups one example
- Finding an oranization with mandate/resources to set up workshops another example
- Local partners / champions (see “culture”)
- One experience using IRC (even in person) to manage spoken English requirement.
- Culture / dependency
- Wanting to avoid establishing dependency (the soul of FOSS is independence)
- Identifying and tapping local resources.
- e.g. Vietnam: very hesitant to ask questions
- Using asynchronous communication may help (time to put thoughts together; English)
- Matching a fairly fresh (non-intimidating) person up with a newbie to bring them on
- How did that work? Created a volunteer role (“guide”)
- People don’t know how to program even though they claim to.
- Cycle length. How do you plan this from the basics?
- Can small projects afford that investment?
- Choose local partners very carefully to ensure a baseline.
- Notions of collaboration. People don’t have the same notion.
- Combatting fear of “having heads chopped off”
- Use challenges. Should have fun, but should feel challenged.
- Communication breakdown may indicate more face time is required
- Philosophical – can we expect less monied societies to sacrifice security for FOSS feel-goods?
- e.g. A central figure in India FOSS contributor passes away; community is threatened b/c of loss.
- Local business development as a way to influence local culture in a sustainable way
- Job requirement (e.g. medical systems – have to have something, FOSS one option)
- Career advancement. That’s great, but how do you get them to stick around?
- It might be a loss of a person, but it means refining/building the process.
- Consider “infinite” supply of awesome potential people. Everyone who leaves, leaves aware of your project.
- Asynchronous is a necessary, big piece of the pie.
- Nothing beats boots on the ground for high-bandwidth engagement
- May involve considerable investment in skill development
- Culture was a major topic of discussion.
- Different ideas of collaboration
- Finding the incentive that applies where you are: Philosophical; Business development; Career advancement
- Gnome; Debian; Guadec