Archive for August, 2010

OSS 4.0 and licenses: not a clear-cut choice

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.

, , , ,


Oracle, Sun, Java: lawsuits mark the exit road

I already wrote a few words on the Oracle/Google lawsuits here and here, and I would like to thank all those that found them interesting enough to read and comment on. I found recently a very interesting post by Java author extraordinaire, James Gosling, where he answers on some of his readers’ comments. In the post there are many interesting ideas, and a few points that I believe are not totally accurate – or better, may be explained in a different way. In particular, I believe that the role of Java in the enterprise will remain and will become “legacy”, that is stable, plain and boring, while the real evolution will move from Java to… something else.

James clearly points out the fact that JavaME fragmentation was a substantial hurdle for developers, and believes that in a lesser way this may be true for Android as well. While it is true that fragmentation was a problem for Java on mobile, this was a common aspect of mobile development at the time (go ask a Windows Mobile developer about fragmentation. And see a grown man cry, as the song says). The problem of JavaME was not fragmentation, but lack of movement – the basic toolkits, the UI components, most of the libraries for one reason or the other remained largely unchanged apart a few bug fixes. JavaFX should have been promoted much, much earlier, and would have had a great impact on software development, like (I believe) the more recent Qt releases from Nokia and their idea of declarative user interfaces.

If we compare with the rest of Java, we see a much stronger push towards adding libraries, components, functionalities: all things that made Java one of the best choices for software developers in the enterprise space, because the developers can trust Sun to update and extend their platform, making their job easier and faster. It was the same approach that made Microsoft the king of software: create lots of tools and libraries for developers, sometimes even trying to push more than one approach at a time to see what sticks (like Fahrenheit) , or trying very experimental and skunkworks approach, that later are turned into more mature projects (like WinG). JavaEE and JavaSE followed the same model, with a consistent stream of additions and updates that created a confidence in developers – and, despite all the naysayers, for enterprise software Java was portable with very little effort, even for very large applications.

JavaME was not so lucky, and partly to guarantee uniform licensing Sun was forced to do everything on their own (a striking difference with Android, that – if you check the source code – included tons of external open source projects inside) limiting the rate of growth attainable. Some features that now we take for granted (like web browsing) were not included as default, or implemented by vendors in inconsistent way because Sun never gave guidance on the roadmap and product evolution; multimedia has been mostly an afterthought, usually forcing developers to create (or buy) external libraries to implement anything more complex than a video or audio player. As I wrote before: JavaFX should have been announced much, much earlier, and not as a reactive answer to the competition, but as part of a long-term roadmap that JavaEE had, while the rest of Java missed.

This is, in my opinion, one of the real reasons for the lawsuit: Sun (now Oracle) was unable to create and maintain a real roadmap outside of JavaEE (and partly JavaSE), and especially for JavaME they constantly followed – never led. This, as any developer will tell you, is never a good position; it’s full of dust and you miss all the scenery. So, since Oracle is really more interested in their own markets (the DB and the applications) and not really caring about software developers, ecosystems or openness, they probably believe that lawsuits do have a better return on investment.



OpenWorldForum 2010: Join me in the OSS governance session!

I will have the opportunity to present our most recent results on the best practices for OSS adoption at the Open World Forum governance session, moderated by Martin Michlmayr (HP community manager) and Matteo Melideo (QUALIPSO project consortium leader). The program is available here, and packs quite a substantial amount of high quality talks. I hope to see you there!

The Open World Forum is the premier global summit meeting bringing together decisions-makers from across the world to discuss the technological, financial and social impact of open technologies, and to cross-fertilize ideas and initiatives in these areas. At the hub of the Free/Open Source revolution, the event was first staged in 2008, and takes place every year in Paris with more than 140 speakers from 40 countries, a 1,500-strong international audience and numerous conferences, workshops and think-tanks. The 2010 Open World Forum will be held on 30 September and 1 October, under the banner of “Open is the future: Open Innovation – Open Enterprise – Open Society”. Organized by a unique network of partners including the main Free/Open Source communities and most of the leading IT players worldwide, the Open World Forum is a must-attend event to discover the latest trends in open technology, business and social issues and to explore the future of Free/Open Source initiatives. It also offers a unique opportunity to share insights and best practices with many of the most respected visionaries, entrepreneurs and community leaders, and network with technology gurus, CxOs, analysts, CIOs, researchers, government leaders and investors from six continents. To request an invitation, please visit


No Comments

EveryDesk beta3 released – now available as a VirtualBox image!

I am quite happy to announce the release of the third beta of our EveryDesk flash-based desktop, now available in VirtualBox format as well – so you can try it out without the need of a USB key. EveryDesk is a reinterpretation of the Linux desktop. It executes from a 4Gb USB Key, and allows the user to run a modern and efficient Linux Desktop on most PCs without the need of changing or removing the native operating system such as Windows. 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, and as such allows for extensive customization and adaptation to each Public Administration need. It is the result of the open sourcing of parts of the  Conecta 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).

There are more than 120 changes from the previous edition; among them, all the medical applications are integrated in the same image – so there is no need to have a separate edition for Health Care applications. Among the updates:

  • Latest edition of the DICOM browser for hospitals and medical applications; now supports per-user monitor calibration.
  • Integrated medical dictionary in
  • Integrated the After the Deadline OpenOffice grammar checker
  • LikeWise 6 Active directory integration tool
  • A fast, efficient and very capable RDP, NX and VNC connection manager: Remmina based on FreeRDP
  • The latest VirtualBox
  • Several ancillary additions, like a large complement of fonts



To facilitate the final bug fixing, we made the boot process visible – that will be reverted to silent boot as soon as the final testing is completed. As usual, you will find the images at our sourceforge page.

, ,


Oracle/Google: the strategy behind Sun, Oracle and the OSS implications

In my previous post, I tried to provide some details on what in my opinion were the most relevant legal and licensing aspects of the recently launched Oracle lawsuit against Google. I would like now to provide some perspective on what may have been the motives behind this lawsuit, and what are the possible implications for the Java and Open Source communities.

First of all, it is clear that, as I mentioned before, Google turned the lawsuit into a positive event for their (slightly battered) public image. By turning the lawsuit against Android into an attack to the open source community, Google effectively created a positive image, as David unjustly accused by the Oracle giant. It is also clear that the lawsuit itself is actually quite weak, focusing on a copyright claim that is very vague (given the fact that Google never claimed to use Java), and a set of patent claims for techniques that are probably not relevant anymore (especially in the post-Bilski era). One of the possible reasons for this is to be sure that even the widely different Dalvik machine would be at least partially covered; the other is the fact that all of Classpath was included in the OIN “System Components” covered technologies. Since both Oracle and Google are part of OIN, I suspect that Oracle wanted to avoid any potential complication coming from this “broken marriage”.

But – this is not the only relevant aspect. Actually, an angle that is probably more important is the impact of the lawsuit on Java, Java for mobile, Android and the OSS communities that were part of the Sun technology landscape.

Enterprise Java: no change at all. Java is a very strong brand among corporate developers, and I doubt that the lawsuit will change anything at all; in fact, all the various licensee of the Java full specification are on perfectly legal grounds, and face no problem at all. Despite the opportunistic claims by Miguel De Icaza (that suggests that Mono/C# would have been a better choice), there is nothing in the lawsuit that would imply that other Java or Java-related technologies may be impacted (actually, Mono and the CLR are in the same situation as Dalvik, actually).

Mobile Java: as I mentioned before, the lawsuit put the last stone on the JavaME grave. The only potentially relevant route away from the land of the dead could have been JavaFX; that was too little, too late – incomplete, missing several pieces, missing a roadmap, and uselessly released as a binary-only project. Android  used the Java language, extended it with mobile-specific classes that were more modern and more useful for recent smartphones and even non-phone applications (like entertainment devices, automotive and navigation devices). It is not a surprise, that coupled with the Google brand name, Android surged in popularity so much as to become a threat.

Oracle OSS projects: Oracle has always been an opportunistic user of open source. With the term “opportunistic” I am not implying any negative connotation: simply the observation that Oracle dabbled in open source whenever there was an opportunity to reduce its own research and development costs. If you look at oracle projects, it is clear that all projects are related to infrastructural functionality for the Oracle run-time and for developers tools (using Eclipse as a basis). I was not able to find any “intrinsic” open source project started or adopted by Oracle that was not focused on this approach. So, for those projects, I believe that there will be no difference; for example, I believe that the activity on the Oracle-sponsored BTRFS project will not change significantly. Oracle, actually does not care at all if they are seen as “enemies”, or if their projects are not used anymore by others. What they care for is for their patches to be included in Linux. Remember that Oracle is an “old style” company; it does have two basic product lines: its database and its set of enterprise applications. Everything else is not quite necessary, and probably will be abandoned.

Sun OSS projects: as for Sun, there is a long preamble first. Sun has always been, first and foremost, an engineering company – something like Silicon Graphics in the past, or more recently Google. Sun had open sourced something of value whenever it was necessary to establish a common platform or protocol, like NFS or NIS+; but it was the advent of Jonathan Schwartz that actually turned things towards open source. The ponytailed CEO tried to turn the Sun behemoth towards a fully open strategy, but was unable to manage the conversion before being ousted out. It is a pity, actually – Sun could have leveraged its size, large number of technical partners and amount of technologies to become a platform provider like RedHat – but 10 times larger. The problem of this strategy is that it implies a large amount of cooperative development, and thus a substantial downsizing of the company itself. The alternative could have been the use of an open-core like strategy, for example creating a scalable JVM designed to auto-partition code execution on network of computers. The basic JVM could have been dual licensed, with the enhanced one released on a proprietary basis; this could have leveraged the exceptional Sun expertise in grid and parallel computing, filesystems and introspection systems.

But Sun never managed to complete the path – it dwindled left and right, with lots of subprojects that were started and abandoned. The embracing of PostgreSQL, its later abandonment, the latter embrace of MySQL, that was then not integrated anywhere; the creation of substantial OSS projects from their proprietary offering, but then losing interest as soon as a project started to become a threat for the proprietary edition. There is no surprise that despite the incredible potential, Sun never recouped much of their OSS investment (despite the great growth in their latest quarters, the OSS services remained a small portion of their revenues). Now that Oracle has taken control, I believe that Sun “openness” will quickly fade towards small, utilitarian projects – so, even if now everyone looks at Oracle with anger, noone at Oracle could care less.

Why oracle sued? The blogosphere is exploding with possible answers; my own two hypothesis are:

  • Oracle found a substantial technology it acquired (Java) losing value in what is the hottest tech market today, namely mobile systems. Sun had no credible plan to update JavaME, no credible alternative, and thus Android (that is loosely java based) is at the same time a threat to an acquired asset and (from their point of view) a stolen technology. Since anyone can follow the same path, Oracle wants to make sure that noone else would try to leverage Java to create an unlicensed (and uncontrolled) copy.
  • Oracle wants a piece of the mobile enterprise market, and the alternatives are unavailable (Apple does not want anything to do with Java, Blackberry is a JavaME licensee, Windows Mobile is backed by arch-rival Microsoft). Android is working well, grows incredibly fast, and Oracle wants a piece of it; Google probably rebuffed initial contacts, and now Oracle is showing the guns to make Google obey. I am skeptical, however, that Google would back down on what is becoming its most important growth path. The lawsuit itself is quite weak, and Google would risk too much by licensing the TCK from Oracle; they would basically destroy their opportunity for independent development. It is never a good idea to corner someone – if you leave no alternative, fight is the only answer.

I believe that the first one is the most probable one; Larry Ellison should know that cornering Google would not be sufficient to make them capitulate – they have too much to lose. But this will not be sufficient to create an opportunity for Oracle; I believe that the lawsuit will actually bring nothing to Oracle, and lots of advantages to Google. But only time will tell; the only thing that I can predict for sure right now is that Solaris will quickly fade from sight (as it will be unable to grow at the same rate of Linux) exactly like AIX and HP-UX: a mature and backroom tech, but nothing that you can base a growth strategy upon.



Oracle/Google: the patents and the implications

Just as LinuxCon ended, Oracle announced that it has filed suit for patent and copyright infringement against Google for its implementation of Android; as an Oracle spokesperson said, “In developing Android, Google knowingly, directly and repeatedly infringed Oracle’s Java-related intellectual property. This lawsuit seeks appropriate remedies for their infringement … Android (including without limitation the Dalvik VM and the Android software development kit) and devices that operate Android infringe one or more claims of each of United States Patents Nos. 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; and 6,061,520.” (some more details in the copy of Oracle complaint). Apart from the slight cowardice of waiting after LinuxCon for announcing it, the use of the Boies Schiller legal team (the same of SCO) would be ironic on its own (someone already is calling the company SCOracle).

The patent claims are:

Let’s skip the patent analysis for a moment, and let’s focus on the reasons behind this. Clearly, it is a move typical of mature industries: when a competitor is running past you, you try to put a wrench in its engine. That is a typical move, and one of the examples of why doing things by the book in this modern, collaborative world is wrong. Not only that, but I believe that previous actions by Sun made this threat clearly useless – even dangerous.

Let’s clear the table from the actual patent claims: the patent themselves are quite broad, and quite generic; a good example of what should not be patented (the security domain one is a good example; look at the sheet 5 and you will find the illuminating flowchart with the representation of: do you have the rights to do it? if yes, do it, if no, do nothing. How brilliant). Also, Dalvik implementation is quite different from the old JRE one, and I have strong suspicions that the actual Dalvik method is substantially different. But, that is not important. I believe that there are two main points that Oracle should have checked before filing the complaint (but, given the use of Schiller&Boies, I believe that they have still to learn from the SCO debacle): first of all, Dalvik is not Java and Google never claimed any form of Java compatibility. Second, there is a protection for patents as well, just hidden in recent history.

On the first point: in the complaint, Oracle claims that “The Android operating system software “stack” consists of Java applications running on a Java-based object-oriented application framework, and core libraries running on a “Dalvik” virtual machine (VM) that features just-in-time (JIT) compilation”. On copyrights, Oracle claims that “Without consent, authorization, approval, or license, Google knowingly, willingly, and unlawfully copied, prepared, published, and distributed Oracle America’s copyrighted work, portions thereof, or derivative works and continues to do so. Google’s Android infringes Oracle America’s copyrights in Java and Google is not licensed to do so … users of Android, including device manufacturers, must obtain and use copyrightable portions of the Java platform or works derived therefrom to manufacture and use functioning Android devices. Such use is not licensed. Google has thus induced, caused, and materially contributed to the infringing acts of others by encouraging, inducing, allowing and assisting others to use, copy, and distribute Oracle America’s copyrightable works, and works derived therefrom.”

Well, it is wrong. Wrong because Google did not copied Java – and actually never mention Java anywhere. In fact, the Android SDK produced Dalvik (not Java) bytecodes, and the decoding and execution pattern is quite different (and one of the reasons why older implementations of Dalvik were so slow – they were made to conserve memory bandwidth, that is quite limited in cell phone chipsets). The thing that Google did was to “copy” (or – for a better word – inspire) the Java language; but as the recent SAS-vs-WPS lawsuit found, “copyright in computer programs does not protect programming languages from being copied”. So, unless Oracle can find pieces of documentation that were verbatim lifted from the Sun one, I believe that the copyright part is quite weak.

As for patents, a little reminder: while copyright covers specific representations (a page of source code, an Harry Potter book, a music composition), software patents cover implementations of ideas, and if the patent is broad enough, all possible implementation of an algorithm (let’s skip for the moment the folly of giving monopoly protection on ideas. You already know how I think about it); so, if in any way Oracle had, now or in the past, given full access to those patents through a licensing that is transferable, Google is somehow protected there as well. And – guess what? That really happened! Sun released the entire Java JDK under the GPLv2+classpath exception; granting with that release full rights of use and redistribution of the IPR assigned on what was released. This is different from the TCK specification, that Google wisely never licensed; because the TCK license requires for the patents to be transferred to limit the development to enhancements or modifications to the basic JDK as released by Sun.

But, you would say, Dalvik is independent from OpenJDK, so patents are not transferred there. So, include the code that is touched by the patents from the OpenJDK within Dalvik – compile it, and make a connecting shim, include it in a way that is GPLv2 compatible. The idea (just an idea! and IANAL of course..) is that through the release of the GPL code Sun gave an implicit license to embedded patents that is connected with the code itself. So, if it is possible to create an aggregate entity of the Dalvik and OpenJDK code, the Dalvik one would become a derivative of the GPL license, and would obtain the same patent protection as well. That would be a good use of the GPL, don’t you think?

What will be the result of the lawsuit? First of all, the open source credibility of Oracle, already damaged by the OpenSolaris affair, is now destroyed. It is a pity – they have lots of good people there, both internal and through the Sun acquisition; after all, they are among the 10 largest contributors to the Linux kernel. That is something that will be very difficult to recover.

Second, Google now has a free, quite important gift: the attention has been moved from their recent net neutrality blunder, and they are again the David of the situation. I could not imagine a better gift.

Third, with this lawsuit Oracle basically announced the world that Java in mobile is dead. This was actually something that most people already knew – but seeing it in writing is always reassuring.

Update: Miguel de Icaza claims that “The Java specification patent grant patent grant seems to be only valid as long as you have a fully conformant implementation”, but that applies only to the Standard Implementation of Java, not OpenJDK. Sorry Miguel – nice try. More luck next time.

Update 2: cleaned the language on the phrase on patents, ideas and implementation that was badly worded.ù

Update 3: clarified the Dalvik+OpenJDK idea.

, ,


Estimating source-to-product costs for OSS: an experiment

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.

, ,