Archive for May, 2009
As I prepare for a long tour of Europe for various EU project evaluation, I would like to provide some snippets and comments on some debates and discussions for which maybe a long post would be not appropriate, starting of course with the ping-pong like debate between Matt Asay and Tarus Balog on what constitutes an OSS company. I already have wrote too much about it, but I would like to point out two errors (at least in my view) in Matt Asay post, in particular in the phrase:
Red Hat is an example of “free done right,” following analysis from TechDirt. We’ve moved beyond the business models that insist that every line of software be open source: they couldn’t scale and tended to treat openness as an end in and of itself, rather than as a means to an end.
The first point is that RedHat is a perfect example of an OSS company under almost any definition of the terms. There is little or no code that is unreleased, and actually most of those cases are for code that was recently acquired, and thus still not vetted for release. I know that Matt disagrees with this (because the service contract is more restrictive), but the point is that you acquire all source code and after removal of the trademarked logos you are allowed to do whatever you want with it. If you don’t like RedHat services you can go with Oracle, or the many companies that provide additional support contracts. If Matt has a substantial example of withheld code that is sold for a proprietary license, I would happily apologize; until that moment, I stand my case.
The second point is related to the fact that OSS companies are unable to scale. This is something that I already discussed in our study on business models, and it is mainly an organizational problem: the reality is the correct phrase should be “small companies’ service based models do not scale”, as there are several excellent examples of service based companies that are very large (Accenture, IBM global services, HP services, CapGemini, Fujitsu, BT, and many others) and that are human capital intensive. The critical point is that to scale it is necessary to change internal structure, and become organized in a more efficient and “industrial” way; there is in this no difference between OSS and non-OSS companies.
On a totally different field, it was interesting to notice the great amount of interest for Android-based netbooks. Many claimed this combination to be the real alternative to XP netbooks, or in the near future to Windows 7 netbooks. The reality is that Android as a system does not have magical properties; the underlying kernel is still Linux, and having a set of customized interface reduces greatly the memory consumption, but does not provide any significant improvement when compared with lean, netbook-optimized linux distribution. On the contrary, the user interface (designed for one-app-per-screen, and use with imprecise controls like touch screens and trackballs) is not exactly ideal for something like a netbook, that does have a keyboard and a large-enough screen. In this sense, I would say that Moblin may constitute a much better environment for this kind of applications.
MID (Mobile Internet Devices) like the Nokia N810, Archos devices and many more are clearly a better match for Android; while other environments (like Maemo) do exist and are stable, the App Store and the enlarging software ecosystem may become a differentiating element. As I already wrote in the past, I believe that VoIP applications (and in a more general sense, social and interaction applications) will become the real differentiating element in the future. I believe that as 3.5G wireless data contracts start to become common, the phone will become more and more a “modem” for connecting with a separate and non-carrier-controlled MID, where VoIP and IM applications will join the web browser as the most frequently used applications.
There is an interesting blog-debate between Tarus Balog of OpenNMS fame, Matt Asay of Alfresco and Matthew Aslett on the relative “good” and “evil” of open source, business models and more in relations to whether “open core” companies are really open source or not (and of course I could not resist in chiming in). Before rolling your eyes in disgust for the continuous discussion (that should enter now its 10th year, more or less) I would like to give you my impression on why this has continued to be debated, and why I believe it will be gradually less and less important, to the point that it will be no more than background noise.
Tarus starts with a very good analysis of why the open source definition and the free software definition can be considered to be equivalent, and thus creates an equivalence between open source and free software (that is something that I believe is valid, from the “legal” point of view). Then he extends the concept of open source to companies, and presents his view of what he calls “fauxpen source companies”, that is companies that are not distributing (all) of their software products under an open source license. I understand perfectly the reasons behind Tarus words, but I equally understand why Matt Asay is so vitriolic about them: they talk about different things.
I will state my position in advance, so as to provide some transparency: I have nothing against “open core” models (where part of the code is not available as OSS), and I perfectly understand why some companies may be more interested in adopting such a model instead of a “pure” model, where the entirety of the code is available under one or more OSS licenses. On the other hand, I found no proof of the fact that the open core or hybrid model is superior in terms of revenues, margins, long term sustainability and so on, despite the many papers and blog post that claim that the hybrid model is the clear winner (but unfortunately without any data or proof). So, I believe that Tarus is clearly upset of the fact that hybrid proponents are claiming the superiority of a model against the others, and the fact that by claiming that everyone is “open source” the vendors are effectively diluting the indentification capability of such a tag, and then OpenNMS (as a company) will lose one of the differentiating tools in its commercial proposition.
On the other hand, I clearly understand the fact that Matt clearly feels right in claiming to be part of an open source company, as the majority of the code is clearly OSS, and the recent introduction of non-OSS parts is limited. So, I believe that both are rights, and the problem will disappear with time, for economic reasons.
I will try to explain by using some of my previous words:
There is, however, a point that I would like to make about the distinction between “pure OSS” and “open core” licensing, a point that does not imply any kind of “ethical” or “purity” measure, but just a consideration on economics. When we consider what OSS is and what advantage it brings to the market, it is important to consider that a commercial OSS transaction usually has two “concrete” partners: the seller (the OSS vendor) and the buyer, that is the user. If we look at the OSS world we can see that in both the pure and the open core model the vendor has the added R&D sharing cost reduction (that, as I wrote about in the past, can provide significant advantages). But R&D is not the only advantage: the reality is that “pure” OSS has a great added advantage for the adopter, that is the greatly reduced cost and effort of procurement. With OSS the adopter can scale a single installation company-wide without a single call to the legal or procurement departments, and it can ask support from the OSS vendor if needed- eventually after the roll-out has been performed. With open core, the adopter is not allowed to do the same thing, as the proprietary extensions are not under the same license of the open source part; so, if you want to extend your software to more servers, you are forced to ask the vendor- exactly the same of proprietary software systems. This is, in fact, a much overlooked advantage of OSS, that is especially suited to those “departmental” installations that would be probably prohibited if legal or acquisition department would have to be asked for budget.
The point is that the “open core” against which Tarus fights is not relevant anymore. That is, that “fake” open source product, basically useless, used just as a leverage to the proprietary one is simply not a good strategy for distribution, as it does have none of the advantages of OSS and all the disadvantages of proprietary (in fact, most of those “fake” OSS companies are not in the market anymore, at least not in the same way). If you look at many of the most recent open core propositions, you will see that the real differentiating aspects are support, availability of stable releases, and only in minimal part ancillary non-OSS code, exactly the kind of model predicted by economic advantage for the buyer. The main point is the one I written a few years ago: for the model to work, the Free Software product must be valuable to be attractive for the users, i.e. it should not be reduced to “crippleware”. If you look at some of the examples I presented to Matthew during our comment exchange, projects like TenderSystem, DimDim and many others are not using non-proprietary parts anymore as the main differentiating aspects, but more as “complements” that enrich a complex mix of services like support, binary packaging and testing, documentation and much more.
So, I believe that we will still see flames between experts, but it will become more and more a playful debate, similar to the one between soccer team fans – playful, heated, and ultimately not relevant for business.
Matt Asay just published a post titled “‘Community’ is an overhyped word in software“, where he collects several observations and basically states that ” Most people don’t contribute any software, any bug fixes, any blog mentions, or any anything to open-source projects, including those from which they derive considerable value. They just don’t. Sure, there are counterexamples to this, but they’re the exception, not the rule.” While true to some extent, the way the post is presented seems to imply that only commercial contributions are really of value (as he states later “So, if you want to rely on a community to build your product for you, good luck. You’re going to need it, as experience suggests that hard work by a committed core team develops great software, whether its Linux or Microsoft SharePoint, not some committee masquerading as a community.”)
This is somewhat true and somewhat false, and this dichotomy depends on the fact that “community” is an undefined word in this context. Two years ago I gave an interview to Roberto Galoppini, and one of the questions and answer was:
“What is your opinion about “the” community?
Alessandro [Rubini] is right in expressing disbelief in a generic “community”; there are organized communities that can be recognized as such (Debian or Gentoo supporters are among them) but tend to be an exception and not the rule. Most software do not have a real community outside of the developers (and eventually some users) of a single company; it takes a significant effort to create an external support pyramid (core contributors, marginal contributors, lead users) that adds value. If that happens, like in Linux, or the ObjectWeb consortium the external contributions can be of significant value; we observed even in very specialized projects a minimum of 20% of project value from external contributors.
I still believe that by leaving the underlying idea of “community” undefined Matt does collate together many different collaboration patterns, that should really not be placed together. In the mentioned example, the 20% was the result of an analysis of contribution to the OpenCascade project, a very specialized CAD toolkit. As I mention in my guide: “In the year 2000, fifty outside contributors to Open Cascade provided various kinds of assistance: transferring software to other systems (IRIX 64 bits, Alpha OSF), correcting defects (memory leaks…) and translating the tutorial into Spanish, etc. Currently, there are seventy active contributors and the objective is to reach one hundred. These outside contributions are significant. Open Cascade estimates that they represent about 20 % of the value of the software.” In a similar way, Aaron Seigo listed the many different ways “contribution” are counted in KDE, and noticed how those contributions are mostly not code-based:
- Human-computer interaction
- Quality Assurance
- Software Development
Or take the contributors area map from OpenOffice.org:
While the yellow area is code-related, lots of other contributors are outside of that, and help in localization, dissemination, and many other ancillary activities that are still fundamental for the success of a project.
The Packt survey that Matt mentions is explicit in the kind of contribution it was mentioned: “Despite this apparent success, individual donations play an important role in its development. Its team still maintains a page on the project website requesting monetary donations, which they utilize for the promotion of phpMyAdmin. This highlights the importance of individual contributions and how they still play a vital role in sustaining and opening up open source projects to a larger audience.” This kind of monetary contribution is the exception, not the role, and using this data point to extend it to the fact that most projects are not dependent on external contributions (or do so in limited way) is an unwarranted logic jump.
I must say that I am more in agreement with Tarus Balog, that in his post (called, humorously, “sour grapes“) wrote: “The fact that marketing people can’t squeeze value out of community doesn’t mean that communities don’t have value… OpenNMS is a complex piece of software and it takes some intense dedication to get to the point where one can contribute code. I don’t expect anyone to sit down and suddenly dedicate hours and hours of their life working on it. Plus, I would never expect someone to contribute anything to OpenNMS unless they started out with some serious “free-loader” time.” This resonates with my research experience, where under the correct conditions communities of contributors provide a non-trivial benefit to the vendor; on the other hand, as we found in our previous FLOSSMETRICS research, monetization barrier can be a significant hurdle for external, disengaged participation, and this may explain why companies that use an “open core” or dual licensing model tend to see no external community at all. On the other hand, when community participation is welcomed and there is no “cross-selling”, external participations may provide significant added value to a project. A good example is Funambol (that has one of the best community managers I can think of), and a Twitter post I recently read about them: “HUGE contribution to !funambol MS Exchange connector from #mailtrust. Way to go, #community rocks“. Are commercial OS providers really interested in dismissing this kind of contributions as irrelevant?
“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 email@example.com.
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
“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|
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:
[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