Archive for April, 2010
Just a few days ago, Glynn Moody posted a tweet with the message: “Italy to begin an open source competence centre”; a result of the recent EU project Qualipso, created with the purpose to identify barriers to OSS adoption, quality metrics and with the explicit target of creating a network of OSS competence centers, sharing the results of the research effort and disseminating it with the European community of companies and public administration. For this reason, the project created more than one competence center, and created a network (that you can find under this website) to cover not only Europe, but China, India and Japan as well. This is absolutely a great effort, and I am grateful to the Commission and the project participants for their work (hey, they even cited my work on business models!)
There is, however, an underlying attitude that I found puzzling – and partially troubling as well. The announcement mentioned the competence center of Italy, and was worded as there was no previous such effort in that country. If you go to the network website, you will find no mention of any other competence center there, even when you consider that the Commission already has a list of such centers (not much updated, though) and that on OSOR there is even an official group devoted to Italian OSS competence centers, among them two in Friuli (disclaimer: I am part of the technical board of CROSS, and work in the other), Tuscany, Trentino, Umbria, Emilia (as part of the PITER project), a national one and many others that I probably forgot. Then we have Austria, Belgium, Denmark, Estonia, Finland, Germany, Ireland, Malta, Netherlands, Nordic Countries and many others. What is incredible is that most of these centers… actually don’t link one with the other, and they hardly share information. The new Qualipso network of competence centers does not list any previous center, nor does it point to already prepared documentation – even by the Commission. The competence center network website does not link to OSOR as well, nor does it links to other projects – past or current.
I still believe that competence centers are important, and that they must focus on what can be done to simplify adoption – or to turn adoption into a commercially sustainable ecosystem, for example by facilitating the embracing of OSS packages by local software companies. In the past I tried to summarize this in the following set of potential activities:
- Creating software catalogs, using an integrated evaluation model (QSOS, Qualipso, FLOSSMETRICS-anything, as long as it is consistent)
- For selected projects, finds local support companies with competence in the identified solution
- Collect the needs of potential OSS users, using standardized forms (Technology Request/Technology Offer, TR/TO) to identify IT needs. Find the set of OSS projects that together satisfies the Technology Request; if there are still unsatisfied requirements, join together several interested users to ask (with a commercial offer) for a custom-made OSS extension or project
- Aggregate and restructure the information created by other actors, like IST, IDABC, individual national initiatives (OSOSS, KBST, COSS, …)
This models helps in overcoming several hurdles to OSS adoption:
- Correctly identify needs, and through analysis of already published TR can help in aggregating demand
- Helps in finding appropriate OSS solutions, even when solutions are created through combination of individual pieces
- Helps in finding actors that can provide commercial support or know-how
It does have several potential advantages over traditional mediation services:
- The center does NOT participate in the commercial exchange, and in this sense acts as a pure catalyst. This way it does not compete with existing OSS companies, but provides increased visibility and an additional dissemination channel
- It remains a simple and lean structure, reducing the management costs
- By reusing competences and information from many sources, it can become a significant learning center even for OSS companies (for example, in the field of business models for a specific OSS project)
- It is compatible with traditional IT incubators, and can reuse most of the same structures
Most of this idea revolves around the concept of sharing effort, and reusing knowledge already developed in other areas or countries. I find it strange that the most difficult idea among these competence centers is… sharing.
(update: corrected the network project name – Qualipso, not Qualoss. Thanks to Matteo for spotting it.)
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.