If there is a concept that is clear in the analysts’ minds is the fact that mobile (in any form) is the hot market right now. Apple’s iOS devices are growing by leaps and bounds, dispelling the doom predictions of our beloved Ballmer: “There’s no chance that the iPhone is going to get any significant market share. No chance. … 2% or 3%, which is what Apple might get” or dismissing the iPad as “yet another pc”. The reality is that new mobile platform are consolidating a concept -  the idea of the App store, that is an integrated approach to managing and buying applications – and the idea of “apps for everything”, even for data that comes off straight from a web site, like the recently launched Twitter app for the iPad, that is – in my own, clearly subjective opinion – beautiful.

After all the talks about platform independence, portability, universality of HTML5, and so on  – why Apps? why closed (or half-open) app stores, when theoretically the same thing can be obtained through a web page? I have a set of personal opinion on that, and I believe that we still need some additional features and infrastructures from browsers (and probably operating systems) to really match the feature set and quality of apps. If – or when – those missing pieces are delivered to the browser, the whole development experience will in my opinion return back to the web as a medium, substantially enlarging the potential user base and reducing the importance of a single OS to develop for.

User Interfaces: this is, actually, one of the easiest things. HTML5, CSS3, Canvas, and a whole bunch of additions (like WebGL) are already closing in on the most refined native UI toolkits. There is still a margin – of course – but that gap is closing fast. Modern toolkits like Cappuccino (one of my favorites, used to create the stunning 280slides tool) are quite comparable to native UIs, and the few remaining features are being added at a frantic pace (thanks in part to the healthy competition between Mozilla and WebKit).

Video: actually, WebM is in my tests a very good alternative to H264, in terms of quality and in decoding efficiency (in my tests, WebM playback uses 20 to 30% less CPU than the ffmpeg H264 decoder, which is quite a good result). As for quality, the results of MSU graphics and media lab codec comparison found out that WebM is approximately equivalent to the baseline x264 encoding; that is, good enough for most applications. The substantial drawback of WebM is at the moment the dreadful encoding time – 5 to 20 times slower than comparable, more mature encoders. Substantial effort is needed before WebM can become encoding-wise competitive.

2D and casual gaming: ah, the hard point of gaming on the web. Up to now, gaming has been mainly relegated to the Flash engine, and is one of the parts still not replicated well by HTML5, Javascript et al; in fact, Flash is quite important for the casual gaming experience, and some quite stunning games are based on flash, and comparable to native games (if you want to waste some time, look at RoboKill2 as an example).However, given the fact that no fully compatible open source flash player exist, there are still issues with the real portability and platform independence of flash gaming in general (despite the excellent improvements in Gnash and LightSpark; also, it may even be possible to see in the future a native translator to Javascript like the SmokeScreen project. Actually, there is a great deal of overlap of Flash with recent evolutions of Canvas/HTML5/Javascript – it is clear that the overall evolution of the open web platform is going in the direction of integrating most of flash functionalities directly within HTML.

3D gaming: There is at the moment no way to create something like the Epic Citadel demo, or Carmack’s RAGE engine on iOS. The only potential alternative is WebGL, that is (like the previous links) based on OpenGL 2.0 ES, and paints on the HTML5 canvas (that, in the presence of proper support for hardware compositing, should allow for complex interfaces and effects). The problem is that browser support is still immature – most browsers are still experimenting in an accelerated compositing pipeline right now, and there are still lots of problems that need to be solved before the platform can be considered stable. However, after the basic infrastructure is done, there is no reason for not seeing things like the current state of the art demos on the web; modern  in-browser Javascript JIT are good enough for action and scripting, web workers and web sockets are stable enough to create complex, asynchronous event models. It will take an additional year, probably, until the 3D support is good enough to see something like WoW inside a browser.

Local binary execution: for those things that actually cannot be done by a browser, local execution is the only alternative. For example, having a complex VPN client embedded in a web page is something that would simplify the task of connecting to a web (or non-web) in an easy way without downloading any additional package. This model was demonstrated by Google in its ChromeOS presentation, showing off a game based on the Unity web player, ported to the Native Client (NaCl) environment. The problem of the initial implementation of NaCl was that the binary was actually not portable across cpu architectures; the new pNaCl (portable NaCl) uses the incredibly good LLVM infrastructure to generate portable bytecodes.

Payment: there is one thing that is sorely missing or incomplete, and that is billing and payment management from the web application. Within iOS, and thanks to iTunes and carrier interactions, paying even in-game or in-app is easy and immediate. There is no similar ease of use and instant monetization within web applications, at the moment. One of the missing things is actually the overall management of digital identities, that is inextricably linked to the payment possibilities and channels.

DRM: yes, DRM. Or content protection, or whatever. Despite the clear indication that DRM schemes do not work, there is no shortage of studios or content producer that want to ensure that there is at least a minimum form of “protection” against unwanted use. I don’t believe that this form of protection is useful at all, but I am not confident in people accepting this in the next 5 years – and this means that DRM should be possible in the context of the browser. Possible alternatives are the use of a ported content execution engine (imagine a video player based on pNaCl, that brings its own DRM engine inside). Or integrating an open source DRM engine like DReaM (if it survives the Oracle changeover, that is). This kind of tool can also help to prevent cheating in online games (imagine a WoW like game, based on Javascript: what prevents the user to change the code on the fly with something like GreaseMonkey?) and other multiplayer environments.

App stores: what is an app store?  A tool to reduce searching costs, and in Apple iTunes model a framework for app management and backup. In a sense, something like this is possible right now with some browser/OS integration (the excellent Jolicloud has something like that right now, and with some additional support for web packaging formats and remote synchronization like Mozilla Sync this can become ubiquitous).

What do you think? Is there something else missing? Comments are, as usual, welcome…

Updated: despite the Business Insider claims, the list of motives is actually a perfect copy of those mentioned by Steve Ballmer in a CNN interview, and I also found that the list of motives for the claimed inferiority of Android is actually from 2008, as can be found here. I found quite funny that basically the same motivations apply two years later for a different OS (in 2008 it was Windows Mobile 6.5, a totally different operating system), and are quite similar to the list of motivations from MS to avoid open source – namely, inferior user experience, hidden costs and IPR risks. Maybe Microsoft has not changed so much as it would like to claim.

A recent Business Insider post provided, other than a nice retouched photo of Google’s Schmidt with menacing red eyes, a snippet of conversation with an anonymous MS employee that claimed that Android “free” OS is not free at all, and its costs are much higher than the $15 asked by Microsoft as licensing fees. Having had my stint on mobile economics, I would like to contribute some of my thoughts on what is actually implied by the MS employee, and why I believe that some parts of it are not accurate. Before flaming me as a Google fanboy, I would like to point out that I am not affiliated with Google, MS, anyone else (apart my own company, of course), and my cellphone is a Nokia. Enough said.

OEMs are not using the stock Android build. All Android OEMs are bearing costs beyond “free.” That goes with the definition of OEM – it is hardly a surprising idea. My gripe with the phrase is that the author had, conveniently, conflated the concept of “free” as “freely available operating system” with “free as in I have nothing to do, everything is done for me for free”. The second concept is actually quite uncommon, and I had never met an OEM product manager that believed in something like that. It reminds me a lot of the old taglines used in the infamous MS “comparisons”, that were – with blessings from all – sacked from Microsoft web site. So, in conclusion: yes, you will bear costs other than downloading Android from GIT. And – surprise – I am sure MS will ask for engineering costs for adapting WinPhone7 for any adaptation outside the stock image.

Lawsuits over disputed Android IP have been costly for Android OEMs. (See Apple/HTC, as just one example.) Microsoft indemnifies OEMs who license Windows Phone 7 against IP issues with the product. That is, legal disputes over the IP in Windows Phone 7 directed at OEMs will be handled by Microsoft. This goes a long way toward controlling legal costs at the OEM level. Ah, please, Microsoft – you are so friend of OSS, and you still drum the “IPR violation” song? Anyway, I am quite sure that indemnification can be quite easily acquired, probably from Google or from a third party. It depends on the kind of IPR that the OEM itself does have; in some cases such a patent safety scheme is uneconomical. It is, in any case, a business decision – Symbian did not had indemnification either (or only as an additional product) but that did not stopped Symbian from becoming the most widely used mobile OS.

Android’s laissez faire hardware landscape is a fragmented mess for device drivers. (For background, just like PCs, mobile devices need drivers for their various components—screen, GPS, WiFi, Bluetooth, 3G radio, accelerometer, etc.) Android OEMs have to put engineering resources into developing these drivers to get their devices working. The Windows Phone 7 “chassis strategy” allows devices to be created faster, saving significant engineering cost. It’s essentially plug and play, with device drivers authored by Microsoft. This (apart from the use of the clearly pejorative mention of “fragmented mess” is naturally true. It is also – another surprise – the reason of Windows success, namely the external ecosystem of hardware devices, mostly unpredictable, that were basically developed and managed outside of Microsoft control. After much bashing of Apple’s “walled garden”, now Microsoft seem to imply that the same model that brought them success is now useless, and that to win in mobile you have to adopt Apple centrally managed hardware experience. It may be true, or not – but I suspect that hardware manufacturers will be more happy to create many permutation and device models, designed for different price points and different users, in a way that would be incompatible with MS central control and central device driver development. What happens if I need to push on the market a device that deviates from the MS chassis? Will MS write the driver for me, for free? What if it doesn’t want to write it? The chassis model is nice if you are Apple, and are selling basically a single (or a few) models; if you are going to market with many hardware vendors, you are forcing the same, undifferentiated hardware on all OEM – and this is a great no-no. How are you going to go against competitors that do employ exactly the same model, bill of material, same procurement channel?

Also, this phrase is a clear indication that someone inside of MS still don’t understand what (real) open source is about. The amount of engineering necessary for creating a complex product out of OSS is substantially lower than proprietary alternatives, as I demonstrated here and here; the driver development effort can easily be shared among many different projects that use the same component, lowering the development costs substantially.

Windows Phone 7 has a software update architecture designed to make it easy for OEMs to plug-in their custom code, independent of the OS code. We’ve seen the delays due to Android OEMs having to sink engineering resources into each and every Android update. Some Android OEMs skip updates or stop updating their less popular devices. Because of the unique update architecture, Windows Phone 7 OEMs don’t need to roll their own updates based on the stock build. Costs are reduced significantly. This is another part that is, until Phone 7 is out, difficult to judge. It is a part that I believe stems from an underlying error: OEMs add code to differentiate and to push branded apps and services, not because they have to compensate for an OS missing functionality (especially now, with Android 2.2; Android 1.5 and 1.6 needed some addition from third parties because of lack of features). Carriers, once sold a device, are not that interested in providing updates – after all, you are already locked in a contract. I had seen no official documentation on why Phone7 can be so modular that no engineering is needed even for custom layers on top of the user interface – we will see.

Android OEMs need to pay for licenses for many must-have features that are standard in Windows Phone 7. For example, software to edit Office documents, audio/video codecs (see some costs here), or improved location services (for this, Moto licenses from Skyhook, just as Apple once did). Of course, all of these license fees add up. I like the concept of “must have” – it is widely different for every user and company. For example, I am sure that using Google Docs or Zoho (or Microsoft Web office, that is quite good on its own) would go against the “edit Office documents” part; as for the audio/video codecs, of course you have to license them… unless you use WebM or similar. Or, like many OEM, you are already a licensee for H264 and other covered standards-  in this case, you pay around 1$ per device. As for other services: I found no mention of location services from MS, at least not in the public presentations. If anyone has more details on them, I would welcome any addition.

Windows Phone 7 supports automated testing. Android doesn’t. When OEMs hit the QA phase of the development lifecycle, it’s faster and less expensive to QA a Windows Phone 7 device than an Android device. Again: if you have a single chassis, or a few of them, testing is certainly easier. However, there are quite a few testing suites that allow (through the emulator) to provide a very good automated testing facility.

Finally, Windows Phone 7 comes with great user experiences in the Metro UI, Zune, Xbox LIVE, Exchange, and Visual Studio for app development. Creating these experiences for Android is costly. They’re not baked into the stock build of Android. Well, there are quite a few tools for app development on Android as well. How, exactly, Exchange should be counted as a great user experience is something I am not understanding well, but that is probably a limit of mine.

In synthesis, the new MS concept is “we do it like Apple”. I am not sure that this can work for anyone that is not Apple, though; first of all, because up to now product engineering excellence was not among MS most touted virtues, and because this will in turn go against the differentiation trend that OEM and telcos are pushing to make sure that their brand lines remain unique and appealing enough. How many Phone7 devices can a telco carry? 1? 2? It is possible to imagine a custom Android device for every price point instead – some carriers like Motorola and HTC are already pushing 5,6 devices and more, and low cost handsets are adding even more to the segmentation mix.

A very interesting blog post was published on the 100% Open website about 7 tactics and incentives for open innovation. It struck me how well these all apply to open source software projects. So I’ll discuss all 7 of them from the perspective of open source, but make sure you’ll also read the original post for the original, more generally applicable view on these tactics and incentives.

1. Share both Risks and Rewards

When participating in an open source project you are largely in the same boat as all the other contributors to the project, therefore sharing the risks among each other. If a release is delayed or major bugs are introduced in the software, everybody suffers. However, some open source licences allow you to add your own private rewards by building your own customization of the software without contributing it back to the project. It is a bad idea to do so because when you let your code deviate from the project’s code you always end up with more complex migration paths which makes it harder to keep profiting from the efforts of the community.

2. Tap into Intrinsic Incentives

Intrinsic incentives are extremely important for open source software projects. There is still a widespread misconception that open source software is being developed by hobbyists where there is no money involved. This is not the case, because a large majority of the code in open source software projects is being developed by people who are paid by their employers to do so. This is also true in the educational sector in the UK, where software projects are being fund by the likes of JISC and the research councils. Nevertheless, for any sustainable open source community intrinsic incentives are very important. For example in the Apache Software Foundation, when a contributor becomes a committer to an ASF project they personally become one and never as an employee of some company X. Being part of a community that builds cool software is just great and having a culture within the project that feeds into that is therefore extremely important. A nice illustration of this Dan Plink’s TED talk on motivation. He shows in a very powerful way that highly skilled people are not mainly motivated by money, but by being challenged and by the opportunity to develop a mastery.

3. Don’t Expect Something for Nothing

For an open source software project to be truely sustainable, external contributions and engagement from new participants are extremely important. Usually, a public mailing list or forum is the first entry point for potential contributors. Although it is likely that people first ask questions on these lists rather than answering them, in a healthy project all participants help out each other. This makes the project scalable and is one of the reasons why it does not necessarily takes a lot of time to open up a software projects to the outside: if you manage to engage new people they will help out others and that way a truly sustainable community can develop.

4. Ask Engaging Questions

People or companies that are involved in open source projects never have completely overlapping problems and therefore it is not always clear which solution is the most appropriate for all of them. Moreover, if you encounter a project that provides a lot of the functionality you need but not all of it, there are very effective mechanisms to discuss the features of the project. Mailing lists and forums are used widely to engage in discussion and find ways of merging features different people need. Of course, if you require a specific piece of functionality, it is up to you to build it and contribute it to the project. But discussing the requirements and problems of different people can lead to interesting insights that can be valuable to the whole project. Due to the distributed nature of open source software projects people with very different backgrounds will bring their own viewpoints, which can lead to more creative solutions and spark new ideas.

5. Build Business Empathy

Open source projects can thrive or be damaged by reputation just like businesses. The plea in the original post for an honest and human approach is very well applicable to open source projects. But in many cases it comes more natural to open source projects to have that approach because, as mentioned earlier, there is already a focus on individual contributions incorporated in the dna of many projects. For new projects or projects that are working towards sustainability it is important to define processes that support this approach and to fix it in a governance model document, so it is clear to everybody what they can expect from the project, thereby providing a more level playing field.

6. Target Quantity before Quality

This tactic is well-known in software where it is more commonly known as the ‘Release early, release often’ mantra. If you are active in a young open source software project that is still in its infancy, getting a release out is a very effective way of engaging new contributors and is therefore a huge opportunity to let your project grow to become sustainable. Releasing early makes the barrier to entry lower for new users, albeit that the first few releases will be of lower quality and contain less features. As long as this is clearly communicated to the (prospective) this need not be a problem but can help the project as a whole move forward more quickly.

7. Find Your Top 1%

In the original post the 100% open team explains that out of 100 users, there are usually only 10 who are really engaged and just 1 who will provide a substantial contribution. Although the percentages may vary, also in open source software projects it is very important to identify the users of today that are most likely to become the contributors of tomorrow. It is essential for any open source project to engage those users and try to have them contribute to the project and perhaps even become a committer to help achieving sustainability in the long run.

OSS Watch community development manager Gabriel Hanganu published an excellent briefing note recently, in which he explains how the sustainability lessons can be appied to research infrastructure. Gabriel’s analyis shows that a lot of the tactics and incentives for open innovation are also important in that space.

During the last three weeks I’ve been diving into cvsanaly to refresh my python skills. My first contributions have been a couple of easy fixes but now I’m finishing the integration of the ohcount tool which detects the license used in source code files ( see my previous entries about ohcount ).

This afternoon with 35ºC outside I’m very close to the air conditioning while testing and cleaning up the code before submitting the patch to my colleague carlosgc. With this new extension we get a table which relates files, revisions and licenses. See the picture below.

Ohcount is a very interesting tool, we even realized we had incorrect headers in 31 source files of cvsanaly. The new extension allow us to detect these changes. For instance the image below reflects the different licenses over time on one of the cvsanaly files, as you can see the file had two licenses (gpl and lpgl) before revision 609. That happened due to a incorrect header which mixed gpl and lgpl text together.

So, our plan is to integrate ohcount to study the licenses used in the fresh code and start studying if there are significant facts over time. I hope the code will be committed to git://git.libresoft.es/git/cvsanaly by the end of next week, in any case drop me a mail if you are interested on it and I’ll let you know.

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.

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.

In Norse mythology it’s predicted that the final days of the world will see a supernatural wolf called Sköll swallow the sun before helping to kill Odin, the mightiest of the Gods. In a move that will surprise no ancient Vikings, Oracle – the gigantic database corporation that up swallowed Sun Microsystems – has made a wide-ranging patent and copyright infringement complaint (pdf) against the mighty Google Inc. that may or may not indicate that the world will soon end.

The complaint concerns the use of Java-related technologies in Google’s Android mobile Linux platform, and the details are ugly indeed. Ever since Sun released Java back in 1995, they (and now new owners of the Java IP Oracle) have been looking for ways to make some money off it. Java was intended to provide a solution to the problem of platform fragmentation – the unfortunate situation that means software developers have to write many differing versions of their code to cater for all the different varieties of computing environment out there (Macs, Windows, Unix etc). Sun’s Java provided a layer of virtualisation, so that in theory you could write your Java code once and have it run anywhere, confident that the virtualisation layer (or ‘virtual machine’) on each system would handle the complexities of translating your program for use on the local hardware.

It didn’t help that the technology grew in ways that Sun had not really predicted – seeing far more adoption on the server than in the client area at which it was initially targeted. When mobile phones and set top boxes began to become more powerful and able to run consumer software, Sun launched a ‘Micro Edition’ (ME) of Java that was intended to coalesce this massively fragmented market. This ought to have given Sun a strong, commercialisable position as gatekeeper between software developers and a wide spectrum of hardware platforms, but in the event the technology was not equal to the vision and developers still needed to tweak Java ME software to run efficiently on each platform, causing much woe and despondency. Nevertheless, the mobile market remained Sun’s core focus in the struggle to wring money out of Java. At the same time, Sun was positioning itself as an open source-friendly company, and was therefore receiving quite a lot of pressure from the open source community to put its money where its mouth was and release Java under an open source licence. In 2006, when Sun finally did release Java as free software, the strategy to monetise mobile was still very clear in their licensing choices.

The standard edition of Java – designed to run on desktop computers and servers – was released under the GNU GPL with the so-called ‘Classpath Exception’. This was a licence created by the Free Software Foundation’s GNU project to cover their own free software implementation of the core Java-compatible class libraries (essentially toolkits of functionality for building complex applications). The exception meant that you could use the GPL-licensed libraries to build your applications without having the copyleft requirements of the GPL transmit to your own code. However for the ‘Micro’ edition of Java, Sun used a dual licensing model, leaving out the exception from the GPL version and selling commercial licences for device manufacturers and developers who wanted to write mobile software which was not compelled to be GPL.

Thus, when Google decided it wished to use Java as the development language for software on their eagerly anticipated mobile Linux platform Android, one could argue that it should – finally – have been a huge payday for Sun. However it was not to be. For whatever reason, Google did not want to go down the road of licensing and mandating the use of Java ME. Instead, they took an open source implementation of Java called Apache Harmony and made some variations to it of their own. First they created their own virtual machine called Dalvik, which ran a different kind of code to a standard Java virtual machine (a tool in the Android development kit converts standard Java ‘byte-code’ to the new Android format). They also added many new libraries to support more modern functionality such as Bluetooth and the 3D graphical acceleration technology OpenGL. Everyone – except Sun – was happy. Developers did not need to buy commercial Java ME licences from Sun but could still use the Java skills they had developed over the last decade. Google did not have to rely on another company to mediate their relationship with developers and handset manufacturers. Sun had lost out again. Perhaps their previous highly-publicised love affair with open source meant that they could not easily start suing a competitor over a piece of open source software? Finally in early 2010 a financially embarrassed Sun was acquired by Oracle.

Oracle itself has some open source credentials – they run a proprietary/open dual licensing model for the product Berkeley DB. However the majority of their business is unashamedly closed source and therefore ever since they acquired the Java IP with Sun there has been much speculation that they would come after Google over Android and Dalvik. The complaint that has finally emerged is a wrathful document indeed, accusing Google of wilfully infringing on Sun/Oracle’s patents and copyright and seeking the seizure of all infringing devices, code and even advertising materials. Due to what they see as the egregious cheekiness of the infringement, Oracle want punitive triple damages.

What makes this case interesting – apart from the enormity of the two combatants – is the range of the counts. Along with seven fairly generic technology patents dealing with program compilation and execution, Oracle are also alleging copyright infringement. This would normally imply – in the case of software – that Oracle believes that Google (and quite possibly Apache Harmony) have incorporated verbatim sections of their code in their own products. Here, though, it’s hard to see how that could be the case. As an open source project Harmony’s source has been available for the world to see for many years, and one might have expected any literal code inclusion to have been noticed and acted upon a long time ago. As for the parts added by Google, it seems extremely unlikely that a company with Google’s resources would risk any kind of ‘code contamination’. Dalvik has been widely reported to have used ‘clean room’ reimplementation in its creation – meaning that no-one with any experience of (in this case) Java’s internals would be allowed to contribute any code to the project. The only point of connection between the original and the new code in a clean room reimplementation is the specification – the detailed but high-level description of how the software should operate. Could Oracle be suing over the use of the specification?

Oracle’s complaint says this:

38. The Java platform contains a substantial amount of original material (including
without limitation code, specifications, documentation and other materials) that is copyrightable
subject matter under the Copyright Act, 17 U.S.C. § 101 et seq.

39. 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.

…so specifications are explicitly listed as a variety of copyright work Oracle considers itself to hold in Java. This is of course true – specifications are copyright works as they are original and complex. The documents themselves are clearly ownable and their owners rightly get peeved if people copy and distribute them without permission. Here’s another quote from the Java Specification Participation Agreement – the agreement which allows third parties to get involved with defining and implementing new parts of Java:

For any Specification produced under a new JSR, the Spec Lead for such JSR shall offer to grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license under its licensable copyrights in and patent claims covering the Specification (including rights licensed to the Spec Lead pursuant to Section 4.A and 4.C) to anyone who wishes to create and/or distribute an Independent Implementation of the Spec.

(JSRs are Java Specification Requests – basically descriptions of new features). Taking the language of the complaint along with the language of the participation agreement, it seems quite possible that Oracle are going to argue that any implementation of their specification is a derivative work of that specification and therefore needs a licence from them. This kind of copyright action – essentially claiming a high-level copyright in the design of the technology – is controversial and difficult to win. The more abstract the entity for which you are trying to claim copyright ownership, the harder it is to show indisputable infringement. Verbatim code copying is fairly easy to spot and demonstrate; the duplication of structures and interfaces is harder to demonstrate and is always open to arguments that there is no substantial relationship between the design and the implementation.

Of course, it may be that Oracle does have evidence of more concrete low-level copyright infringement, despite my personal instinct that that is unlikely. However if they will be arguing on the difficult basis of ’specification infringement’ I have to wonder why. Is it a plan to bolster a set of patents they are unsure about? Somewhat selfishly part of me hopes that the case will play out publicly and not be settled behind closed doors, if only to clarify this controversial area of copyright.

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 http://www.openworldforum.org

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 OpenOffice.org
• 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.

Damien Katz, whose Apache CouchDB recently hit 1.0, provides some excellent tips on creating a successful open source project in his blog Getting your open source project to 1.0. Drawn from five years’ experience, the tips include general advice interwoven with examples from the project. He begins with the fundamental question, Why?, explaining that a successful project needs a reason for being – a clear idea of what problem it solves – and you need to figure this out and explain it.

Almost as important as knowing what you are is knowing what you’re not: ‘Stating clearly what your project isn’t trying to do or be helps make it much easier to explain what you can’t implement or change …. and to focus on what you actually are.’ Next, he advises, ‘don’t expect to attract anyone to your project until you have a substantial amount of working code that isn’t a big ball of spaghetti’. Code comes first, but don’t try to do everything (well), as you’ll probably never actually release anything: ‘You’ll need to pick a few things that you do really well and execute on those things.’

On the subject of community, Katz encourages you to ‘make sure the people who show a strong desire to contribute aren’t ignored, and feel like their efforts will eventually amount to something’. But bear in mind, he warns, that community is often incompetent. You will sometimes need to hurt people’s feelings for the sake of the project because ‘the quality of the community is more important than its absolute size’. ‘Our committers,’ he stresses, ‘are our first line of defence against poor code and design.’

In the end, though, it’s up to you to use your brain and ‘figure out what’s actually important to you, your project and its community … Projects can’t follow cookie cutter rules.’

One tip that could be added to this list is to contact OSS Watch. We can help you create a successful open source project by providing advice every step of the way. In addition, our briefing documents offer invaluable information on everything a new project needs to consider, including governance models, sustainability, how to build an open source community and licensing.

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.

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:

• Protection domains to provide security in a computer system
• Controlling access to a resource
• Method and apparatus for pre-processing and packaging class files
• System and method for dynamic preloading of classes through memory space cloning of a master runtime system process
• Method and apparatus for resolving data references in generated code
• Interpreting functions utilizing a hybrid of virtual and native machine
• Method and system for performing static initialization

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.

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.

Practical Guide to using Free Software in the Public Sector has been published recently in the OSOR web site. This guide is under Creative Commons "Attribution + ShareAlike" licence and has been authored by Patrice-Emmanuel Schmitz.

This guide explains some basics about software to help non technical people to understand the importance of the code which makes our machines work everyday. Moreover, after these basics definitions the document goes through what is free software and another important questions like what is proprietary software and licences matters, even some not so trivial cases like compatibility between licences and software components under multiple licence.

Practical Guide to using Free Software in the Public Sector has been published recently in the OSOR web site. This guide is under Creative Commons "Attribution + ShareAlike" licence and has been authored by Patrice-Emmanuel Schmitz.

This guide explains some basics about software to help non technical people to understand the importance of the code which makes our machines work everyday. Moreover, after these basics definitions the document goes through what is free software and another important questions like what is proprietary software and licences matters, even some not so trivial cases like compatibility between licences and software components under multiple licence.

During the past 15th and 16th of June at Barcelona was celebrated the W3C Workshop: “Augmented Reality on the Web”.

“This W3C Workshop was held to discuss whether and how the exciting opportunities offered by Augmented Reality can benefit from Web technologies. Augmented Reality on the Web was hosted in Barcelona by Escola Tècnica Superior d'Enginyeria de Telecommunicació de Barcelona (ETSETB) at Universitat Politècnica de Catalunya (UPC). It attracted over 40 attendees and 22 papers. The participants represented a broad range of businesses including telecom operators, device manufacturers, AR content and platform developers, AR users from the advertising world, academics and standards bodies.”

GSyC/LibreSoft was invited to participate in the event thanks to their experience with LibreGeoSocial regarding social networks and augmented reality. During the event, GSyC/LibreSoft exposed the paper: “Mobile Augmented Reality browsers should allow labeling objects”, and a presentation about the needs of allowing users to tag the reality with augmented reality technologies. Also, a live demonstration of LibreGeoSocial was made, about the capabilities of tagging the real world.

The experience was very interesting because it was a workshop organized by the W3C. It was focused in the importance of using standards for augmented reality, a good opportunity to point to FLOSS solutions to achieve this goals.  

Material: [Paper] [Slides]

A falta de análisis más profundos (escribo esto unos minutos después de terminar la "conf call"), son sin duda grandes noticias para el software libre en general y para la comunidad de OpenSolaris en particular. 

Illumos no es un fork (como muchos especularon) pero tampoco una distro (como yo mismo apostaba en el post anterior). Es una "derivación del código" de OS/Net (conocido como ON), es decir, una "rama" creada a partir de la "consolidación" principal del código fuente de OpenSolaris (ON incluye el código fuente del kernel, los servicios de red, las librerías del sistema y los comandos básicos del sistema operativo). Será totalmente compatible a nivel binario (ABI) con OpenSolaris (también lo será a nivel legal) y pretende ser una código-base 100%  software libre para futuras distribuciones basadas en Illumos.

 La primera tarea de Illumos será la de reemplazar por fin las partes privativas que quedan en OpenSolaris (algunos drivers críticos, partes de libc como libc_i18n, NFS/CIFS lock manager, etc.). El objetivo no es competir con "Solaris", ni con Oracle (a la que se le ha ofrecido participar en pie  de igualdad, como un "partner" más), sino crear una "base" neutral (también neutral en cuanto al empaquetado) a partir de la cual sea fácil construir distribuciones totalmente libres e independientes de empresa alguna (y por tanto sin peligro de que nadie externo eche el cierre).

El proyecto se mantendrá lo más cercano posible a la consolidación ON de Oracle. No hay pues intención alguna de crear un fork mientras el repositorio de código de Oracle siga recibiendo aportaciones, y sigan siendo abiertas, como es el caso (OpenSolaris no ha estado ni mucho menos "parado" estos meses, como muchos creen). Por ello se exigirá que las contribuciones a Illumos sean siempre bajo licencias BSD, MIT o CDDL (con la firma del Sun Contributor Agreement) con el fin de garantizar que cualquier contribución de código a Illumos pueda incorporarse legalmente al "upstream". Lo que sí habrá son proyectos experimentales (como distros y otros), que no necesariamente interesen a "upstream".

Illumos no es un fork, pero se ha dejado claro que, en caso necesario, podría llegar a serlo. Lo que hace Illumos es garantizar la independencia del proyecto frente a los vaivenes de cualquier empresa (sea Oracle o Nexenta), y poner en manos de la comunidad el control del proyecto. Nexenta será un sponsor, como otras empresas con las que se mantendrán relaciones de cooperación, pero que no tendrán el control, sino que se establecerán mecanismos de autogobierno de la comunidad Illumos (temporalmente liderada por Garrett).

Respecto a qué plataformas soportará, Garrett ha dicho que inicialmente x86/amd64, pero más adelante está previsto soportar Sparc, como no podía ser menos.

En una primera valoración personal, mi opinión de Illumos es muy positiva ya que creo que se ha elegido el camino adecuado: un fork habría sido suicida y una simple distro habría mantenido la dependencia de "upstream" (Oracle). Empezar por "limpiar" OpenSolaris del código privativo que queda y dotar a la comunidad de independencia operativa es el mejor inicio posible: una apuesta pragmática y realista, una base adecuada para labrar un futuro brillante y libre para OpenSolaris.  Ahora todo depende de los usuarios, de los administradores y de los desarrolladores (también desde luego de empresas que quieran involucrarse en pie de igualdad): se acabó el gastar energías echándole la culpa a Oracle o a las malvadas corporaciones. O a las partes cerradas. ¡Ya no hay excusas para no implicarse en uno de los proyectos técnicamente más atractivos del software libre!

• FAQ del Proyecto Illumos

• Transparencias de la presentación oficial
• Listas de correo
  

Scott Wilson from CETIS, University of Bolton showed in a very compelling way at TransferSummit/UK 2010 how it can be strategically important to sustain your publicly funded software project beyond its initial funding period. The figures in Scott’s slides say it all: by investing a tiny survival budget to sustain their Wookie project after the funding would run out they managed to secure about £700k of new funding from two European (FP7) projects.

How they achieved this? Their overall project, although being a bit specific, implemented the emerging W3C widget standard which is relevant to a wider community. They managed to attract some interest from outside the initial project group. OSS Watch helped them with community development and identifying potential sources of value and funding. A good home for the project was found at the Incubator of the Apache Software Foundation, thereby attracting much more interest and contributions from parties inside and outside the academic sector.

Currently, Apache Wookie (Incubating) is a thriving project and has seen many bugfixes and new features contributed by the community. It resulted in a lot of visibility for the University of Bolton outside the regular channels, leading to new partnerships with the commercial sector and universities inside and outside of the UK. Last but not least they managed to secure a lot of new project funding from European sources.

Sustaining your software project beyond funding is not just morally right or something that should be done so your money is not spent wastefully. Scott’s example shows that it is very much in the interest of the institutions and the project team to sustain the project. So think about how your software development project can be sustained after the funding has run out or which part of it is most potential to generate a viable community. And get in touch with OSS Watch; we are here to help.

Meses de preguntas sin respuesta sobre por qué han cesado las actualizaciones de la versión binaria de OpenSolaris, o sobre si la desaparición de Sun le condenaba a desaparecer pese a su excelencia técnica y a su pequeña pero activa comunidad, o sobre el motivo de la extraña política comunicativa de Oracle, depositaria de una herencia que no parece apreciar, y que ha venido ignorando por completo a los órganos representativos de la comunidad y al propio proyecto OpenSolaris.

Oracle, que sigue sin dar señales de vida ni responde al emplazamiento del "board" de OpenSolaris, ha dilapidado en muy poco tiempo el trabajo y la reputación que Sun había atesorado durante años en el mundo del software libre, y que la habían convertido en la empresa que más líneas de código aportaba al software libre. Todo eso ha alimentado el FUD de forma despiadada contra el proyecto OpenSolaris y, por qué no decirlo, ha hecho cundir el desánimo y en algunos casos la deseperación entre la propia comunidad, convertida en un mal remedo de Esperando a Godot.

Ante panorama tan desolador, agravado por el abandono de algunos de los mejores hackers de Sun, ayer mismo y cuando muchos lo daban por muerto, se ha anunciado un nuevo proyecto llamado Illumos, que parece que puede romper el impasse y cambiar la dinámica depresiva en la que estábamos inmersos sus usuarios. Anil Gulecha, Garrett D'Amore y Sergey Generalov, miembros destacados de la comunidad OpenSolaris y actualmente en Nexenta, han convocado una presentación pública del nuevo proyecto Illumos el 3 de agosto a la 1PM EDT, invitando a unirse a toda la comunidad OpenSolaris.

Es un momento de mucha expectación, al menos para los "solariegos", que estaremos ilusionados y expectantes a ver qué se proponen. Apenas se conocen detalles, no sabemos lo que nos contarán el día 3, ni el papel que tendrá Nexenta, pero parece que se prepara una distribución independiente, orientada a la comunidad y totalmente software libre, que cubra el hueco dejado por Indiana (la distro binaria oficial de Sun de OpenSolaris).  Pronto saldremos de dudas. :-)

It is always strange to see the savage infighting that sometimes happens in the free and open source world – sometimes, like red in front of a bull, the net suddenly lights their flame-throwers and decides to roast someone. Today’s target is Canonical, makers of the Ubuntu distribution, accused of being leeches and “stealing” from the open source communities, giving little or nothing back, and profiting from that. The issue emerged from the publication of the Gnome census, where it emerged that Canonical As Sam Varghese writes, “Canonical derives the base for Ubuntu from the Debian project. It takes liberally from many free and open source software projects to produce a distribution.  While this distribution is available for free download, Canonical is also basing a business on it, and developing ways and means of making money off Ubuntu.” (which is, probably, a crime). He wrote something similar before, and  Greg DeKoenigsberg has an even more vitriolic argument in his post “Red Hat, 16%. Canonical, 1%”, that happily buries under the ground Canonical, Ubuntu and most Ubuntu fanboys.

Well, you’re all wrong.

Not because the percentages are wrong (but nearly useless, as Canonical is relatively recent and RedHat is not, because Gnome is only one of the projects and there are many others, etc.) but because they measure too little. I already wrote in the past about the enormous effort that goes to non-code contributions, and that no-one measures (as for OpenOffice, there are more contributors in non-code parts than in code); there is also a substantial effort in creating a product out of contributions. And Ubuntu certainly invested in product engineering, marketing, even engineering (less than Red Hat? So what? Large IT consulting companies are getting paid millions for open source-based systems, and I never saw a contribution at all). When Matt Asay claims that bringing Ubuntu to million of people is a contribution, he is claiming an absolute truth; every time Canonical manages to bring a press release out it is making a huge contribution. Maybe less code than others, but this is not a beauty contest – this is a cooperative effort for building a better future, not a race to see who is the nicest or worked harder. It is true that Canonical (I hope) profits from OSS: well, it is one of the most important thing for OSS, as it demonstrates that OSS is sustainable, that people can live off OSS services and products, all the while improving our world. I repeat: maybe someone at Red Hat is not happy of the visibility of Canonical, given all the contributions they do? I am sorry – and I am quite happy to show at all my talks that Red Hat is an incredibly good and well-managed company, that has open sourced all the proprietary products it acquired – and invests an incredible amount of effort in engineering in the open. I like them a lot (no, I don’t work for them, and never did use one of their services), but I like Canonical as well, because they are investing heavily in the desktop market, a market that is not the focus of Red Hat any more and that I believe is quite important.

This is not a contest. We should be happy for every, small, large, strange or different contributions that we receive. Should it be more? Maybe. But don’t overlook all those things that are being done, some of them outside of pure code. Because, as I wrote in the past, there is much more than code in an OSS project.