Archive for category OSS data
Estimating source-to-product costs for OSS: an experiment
Posted by cdaffara in OSS business models, OSS data on August 10th, 2010
One of my recurring themes in this blog is related to the advantages that OSS brings to the creation of new products; that is, the reduction in R&D costs through code reuse (some of my older posts: on reasons for company contribution, Why use OSS in product development, Estimating savings from OSS code reuse, or: where does the money comes from?, Another data point on OSS efficiency). I already mentioned the study by Erkko Anttila, “Open Source Software and Impact on Competitiveness: Case Study” from Helsinki University of Technology, where the author analysed the degree of reuse done by Nokia in the Maemo platform and by Apple in OSX. I have done a little experiment on my own, by asking IGEL (to which I would like to express my thanks for the courtesy and help) for the source code of their thin client line, and through inspecting the source code of the published Palm source code (available here). Of course it is not possible to inspect the code for the proprietary parts of both platforms; but through some unscientific drill-down in the binaries for IGEL, and some back of the envelope calculation for Palm I believe that the proprietary parts are less than 10% in both cases (for IGEL, less than 5% – there is a higher uncertainty for Palm).
The actual results are:
- Total published source code (without modifications) for IGEL: 1.9GB in 181 packages; total amount of patch code: 51MB in 167 files (the remaining files are not modified). Average patch size: 305KB, Patch percentage on total publisheed code: 2.68%
- Total published source code (without modifications) for Palm: 1.2GB in 106 packages; total amount of patch code: 55MB in 83 files (the remaining files are not modified). Average patch size: 664KB, Patch percentage on total published code: 4.58%
If we add the proprietary parts and the code modified we end up in the same approximate range found in the Maemo study, that is around 10% to 15% of code that is either proprietary or modified OSS directly developed by the company. IGEL reused more than 50 million lines of code, modified or developed around 1.3 million lines of code. Without OSS, that would have costed more than 2B$, required a full staffing of more than 700 people for an effort duration of more than 20 years. Through OSS, the estimated cost (using the more appropriate semidetached model) is around 90M$, with an average staffing of 150 people and an estimated project duration of 5 years. Palm has a similar cost (the amount of modified code is quite similar), but starting from a smaller amount of reused code (to recode everything would still require 12B$, 570 people and 18 years of work). We have to add some additional costs (for an explanation you can check my previous post on the proper use of COCOMO II and OSS, using the model by Abts, Boehm and Bailey) that would bring the total cost to a little less than 100M$ (still substantially less than the full cost of development from scratch).
Open Source allows to create a derived product (in both case of substantial complexity) reducing the cost of development to 1/20, the time to market to 1/4, the total staff necessary to more than 1/4, and in general reduce the cost of maintaining the product after delivery. I believe that it would be difficult, for anyone producing software today, to ignore this kind of results.
Addendum: I received some requests for specific parts of source code from people willing to check the kind of modifications performed. For Palm, the website provides both original source code and patches. For IGEL, I requested the access to the source code, and was kindly provided with a username and password to download it. Since the single most requested file seems to be the modified rdesktop, I have linked the GPL sources here.
A small and unscientific exploration of OSS license use
Posted by cdaffara in OSS data, divertissements on March 17th, 2010
I was intrigued by an excellent (as usual) post by Matthew Aslett of 451 group, titled “On the fall and rise of the GNU GPL“, where Matthew muses on the impact of cloud computing and other factors in the decreasing role of the GPLv2 versus other type of licenses. Simon Phipps twitted “you only consider number of projects and not volume of deployed code. I have never found number of projects compelling” which is something that I absolutely believe is true: it is, however, quite difficult to imagine other possible ways to measure “impact” of a project. Do we have to add a weight related to usage? Then, given the large use of Linux, GNOME or KDE, OpenOffice, Firefox we would probably see a huge jump in the GPL and MPL percentages, at the cost of added uncertainty (as usage estimates are variable at best). As I am desperately try to avoid doing real work, I started using the Ohloh web site to extract slightly less than 100 projects (among the “active” ones, so there is already an initial preselection), along with the licensing and the number of committers for each project. My idea was to measure not only the number of projects, but how many people contributes to each, to see if this scenario gives different percentages. In a sense, the number of committers is a measure of “activity” or community interest in a project, and so my idea was to see if there was a difference between the percentages obtained with only the amount of projects listed under a license, and the number of committers using a license. The result is this:
| license | projects | committers | %projects | %committers | blackduck % |
| gpl2 | 49 | 15878 | 52.1% | 62.9% | 48.83 |
| lgpl | 8 | 2286 | 8.5% | 9.1% | 9.35 |
| mit | 6 | 1668 | 6.4% | 6.6% | 4 |
| bsd | 8 | 1150 | 8.5% | 4.6% | 6.26 |
| gpl3 | 3 | 988 | 3.2% | 3.9% | 5.5 |
| php | 2 | 730 | 2.1% | 2.9% | 0.24 |
| cddl | 1 | 673 | 1.1% | 2.7% | 0.32 |
| mpl | 2 | 655 | 2.1% | 2.6% | 1.22 |
| apache | 10 | 557 | 10.6% | 2.2% | 4.02 |
| boost | 1 | 266 | 1.1% | 1.1% | |
| epl | 2 | 241 | 2.1% | 1.0% | 0.46 |
| python | 1 | 133 | 1.1% | 0.5% | |
| cpl | 1 | 6 | 1.1% | 0.0% | 0.56 |
The result is interesting: first of all, by looking in terms of contributors, the GPLv2 has an higher percentage of committers than that of projects; that is, there are more committers per project under the GPLv2 in respect to the normal share. The percentage of projects obtained is similar to that from BlackDuck (52.1% versus 48.83%), so I think that there is not too much bias in the choice of projects. The LGPL has more or less its fair share of committers, on a par with the number of projects and the results from BlackDuck. MIT is slightly higher, both in projects and commits, while the GPLv3 is under-represented – probably because the sample is too small, and in the project selection the “new” projects under the GPLv3 simply were not among the first 100 or so selected. A substantial difference exist for Apache-licensed projects, where the average number of committers seems smaller than its fair share; this may be an artefact of the project selected, or may be simply an effect of how Ohloh measures the active committers (I find strange that Boost has half of all the committers of all the Apache projects together!)
As I said, this is a little, unscientific experiment designed to explore what we can invent to better measure the “impact” of an OSS project. I would love to receive you comments and suggestions; on my side, I will try to leverage the FLOSSMETRICS database to try to find some numbers on a more consistent data sample.
On licenses, communities, business models
Posted by cdaffara in OSS business models, OSS data on August 28th, 2009
The debate on whether the GPL is going the way of the dodo or not is still raging, in a way similar to the one on open core – not surprisingly, since they are both related to similar aspects, that intermingle technical and emotional aspects. A recent post from BlackDuck indicates that (on some metric, not very well specified unfortunately) the GPLv2 for the first time dropped below 50%; while Amy Stephen points out that the GPLv2 is used in 55% of the new projects (with the LGPL at 10%), something that is comparable to the results that we found in FLOSSMETRICS for the stable projects. Why such a storm? The reason is partly related to a strong association of the GPL with a specific political and ethical stance (an association that is, in my view, negative in the long term), and partly because the GPL is considered to be antithetic to so-called “open core” models, where less invasive licenses (like the Apache or Eclipse licenses) are considered to be more appropriate.
First of all, the “open core” debate is mostly moot: the “new” open core is quite different from the initial, “free demo” approach (as magistrally exemplified by Eric Barroca of Nuxeo). While in the past the open core model was basically to present a half-solution barely usable for testing now open core means a combination of services and (little) added code, like the new approach taken by Alfresco – that in the past I would have probably classified in the ITSM class (installation/training/support/maintenance, in recent report rechristened as “product specialist). Read as an example the post from John Newton, describing Alfresco approach:
- We must insure that customers using our enterprise version are not locked into that choice and that open source is available to them. To that end, the core system and interfaces will remain 100% open source.
- We will provide service and customer support that provides insurance that systems will run as expected and correct problems according our promised Service Level Agreement
- Enterprise customers will receive fixes as a priority, but that we will make these fixes available in the next labs release. Bugs fixed by the community are delivered to the community as a priority.
- We will provide extensions and integrations to proprietary systems to which customers are charged. It is fair for us to charge and include this in an enterprise release as well.
- Extensions and integrations to ubiquitous proprietary systems, such as Windows and Office, will be completely open source.
- Extensions that are useful to monitor or run a system in a scaled or production environment, such as system monitoring, administration and high availability, are fair to put into an enterprise release.”
The new “open core” is really a mix of services, including enhanced documentation and training materials, SLA-backed support, stability testing and much more. In this new model, the GPL is not a barrier in any way, and can be used to implement such a model without additional difficulties. The move towards services also explains why despite the claim that open core models are the preferred monetization strategies, our work in FLOSSMETRICS found that only 19% of the companies surveyed used such a model, a number that is consistent with the 23.7% found by the 451 group, despite the claim that “Open Core becomes the default business model”. The reality is that the first implementation of open core was seriously flawed; for several reasons:
“The model has the intrinsic downside that the FLOSS product must be valuable to be attractive for the users, but must also be not complete enough to prevent competition with the commercial one. This balance is difficult to achieve and maintain over time; also, if the software is of large interest, developers may try to complete the missing functionality in a purely open source way, thus reducing the attractiveness of the commercial version.”
and, from Matthew Aslett:
I previously noted that with the Open-Core approach the open source disruptor is disrupted by its own disruption and that in the context of Christensen’s law of Conservation of Attractive Profits it is probably easier in the long-term to generate profit from adjacent proprietary products than it is to generate profit from proprietary features deployed on top of the commoditized product.
In the process of selecting a business model, then, the GPL is not a barrier in adopting this new style of open core model, and certainly creates a barrier for potential freeriding by competitors, something that was for example recognized by SpringSource (that adopted for most of their products the Apache license):
The GPL is well understood by the market and the legal community and has notable precedents such as MySQL, Java and the Linux kernel as GPL licensed projects. The GPL ensures that the software remains open and that companies do not take our products and sell against us in the marketplace. If this happened, we would not be able to sufficiently invest in the project and everyone would suffer.
The GPL family, at the moment, has the advantage that the majority of packages are licensed under one of such licenses, making compatibility checking easier; also, there is an higher probability of finding a GPL (v2, v3, AGPL, LGPL) package to improve than starting for scratch – and this should also guarantee that in the future the license mix will probably continue to be oriented towards copyleft-style restrictions. Of course, there will be a movement towards the GPLv3 (reducing the GPLv2 share, especially for new projects) but as a collective group the percentages will remain more or less similar.
This is not to say that the GPL is perfect: on the contrary, the text (even in the v3 edition) lacks clarity on derivative works, has been bent too much to accommodate anti-tivoization clauses (that contributed to a general lack of readability of the text) and lacks a worldwide vision (something that the EUPL has added). In terms of community and widespread adoption the GPL can be less effective as a tool for creating widespread platform usage; the EPL or the Apache license may be more appropriate for this role, and this because the FSF simply has not created a license that fullfills the same role (this time, for political reasons).
What I hope is that more companies start the adoption process, under the license that allows them to be commercially sustainable and thriving. The wrong choice way hamper growth and adoption, or may limit the choice of the most appropriate business model. The increase in adoption will also trigger what Matthew Aslett mentioned as the fifth stage of evolution (still partially undecided). I am a strong believer that there will be a move toward consortia-managed projects, something similar to what Matthew calls “the embedded age”; the availability of neutral third-party networks increase the probability and quality of contributions, in a way similar to the highly successful Eclipse foundation.
Some observations on licenses and forge evolution
Posted by cdaffara in OSS adoption, OSS business models, OSS data on August 12th, 2009
One of the activities we are working on to distract ourselves from the lure of beaches and mountain walks is the creation of a preliminary model of actor/actions for the OSS environment, trying to estimate the effect of code and non-code contributions and the impact of OSS on firms (adopters, producers, leaders – following the model already outlined by Carbone), and the impact of competition-resistance measures introduced by firms (pricing and licensing changes are among the possibility). We started with some assumptions on our own, of course; first of all, rationality of actors, the fact that OSS and traditional firms do have similar financial and structural properties (something that we informally observed in our study for FLOSSMETRICS, and commented over here), and the fact that technology adoption of OSS is similar to other IT technologies.
Given this set of assumptions, we obtained some initial results on licensing choices, and I would like to share them with you. License evolution is complex, and synthesis reports (like the one that is presented daily by Black Duck) can only show a limited view of the dynamics of license adoption. In Black Duck’s database there is no account for “live” or “active” projects, and actually I would suggest them to add a separate report for only the active and stable ones (3% to 7% of the total, and actually those that are used in the enterprise anyway). Our model predicts that in the large scale, license compatibility and business model considerations are the main drivers for a specific license choice; in this sense, our view is that for new projects the license choice is more or less not changed significantly in the last year, and that can be confirmed by looking at the new projects appearing in sourceforge, that maintain an overall 70% preference for copyleft licensing models (higher in some specialized forges, that reach 75%, and of course lower in communities like Codeplex). Our prediction is that license adoption follows a diffusion process that is similar to the one already discussed here:
for web server adoption (parameters are also quite similar, as the time frame) and so we should expect a relative stabilization, and further reduction of “fringe” licenses. In this sense, I agree with Matthew Aslett (and the 451 CAOS 12 analysis) on the fact that despite the claims, there is actually a self-paced consolidation An important aspect for people working on this kind of statistical analysis is the relative change in importance of forges, and the movement toward self-management of source code for commercial OSS companies. A good example comes from the FlossMOLE project:
It is relatively easy to see the reduction in the number of new projects in forges, that is only partially offset by new repositories not included in the analysis like Googlecode or Codeplex; this reduction can be explained by the fact that with an increasing number of projects, it is easier to find an existing project to contribute to, instead of creating one anew. An additional explanation is the fact that commercial OSS companies are moving from the traditional hosting on Sourceforge to the creation of internally managed and public repositories, where the development process is more controlled and manageable; my expectation is for this trend to continue, especially for “platform-like” products (an example is SugarForge).
The different reasons for company code contributions
Posted by cdaffara in OSS adoption, OSS business models, OSS data on July 15th, 2009
It was recently posted by Matt Asay an intriguing article called “Apache and the future of open-source licensing“, that starts with the phrase “If most developers contribute to open-source projects because they want to, rather than because they’re forced to, why do we have the GNU General Public License?“
It turns out that Joachim Henkel (one of the leading European researchers in the field of open source) already published several papers on commercial contributions to open source projects, especially in the field of embedded open source. Among them, one of my favourite is “Patterns of Free Revealing – Balancing Code Sharing and Protection in Commercial Open Source Development“, that is available also at the Cospa knowledge base (a digital collection of more than 2000 papers on open source, that we created and populated in the context of the COSPA project). In the paper there is a nice summary analysis of reasons for contributing back, and one of the results is:
What does it means? That licensing issues are the main reason for publishing back, but separated by very few percentage points other reasons appear: the signaling advantage (being good players), the R&D sharing, and many others. In this sense, my view is that the GPL creates an initial context (by forcing the publication of source code) that creates a secondary effect – reuse and quality improvement – that appears after some time. In fact, our research shows that companies need quite some time to grasp the advantages of reuse and participation; the GPL enforces participation for enough time that companies discovers the added benefits, and start moving their motivations to economic reasons, as compared to legal enforcing or legal risks.
The new form of Open Core, or how everyone was right
Posted by cdaffara in OSS adoption, OSS business models, OSS data on July 9th, 2009
Right on the heels of the 451 group’s CAOS 12 report, I had the opportunity to perform a comparison between monetization modalities that we originally classified as open core in the first edition of our work with the more recent database of OSS companies and their adopted models (such an analysis can be found in our guide as well). An interesting observation was the shifting perspective on what open core actually is, and to present some examples on why I believe that the “original” open core nearly disappeared, while a “new” model was behind the more recent claims that this has become one of the preferred models for OSS companies.
In the beginning, we used as a classification criteria the distinction of code bases: an Open Core company was identified by the fact that the commercial product had a different source code base (usually an extension of a totally OS one), and the license to obtain the commercial was exclusive (so as to distinguish this from the “dual licensing” model). In the past, open core was more or less a re-enactment of shareware of old; that is, the open source edition was barely functional, and usable only to perform some testing or evaluation, but not for using in production. The “new” open core is more a combination of services and some marginal extension, that are usually targeted for integration with proprietary components or to simplify deployment and management. In this sense, the “real” part of open core (that is, the exclusive code) is becoming less and less important – three years ago we estimated that from a functional point of view the “old” open core model separated functions at approximately 70% (the OS edition had from 60% to 70% of the functions of the proprietary product), while now this split is around 90% or even higher, but is complemented with assurance services like support, documentation, knowledge bases, the certification of code and so on.
Just to show some examples: DimDim “We have synchronized this release to match the latest hosted version and released the complete source code tree. Bear in mind that features which require the Dimdim meeting portal (scheduling & recording to note) are not available in open source. There is also no limit to the number of attendees and meetings that can be supported using the Open Source Community Edition.” If you compare the editions, it is possible to see that the difference lies (apart from the scheduling and recording) in support and the availability of professional services (like custom integration with external authentication sources).
Alfresco: The difference in source code lies in the clustering and high-availability support and the JMX management extensions (all of which may be replicated with some effort by using pure OSS tools). Those differences are clearly relevant for the largest and most complex installations; from the point of view of services, the editions are differentiated through availability of support, certification (both of binary releases and of external stacks, like database and app server), bug fixing, documentation, availability of upgrades and training options.
Cynapse (an extremely interesting group collaboration system): The code difference lies in LDAP integration and clustering; the service difference lies in support, availability of certified binaries, knowledgebase access and official documentation.
OpenClinica (a platform for the creation of Electronic Data Capture systems used in pharmaceutical trials and in data acquisition in health care); from the web site: “OpenClinica Enterprise is fully supported version of the OpenClinica platform with a tailored set of Research Critical Services such as installation, training, validation, upgrades, help desk support, customization, systems integration, and more.”
During the compilation of the second FLOSSMETRICS database I found that the majority of “open core” models were actually moving from the original definition to an hybrid monetization model, that brings together several separate models (particularly the “platform provider”, “product specialist” and the proper “open core” one) to better address the needs of customers. The fact that the actual percentage of code that is not available under an OSS license is shrinking is in my view a positive fact: because it allows for the real OSS project to stand on its own (and eventually be reused by others) and because it shows that the proprietary code part is less and less important in an ecosystem where services are the real key to add value to a customer.
Just finished: the final edition of the SME guide to open source
Posted by cdaffara in OSS adoption, OSS business models, OSS data on July 2nd, 2009
It has been an absolutely enjoyable activity to work in the context of the FLOSSMETRICS project with the overall idea of helping SMEs to adopt, and migrate to, open source and free software. My proposed approach was to create an accessible and replicable guide, designed to help both those interested in exploring what open source is, and in helping companies in the process of offering services and products based on OSS; now, two years later, I found references to the previous editions of the guide in websites across the world, and was delighted in discovering that some OSS companies are using it as marketing material to help prospective customers.
So, after a few more months of work, I am really happy to present the fourth and final edition of the guide (PDF link) that will (I hope) improve in our previous efforts. For those that already viewed the previous editions, chapter 6 was entirely rewritten, along with a new chapter 7 and a newly introduced evaluation method. The catalogue has been expanded and corrected in several places (also thanks to the individual companies and groups responsible for the packages themselves) and the overall appearance of the PDF version should be much improved, compared to the automatically generated version.
I will continue to work on it even after the end of the project, and as before I welcome any contribution and suggestion.
Horses, carriages and cars – the shifting OSS business models, and a proposal
Posted by cdaffara in OSS business models, OSS data on June 8th, 2009
If there is a constant in this research area, is the fact that everything is constantly changing. While we debate about whether mixed models are really that important or not, or while free software experts are fighting against brand pollution, I still find amusing the fact that most of what we debate will be probably not relevant in the future at all. Exactly like the initial car models, that resembled the horse-driven carriages that were planning to supplant, some actual OSS business models are half-hearted attempts at bridge the gap between two different worlds, with some advantages and disadvantages of each.
All OSS business models are based on the idea of monetization of a code base, and this monetization can happen in many different steps of the acquisition or use process. Monetization of services, for example, usually happens in the initial adoption step through training and set-up fees, while support monetization happens in the long-term use phase (and in large scale companies tend to be limited in time, as the internal IT staff becomes more and more expert at the infrastructure, and the need for external supports reduces with time); sometimes monetization happens elsewhere (like Mozilla and Google).
Mixed models try to leverage the R&D cost reduction that is inherent in the OSS process, while at the same time maintain the easy and clear proprietary licensing model, where there is a token-based monetization (per CPU, per user, per server, and so on) that is not related to an inherent limitation of the software, but is an artificial barrier introduced to prevent free riding. This, however, introduces the disadvantages of both models into the equation: developers working for a commercial company are reluctant to participate in a project that has a clear potential for third party exploitation, while non-employed developers may be more interested in contributing to more “libre” projects. On the adopter side, the user is not allowed to experiment with the full version of the software, and may not be interested enough in trying the OSS version if the difference in terms of stability and features is too high.
That explains why mixed-model vendors claim that basically no one contributes code to their project (thus neglecting all the non-code contributions, that in some cases are significant), while vendors that select alternative monetization approaches seem to fare better. Pure OSS products are in fact more efficient (and tend to allow for higher company competitiveness), and even vendor-backed projects like Eclipse receive significant external contributions (IBM has only 25% of the active committers, for example).
About the claims that mixed models or open core approaches are the norm, I still stand on my numbers, that shows that less than 25% of the companies use this approach to monetization. Also, the companies are adopting a more softer stance on open core; while a few years ago the code available under the non-OSS license was a substantial part of the functionality of the full product, now the vendors are using many separate non-functional product areas and put them together to create the proprietary product, like certification, stability assurance, official support and sometimes additional code for ancillary activities like monitoring and high-end features like clustering (Alfresco recently announced such a change).
As the horse, carriage and cars example I made at the beginning of this post, I believe that these are steps taken in trying to approach and adopt the optimal model; in this sense, I believe that a better approach is to clearly divide the “core” and “non-core” groups into separate legal entities, with differentiated governance models. In particular, I believe that a more efficient approach is:
- To have a core, Eclipse-like consortia that provide clear, public, transparent management of the central open source part of the project. As for Eclipse, while initially the vendor dominates in terms of contribution, after a while (and in the presence of a healthy external ecosystem) contributions start to reduce the R&D cost – in the case of Eclipse, over 75% of the code commits are from outside IBM.
- To have a separate, independent unit/company that provides, under a traditional proprietary license, the stabilized/extended software without any confusion about what is open source and what is not. It will not be “mixed model”, “commercial OSS” or whatever – just proprietary software. Or, if the offer is service-based, it will be a pure service contract.
I strongly believe that this model can not only put on a rest the entire “mixed model” or open core debate, but can also provide significant productization benefits, by reducing the contribution barrier that so many OSS vendors are experiencing right now. By creating an ecosystem of “development consortia” it will also be possible to increase coordination opportunities, that are sometimes stifled by OSS vendors that pursue independent agendas; it will also reduce customer confusion about what actually they buy when they receive an offer from such a vendor.
Economic Free Software perspectives
Posted by cdaffara in OSS business models, OSS data on May 4th, 2009
“How do you make money with Free Software?” was a very common question just a few years ago. Today, that question has evolved into “What are successful business strategies that can be implemented on top of Free Software?”
This is the beginning of a document that I originally prepared as an appendix for an industry group white paper; as I received many requests for a short, data-concrete document to be used in university courses on the economics of FLOSS, I think that this may be useful as an initial discussion paper. A pdf version is available here for download. Data and text was partially adapted from the results of the EU projects FLOSSMETRICS and OpenTTT (open source business models and adoption of OSS within companies), COSPA (adoption of OSS by public administrations in Europe), CALIBRE and INES (open source in industrial environments). I am indebted with Georg Greve of FSFE, that wrote the excellent introduction (more details on the submission here), and that kindly permitted redistribution. This text is licensed under CC-by-SA (attribution, sharealike 3.0) . I would grateful for an email to indicate use of the text, as a way to keep track of it, at cdaffara@conecta.it.
Free Software (defined 1985) is defined by the freedoms to use, study, share, improve. Synonyms for Free Software include Libre Software (c.a. 1991), Open Source (1998), FOSS and FLOSS (both 200X). For purposes of this document, this usage is synonymous with “Open Source” by the Open Source Initiative (OSI).
Economic Free Software Perspectives
Introduction
“How do you make money with Free Software?” was a very common question just a few years ago. Today, that question has evolved into “What are successful business strategies that can be implemented on top of Free Software?” In order to develop business strategies, it is first necessary to have a clear understanding of the different aspects that you seek to address. Unfortunately this is not made easier by popular ambiguous use of some terms for fundamentally different concepts and issues, e.g. “Open Source” being used for a software model, development model, or business model.
These models are orthogonal, like the three axes of the three-dimensional coordinate system, their respective differentiators are control (software model), collaboration (development model), revenue (business model).
The software model axis is the one that is discussed most often. On the one hand there is proprietary software, for which the vendor retains full control over the software and the user receives limited usage permission through a license, which is granted according to certain conditions. On the other hand there is Free Software, which provides the user with unprecedented control over their software through an ex-ante grant of irrevocable and universal rights to use, study, modify and distribute the software.
The development model axis describes the barrier to collaboration, ranging from projects that are developed by a single person or vendor to projects that allow extensive global collaboration. This is independent from the software model. There is proprietary software that allows for far-reaching collaboration, e.g. SAP with it’s partnership program, and Free Software projects that are developed by a single person or company with little or no outside input.
The business model axis describes what kind of revenue model was chosen for the software. Options on this axis include training, services, integration, custom development, subscription models, “Commercial Off The Shelve” (COTS), “Software as a Service” (SaaS) and more.
These three axes open the space in which any software project and any product of any company can freely position itself. That is not to say all these combinations will be successful. A revenue model based on lock-in strategies with rapid paid upgrade cycles is unlikely to work with Free Software as the underlying software model. This approach typically occurs on top of a proprietary software model for which the business model mandates a completed financial transaction as one of the conditions to grant a license.
It should be noted that the overlap of possible business models on top of the different software models is much larger than usually understood. The ex-ante grant of the Free Software model makes it generally impossible to attach conditions to the granting of a license, including the condition of financial transaction. But it is possible to implement very similar revenue streams in the business model through contractual constructions, trademarks and/or certification.
Each of these axes warrants individual consideration and careful planning for the goals of the project. If, for instance the goal is to work with competitors on a non-differentiating component in order to achieve independence from a potential monopolistic supplier, it would seem appropriate to focus on collaboration and choose a software model that includes a strong Copyleft licence. The business model could potentially be neglected in this case, as the expected return on investment comes in the form of strategic independence benefits, and lower licence costs. In another case, a company might choose a very collaborative community development model on top of a strong Copyleft licence, with a revenue model based on enterprise-ready releases that are audited for maturity, stability and security by the company for its customers. The number of possible combinations is almost endless, and the choices made will determine the individual character and competitive strengths and weaknesses of each company. Thinking clearly about these parameters is key to a successful business strategy.
Strategic use of Free Software vs. Free Software Companies
According to Gartner, usage of Free Software will reach 100 percent by November 2009. That makes usage of Free Software a poor criterion for what makes a Free Software company. Contribution to Free Software projects seems a slightly better choice, but as many Free Software projects have adopted a collaborative development model in which the users themselves drive development, that label would then also apply to companies that aren’t Information Technology (IT) companies.
IT companies are among the most intensive users of software, and will often find themselves as part of a larger stack or environment of applications. Being part of that stack, their use of software not only refers to desktops and servers used by the company’s employees, but also to the platform on top of which the company’s software or solution is provided.
Maintaining proprietary custom platforms for a solution is inefficient and expensive, and depending upon other proprietary companies for the platform is dangerous. In response, large proprietary enterprises have begun to phase out their proprietary platforms and are moving towards Free Software in order to leverage the strategic advantages provided by this software model for their own use of software on the platform level. These companies will often interact well with the projects they depend upon, contribute to them, and foster their growth as a way to develop strategic independence as a user of software.
What makes these enterprises proprietary is that for the parts where they are not primarily users of software, but suppliers to their downstream customers, the software model is proprietary, withholding from its customers the same strategic benefits of Free Software that the company is using to improve its own competitiveness.
From a customer perspective, that solution itself becomes part of the platform on which the company’s differentiating activities are based. This, as stated before, is inefficient, expensive and a dangerous strategy.
Assuming a market perspective, it represents an inefficiency that provides business opportunity for other companies to provide customers with a stack that is Free Software entirely, and it is strategically and economically sane for customers to prefer those providers over proprietary ones for the very same reasons that their proprietary suppliers have chosen Free Software platforms themselves.
Strategically speaking, any company that includes proprietary software model components in its revenue model should be aware that its revenue flow largely depends upon lack of Free Software alternatives, and that growth of the market, as well as supernatural profits generated through the proprietary model both serve to attract other companies that will make proprietary models unsustainable. When that moment comes, the company can either move its revenue model to a different market, or it has to transform its revenue source to work on top of a software model that is entirely Free Software.
So usage of and contribution to Free Software are not differentiators for what makes a Free Software company. The critical differentiator is provision of Free Software downstream to customers. In other words: Free Software companies are companies that have adopted business models in which the revenue streams are not tied to proprietary software model licensing conditions.
Economic incentives of Free Software adoption
The broad participation of companies and public authorities in the Free Software market is strictly related to an economic advantage; in most areas, the use of Free Software brings a substantial economic advantage, thanks to the shared development and maintenance costs, already described by researchers like Gosh, that estimated an average R&D cost reduction of 36%. The large share of “internal” Free Software deployments explains why some of the economic benefits are not perceived directly in the business service market, as shown by Gartner:
Gartner predicts that within 2010 25% of the overall software market will be Free Software-based, with rougly 12% of it “internal” to companies and administrations that adopt Free Software. The remaining market, still substantial, is based on several different business models, that monetize the software using different strategies.
A recent update (february 2009) of the FLOSSMETRICS study on Free Software-based business model is presented here, after an analysis of more than 200 companies; the main models identified in the market are:
- Dual licensing: the same software code distributed under the GPL and a proprietary license. This model is mainly used by producers of developer-oriented tools and software, and works thanks to the strong coupling clause of the GPL, that requires derivative works or software directly linked to be covered under the same license. Companies not willing to release their own software under the GPL can obtain a proprietary license that provides an exemption from the distribution conditions of the GPL, which seems desirable to some parties. The downside of dual licensing is that external contributors must accept the same licensing regime, and this has been shown to reduce the volume of external contributions, which are limited mainly to bug fixes and small additions.
- Open Core (previously called “split Free Software/proprietary” or “proprietary value-add”): this model distinguishes between a basic Free Software and a proprietary version, based on the Free Software one but with the addition of proprietary plug-ins. Most companies following such a model adopt the Mozilla Public License, as it allows explicitly this form of intermixing, and allows for much greater participation from external contributions without the same requirements for copyright consolidation as in dual licensing. The model has the intrinsic downside that the Free Software product must be valuable to be attractive for the users, i.e. it should not be reduced to “crippleware”, yet at the same time should not cannibalise the proprietary product. This balance is difficult to achieve and maintain over time; also, if the software is of large interest, developers may try to complete the missing functionality in Free Software, thus reducing the attractiveness of the proprietary version and potentially giving rise to a full Free Software competitor that will not be limited in the same way.
- Product specialists: companies that created, or maintain a specific software project, and use a Free Software license to distribute it. The main revenues are provided from services like training and consulting (the “ITSC” class) and follow the original “best code here” and “best knowledge here” of the original EUWG classification [DB 00]. It leverages the assumption, commonly held, that the most knowledgeable experts on a software are those that have developed it, and this way can provide services with a limited marketing effort, by leveraging the free redistribution of the code. The downside of the model is that there is a limited barrier of entry for potential competitors, as the only investment that is needed is in the acquisition of specific skills and expertise on the software itself.
- Platform providers: companies that provide selection, support, integration and services on a set of projects, collectively forming a tested and verified platform. In this sense, even GNU/Linux distributions were classified as platforms; the interesting observation is that those distributions are licensed for a significant part under Free Software licenses to maximize external contributions, and leverage copyright protection to prevent outright copying but not “cloning” (the removal of copyrighted material like logos and trademark to create a new product)1. The main value proposition comes in the form of guaranteed quality, stability and reliability, and the certainty of support for business critical applications.
- Selection/consulting companies: companies in this class are not strictly developers, but provide consulting and selection/evaluation services on a wide range of project, in a way that is close to the analyst role. These companies tend to have very limited impact on the Free Software communities, as the evaluation results and the evaluation process are usually a proprietary asset.
- Aggregate support providers: companies that provide a one-stop support on several separate Free Software products, usually by directly employing developers or forwarding support requests to second-stage product specialists.
- Legal certification and consulting: these companies do not provide any specific code activity, but provide support in checking license compliance, sometimes also providing coverage and insurance for legal attacks; some companies employ tools for verify that code is not improperly reused across company boundaries or in an improper way.
- Training and documentation: companies that offer courses, on-line and physical training, additional documentation or manuals. This is usually offered as part of a support contract, but recently several large scale training center networks started offering Free Software-specific courses.
- R&D cost sharing: A company or organization may need a new or improved version of a software package, and fund some consultant or software manufacturer to do the work. Later on, the resulting software is redistributed as open source to take advantage of the large pool of skilled developers who can debug and improve it. A good example is the Maemo platform, used by Nokia in its Mobile Internet Devices (like the N810); within Maemo, only 7.5% of the code is proprietary, with a reduction in costs estimated in 228M$ (and a reduction in time-to-market of one year). Another example is the Eclipse ecosystem, an integrated development environment (IDE) originally released as Free Software by IBM and later managed by the Eclipse Foundation. Many companies adopted Eclipse as a basis for their own product, and this way reduced the overall cost of creating a software product that provides in some way developer-oriented functionalities. There is a large number of companies, universities and individual that participate in the Eclipse ecosystem; as an example:
As recently measured, IBM contributes for around 46% of the project, with individuals accounting for 25%, and a large number of companies like Oracle, Borland, Actuate and many others with percentages that go from 1 to 7%. This is similar to the results obtained from analysis of the Linux kernel, and show that when there is an healthy and large ecosystem the shared work reduces engineering cost significantly; it is estimated that it is possible to obtain savings in terms of software research and development of 36% through the use of Free Software; this is, in itself, the largest actual “market” for Free Software, as demonstrated by the fact that the majority of developers are using at least some Free Software within their own code (56.2%). - Indirect revenues: A company may decide to fund Free Software projects if those projects can create a significant revenue source for related products, not directly connected with source code or software. One of the most common cases is the writing of software needed to run hardware, for instance, operating system drivers for specific hardware. In fact, many hardware manufacturers are already distributing gratis software drivers. Some of them are already distributing some of their drivers (specially those for the Linux kernel) as Free Software.
The loss-leader is a traditional commercial model, common also outside of the world of software; in this model, effort is invested in a Free Software project to create or extend another market under different conditions. For example, hardware vendors invest in the development of software drivers for Free Software operating systems (like GNU/Linux) to extend the market of the hardware itself. Other ancillary models are for example those of the Mozilla foundation, which obtains a non trivial amount of money from a search engine partnership with Google (an estimated 72M$ in 2006), while SourceForge/OSTG receives the majority of revenues from ecommerce sales of the affiliate ThinkGeek site
We found (confirming previous research from the 451 group) that at the moment there is no “significant” model, with companies more or less adopting and changing model depending on the specific market or the shifting costs. For example, during 2008 a large number of companies shifted from an “open core” model to a pure “product specialist” one to leverage the external community of contributors.
According to the collected data, among Free Software companies the “Fully Free Software” approach is still prevalent, followed by the “Open Core” and the “Dual Licensing” mode:
| Model name | # companies |
| product specialist | 131 |
| open core | 52 |
| Indirect | 44 |
| dual licensing | 19 |
| R&D sharing | 6 |
| training | 5 |
| aggregate supp. | 5 |
| legal cert | 5 |
| platform providers | 4 |
| selection/consulting | 4 |
Some companies have more than one principal model, and thus are counted twice; in particular, most dual licensing companies are also selling support services, and thus are marked as both. Also, product specialists are counted only when there is a demonstrable participation of the company into the project as “main committer”; otherwise, the number of specialists would be much greater, as some projects are the center of commercial support from many companies (a good example is OpenBravo or Zope).
Another relevant consideration is the fact that platform providers, while limited in number, tend to have a much larger revenue rate than both specialists or open core companies.
Many researchers are trying to identify whether there is a more “efficient” model among all those surveyed; what we found is that the most probable future outcome will be a continuous shift across model, with a long-term consolidation of development consortia (like Symbian and Eclipse) that provide strong legal infrastructure and development advantages, and product specialists that provide vertical offerings for specific markets. This contrasts with the view that, for example, “mixed” models provide an inherent advantage; for example, Matthew Aslett of the 451 group (one of the leading researchers in Free Software business models) wrote:
“The Open-Core approach is mostly (though not exclusively) used by vendors that dominate their own development communities. While this provides benefits in terms of controlling the direction of development and benefiting from the open source distribution model there are also risks involved with promoting and managing community development – or not. In fact, many of these companies employ the majority of the developers on the project, so they are actually missing out on many of the benefits of the open source development model (more eyeballs, lower costs etc).
Additionally, by providing revenue-generating features on top of open source code, Open-Core vendors are attempting to both disrupt their segment and profit from that disruption. I previously argued that “it is probably easier in the long-term to generate profit from adjacent proprietary products than it is to generate profit from proprietary features deployed on top of the commoditized product.”
While Open-Core is definitely the commercial open source strategy of the day and is effective in building the revenue growth required to fuel an exit strategy, I have my doubts as to whether it is sustainable in the long-term due to a combination of the issues noted above.”
The fact that Free Software is in a sense a non-rival good also facilitates cooperation between companies, both to increase the geographic base and to be able to engage large scale contracts that may require multiple competencies. Three main collaboration strategies were identified among smaller companies: geographical (same product or service, different geographical areas); “vertical” (among products) or “horizontal” (among activities). Geographic cooperation is simpler, and tends to be mainly service-based; an example is the Zope Europe Association, that unites many service providers centered on specific Zope and Plone expertise. Vertical cooperation is done by companies that performs an integrated set of activities on one or more packages. Multiple vendors with overlapping products can collaborate on a single offer (eg. operating system and Groupware), that may form a more interesting or complete offer for the selected customer segment.
The summary table is available here along with a rationale for the categories used; linked below to a public Google docs document:
Bibliography:
[451 08]The 451 group, Open source is not a business model.
[Car 07]Carbone, P. Value Derived from Open Source is a Function of Maturity Levels, OCRI conference “Alchemy of open source businesses”, 2007
[DB 00]Daffara, C. Barahona, J.B. Free Software/Open Source: Information Society Opportunities for Europe? working paper
[Daf 06]Daffara, C. Sustainability of FLOSS-based business models, II Open Source World Conference, Malaga 2006
[Daf 06-2]Daffara, C. Introducing open source in industrial environments. 3rd CALIBRE workshop
[Daf 07]Daffara, C. Business models in OSS-based companies. OSSEMP workshop, Third international conference on open source. Limerick 2007
[ED 05]Evans Data, Open Source Vision report, 2005
[Gar 06]Gartner Group, Open source going mainstream. Gartner report, 2006
[Gosh 06]Gosh, et al. Economic impact of FLOSS on innovation and competitiveness of the EU ICT sector.
[IDC 06]IDC, Open Source in Global Software: Market Impact, Disruption, and Business Models. IDC report, 2006
[Jul 06]Jullien N. (ed) New economic models, new software industry economy. RNTL report
[VH 03]Von Hippel, E. and G. von Krogh, Open Source Software and the “Private-Collective” Innovation Model: Issues for Organizational Science. Organization Science, 2003. 14(2): p. 209-223
[VH 05]Von Hippel, E. Democratizing innovation. MIT press, 2005
Helping OSS adoption in public administrations: some resources
Posted by cdaffara in OSS adoption, OSS business models, OSS data on April 30th, 2009
It was a busy and happy week, and among the many things I received several requests for information on how to facilitate adoption of OSS by public administrations. After the significant interest of a few years ago, it seems that the strong focus on “digital citizenship” and the need to increase interoperability with other administrations is pushing OSS again (and the simplification, thanks to the reduction in procurement hurdles, also helps). I have worked in this area for some years, first in the SPIRIT project (open source for health care), then in the COSPA and OpenTTT projects, that were oriented towards facilitating OSS adoption. I will try to provide some links that may be useful for administrations looking to OSS:
- Let’s start with requirement analysis. What is important, what is not, and how to prioritize things was one of the arguments discussed in COSPA, and two excellent deliverables were produced (maybe a bit theoretical, but you can skip the boring parts): analysis of requirements for OS and ODS and prioritization of requirements (both pdf files).
- As part of our guide in the FLOSSMETRICS project we have a list of best practices, that may be useful; in general, the guide does have some more material from various European projects. I would like to thank PJ from Groklaw, that hosted my work for discussion there, and to the many groklawers that helped in improving it.
- One of the best migration guide ever created, by the Germany Ministry of the Interior (KBST), is available in english (pdf file). It covers many practical problems, server and desktop migrations, project planning, legal aspects (like changing contractual relations with vendors), evaluation of economics and efficiency aspects and much more. Unfortunately the 2.1 edition is still not available in english…
- For something simpler, some guidance and economic comparison from the Treasury board of Canada;
- and a very detailed desktop migration redbook from IBM.
- The European Open Source Observatory does have a long and interesting list of case studies, both positive and negative (so the reader can get a balanced view).
And now for some additional comment, based on my personal experience:
- A successful OSS migration or adoption is not only a technical problem, but a management and social problem as well. A significant improvement in success rates can be obtained simply by providing a simple, 1 hour “welcoming” session to help users in understanding the changes and the reasons behind it (as well as providing some information on OSS and its differences with proprietary software).
- In most public administrations there are “experts” that provide most of the informal IT help; some of those users may felt threatened by the change of IT infrastructure, as it will remove their “skill advantage”. So, a simple and effective practice is to search for them and for passionate users and enlist them as “champions”. Those champions are offered the opportunity for further training and additional support, so they can continue in their role without disruptions.
- Perform a real cost analysis of the actual, proprietary IT infrastructure: sometimes huge surprises are found, both in contractual aspects and in actual costs incurred that are “hidden” under alternative balance voices.
- If a migration requires a long adaptation time, make sure that the management remains the same for the entire duration, or that the new management understands and approves what was done. One of the most sad experiences is to see a migration stop halfways because the municipality coalition changes, and the new coalition has no understanding of what was planned and why (”no one remembers the reasons for the migration” was one of the phrases that I heard once).
- Create an open table between local administrations: sometimes you will find someone that already is using OSS and simply told no one. We had a local health agency that silently swapped MS Office with OpenOffices in the new PCs for hospital workers, and nobody noticed
- Have an appropriate legislative policy: informative campaigns and mandatory adoption are the two most efficient approaches to create OSS adoption, while subsidization has a negative welfare effect: “We show that a part from subsidization policies, which have been proved to harm social surplus, supporting OSS through mandatory adoption and information campaign may have positive welfare effects. When software adoption is affected by strong network effects, mandatory adoption and information campaign induce an increase in social surplus” (Comino, Manenti, “Free/Open Source vs Closed Source Software: Public Policies in the Software Market”). Also, in the TOSSAD conference proceedings, Gencer, Ozel, Schmidbauer, Tunalioglu, “Free & Open Source Software, Human Development and Public Policy Making: International Comparison”.
- Check for adverse policy effects: In one of my case studies I found a large PA that was forced back to commercial software, because the state administration was subsidizing only the cost of proprietary software, while OSS was considered to be “out of procurement rules” and thus not paid for. This does also have policy implications, and require a careful choice of budget voices by the adopters administration.
We found that by presenting some “exemplar” OSS projects that can be used immediately, the exploration phase usually turns into a real adoption experiment. The tool that I use as an introduction are:
- Document management: Alfresco. It is simple to install, easy to use and with good documentation, and can be introduced as a small departmental alternative to the “poor man repository”, that is a shared drive on the network. Start with the file system interface, and show the document previews and the search functionalities (more complex activities, like workflow, can be demonstrated in a second time). Nuxeo is also a worthy contender.
- Groupware: my personal favorite, Zimbra, that can provide everything that Exchange does, and has a recently released standalone desktop client that really is a technical marvel. If you are still forced into Outlook you can use Funambol (another OSS gem) that with a desktop client can provide two-way synchronization with Outlook, exactly like Exchange.
- Project management: a little known project from Austria is called OnePoint, and does have a very well designed web and native interface for the traditional project management tasks.
- Workstation management: among the many choices, if (as it usually happens) the majority of the desktops are Windows-based there is a long-standing german project called Opsi, that provides automatic OS install, patch management, HW&SW inventory and much more.
Of course there are many other tools, but by presenting an initial, small subset it is usually possible to raise the PA interest in trying and testing out more. For some other software packages, you can check the software catalog that we provided as part of our FLOSSMETRICS guide. I will be happy to answer to individual requests for software that will be posted as comments to this articles, or sent to me by twitter (@cdaffara); if there are enough interest, I will prepare a follow-up post with more tools.
Recent Comments