Archive for April 12th, 2010
Welcome to the fourth part ofÂ our little analysis of OSS business models (first part here, second part here, third part here). It is heavily based on the Osterwalder model, and follows through the examination of our hypothetical business model; after all the theoretical parts, we will try to add a simple set of hands-on exercises and tutorials based on a more or less real case. We will focus today on the remaining parts of our model canvas (with less detail, as those parts are more or less covered by every business management course…), and will start a little bit of “practical” exploration, to create the actors/actions model that was discussed in the previous instalments.
Cost structure: this is quite simple – the costs incurred during the operation of our business model. There are usually two kind of models, called “cost-driven” (where the approach is minimization of costs) or “value-driven” (where the approach is the maximization of value creation). Most models are a combination of the two; for example, many companies have a low-cost offering to increase market share, and a value offering with an higher cost and higher overall quality. In open source companies it is usually incorrect to classify the open source edition as “cost-driven”, unless a specific price and feature difference is applied between a low-level and high-level edition.
Key partners: do our company partners with external entities? Common examples are resellers, external support providers, and so on. Additional examples may be partnerships with other companies or external groups for co-development of the OSS components (even competitors may share work on improving a reciprocally useful OSS package); sometimes the partnership may be informal (for example, with an OSS community) but fundamental as well.
Key activities: what is the basis of our work in our hypothetical OSS company? Of course, software development may be a big part; other examples are marketing, support… every company do have a specific mix, that is easily recognized simply by looking at what each person inside the company is doing right now.
Channels: how do we contact our customers, or potential ones? Directly? Through an external channel? Each channel provide different properties; web marketing is different from web word-of-mouth, exactly like radio advertising is different from print advertising. Choosing an appropriate channel is adifficult art, and is something that changes with time.
Customer relationships: How does the customer (or potential customer) interact with our company? Only through the software? Through online or in-person channels, like workshops? Support is self-service (the customer does it by itself) or requires human interaction? Is this interaction monitored? By who? A special case is handling the relationship with contributors (that are offering something of value to the company, without an economic intermediation) and OSS communities, that should be handled as a distinct entity (and not simply a collection of individuals). In this area I depart a little bit from the original Osterwalder model, by including not only customers but any interacting actor that provides value to the company, in one form or the other; this allows us to model in a more accurate way all those interactions that are not strictly monetary,
Revenue streams: this is easy! How the money enters your company? Is it structured in one-time payments, multiple recurring payments? Are there alternative form of revenue?
Are you still with me? Now that you have collected all the data on your company, the fun begins. We need to draft the network of actors (like your key resources, customer segments, external contributors…) and link these actors together with their relationship and effect. Some relations may impact on specific variables whileÂ changing others (lowering the attractiveness of the community edition may increase conversion rates, but lower overall adoption rates).
In the next instalment we will provide an initial draft, and will later show how to convert this graph into a small and simple simulation.