Archive for July, 2011

“FOSS isn’t always the answer”. And you asked the wrong question.

There is an interesting post from James Turner on O’Reilly Radar, that starting with the charming title of “FOSS isn’t always the answer” and ends up with, among other interesting comment, something like “But [the FLOSS proponent] need to accept the ground rules that most of us live in a capitalist society”. At that point, I was snickering and torn between laugh it off or respond – and of course, my desire to find good excuses for not work today had finally won me over.

from the always, always perfect Xkcd

Reading this post made me think of one of my first conferences, where an economics professor kindly told me “good work, kid. Now, economic theory tells us that this little, nice communist dream will fail in one or two years. In the meanwhile, enjoy your gift economy ideal”. I have been called a “communist” for quite some time, and still chuckle at the idea: that someone still thinks that FLOSS is inherently “anti-capitalistic”. This is something that curiously is commonly repeated by people working for a very large, Redmond-based company, that constantly presents slides like these:


See? The GPL is, magically, “anti commercial” (despite the fact that OSS provide cost reduction and increases in efficiency of at least 116B€, 31% of the software and services market). And the author makes the example of TCP/IP or NSA linux as projects that made no commercial impact… Let’s all revel in the idea that TCP/IP had no commercial impact for a moment, including the irony of doing it on a TCP/IP network like the Internet, and let’s continue.

Let’s comment on the individual points that Turner raises:

“No one uses a closed source compiler anymore, Eclipse is one of the leading IDEs for many languages, and Linux is a dominant player in embedded operating systems. All these cases succeeded because, largely, the software is secondary to the main business of the companies using it (the major exception being Linux vendors who contribute to the kernel, but they have a fairly unique business model.)” That’s an interesting comment, for more than a reason. First of all, because it fails to grasp one of the most important economic points of software: with the exception of software producers, software is always secondary – it is a supporting technology. You would consider electric power as secondary as well, despite the fact that it is essential; software has a similar property – it is secondary and essential at the same time. The second interesting comment is related to Linux vendors: for some curious reasons they were able to profit from something that is distributed for free, but Turner dismisses them as an “exception” because… they don’t fit his model of the market.

“Where FOSS breaks down pretty quickly is when the software is not a widely desired tool used by the developer community.” The underlying assumption is that open source is developed for free by developers, because that’s what they do normally, and they want to donate time to the community. This assumption is wrong. The majority of open source developers are paid for work on open source; also, the idea that they do it for free is some nice communist-like idea that is unfortunately totally distant from reality.

“The typical line of thought runs like this: Let’s say we’re talking about some truly boring, intricate, detail-laden piece of software, such as something to transmit dental billing records to insurers … So, if all software should be free and open source, who is going to write this code? One argument is that the dentist, or a group of dentists, should underwrite the production of the code. But dentistry, like most things in western society, tends to be a for-profit competitive enterprise. If everyone gets the benefit of the software (since it’s FOSS), but a smaller group pays for it, the rest of the dentists get a competitive advantage. So there is no incentive for a subset of the group to fund the effort.” There goes the main argument: since software is given for free, and someone else is getting advantages for free, free riding will quickly destroy any incentive. This is based on many wrong assumptions, the first of which is that the market is always capable to provide a good product that matches the needs of its users. This is easily found out to be wrong, as the example of SAKAI and Kuali demonstrate: both products were developed because the proprietary tools used by the initial group of universities were unable to meet the requirements, and the costs were so high that developing reusing open source was a better alternative. And consider that Kuali is exactly the kind of software that Turner identifies as “non-sexy”, that is a financial management system (if you want more examples of the medical nature, go to VISTA, OpenClinica, or to meet Turner article, OpenDental). The reality is that some kind of software is essential, most of the software is non-differentiating, and maintaining that software as open source has the potential to reduce costs and investment substantially – for the actual data, check this post).

“Another variant is to propose that the software will be developed and given away, and the developers will make their living by charging for support. Leaving alone the cynical idea that this would be a powerful incentive to write hard-to-use software, it also suffers from a couple of major problems. To begin with, software this complex might take a team of 10 people one or more years to produce. Unless they are independently wealthy, or already have a pipeline of supported projects, there’s no way they will be able to pay for food (and college!) while they create the initial product.” Great! Turner now discovered one of the possible open source-based business models we classified in FLOSSMETRICS. Of course, he conveniently forgot that by reusing open source, this hapless group of starved developers can create their product for one tenth of the cost and the time. So, the same property that Turner thinks can doom this poor group of misguided developers can actually provide them with the solution as well.

“And once they do, the source is free and available to everyone, including people who live in areas of the world with much lower costs (and standards) of living. What is going to stop someone in the developing world from stepping in and undercutting support prices? It strikes me as an almost automatic race to the bottom.” That’s called competition. Never heard of it? Despite the “race to the bottom” (that, in economic terms, is applicable only to commodities) service companies seem to do quite well nowadays.

“But I have spent most of my adult life writing proprietary software — most of it so specialized and complicated that no open source project would ever want to take it on — and I find the implication that the work I do is in some way cheap or degrading to be a direct insult.” Here we see two different concept: the first, that open source is unable to reach the level of complexity of proprietary software. This is contradicted by some of the examples mentioned by Turner himself (unless he considers a compiler to be too simple), or by academic research: “The growing rate, or the number of functions added, was greater in the open source projects than in the closed source projects. This indicates that the open source approach may be able to provide more features over time than by using the closed source approach. In terms of defects, our analysis finds that the changing rate or the functions modified as a percentage of the total functions is higher in open source projects than in closed source projects. This supports the hypothesis that defects may be found and fixed more quickly in open source projects than in closed source projects, and may be an added benefit for using the open source development model.” (Paulson, Succi, Eberlein “An Empirical Study of Open Source and Closed Source Software Products”).

More important is the second part of the phrase: “the implication that the work I do is in some way cheap .. is a direct insult”. There you are: unless I am paid directly for my software, I consider it to be too cheap. This means only one thing: that Turner knows only one potential model, that is the “I sell a box to you, and you pay it for that”, and all the others are an “insult”. Well, RedHat does it differently, and is reaching 1B$ in revenues; my brief contacts with RHT people never gave me the indication that they feel insulted. Or OpenNMS, where Tarus is proud of its openness. Or Eclipse (the ultimate communist dream! Friends and Foes all together!)

“But they need to accept the ground rules that most of us live in a capitalist society, we have the right to raise and provide for a family, and that until we all wake up in a FOSS developer’s paradise, we have to live and work inside of that context. I’d love to hear how a proprietary-free software world could work.” Here we return to the assumption that open source is inherently non-capitalist, which is simply not true; the ending is also telling: “a proprietary-free software world” assumes that there should be only one solution. Exactly like Turner, I believe in freedom of choice – anyone is free (when is not forced by his government to use a proprietary office suite or operating system, of course) to choose for the best. I would not, however, bet against FLOSS.

1 Comment

It could have been different: Android, Google and all that

If there’s one thing that is totally clear, is that Android is ravaging the smartphone market, and all those that are feeling the heat are trying to use the most innovative and transparent approach to stop it: sue Google and its partners out in the oblivion. Software patents, design patents, copyrights, plain trolling- anything goes if it can help in stop the Droid juggernaut. At the same time, Google is under attack for its delay in publishing the Honeycomb source code, attacked for the half-backed results that can be witnessed in some tablet products, all of this in an environment where Android phone makers are obtaining extraordinary revenues, in large part thanks to those contested products (Samsung comes to mind).

Of course, hindsight is 20/20 as they say, and it’s easy to “predict” that the extraordinary success of Android would have generated such a defensive attack. It is however at least predictable, given the extreme litigation of software companies, that patents would have been used as a blunt instrument to fend off competitors. Could things have been different? I believe so, and I also believe that Google made some errors in its decision, especially in trying to create a control point (the “Google experience”) instead of favoring a more long-term vision.

Let’s start from the beginning. Android is two things at once; from one side it is a collection of many, many different open source projects, some external, some Google-created, some heavily modified and adapted specifically for the purpose. There is a separate, private tree (at the moment the 3.x branch) that is also based on open source projects, but is at the moment internal to Google and the partners that decided to join its Open Handset Alliance. Some projects are clearly behind their open counterparts, especially WebKit, while at the same time maintaining substantial external off-tree patches that are extremely difficult to integrate like in the Linux Kernel. There is an additional layer of totally proprietary apps, that are installable only for those partners (and phones) that subjugate themselves to an additional set of requirements and licensing rules, something that for example caused lots of problems for Motorola and Google in the SkyHook lawsuit. This will probably continue, and will be the real battleground, given the fact that Android and iOS are clearly emerging as the leading platforms.

Could it have been different? I think so. And by releasing some degree of control, Google could have created a much safer and open environment, while sacrificing very little. Let’s start with the point that what Google really, really wants is an unencumbered rich internet-enabled platform, that is not constrained by third parties, and that it uses Google services. The reality is that Google lives off advertising (at the moment, at last) and is trying to expand it to other services, like enterprise mail, documents, and so on; there are two roads to do that: the first is to create a platform that is strongly tied to Google services, so that it is nearly impossible to escape its control. In doing so, however, you face the tension of the OEM and vendors that may want to switch services, or that want to push internally developed offerings. In this case, they will have nothing left to do but to go with the competition, or create their own variant (something that already happened) increasing the adoption costs.

The alternative is the “A rising tide lifts all boats” – make it a purely open source project, where there is a real distributed control, like Eclipse. Turn it to the Apache foundation. Make all the interested partners a part of the foundation or consortium, make the code public (with limited exceptions, like for prerelease hardware drivers) and try to track as much as possible the projects where you take things from. Apply a strict code contribution regime to strengthen your position against IP claims, and especially don’t turn it into a product. Yes, you read it properly- the code should be a strict open source project. This way, it would be extremely difficult for an external party to sue the “origin”, given the difficulties in identifying a directly derived infringing device; Google could have then (using this more sanitized and cleaner base) provided insurance through a third party for IP infringement claims, if the code base adopter would want to use such an opportunity (some may decide to fight on their own, of course). This implies that an Android OEM can substitute the Google services and use something else (that, by the way, is possible even now) but would have easily prevented most antitrust-based attacks. The purely open code base and the increased external participation would have further shortened the time-to-market for providing a new board to the marketplace, reduced adoption costs, and facilitated an external ecosystem of providers for Android based services.

Google could have at least avoided some of the worst blows, increased its credibility with the various OS communities, and reduced the cost of adopting Android for an OEM, pushing more and more the platform. This, in exchange for some of the tight control that currently Google exercise on the platform. Unfortunately, I think it’s too late for that; and we will still have to face the sad situation that the life of a mobile platform is dictated purely by judges.

, , ,


Open Source as a differentiator?

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.

, ,