FOSS Business Models and Sustainability

From Wiki

Overview of existing FOSS business models

General comment on "generic" vs. unique software functionality: FOSS business models may tend to work better with applications where unique IP and/or business strategy/logic are not embedded in the application. Though projects like Asterisk serve as counter-examples.

• Support model: Red Hat

• Consulting model(s): Open Source CMS

• Data-dependent model: code is FOSS, but depends on non-open data

• ASP hosted services: value-added hosting around FOSS: value is in hosting, up-time, support, maintenance

• Hardware-based business models: linsys routers, linux cellphones make money on hardware sales and/or subscriptions where open source is just an ingredient in the product offering.

• MySQL: dual licensing, free to GPL projects, not free to proprietary

build/deploy/support

Question: custom development: extending CMS, developing

Question: How well do these models transfer to Africa? It's hard to make money in Africa

Question: is the majority of IT expenditure in developing countries government-driven?

Mark D's Answer: apart from large telecoms, yes. But trying to have government understand the difference between free/open source is quite difficult.

Mark D: it's difficult to have enough FOSS support options. Until you get to that tipping point where there's more demand and prices come down, you're kind of stuck. Microsoft is lower quality, but it's more cost effective. It may be different in Kenya – bigger markets, more options.

Mark D: we also have a “disease” in “certific-itis”. All folks want is certificates, not knowledge. Microsoft does this quite well in certifying MS expertise. We need that in Linux.

Chris S: there's also a difference between NGO's and private enterprise; NGO's can use grants and other sources in ways that companies might not.

Now let's talk through a scenario and discuss business model and sustainability:

Mark D: We could either take drumnet and move that forward, or take a fictional scneario (Diane from Zambie has an opportunity to build a product).

Let's take DrumNet

Robert: DrumNet wants to connect 4 actors: buyer, farmer/producer, banks, and input suppliers (fertilizer, etc). We want to have a seamless interface between these suppliers

MFI: Market / Finance / Information

Using phones and internet to connect these actors is a win win: banks loan and make money, farmers get support and sales, buyers get better organized local market, suppliers sell product.

How do we build the software and how do we mediate the deployment?

Biggest challenge is getting the farmer to interact with the system reliably.

Use case:

Farmers join, indicating number of Sunflower acres to be planted SMS/email sent to suppliers, telling them how much to ship to farmer Suppliers send goods to a stockist Farmers pick up goods

Trying to do whole chain of communication using SMS

Opportunity is that agricultural markets are poorly served, and system like above can introduce efficiencies and transparency into the market place.

Mark S: we've struggled with the business model: is it transactional, is it ASP, is it training and support?

Mark D: right now DrumNet is FOSS and Tradenet is proprietary. There are multiple dimensions: it needs to be private sector, social impact, profitable, and African

Mark S: We've struggled with our value proposition: no one thing we do is uniqe; is our aggregate offering unique enough?

Mark D: our business model is subscriptions to using the service and SMS transactions.

Edith: when you have funders in the equation, funders are distributing taxpayers money. It can't go directly to private sector. It can become private sector after the funding, but not during the funding period.

BREAK

Mark D: you're driving facebook for the agricultural community driven by cell phones. DrumNet would be one module within that system. If you're getting information that is useful to you, you're going to pay for it.

Mark S: we have a “throw-away” prototype, and what will probably happen. This version has been a requirement-building exercise. Actors thought it was great at the 10,000 level, but at the detailed level it was confusing to figure out how it worked.

Mark D: A discovery in this phase has been how complex the relationships are and how to service them, identifying the roles and responsibilities

Now let's do some scenario modeling for DrumNet with an open source platform:

Scenario	Drumnet Value Add	Revenue Sources	Risks	Advantages
Single Instance	Market and Actor knowledge and relationships, Trust Factor, System knowledge	Transaction & interest fees, Certifications, Training & doc, Access fees/sponsorships	Cloned by competition	Goodwill, Trust, leadership by example, 3rd party contributions
Franchise (contractual)	Markets knowledge, Strategic consulting, Organization development	Consulting, % of volume, Support, Customization	Contract non-compliance via hacked code or fake data
ASP model	content/data integration, scale in markets (a/k/a critical mass)	Hosting fees, meta-consulting, partnering, advertising
Data-centric	Unique data, “Secret sauce”	Selling data, consulting on data	Reverse engineering