Category Archives: development

Android only 23% open says report; Linux, Eclipse win praise

Vision Mobile has published a report on what it calls the Open Governance Index. The theory is that if you want to measure the extent to which an open source project is really open, you should look at its governance, rather than focusing on the license under which code is released:

The governance model used by an open source project encapsulates all the hard questions about a project. Who decides on the project roadmap? How transparent are the decision-making processes? Can anyone follow the discussions and meetings taking place in the community? Can anyone create derivatives based on the project? What compliance requirements are there for creating derivative handsets or applications, and how are these requirements enforced? Governance determines who has influence and control over the project or platform – beyond what is legally required in the open source license.

The 45-page report is free to download, and part-funded by the European Union Seventh Framework Program. It is a good read, covering 8 open source projects, including the now-abandoned Symbian Foundation. Here is the result:

Open Governance Index (%open)
Eclipse 84%
Linux 71%
WebKit 68%
Mozilla 65%
MeeGo 61%
Symbian 58%
Qt 58%
Android 23%

The percentages are derived by analysing four aspects of each project.

  • Access covers availability of source code and transparency of decisions.
  • Development refers to the transparency of contributions and acceptance processes.
  • Derivatives covers constraints on use of the project, such as trademarks and distribution channels.
  • Community structure looks at project membership and its hierarchy.

What is wrong with Android? I am not sure how the researchers get to 23%, but it scores badly in all four categories. The report observes that the code to the latest “Honeycomb” version of Android has not been published. It also has this to say about the Open Handset Alliance:

When launched, the Open Handset Alliance served the purpose of a public industry endorsement for
Android. Today, however, the OHA serves little purpose besides a stamp of approval for OHA
members; there is no formal legal entity, no communication processes for members nor frequent
member meetings.

By contrast, Eclipse and Linux are shining lights. MeeGo and Mozilla are also praised, thought the report does mention Mozilla’s “Benevolent dictators”:

In the case of conflicts and disputes, these are judged by one of two Mozilla “benevolent dictators” – Brendan Eich for technical disputes and Mitchell Baker for non-technical disputes.

Qt comes out OK but has a lower score because of Nokia’s control over decision making, though it sounds like this was written before Nokia’s Windows Mobile revolution.

WebKit scores well though the report notes that most developers work for Apple or Google and that there is:

Little transparency regarding how decisions are made, and no public information provided on this

Bearing that in mind, it seems odd to me that WebKit comes above Mozilla, but I doubt the percentages should be taken too seriously.

It is good to see a report that looks carefully at what it really means to be open, and the focus on governance makes sense.

Microsoft releases Visual Studio LightSwitch: a fascinating product with an uncertain future

Microsoft has released Visual Studio LightSwitch, a rapid application builder for data-centric applications.

image

LightSwitch builds Silverlight applications, which may seem strange bearing in mind that the future of Silverlight has been hotly debated since its lack of emphasis at the 2010 Professional Developers Conference. The explanation is either that Silverlight – or some close variant of Silverlight – has a more important future role than has yet been revealed; or that the developer division invented LightSwitch before Microsoft’s strategy shifted.

Either way, note that LightSwitch is a model-driven tool that is inherently well-suited to modification for different output types. If LightSwitch survives to version two, it would not surprise me to see other application targets appear. HTML 5 would make sense, as would Windows Phone.

So LightSwitch generates Silverlight applications, but they do not run on Windows Phone 7 which has Silverlight as its development platform? That is correct, and yes it does seem odd. I will give you the official line on this, which is that LightSwitch is not aimed primarily at developers, but is for business users who run Windows and who want a quick and easy way to build database applications. They will not care or even, supposedly, realise that they are building Silverlight apps.

I do not believe this is the whole story. It seems to me that either LightSwitch is a historical accident that will soon be quietly forgotten; or it is version one of a strategic product that will build multi-tier database applications, where the server is either Azure or on-premise, and the client any Windows device from phone to PC. Silverlight is ideal for this, with its modern presentation language (XAML), its sandboxed security, and its easy deployment. This last point is critical as we move into the app store era.

LightSwitch could be strategic then, or it could be a Microsoft muddle, since the official marketing line is unconvincing. I have spent considerable time with the beta and doubt that the supposed target market will get on with it well. Developers will also have a challenge, since the documentation is, apparently deliberately, incomplete when it comes to writing code. There is no complete reference, just lots of how-to examples that might or might not cover what you wish to achieve.

Nevertheless, there are flashes of brilliance in LightSwitch and I hope, perhaps vainly, that it does not get crushed under Microsoft’s HTML 5 steamroller. I set out some of its interesting features in a post nearly a year ago.

Put aside for a moment concerns about Silverlight and about Microsoft’s marketing strategy. The truth is that Microsoft is doing innovative work with database tools, not only in LightSwitch with its model-driven development but also in the SQL Server database projects and “Juneau” tools coming up for “Denali”, SQL Server 2011, which I covered briefly elsewhere. LightSwitch deserves a close look, even it is not clear yet why you would want actually to use it.

image

Adobe closes AIR Marketplace, InMarket

Adobe is giving up its efforts to support developers deploying to multiple app stores. The idea of InMarket,  announced at the Adobe MAX Conference in October 2010, was to be a one-stop distribution point for developers seeking to target multiple platforms. Adobe handled distribution and billing. The reason given:

After reviewing our efforts and based on feedback from developers, we have decided that we will deliver the most value by helping developers author and publish their apps on multiple platforms. Given this focus, we have decided to discontinue development and support of Adobe InMarket. We are going to continue to provide support for publishing to different app stores through our tooling. The recent Flash Builder 4.5 and Flash Professional CS5.5 provide support for publishing to multiple mobile platforms including Android and Apple iOS devices.

Adobe is not giving developers much time to adjust. The InMarket URL will terminate on August 31. This is causing some consternation:

I don’t understand how you expect publishers will be able to push an update to all the markets they publish to with enough time to get their user base to update before they’re totally screwed. One month? You do realize that even updates pushed to AppUp can take up to 2-weeks for vetting? This is crazy

That said, the low traffic on the InMarket forum is a clue to what Adobe is closing it down.

InMarket only supported Intel AppUp and AIR Marketplace, which rather misses the point of targeting multiple platforms. Had Adobe been able to offer instant deployment to all the key app stores, including Android Market and Apple’s iOS App Store, it would have been more attractive. Given the complexities of the approval process, it is not surprising that this was hard to achieve. A further complication is that Adobe’s AIR runtime is not allowed on iOS. Apps for iOS have to be packaged as native iOS apps.

What about AIR Marketplace?

When we established Adobe AIR Marketplace three years ago, there were few distribution opportunities for AIR developers. There are now several app stores on desktops, mobile devices and tablets that service AIR developers including Apple App Store, Android Market, BlackBerry App World, Intel AppUp center, Samsung Apps, and Toshiba App Place. We encourage you to use these newer popular app stores to distribute your applications.

This of course describes describes exactly the problem that InMarket was meant to address: the challenge of maintaining support for multiple app stores.

AIR Marketplace is still up and running at the time of writing, and seems to have more life than InMarket:

image

That said, why would any potential customer look specifically for AIR applications? It is a runtime and ideally should be invisible to the user. I was interested to see reference to AIR packagers for Windows, Mac and Android in a recent announcement, suggesting to me that Adobe is de-emphasising AIR as a runtime and making it into something more like a cross-platform development tool.

The strategy behind Mono has shifted: ten years of open source .NET

Yesterday, SUSE and Xamarin announced, in effect, the transfer of all things Mono to Xamarin.

The agreement grants Xamarin a broad, perpetual license to all intellectual property covering Mono, MonoTouch, Mono for Android and Mono Tools for Visual Studio. Xamarin will also provide technical support to SUSE customers using Mono-based products, and assume stewardship of the Mono open source community project.

Xamarin is a startup formed by Mono founder Miguel de Icaza following the acquisition of Novell and SUSE by Attachmate, which ceased Mono development.

Attachmate acquired Novell in November 2010. Mono has been plucked from the abyss with impressive speed.

That said, the strategy behind Mono has shifted. Mono exists because de Icaza liked what Microsoft announced back in 2000 when it introduced C# and the .NET Framework. Microsoft made a show of standardizing the .NET CLI (Common Language Infrastructure), which made PR sense at the time since there was controversy over Sun’s ownership of Java, though nobody really believed that Microsoft knew how to steward an open source development platform or indeed believed that it was really serious about it. History largely justifies that scepticism; but de Icaza called Microsoft’s bluff and forged ahead with Mono, implementing not only the CLI and C# but most of the .NET Framework as well.

The goal of Mono, as I recall, was to bring the benefits of C# and .NET to Linux developers, and to enable developers to move applications freely between Windows and Linux. Apple OS X was also on the radar, though it took longer to become much use. Recalling Mono’s early days, de Icaza said:

Mono to me is a means to an end: a technology to help Linux succeed on the desktop.

Mono worked remarkably well from quite early on, but never quite well enough to persuade mainstream developers it was a sensible choice for applications that would otherwise have run on Windows. It did emerge as a viable and productive toolset and platform for Linux and a number of Mono applications became popular, including Beagle search, Tomboy notes, and F-Spot photo management. Some ASP.NET applications run on Mono; I have one on this site. Another Mono success was its use as the scripting engine in Unity, a game development platform.

A big problem for Mono though was the lack of a business model. There was support and servicing of course, which must have generated some revenue for Novell, but most Mono use is free. Novell possibly had in mind that Mono could be significant as an application server, but it has never become a really trusted platform in the Enterprise. For example, as Alan Radding (Dancing Dinosaur) notes:

DancingDinosaur has not found any SUSE on z user that has successfully implemented .NET apps on the mainframe. A few have tried but reported that Mono on z wasn’t ready for prime time.

Even among the free software and open source community, Mono was hampered by suspicion of Microsoft. If Mono became successful enough to threaten Microsoft, would lawyers appear? Given the way Microsoft is currently behaving with Android, filing legal actions and signing up licensees, those fears might not be unwarranted.

So what is Mono today? The answer is that Mono is now primarily a mobile platform. The Xamarin home page makes this clear, as well as making it apparent that the Mono team has discovered the value of a business model:

image

Xamarin is tapping into two real business needs. One is the need for a cross-platform mobile development platform that works. The second is a way for Windows developers to use their existing C# skills for mobile development, given that they might not be happy with the tiny market share currently achieved by Windows Phone 7.

When I had a quick try with Monotouch I was impressed, and I would like to spend some more time with it and with Mono for Android.

Mono has touch competition though. In particular, PhoneGap, Appcelerator’s Titanium, and Adobe AIR. I was interested to see that Adobe is coming up with a packager for AIR on Android, which may significantly improve it as a cross-platform mobile toolkit.

Still, Xamarin is small and nimble and I expect it to succeed. It has also has Visual Studio integration, which is an advantage. One of the pieces Xamarin has now licensed from SUSE is Mono for Visual Studio.

The downside of these latest developments is that if you depend on Mono for the desktop or for ASP.NET, you may find these parts of the Mono project getting little attention from the new company. But Mobile is all that matters now, right?

I write this on July 19 2011. According to Wikipedia:

Recognizing that their small team could not expect to build and support a full product, they launched the Mono open source project, on July 19, 2001 at the O’Reilly conference.

Well, if there was a launch there it was low-key. It is not mentioned in this report. But de Icaza does recall:

We planned the announcement to come by July 19th 2001, so we could announce this at the O’Reilly conference, as Tim O’Reilly had been very supportive of this effort, and had offered his help since the early stages, when it was still a very young idea. When we announced the project launch we had our team in place, and we were shipping our metadata framework and our C# compiler as well as a few initial classes So officially the Mono project was launched on that date, but it had been brewing for a very long time.

Happy Anniversary!

Embarcadero RAD Studio XE2 will have cross-platform compilation

A Google search for RAD Studio XE2, presumably the successor to RAD Studio XE which includes Delphi, Delphi Prism (for .NET), C++ Builder and RAD PHP, throws up the following page:

image

The actual links need a login for a closed beta unfortunately.

Hmm, what caught my eye is the entry for cross-platform applications. Good to see this coming soon.

Adobe releases 64-bit Flash Player 11 beta, AIR 3 with packager for Windows, Mac, Android

Adobe has released a beta version of Flash Player 11 and AIR 3. The AIR release is of limited interest since as yet there is no public SDK; Adobe mainly wants to test compatibility.  That said, the announcement describes a key new feature, the ability to package AIR applications as standalone executables on Windows, Mac and Android. You can already do this on Apple iOS, a feature that was forced on Adobe by Apple’s refusal to allow application runtimes on iOS – unless they are WebKit or FileMaker. This is new for the other platforms though, and I assume comes as a result of the popularity of the iOS packager. The effect is that you no longer have to advertise the fact that your app runs on AIR or require users to obtain the runtime; your app will just work.

Adobe may have its eye on the Mac App Store, which will disallow applications that require a runtime. Extending the AIR packager to desktop OS X should get around that limitation.

64-bit Flash Player is also a big deal, and really long overdue, though there has already been a preview codenamed Square which offered 64-bit. Although there are probably not many Flash applications that really need 64-bit, this is good for compatibility with 64-bit browsers and of course desktop applications when compiled with AIR. There could also be value in 64-bit for business intelligence clients which manipulate large datasets.

Another new feature in Flash Player 11 is Stage3D, codename Molehill, which is a new API for hardware-accelerated 3D graphics. Stage3D has its own shader language, called AGAL (Adobe Graphics Assembly Language); my heart sinks a little when I see vendors inventing new languages rather than using one that is already available, such as OpenGL Shading Language, but Adobe says AGAL is simpler and more secure. If you would like to use GL SL with Stage3D, check out the 3rd-party Mandreel framework which comples GL SL shaders to AGAL.

Flash Player 11 also has a built-in H.264/AVC software encoder for cameras, which will improve video chat and video conferencing, and adds potential for applications that stream video out as well as in.

Native JSON support will simplify and accelerate the handling of data in this popular format.

Another feature that caught my eye is socket progress events. When transferring data, it is important to give feedback to the user on progress. A new property lets developers monitor the number of bytes remaining in the write buffer, and a new event is raised when data is being sent, enabling more informative data transfer applications.

LZMA compression for SWF files, the compiled format for Flash content, is claimed to reduce SWF size by up to 40%.

When do we get a full release? Adobe is taking its time, but my hunch is that it will be in 2011, maybe in time for the MAX conference in October.

Hands On with Flash Builder 4.5.1 for Apple iOS

Flash 4.5.1 has been released recently, the first with integrated support for Apple iOS as well as Google Android and RIM Blackberry Tablet OS. I was keen to try my calculator app on iOS, having already tested it for Android. You can do most of the development on Windows, but I moved the project to OS X so I could try it in the iOS simulator and then on an actual iPhone 4.

Adding iOS as a target platform was easy: right-click the project, choose Properties, check to add the platform.

image

Then I worked on the UI. The buttons on my design were too small. The answer I guess is to use relative sizes, but I thought for a quick test I would simply set the device to Apple iPhone 4 and resize the layout for that.

image

After a bit of tweaking I got the app working nicely in the iOS simulator, again set to iPhone4. I was also able to set breakpoints and debug the app easily.

image

Then I tried it on the device. I did the Apple provisioning dance. I then compiled a release build, which took a long time and featured a thermometer that stuck on zero the entire time. It worked though, and I got the app into iTunes and synched.

On the device the app did not look too good.

image

Well, I have read up on supporting multiple screen sizes and on setting mobile project preferences and I am still not sure why this did not work, especially as it looked OK in the simulator. I had auto-scaling on, and the docs say:

When you enable automatic scaling, Flex optimizes the way it displays the application for the screen density of each device.

I fixed the the immediate issue though by adding the attribute applicationDPI=”320” to the ViewNavigatorApplication element.

Now it works fine.

image

So how is performance? I have managed to create some rather poorly performing calculator UIs in my various tests of cross-platform mobile tools, and this is one of the better ones, though not as responsive as the Titanium app on iOS. However the Flex app is more consistent across Android and iOS, whereas Titanium was poor on Android. Loading takes a few second, but it is acceptable. The app size is only 6MB which is not bad, considering that the necessary bits of Adobe AIR are compiled into it.

Note that this is little more than a Hello World app. My reasoning is that if this does not work well, then nothing will.

So far I am encouraged. Taking into account the development experience and performance across both Android and iOS, this is one of the best I have tried so far with my simple example.

Adobe announces strong results though much of the business looks flat

Adobe has announced its financial results for its second quarter. Revenue is up 9% year on year, and profits are up too, so it looks like a strong quarter. However, the success is really limited to a couple of business segments.

Here is the comparison with the equivalent quarter last year:

  Q2 2010 Q2 2011
Creative and interactive 429.3 433.1
Digital Media 139.3 136.7
Digital Enterprise 231.9 283.5
Omniture 91.9 115.9
Print and publishing 56.6 54

Adobe has changed the segmentation of these figures since last time I looked, removing the confusing Platform and splitting out Digital Media. Broadly:

  • Creative and interactive is most of Creative Suite and the Flash platform including both developer tools and streaming servers. It also includes the nascent Digital Publishing Suite for  Apple iPad and tablet publications.
  • Digital Media is Creative Suite Production Premium and individual sales of Photoshop. Premiere Pro, After Effects and Audition.
  • Digital Enterprise Solutions is the LiveCycle middleware, now rebranded as part of the Digital Enterprise Platform, plus the content management platform acquired with Day Software in October 2010, and Acrobat.
  • Omniture is self-explanatory; this is the analytics business acquired in 2009.
  • Print and Publishing is a bunch of tools including, oddly, ColdFusion but not InDesign. Technical authoring sits here, as does Director.

So what do these figures tell us? Creative Suite is trundling on OK, but no more than that, particularly when you consider that Q2 included the release of a paid-for upgrade, CS5.5. Revenue from Digital Media is slightly down, as is Print and publishing.

The strong results are in Digital Enterprise, following the acquisition of Day, and in Omniture.

Both of these were smart acquisitions in my view, though I am not a financial analyst. In a connected era, analytics is crucial, with great potential for integration with the design and development tools.

The enterprise middleware also seems to be going well. This is really a strange amalgam of the old Adobe document publishing and workflow servers with the application services that came from Macromedia. Throw Day software into the mix, with Roy Fielding’s content-centric vision for application development, and you have an interesting platform.

Adobe is also benefiting from the Apple-led revolution towards design-centric software.

That said, not everything is going Adobe’s way. The momentum behind both HTML5 and Apple iOS is a threat to the Flash business. Never mind the technical arguments, the fact is that designers are more likely to be working on removing Flash from their web pages than putting it in. Adobe also needs to sustain its prices, and there is plenty of downward pressure on software prices today, partly driven by Apple and its App Store model. I also get the impression that the hosted services at Acrobat.com have not taken off in the way Adobe had hoped.

C# vs C++ and .NET vs Mono vs Compact Framework performance tests

A detailed benchmark posted on codeproject investigates the performance of basic operations including string handling, hash tables, math generics, simple arithmetic, sorting, file scanning and (for C#) platform invoke of native code. These are the conclusions:

  • There is only a small performance penalty for C# on the desktop versus C++.
  • Mono is generally slower than Microsoft .NET but still acceptable, and all the benchmarks ran without modification.
  • The Compact Framework, an implementation of .NET for mobile devices, performs poorly.

My observations: this matches my own experiments. Why then do some .NET applications still perform badly? When Evernote switched its application from .NET to native code it got much better performance.

The main reason is a couple of issues that this kind of benchmark hides. One is the GUI layer, which involves a ton of platform invoke code under the covers. Another is the large size of .NET applications because of the runtime and library overhead; a lot more stuff gets loaded into memory.

One thing to like about Silverlight is that it is truly optimized for client programming and load time tends to be faster than for a desktop .NET application.

Note that for mobile these benchmarks suggest that C++ still has a big advantage. It would be interesting to see them applied to Silverlight apps on Windows Phone 7. As I understand it, the Silverlight .NET runtime in Windows Phone 7 shares code with the Compact Framework on Windows Mobile, so it is possible that the poor results for the Compact Framework would also apply to Silverlight on Windows Phone 7. Unfortunately developers do not have the option for C++ on Windows Phone 7.

RESTful and modernised: making sense of Adobe’s new Enterprise platform

Adobe has announced its Digital Enterprise Platform for Customer Experience Management. My tip to Adobe: that is too many words with too many syllables for busy IT people who are trying to get their work done. What on earth is it? The same old stuff repackaged, or something genuinely new?

The answer is a bit of each. Adobe has made several big acquisitions over the last few years, starting with the Macromedia merger in 2005 that really formed a new Adobe, bringing together digital publishing and the Flash platform. In September 2009 Adobe acquires Omniture for web analytics, and in October 2010 Day Software. This last one seems to be having a huge impact. Day’s product is called CQ5 Web Content Management and is built on CRX, a content repository which conforms to JCR 2.0 (Java Technology API 2.0), a Java API. Here’s Roy Fielding, formerly at Day and now Principal Scientist at Adobe, from this white paper [pdf]:

The Content Repository API for Java Technology (JCR) is poised to revolutionize the development of J2SE/J2EETM applications in the same way that the Web has revolutionized the development of network-based applications. JCR’s interface designers have followed the guiding principles of the Web to simplify the interactions between an application and its content repository, thus replacing many application-specific or storage-specific interfaces with a single, generic API for content repository manipulation.

JCR is a boon for application developers. Its multipurpose nature and agnostic content model encourages reuse of the same code for many different applications, reducing both the effort spent on development per application and the number of interfaces that must be learned along the way. Its clean separation between content manipulation and storage management allows the repository implementation to be chosen based on the actual performance characteristics of the application rather than some potential characteristics that were imagined early in the application design. JCR enables developers to build full-featured applications based on open source implementations of a repository while maintaining compatibility with the proprietary repositories that are the mainstay of large data centers.

Adobe already has an application platform based on LiveCycle Enterprise Suite, which you will notice now redirects to the Digital Enterprise Platform. Ben Watson, Adobe’s Principal Customer Experience Strategist, explained it to me like this:

The core of the platform now becomes the repository that we got from the Day acquisition. We are also following their leadership around the use of RESTful technology, so changing how we do our web services implementation, how we do our real time data integration into Flash using data services. There’s really four technologies at play here. There’s CQ5, Adobe LiveCycle which is all the business process management on the back end, the online marketing suite with Omniture, and Creative tools which allow to both design and develop all of this content and assets … We had two Java platforms and we brought them into one.

adobe-slide

You can read up on the Digital Enterprise Platform here or see a chart of capabilities here. Much of it does look like rebranding of existing LiveCycle modules; but as a statement of direction it is an interesting one.

Is this for on-premise deployment, or cloud hosted? Adobe has a tie-up with Amazon for hosted deployment, though there is no no multi-tenant hosting from Adobe yet; I got the impression from Watson that it is being worked on.

Adobe is aware that it does not stand alone, and there are several connectors and integration points for third-party applications, such as a SAP data services connector.

Adobe also has a series of “solutions”, which are permutations of web content management, analytics, document processing, social media and so on.  There is also a Unified Workspace, currently in beta, which is a dashboard application.

The company’s line is that it is well placed to address the challenge of the mobile revolution, and to bring greater usability and social interaction to business applications, the consumerization of IT.

Although that sounds a strong pitch, melding all this together into something new while keeping hold of existing developers and designers is a challenge. Another issue for Adobe is that the company’s strong presence in design, multimedia and marketing makes it hard to appeal to more general enterprise developers. Nevertheless, the combination of Fielding’s influence and Adobe’s strength in design, documents and cross-platform clients makes this a platform worth watching.