One of the drivers behind the Betavine Social Exchange is to encourage the mobile ecosystem in emerging markets – help local entrepreneurs to think about the mobile space and its opportunities.  This is a very challenging target and will need a number of key enablers in place i.e. understanding the utility of mobile, understanding the technical issues and knowledge of the business models available.

In creating the Betavine Social Exchange website we are currently thinking about 3 key groups of stakeholders or “audiences” – owners, contributors and activators.


This is the group that “own” the problem or challenge that could be addressed by a mobile solution.   The problem owners can come from many difference and diverse organisations e.g. NGOs, government departments, universities.  The problem owners are those organisations and individuals who understand the situations on the ground and are able to describe it clearly to others.

The engagement of the problem owners with the Betavine Social Exchange is key to its success.  The Betavine Social Exchange will seek to make it very easy to describe a problem in a way that is accessible to the problem owner but also helpful to the contributors and activators.


This group are the mobile developers or other mobile enthusiasts who have the knowledge or interest in “contributing” towards mobile solutions for the defined problems.   Contributions can be helpful pointers, software (open source code), time to lead a co-creation project online, user interface designs or business advice.

Contributions can come from anyone in the world … the global mobile development community or mobile enthusiasts.  The beneficiaries are the local entrepreneurs who are able to deploy a mobile solution that meets a pre-defined and real problem.


This group is made up of the local businesses or entrepreneurs in the emerging markets that are willing to step forward and “activate” a mobile solution in the local market.  One key advantage for the activators is that the customer, the problem owner, has already been indentified and a mobile solution is available to review.

Local activators can pre-register their interest and engage with the co-creation phase of the project.

Funding for local entrepreneurs can come from many different sources but one possibility is to use kiva.


I have been aware of kiva for a while but it was not until recently that I actually registered and lent some money to a fishmonger in Ghana.  The whole concept behind Kiva is awesome!  I love it.  The website is very simple to use and the process is clearly explained in every step.  I am not surprised that it has been such a great success.  It does the job it set out to do very well.

I am taking note of its success and hoping to learn a lot from it.  I am sure there should be a clear link from the Betavine Social Exchange to Kiva … not sure exactly how this will work but I am going to eplore the possibilities.


The team at the Meraka Institute have sent me some initial comments on the BSX.

An encouraging opening statement from the team: “we have not seen the concept of the co-creation space and tools actually specified before! Really like it!”

The team go on to add:

1. Local skills development should be part of the objectives of the Betavine Social Exchange.

Agreed. They are part of our overall objectives and the objectives of the Vodafone Social Investment Fund.  We need to consider what features and tools on the website would be helpful to the local developer community.   We are working on the concept of the Betavine Academy – which should go some way towards achieving this goal.

2. Linking experienced developers with new developers in a kind of “mentoring” relationship.

This is something that we hoped would result from the Betavine Social Exchange and the forums may be the best place for the interaction to take place.  We will explore ways of “connecting” willing mentors with those interested in learning.

3. Are we missing a “piloting and feedback” mechanism? This would allow many iterations of the solution.

The idea we are working on is to make the co-creation space flexible such that it will support as many iterations as required.  Feeback will be collected on the specific solution and the solution will be updated for another iteration.

Maybe we need to define version numbers for solutions?

4. The “softer” issues also need to be considered.

I guess that you are referring to the user interface design, business models, etc.  The plan is to have input of this nature directly into the co-creation space.  Also, we will be working on a “deployment options” information service to help to get the solutions deployed and put to good use.

As usual all feedback welcome … see the requirements on the LLiSA wiki.