Archive for November, 2011

Reusable widgets demonstrating the potential of open innovation

Published by Sander van der Waal on November 28, 2011 in Community. 0 Comments

OSS Watch is currently leading a small development project called Rave in Context. This project is developing templates to easily write W3C widgets that encompass best-practices in ussability and accessibility out-of-the-box. It is not feasible or useful for small projects like this one to try and develop a completely new community around the software. Instead, we looked for an existing project that would be a good home for the software and found that in Apache Wookie (Incubating). However, the project is also closely related to Apache Rave (also Incubating), because this project also supports the W3C widget standard and a few people involved with that project have shown an interest in what we’re doing.

Because of the close connection with these Apache projects and for the benefit of wider uptake of our project code, we thought it would be good to present about the Rave in Context project at ApacheCon 2011 in Vancouver. I was happy to be allocated a session in the ‘Fast Feather’ track, a track that focuses on latest developments and upcoming technologies.

The widgets that are being developed by the Rave in Context project will conform to the W3C widget standard. This allows for deployment in a W3C widget container such as Wookie. However, there are many other standards in the widgets and gadgets space. Another popular one is the OpenSocial gadget specification, which defines not only social concepts but also the packaging and specification of the gadgets themselves. Because of the big overlap between W3C widgets and OpenSocial gadgets, it has been relatively easy for the Rave project, that started of as an OpenSocial container, to also support W3C widgets. This makes the Rave in Context widget templates useful for that community as well.

During the presentation and some of the other talks and meetups at ApacheCon, it became clear that there is a lot of interest in the gadget/widget portal functionality that is being developed by the Rave project. Also the gadgets and widgets that are being developed may themselves be interesting to the wider community. We talked to a few people, for example, that have worked with portals based on the Java portlet specification, and are finding that this is not a specification that is suiting their needs anymore. They are looking to use a different technology for their front-end portals and the Rave portal is an option they’re considering. Also a project like Sakai OAE (f.k.a. Sakai 3) are working with gadgets and gadget repositories on their front-end. They are currently not working with a gadget standard, but moving to OpenSocial and using Rave as their front-end is something they are interested in.

The code of all the gadgets and widgets are currently scattered around the different projects, and this is not usually the best place for this kind of code. Hence, there is a clear need for a separate project to host the gadgets and widgets created, and this can also include the widgets created as part of the Rave in Context project. We will set one up at the Apache Extras site, which is a code hosting site specifically for Apache-related projects. This will enable anyone to reuse widgets and/or gadgets generated in any of the projects, thereby delivering on the promise of open innovation in software.

Carmack’s Reverse: a FOSS patent case study

Published by Rowan Wilson on November 18, 2011 in Business and Legal. 2 Comments

Just a quick one on the subject of open source and patents. John Carmack is well known in gaming circles as the lead programmer behind such classic PC and console games as Castle Wolfenstein, Doom (and sequels) and Quake (and most of its sequels). Carmack and his company id software are the originators of the ‘First Person Shooter’ genre of game which has in turn spawned such gigantic franchises as Call of Duty and Halo. As well as being technical pioneers, id has an interesting policy of releasing their old engine technology (the software which renders the game’s video and audio) as open source under the GNU GPL v2. This allows students of gaming software development to look at how real commercial games software is written, and also allows the games to be ported to new hardware platforms by volunteers. As the art and sound assets are not included with the code, this also generates a small market for licences to old id games – games which may well not run on more modern operating systems – in order to get the game data for use with the aforementioned ports.

Rage, the id game which uses version five of the id rendering engine (id tech 5, as it is known) has just been released. This is the point at which the source to the previous engine would usually be released as open source. However in this case there is a problem. Back when id tech 4 was being written for the game Doom 3 over the period 2000-2004, many games developers were looking into what were then cutting edge graphical technologies for inclusion in their games. One such technology was stencil shadowing, which accurately projects shadows from moving objects onto surrounding surfaces based upon the light sources which are illuminating them. This is hard work even for the specialist graphics hardware in PCs and consoles, and so any algorithmic optimisations that are possible are highly valued by the industry. So, various developers hit upon the same optimisation around the year 2000. This optimisation has come to be known as Carmack’s Reverse, even though it was first presented by William Bilodeau and Michael Songy of Creative Labs back in 1998. John Carmack discovered it independently some time later, and was perturbed to discover that Creative had already patented the process.

Faced with a choice between licensing the patent from Creative or making his code sub-optimal, Carmack decided to strike a deal with Creative that allowed him to use the technology at no cost. Perhaps coincidentally, id also agreed to use sound rendering technology by Creative in their game.

So the game was shipped and everyone was happy, until half a decade later when it came time to ship the code as open source. Obviously whatever deal was agreed between Creative and id did not involve making code available that embodied Creative’s patent under an open source licence for the whole world to use. In a tweet on the subject Carmack explained:

Lawyers are still skittish about the patent issue around “Carmack’s reverse”, so I am going to write some new code for the doom3 release.

It will be interesting to see how Carmack replaces the code, but the issue is also of interest because it illustrates the importance of keeping good records of the inbound IP in a software project. id’s lawyers caught what could have been an expensive potential infringement of Creative’s rights when they ’skittishly’ requested that Carmack rewrite the code.

So. Farewell Then Flash Player Mobile…

Published by Rowan Wilson on November 11, 2011 in Mobile technology. 0 Comments

(Apologies to E J Thribb)

Adobe’s announcement that it will be dropping Flash Player for mobile devices from its future plans has been widely interpreted as a victory for Apple, and in particular their late Chief Executive Steve Jobs. Perhaps because of his essay Thoughts on Flash, the absence of Flash technology from Apple mobile devices has seemed to be a personal decision of Jobs. In that essay Jobs made a group of points about exactly why he saw Flash as a detrimental technology, certainly for Apple mobile devices, and to some extent for Apple computers in general (“We also know first hand that Flash is the number one reason Macs crash.”) Competing phone and tablet makers pointed to their devices’ ability to run Flash, although not always that well. Apple’s refusal to engage with Flash on mobile led Adobe to declare that Apple mobile devices could not access the ‘full web’, particularly the video content that at that time was most frequently packaged as a Flash object.

In fact, Flash became so synonymous with web video packaging that it is easy to forget that it started life (as FutureSplash Animator back in the dark days of dial-up) as primarily a vector graphics animation package. It provided the possibility of small files containing large images and enhanced interactivity (this was before Javascript was well supported or unified). Gradually Javascript and broadband made these selling points more moot, and Flash then made the leap into bundling video codecs and providing a unified way for browsers to display video. Now, partly as a result of Apple’s stand against it, native video decoding in the browser combined with HTML 5’s <video> tag have once again made Flash less relevant. Now, it could be argued, the chief use of Flash is in rapid prototyping and dissemination of simple web games, many of which go on to spawn native titles on the bigger gaming platforms. Even that function is likely to be somewhat supplanted by HTML 5 apps in the future.

So has Flash as a whole been doomed by Apple’s tactics. It’s worth looking at that Steve Jobs essay again to find out. Among the many legitimate criticisms he levels (instability, insecurity, poor efficiency) Jobs also attacked the fact that Flash provided a path to developing mobile apps (both in the browser and compiled to native code) that was out of the control of the platform owner:

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.

In other words: Apple did not want development tools for their mobile devices to exist which were not under their control. Jobs cited this as ‘the most important reason’ that he rejected Adobe’s technology. Yet only months after that essay Apple backtracked on the restriction and permitted Flash tools to compile Adobe Flash Actionscript applications for submission to the App Store. Indeed, if you don’t own a Mac, using Flash to generate iOS apps is one of the very few alternatives available to you. In fact, Flash Builder, the tool which does the actual compiling of Actionscript programs into iOS applications, is really the open source development environment Eclipse distributed with a proprietary Adobe plugin. Potentially the concession won by Adobe could lead to entirely open source tool chains for the development of iOS apps.

So while Jobs’ tauntings over the possibility of a robust and useful Flash Player Mobile (“We have routinely asked Adobe to show us Flash performing well on a mobile device, any mobile device, for a few years now. We have never seen it”) have proved prescient, in fact Adobe won a crucial concession from Apple almost a year ago. That concession widened the potential role of open source tools in developing iOS apps (it’s always been possible for Android). Adobe have also announced that they intend to ‘aggressively contribute’ to HTML5, perhaps indicating that they will be extending their development tools to allow Actionscript programs to be emitted as HTML5 web apps.

What really emerges from the struggles over mobile Flash is a strong sense of the entropy of the mobile device space at the moment. Rhetoric is deployed and attitudes struck, only for the originators to back away in a matter of months. App Store policies change monthly and with them the possibility of using open source code on the devices they serve. Competitive head-butting between closed source behemoths (like Adobe and Apple) can result in the opening up of data standards (as the pressure from iOS users has resulted in more HTML5 compliant video on the web – although let’s not get into the patents around those). For open source authors and proponents, the mobile space remains a changing and challenging environment. What the skirmishes around Flash demonstrate, though, is that the struggle of closed source vendors for competitive advantage can provide opportunities for free and open source code.