Posts Tagged OSS business models
What is an “open source company”? What is the real differentiation element introduced by Open Source? These and more questions were introduced by a great post by Matthew Aslett (if you don’t follow him, go and follow now. I’ll wait. Yes, do it. You will thank me later.), called “The decline of open source as an identifying differentiator“. It is an excellent analysis of how companies mostly stopped using the term “open source” in their marketing materials, and has a follow up (here) that provides a summary of the main responses by other analysts and observers.
The post raises several interesting points, and in my opinion provides a great basis for a more general discussion: what is the difference introduced by open source? Is there a difference at all?
Let’s start with an observation of the obvious: the use of open source to build software is now so widespread that it is not a differentiating element anymore. There goes the various “built on open source components” of some companies – practically all companies are using open source inside. It’s simply not a difference. So, let’s start with what is the real differential between OSS and proprietary:
The licensing. An open license may introduce a difference for the adopter. This means that if such a differential is used by the company, it must provide a value that derives from the intrinsic property of open source as a legal framework. For example, independence from supplier (at least, theoretically…) both in case of provider change, and independence in terms of adding or integrating additional components, even if the company is in disagreement.
The development model. The collaborative development model is not a certainty – it arises only when there is a clear infrastructure for participation. When it does happen, it is comparatively much faster and more efficient than the proprietary and closed model. For this to be a real differentiator, the company must engage in an open development model, and this is actually happening only in a very small number of cases.
In general, the majority of companies that we surveyed in FLOSSMETRICS have now a limited degree of differentiation when compared to their peers, and even as a “signaling” open source is now no more interesting than other IT terms that entered the mainstream (we can discuss further whether “cloud” will disappear in the background as well..) Of the companies we surveyed, I would say that those that we marked originally as “specialists” are the ones more apt to still use “open source” as a differentiating term, with “open core” ones the least (since they don’t reap the advantages of a distributed development model, neither the adopter reaps the advantages of the open source licensing). A potential difference may arise for development tools or infrastructures, where open source is a near necessity; in this case, the natural expectation will be for the platform to be open – thus not a differentiating element any more.
I have been talking about OSS for a long, long time, and my first public conference on the subject is still imprinted in my mind. It was at a very important post-universitary Italian school, with a renowned economic department, and I got invited to deliver a speech about EU activities in support of OSS, to an audience mainly composed of academics from sociology, economics, political science and such. Just after my talk, one of the professors started a lively debate, claiming that I was a “crypto-communist, deluded and trying to spread the false model of the gift economy upon IT”. Heck, I stopped talking for a moment – something that the people that knows me would find surprising (I tend to talk a lot, on things that I like). I had to think about the best way to answer, and was surprised to find that most of the audience shared the same belief. One professor mentioned that basic economic laws make the very idea of OSS impossible, or only a temporary step towards a market readjustment, and so on.
Guess what? They were wrong. And not wrong a little – wrong a lot (but it took me a few years to demonstrate it).
And so, after all these years, I still find sometimes academics that improvise on the subject, claiming certainty of their models; models that, usually, include hidden assumptions that are more myth and folklore than science. Thankfully for the many ones that are not subject to this faults (Dirk Riehle comes to mind, as Rishab Gosh, Paul David, Francesco Rullani, Cristina Rossi, and many others) we have real data to present and show. I still sometimes open my talks with a mention from “Government policy toward open source software”, a book from AEI-Brookings where Evans claims that “The GPL effectively prevents profit-making firms from using any of the code since all derivative products must also be distributed under the GPL license”. Go tell that to RedHat.
Now, I have a new contender for inclusion in my slides; an article from Sebastian von Engelhardt and Stephen M. Maurer, that you can find in all its glory here. I will try to dissect some of the claims that are hidden in the paper, and that for example push the authors towards “imposing a fixed, lump-sum tax on OS firms and using the proceeds to subsidize their [proprietary software] competitors”. I think that Microsoft would love that – a tax on RedHat, Google, IBM! What can be more glorious than that?
I will pinpoint some of the most evident problems:
- “For this reason, the emergence of fundamentally new, “open source” (OS) methods for producing software in the 1990s surprised and delighted observers.” Actually, as I wrote for example here, the tradition of collaborative development of software far predates Stallman and Raymond, and was the norm along with the creation of “user” (more appropriately “developer”) groups like SHARE (Society to Help Avoid Redundant Efforts, founded in 1955 and centered on IBM systems) and DECUS (for Digital Equipment computers and later for HP systems), both still alive. Code was also commonly shared in academic journals, like the famous “Algorithms” column of the “Communications of the ACM” journal. It was the emergence of the shrinkwrapped software market in the eighties that changed this approach, and introduced the “closed” approach, where only the software firm produces software. This is actually an illusion: in Europe, the market for shrinkwrapped software is only 19% of the total software+services marker, with own-developed software at 29%. We will return upon this number later.
- “This made it natural to ask whether OS could drastically improve welfare compared to CS. At first, this was only an intuition. Early explanations of OS were either ad hoc (“altruism”) or downright mysterious (e.g. a post-modern “gift economy”). [Raymond 1999] Absent a clear model of OS, no one could really be certain how much software the new incentive could deliver, let alone whether social welfare would best be served by OS, CS, or some mix of the two.” Argh. I understand the fact that my papers are not that famous, but there are several excellent works that show that OSS is about the economics of production, and not politics, ideology or “gif economies”.
- “economists showed that real world OS collaborations rely on many different incentives such as education, signaling, and reputation.” See? No economic incentives. People collaborate to show their prowess, or improve their education. Actually, this applies only to half of the OSS population, since the other half is paid to work on OSS – something that the article totally ignores.
- “We model the choice between OS and CS as a two-stage game. In Stage 1, profit-maximizing firms decide between joining an OS collaboration or writing CS code for their own use. In Stage 2 they develop a complementary product, for example a DVD player or computer game, whose performance depends on the code. The firms then sell the bundled products in markets that include one or more competitors.” So, they are describing either a R&D sharing effort or an Open Core model (it is not well explained). They are simply ignoring every other possible model, something that I have already covered in detail in the past. They also ignore the idea that a company may contribute to OSS for their own internal product, not for selling it; something that is in itself much bigger than the market for shrinkwrapped software (remember the 29% mentioned before?) and that is totally forgotten in the later discussion on welfare.
- “OS only realizes the full promise of cost-sharing when CS firms are present”. This is of course false: R&D sharing is always present every time there is a cooperation across a source base. But the article mentions only a simplistic model that assumes a OS company and a proprietary company (they insist in calling it Commercial Software, which is not).
There is a large, underlying assumptions: that OSS is produced now only by companies that create Open Core-like products. The reality is that this is not true (something that was for example found in the last CAOS report from the excellent Matthew Aslett) and the exclusion of users-developers makes any model that tries to extract welfare totally unreliable.
Ahh, I feel better. Now I have another university where I will never be invited
Yesterday Julie Bort wrote in the NetworkWorld site an interesting post called “Cisco doesn’t contribute nearly enough to open source”, where she contends that “”[despite its] .. proclaims it responsible for a half percent of the contributions to the Linux kernel (0.5%). In reality, Cisco has been a near non-entity as an open source contributor”. Of course the author is right in its claims – the amount of contributed code to the Linux kernel is substantial but very “vertical”, and specific to the needs of Cisco as a Linux adopter.
Which is a perfectly sensible thing to do.
The problem of “contribution” comes up and again in many discussions on open source and business adoption of OSS; it is, in fact, a source of major debate why participation is low, and what can be done to improve it. It is my opinion that there are some barriers to OSS contribution – namely, internal IPR policies, lack of understanding of how participation can be helpful and not just a gift to competitors, and more. On the other hand, two points should be made to complement this view: the first is that some companies contribute in ways that are difficult to measure, and the second is that sometimes companies have no economic reasons to do so.
Let’s start with the first point, that is a little peeve of me. Companies can provide source code; some do, and that’s a beautiful thing. However, there are many, many alternative ways of collaborating. Aaron Seigo, of KDE fame, in one presentation outlined the many activities that are part of the possible KDE contributions:
- Human-computer interaction
- Quality Assurance
- Software Development
In fact, I would say that some aspects like Artwork, Marketing and Quality Assurance may even be more important than pure coding – the problem is measuring such contributions. While the technical work underpinning source code analysis is quite well researched (among others, in our FLOSSMETRICS project) there is NO research on how to measure non-code contributions. And such contributions may be hugely important; one of my favorite example is the release, from Red Hat, of the Liberation fonts – a set of fonts with metrics compatible with the most widely used Microsoft fonts, like Arial. That alone helped substantially in improving the quality and correctness of document editing and visualization on Linux. How to measure that? Ubuntu has substantially contributed in terms of dissemination, in creating a base for many other distributions (including our own Everydesk). How to assess the value of that?
The second aspect is more complex, and is related to the strategy and tactics that a company uses to fulfill its own goals. Let’s take into account what a normal company do: first of all, survive (that is, revenues+reserves>expenses). Not all companies do have such a goal (a company designed to fulfill a task and then end its activities does have the survival goal with a deadline) but most do. This means that a company performs an internal or external activity if it does provide, now or in the future, a probable increase in revenues or reserves, or decreases expenses. Moral or ethical goals can be easily modeled in this schema using a “ethical asset”, that is a measure of how good we are in a specific target environment; for example, ecological contributions and so on.
So, let’s think about our typical company using OSS for a product. Let’s imagine that the company is doing a tactical adoption, that is it does not have a long term strategy that is based on Open Source. If the cost of contributing something is lower than the cost of doing everything from scratch, then the company will contribute back (or at least, the probability of that action is higher). In absence of a strategy based on open source, there is no need to go further.
For example, in the blog post the open sourcing of IOS is mentioned; the question is: why? What economic goal this open sourcing brings? If the company decides to adopt a long term strategy based on resource sharing (with the idea of receiving substantial contributions from external entities – like Linux, WebKit, Apache, and so on) then this may make sense; but it implies a substantial change in company strategy. Such large changes are not easy to do and perform well; Sun tried (and partly failed), and most of the “famous” examples are only partially adopting an open-based strategy (IBM, Oracle, Google).
To recap: 1) we must evaluate and appreciate all kind of contributions – not only code. 2) We can expect large scale contributions only from companies that bet their strategy on OSS – Red Hat is among my favorite examples of that. We cannot expect, realistically, for companies that are using Open Source in a tactical way to contribute back in the same way.
The (always great) Matthew Aslett posted today on some of his most recent results on the future of OSS licensing, in what he calls “Open Source 4.0″, characterized by corporate-dominated development communities. This form of evolution was one of the prediction in my previous posts – not for ethical,or community reasons, but for entirely practical and economic reasons: collaborative development is one of the strongest model in all the 11 basic components that we have identified in the FLOSSMETRICS group. In fact, I wrote in the past something like
“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“
which, I believe, matches quite well Matthew’s idea about OSS4.0. One area where I am (slightly) in disagreement with Matthew is related to licensing; I am not totally sure about the increased success of non-copyleft licenses in this next evolution of the open source market. Not because I believe that he is wrong (I would never do that – he is too nice ) but because I believe that there are additional aspects that may introduce some differences.
The choice of an open source license for a project code release is not clear-cut, and depends on several factors; in general, when reusing code that comes from external projects, license compatibility is the first, major driver in license selection. Licenses do have an impact on development activity, depending on the kind of project and who controls the project evolution. Previous studies that shown that restrictive, copyleft licenses do have a negative impact on contribution (for example in Fershman and Gandal, “Open source software: motivation and restrictive licensing”) has been refuted by other researchers (Stewart, Ammeter, Maruping, “Impacts of License Choice and Organizational Sponsorship on User Interest and Development Activity in Open Source Software Projects”). An interesting result of that research is the following graph:
What we found is that for non-market sponsors and new code, there is an higher development activity from outside partners for code that is released under a non-copyleft license. But this implies that the code is new and not encumbered with previous license obligations, like for example the reuse of an existing, copyleft-licensed project. The graph shows the impact on development activity in open source projects, depending on license restrictiveness and the kind of “sponsor”, that is the entity that manages a project. “No sponsor” is the kind of project managed by a non-coordinated community, for example by volunteers; “market sponsor” are projects coordinated by a company, while “nonmarket sponsor” are project managed by a structured organization that is not inherently for-profit, like a development consortia (an example is the Eclipse Foundation). The research data identified a clear effect of how the project is coordinated and the kind of license; the license restrictiveness has been found to be correlated with decreased contributions for nonmarket sponsors, like OSS foundations, and is in general related to the higher percentage of “infrastructural” projects (like libraries, development tools, enabling technologies) of such foundations.
In general,the license selection follows from the main licensing and business model constraints:
- When the project is derived from an external FLOSS project, then the main constraint is the original license. In this case, the basic approach is to find a suitable license from those compatible with the original license, and select among the possible business models the one that is consistent with the selected exploitation strategy.
- When one of the partners has an Intellectual Property Rights licensing policy that is in conflict with a FLOSS license, the project can select a MIT or BSD license (if compatible with an eventual upstream release) or use an intermediate releaser; in the latter case there are no constraints on license selection. If a MIT or BSD license is selected, some models are of difficult application: for example, Open Core and Dual Licensing are difficult to implement because the license lack the reciprocity of copyleft.
- When there are no external licensing constraints, and external contributions are important, license can be more or less freely selected; for nonmarket entities, a non-copylefted license gives a greater probability of contribution.
So, if you are creating a nonmarket entity, and you are free to choose: choose non-copyleft licenses. In the other situations, it is not so simple, and it may even be difficult to avoid previous licensing requirements.
The point on intermediate releasers require some additional consideration. An especially important point of OSS licenses is related to “embedded IPR”, that is the relationship of the code released with software patents that may be held by the releasing authority. While the debate on software patents is still not entirely settled, with most OSS companies vigorously fighting the process of patenting software-based innovations, while on the other hand large software companies defending the practice (for example SAP) most open source licenses explicitly mention the fact that software patents held by the releasing authority are implicitly licensed for use with the code. This means that business practices that rely on separate patent licensing may be incompatible with some specific OSS licenses, in particular the Apache License and the GPL family of licenses. The Eclipse Public License gives patent grants to the original work and to enhanced versions based on the original work but not to code not directly derived from the release, while permissive licenses like BSD and MIT give no patent rights at all.
If, for compatibility or derivation, a license that gives explicitly IPR rights must be selected, and the company or research organization wants to maintain the rights to use IPR in a license-incompatible way a possible solution may be the use of an intermediate releaser; that is, an entity that has no IPR on its own, to which the releasing organization gives a copy of the source code for further publication. Since the intermediate release has no IPR, the license clauses that require patent grants are not activated, while the code is published with the required license; this approach has been used for example by Microsoft for some of its contributions to the Apache POI project.
This may become an important point of attention for companies that are interested in releasing source code under an OSS license; most software houses are still interested in maintaining their portfolio of patents, and are not willing to risk invalidation through “accidental licensing” of IPR embedded in source code (one of the reasons why Microsoft will never sell a Linux based system).
As I wrote in the beginning, there is for a large number of consortia a clear preference for non-copyleft licenses; but it is not possible to generalize: the panorama of OSS is so complex, right now, that even doing predictions is difficult.
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.
It is now time to write the closing part of our long multi-part look at open source business models. After all the discussion on how to look at the various parts of a model and how to improve it, I will try to summarize a bit on how to look at an OSS business model, and what implications can be made from a specific choice (for once, without mentioning open core).
The basic idea behind business models is quite simple: I have something or can do something – the “value proposition” – and it is more economical to pay me to do or get this “something” instead of doing it yourself (sometimes it may even be impossible to find alternatives, as in natural or man-made monopolies, so the idea of doing it myself may not be applicable)
There are two possible sources for the value: a property (something that can be transferred) and efficiency (something that is inherent in what the company do, and how they do it). With Open Source, usually “property” is non-exclusive (with the exception of Open Core, where part of the code is not open at all). Other examples of property are trademarks, patents, licenses… anything that may be transferred to another entity through a contract or legal transaction.
Efficiency is the ability to perform an action with a lower cost (both tangible and intangible), and is something that follows the specialization in a work area or appears thanks to a new technology. Examples of the first are simply the decrease in time necessary to perform an action when you increase your expertise in it; the first time you install a complex system may require lots of effort, and this effort is reduced the more you experience the tasks necessary to perform the installation itself.
Examples of the second may be the introduction of a tool that simplifies the process (for example, through image cloning) and it introduces a huge discontinuity, a “jump” in the graph of efficiency versus time.
These two aspects are the basis of all the business models that we have analysed in the past; it is possible to show that all of them fall in a continuum between properties and efficiency:
Among the results of our past research project, one thing that we found is that property-based projects tend to have lower contributions from the outside, because it requires a legal transaction to become part of the company’s properties; think for example at dual licensing: to become part of the product source code, an external contributor needs to sign off his rights to the code, to allow the company to sell the enterprise version alongside the open one.
On the other hand, right-handed models based purely on efficiency tends to have higher contributions and visibility, but lower monetization rates. As I wrote many times, there is no ideal business model, but a spectrum of possible models, and companies should adapt themselves to changing market conditions and adapt their model as well. Some companies start as pure efficiency based, and build an internal property with time; some others may start as property based, and move to the other side to increase contributions and reducing the engineering effort (or enlarging the user base, to create alternative ways of monetizing users).
This is the last post in our little mini-serie on OSS business models; I hope that my archetypal three readers will have enjoyed it as much as I enjoyed writing them. Of course, I will be happy to read and respond to any comment – even negative ones.
Open core is usually built by a set of internal open source components held together by a dual-licensed wrapper, plus proprietary modules on the outside. One of the best examples of this is Zimbra (an excellent product on its own) but MySQL in recent editions can be included in the same group. As discussed in previous posts, dual licensing hampers contributions because it requires an explicit agreement on ceding rights to the company that employs it, in order to be able to relicense it for the proprietary edition. This means that Open Core companies, in itself, will have an easier time in monetizing their software, but will receive much less contributions in exchange. As I wrote before, it is simply not possible to get something like Linux or Apache with Open Core.
Again: open core is not bad per se (but I would have been more cautious in calling Sugar “an open source company”, for whatever definition you have of that). But it is a tradeoff: monetization versus contributions. And, my bets are on contributions, as OpenStack demonstrates – you need leverage and external resources to go beyond what a single company can do.
[Note: since I am writing this from a sunny beach, with a cell phone, I will not be able to add more than a few links to external pages. Will add the rest of them at my return, after the 12th of July]
It seems that Open Core continues to be the source of significant debate; I wrote quite a few posts in the past, and Open Core was one of our researched business models (for more details, see my LinuxTag presentation on business models). I would like to enter again the debate with a few short comments on my own:
- Companies using OC are not the devil, and should not be called names because of their choice of business model. Actually, there are no good and bad business models - only models that work, and those that do not. So, if open core works for a company, that’s a good thing.
- Open core models are somehow confusing for adopters. As a consultant for more than 100 companies and public administrations, actually explaining open core is one of my most common tasks. And the marketing message of companies is confusing: if you go to the Zimbra webpage (no offence against Zimbra, which is a company/product I love and use as example of good practice) you see the phrase “Zimbra – the leader in open source email and collaboration”, not “Zimbra – the leader in open source and proprietary email” (not that the phrase would win any context ) and the same for all the other open core companies. This is not, in my opinion, such a negative point if the website explains the difference between versions in a simple way, as for example both Zimbra and Alfresco do.
- It is true that open core models tend to have a higher revenue than non-OC models. It is also true that OC does have an intrinsic limited number of contributions from outside (as we found in FLOSSMETRICS analysing a few hundreds packages), and as can be found in the mentioned LinuxTag presentation. So, you may have higher monetization ratio, but you basically forfeit external contributions. The CEO should decide what is more important – so the decision is not “ethical”, but practical and based on economics. You will never get the kind of participation that Linux, Apache and Eclipse do have in an Open Core model. If that is ok for you – that’s great.
- The fact that most VC are funding open core companies is just a data point. Lots of open source companies do well without VC funding.
- It is true that lots of people claims that “pure” open source models are not sustainable. Even my friend Erwin Tenhumberg (that is quite knowledgeable, expert and incredibly nice on its own) had a slide in this sense in his LinuxTag presentation; and you can find lots of comments like that in many publication (something like “the majority of OSS companies adopt the so called mixed model”, despite this being actually false, as we found in our survey of OSS companies). The point, like said before, is that the important thing is not that there is a superior model, but that for every company, every market there is an optimal model – it may be OC, it may be pure services, or lots of combinations of our 11 building blocks. The optimal model changes with time and market condition, and what is appropriate now may be wrong tomorrow.
- No open source model can achieve the kind of profit margins of proprietary companies. So, if you want to make your OSS company, remember this basic fact. If you want the kind of profit margins of Microsoft or Oracle, forget it.
So, to end this post, there are three critical points: whether the model is clear for the adopter (and this should be a given, and actually nowadays I would say that most companies are absolutely honest and clear on this), whether the software in its open source edition provides sufficient functionality to be useful to a wide range of adopters (and this is a fine line to walk, and requires constant adaptation) and whether the increased monetization compensates for the lack of external contributions, that can substantially increase the value of the code base (you are trading cash for code and engineering, in a sense).
Can we put this to rest? End the name calling, be friends, and call all of us family? Especially since right now, under the sun of Fuerteventura where I am writing this, it seems difficult to fight
[by the way: sorry for any misspelling. There is no spell checker here on this small screen...]
Now that most of our work for FLOSSMETRICS is ended, I had the opportunity to try and work on something different. As you know, I worked on bringing OSS to companies and public administration for nearly 15 years now, and I had the opportunity to work in many different projects with many different and incredible people. One of the common things that I discovered is that to increase adoption it is necessary to give every user a distinct advantage in using OSS, and to make the exploratory process easy and hassle-free.
So, we collected most of the work done in past projects, and developed a custom desktop, designed to be explorable without installation, fast and designed for real world use; EveryDesk is a reinterpretation of the Linux desktop, designed to be used in public administrations or as an enterprise desktop. EveryDesk is a real OS on a USB key, not a live CD; this way the system allows for extensive customization and adaptation to each Public Administration need It is the result of the open sourcing of part of our HealthDesk system, designed using the result of our past European projects COSPA (a large migration experiment for European Public Administrations), SPIRIT (open source health care), OpenTTT (OSS technology transfer) and CALIBRE (open source for industrial environments).
EveryDesk is a binary image designed for 4GB USB keys, easy to install with a single command both on Linux and Windows, simple to replicate and adapt. It does provide a simple and pleasing user interface, with several pre-installed applications and native support for Active Directory. EveryDesk supports roaming/nomadic work through a special mode that stores all user data on a remote SMB server (both Samba and Windows are supported). This way, the user’s USB key contains no personal data, and can be used in environments that manage sensitive data, like health care or law enforcement.
The files and images can be downloaded from the SourceForge project page.
EveryDesk integrates a simple and easy to use menu, derived from Novell usability research studies, providing one-click access to individual programs, documents, places; easy installation of new software or updates, thanks to the fully functional package manager.
EveryDesk includes support for Terminal Services, VNC, VmWare View and other remote access protocols. One peculiarity we are quite happy with is the idea of simplified VDI; basically, EveryDesk integrates the open source edition of VirtualBox, and allows for mounting the disk images remotely – so the disk storage is remote, and the execution is local. This way, VDI can be implemented by adding only storage (that is cheap and easy to manage) and avoiding all the virtualization infrastructure.
The seamless virtualization mode of VirtualBox allows for a quite good integration between Windows (especially Windows 7) and the local environment. Coupled with the fact that the desktop is small and runs in less than 100MB (with both Firefox and OpenOffice.org, it takes only 150MB) it makes for a good substitute of a traditional thin client, is manageable through CIM, and is commercially supported. Among the extensions developed, we have a complete ITIL compliant management infrastructure, and digitally-signed log storage for health care and law enforcement applications.
Marten Mickos (of MySQL fame) once said that “people spend time to save money, some spend money to save time“. This consideration is at the basis of one of the most important parameter for most OSS companies that use the open core or freemium model, that is the conversion rate (the percentage of people that pays for enterprise or additional functionalities, versus the total amount of users). With most OSS companies reaching less than 0.1%, and only very few capable of reaching 1%, one of the obvious goals of CEOs of said open source companies is to find a way to “convert” more users to paying for services, or to increase the monetization rate.
My goal today is to show that such effort can have only a very limited success, and may be even dangerous for the overall acceptance of the software project itself.
Let’s start with an obvious concept: everyone has a resource at his/her disposal, namely time. This resource does have some interesting properties:
- it is universal (everyone has time)
- it is inflexible (there are 24 hours in a day, and anything you can do will not change it)
- efficiency (work done in the unit of time) does have a lower bound of zero, and an higher bound that depends on many factors; efficiency can vary by one order of magnitude or more.
Another important parameter is the price per hour for having something done. At this point, there is a common mistake, that is assuming that there is a fixed hourly rate, or at least a lower bound on hourly rate. This is clearly wrong, because the price per hour is the simple ratio between what someone is paying you to do the work and the amount of time required for that action; so if no-one pays you, that ratio is zero. So, let’s imagine someone working for a web company, and one of the activities requires a database. Our intrepid administrator will start learning something about MySQL, will work diligently and install it (ok, nowadays it’s nearly point-and-click. Imagine it done a few years ago, with compiles and all that stuff).
This system administrator will never pay for MySQL enterprise, or whatever, because its pay is fixed, and there is no allocated budget for him to divert money to external entities. So, whatever is done by MySQL to monetize the enterprise version, there will be simply no way to obtain money from the people that is investing time, unless you sabotage the open source edition so that you are forced to pay for the enterprise one. But what will happen then? People will be forced to look at alternatives, because in any case time is the only resource available to them.
This basic concept is valid even when companies do have budget available. Consider the fact that the average percentage of revenues invested in ICT (information and communication technology) by companies is on average around 5%, with some sectors investing slightly less (4%) up to high-tech companies investing up to 7%. This percentage is nearly fixed, valid for small to large companies and across countries and sectors; this means that the commercial OSS company is competing for small slices of budget, and its capability to win is related mainly to the perceived advantages of going “enterprise” versus investing personnel time.
Does it means that trying to increase conversion rate is useless? Not exactly. The point is that you cannot address those users that have no budget available, as those will never be able to pay for your enhanced offering; you have two different possible channels: those that are using your product and may have the potential to pay, or address the group of non-users with the same demographics. So, the reality is that mining current users is potentially counterproductive, and it is more sensible to focus on two interlocking efforts:
- increase the number of adopters, and
- make sure that people knows about the commercial offering.
This can be performed “virally”, that is by creating an incentive for people to share the knowledge of your project with others, which is very fast, efficient and low-cost; however, this approach does have the disadvantage that sharing will happen within a single group of peers. In fact, viral sharing happens within only homologous group, and this means that it is less effective for reaching those users that are outside the same group – for example, the non-users that we are pointing at. This means that purely viral efforts are not capable of reaching your target – you need to complement it with more traditional marketing efforts.
Next: resource and development sharing, or how to choose your license depending on your expectations of external participation.