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.


Last Thursday was our first workshop with Dare Digital to go through the requirements for the Betavine Social Exchange .. requirements now updated on the LLiSA wiki.

We still have a lot of work to do, including some research on our target audience – the NGO community.  

We agreed that we need to keep the whole concept of the “solution space” or “co-creation space” simple and easy to use.  The co-creation space should:

  • encourage participation from problem owners and solution providers
  • allow other Betavine members to comment on the developing solution
  • clearly show what stage the project is at e.g. concept, development, testing, deployment
  • have a “notes” section (blog?) for the solution team to record requirements, design decision etc.
  • allow “deployment teams” to make suggestions and set criteria that would need to be met for that particular team to take the solution to deployment

We have a few more workshops planned before moving on to the Information Architecture (IA) phase.

I have a few good questions from Stephane Boyera, co-chair, W3C   Mobile Web for Social Development (MW4D) Interest Group.

1. Are we targetting particular technology?

No, we are planning to be as open as possible and encompass as many types of solutions (voice, SMS, widgets, native applications, mobile web) , platforms (Symbian, linux, Windows Mobile …etc   ) and runtimes (JavaME, Widget Managers, webkits … etc) as possible.

2. Is there a particular role for operator(s) in this framework or the objectives is to implement services independently? Reading “ready for deployment via local operators or partners” means that the business model or the monetization of the final services will be ensured by a set of partners you already have?

Again, we are planning to be open on this.  Solution deployment will depend on local market conditions.  Once a suitable solution has been identified or created it is “business as usual” in terms of local deployment.   Also, local SMEs and entreprenuers may take a solution to market.

3.  Are you planning for closed challenges to have packaged solutions that  would be easily customizable/replicable?

I believe that a lot of the solutions will be in existance already and it may be simply matching up the solution with the problem.  I have not envisaged any closed challenges .. but maybe that would be useful?

4. What is the related IPR?

All IPR remains with the creator / developer.  Developers on Betavine are advised on how to protect their IP in the Betavine IPR Guidelines.  Once a solution is identified for deployment it is “business as usual” and the various parties involved need to agree terms.

I am hoping that over time we will be able to offer information on the variety of deployment options and point to useful resources.

I have now uploaded the first draft of the Betavine Social Exchange requirements and use cases to the LLiSA wiki.

The BSX will extend the scope of Betavine functionality for developing and testing new mobile apps.
Core new domains are:

  1. Problem Capture / Needs Definition
  2. Co-Creation tools
  3. Discovery mechanisms e.g. search, categorisation (social investment domain, country…)
  4. Mobile solutions that are capable of being deployed by local operating companies or third parties

We shall be working with the folk from Living Labs in Southern Africa (LLiSA) over the coming months to refine these requirements and set up a pilot for the BSX in South Africa.

Now I need to figure out how to get people to view and comment on the requirements.

I really would like to crowdsource the requirements, at least the review, correction, addition to the requirements of the Betavine Social Exchange.

I have been given a page on Living Labs in Southern Africa website to post the requirements – this is a great opportunity to engage NGOs in South Africa as the LLiSA community already has members who are NGOs or NPOs (non-profit organisations).  Also, I met some very passionate people connected with the living labs in South Africa in February.

My page is in the Industrial Stakeholders section and is called Vodafone Betavine Social Exchange.  I still have a bit of work to do on the requirements but hope to post them on the weekend.  Once up on the LLiSA site I will outline them in a post and try to get some comments.


One issue I have realised about crowdsourcing is that within my team I can dictate the deadline but that is not so easy when crowdsourcing, I will need to do a lot of work to get the message out so that a percentage of those who read the blog actually comment on it.  I read somewhere, “Innovation happens Elsewhere” I think it was, that open source software projects can take more time and cost more that conventional software projects.  Clearly, there are many good reasons to open source software – see Symbian Foundation , for example – but it is not a free lunch.

So, will it take longer to resolve a consistent and implementable set of requirements via crowdsourcing that more conventional routes?  We will see.