I attended a round table to discuss the use of open source software in government, with Red Hat, Ingres, Alfresco, and on the government side representatives from the Office of National Statistics and Islington Council.
It is a fascinating topic on several levels - and not just for government. The two big questions: first, what is the rationale for prefering open source; and second, if you are convinced of its desirability how on earth do you get a huge, diversified entity like the UK government to increase its adoption?
There is clearly some kind of disconnect. The government already has a policy which stops short of mandating open source, but does say:
Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.
In other words, given two otherwise equal proposals, open source is favoured - yet in practice we were told that 95% of software in use in the UK government remains proprietary.
So why is that? There are dozens of reasons. It's the available skills, with armies of experts in Microsoft, Oracle, IBM, and so on, compared with only a few willing to specify open source technologies. It's the culture, with countless existing supplier relationships and a well-trodden procurement path with the usual suspects. It's the existing envirnonment: if you start from a point where the servers are Windows, say, and the desktops all have Microsoft Office, it feels more comfortable to continue down that path. It's the lock-in, especially when it comes to things like proprietay SQL extensions and stored procedure languages, that simply do not port easily to new database managers. And it's canny vendors, who go for site licences with the widest possible scope, so that if a small group decides to break the mould and use something different, it looks more like a cost than a saving - because they are already licenced for the proprietary stuff.
These are tough obstacles to overcome. Put another way, the rationale for adoption has to be exceptionally strong to overcome the inertia; and it was here that I found the round table unconvincing. The open source companies gave diverse reasons for the benefits. Lower cost was mentioned frequently. By contrast, John Powell, President and CEO of Alfresco, talked intensely about how the UK was somehow handing over its soul to silicon valley, by not building up local skills in open source software. Someone else said how nice it was that open source software was free so that everyone in an organization could use it; another gently observed that since most open source companies make their money from support agreements that are per user, this is often not the case.
The most persuasive rationale is that open source software tends to support open standards and therefore avoids lock-in. This lowers long-term costs, by ensuring that the customer always has freedom to switch.
The snag with all these arguments is that the proprietary companies can counter them easily. They will reel off all the open standards they support. They will draw graphs showing how much money you save by using their stuff. They will point out that those with skills in their technology can easily market them worldwide. The outcome is that nothing changes.
I don't doubt that leading vendors make excessive profits on software that should be commoditised and cheap, or that vendors follow strategies designed as much to keep us hooked on their stuff, as to advance technology for our benefit. It's a cycle that needs to change.
At the same time, the open source vendors have to recognize - and to be fair, I reckon they often do - that most of us will not switch for ideological reasons. We want to get our work done. The best open source projects, things like the Apache web server (if there is anything like it) succeed on sheer quality and reliability, not merely through being open source.
The tough question: does the open source ecosystem have sufficient resources to deliver that quality, against proprietary vendors with huge profits to pour into research and development? There are plenty of decent open source products; the number that are truly best of breed is more limited. Currently it is the big proprietary vendors that have the advantage.
I left the table with more questions than answers. Should governments introduce more draconian legislation, to counterbalance the industry bias towards the status quo? Will the move towards cloud computing break the pattern? Should legislation be focused on mandating standards support, or even that applications should be proven to work on two different platforms, rather than the matter of open versus closed source? If today's MySQL is tomorrow's Oracle, is there really any difference? Isn't there too much to worry about already, solving problems and delivering successful projects?
If pressed, I would always incline towards the best technical solution, rather than one which ticks boxes, even open source boxes. That said, we are all susceptible to being bamboozled, not even looking at open source alternatives if we already know a proprietary tool or component or platform that will do the job. Even for individual developers, it makes sense to choose the open source solution in cases where other things are equal; and to think twice before building vendor lock-in into the applications we create.
Tech media pundits talk incessantly about migration to the cloud, but it is always interesting to get reports from the trenches. Two recents ones interested me. The first is from Patrick McKenzie, who sells a niche Java application. He's just posted a detailed and entertaining blog entitled Why I'm Done making Desktop Applications. His application exists in both desktop and online versions, and he says he was a staunch defender of the advantages of desktop apps - "You can keep your Google Docs, Excel is superior in almost every way." Then he made an online version of his app with if anything fewer features, and tracked the statistics. He discovered the following:
His conclusion:
The next major release will almost certainly be its last. The webapp, and my future webapps, seem to be much better investments.
Does any of this apply to corporate development? It's true that life is easier in some ways if you do not have to make a sale; and there are still some things that desktop applications do better, like integrating with Microsoft Office through COM automation, or continuing to work offline on the train or plane - though see Rails creator David Heinemeier Hansson's You're not on a plane for a contrary view.
Still, many of the other factors do apply. Lower support requests, zero installation, accurate usage monitoring - all these things have immediate financial benefit.
It is no longer web application developers who have to justify their case, but rather those who still advocate desktop development.
If you need any further persuading, take a look at this survey of 1400 Microsoft's small business customers by Accredited Supplier. Apparently 62% prefer business applications that work through a browser, and only 18% prefer desktop applications. The more chilling news for Microsoft is that 13% actively intend to switch to Google Apps - with all that implies for sales of Windows server, Exchange, and Office - while only 36% are sure that they are not switching.
All that cloud talk is translating rapidly into business decisions. I'm not sure whether the future of the business application client lies more with AJAX and HTML 5, Microsoft Silverlight, Adobe Flex, or something else; but for sure it is not a desktop technology.
The Apple Mac's OS X is a gorgeous operating system, beloved by its users, but outside the niche world of designers and musicians it is generally not the one used in business. It's an odd situation that puts pressure on system administrators to accommodate Macs into their systems, either from the aforementioned designers, or from eager home Mac users who want to enjoy it at work as well.
Last week Apple released OS X Snow Leopard, also known as OS 10.6. I was at Apple's flagship store in Regent St, London following a press briefing, and watching throngs of people line up to purchase their upgrades left me in no doubt about the Mac's continuing success. Nevertheless, because of its high price and lack of business penetration the Mac remains a minority choice. The figures are slippery, but it may be around 10% of the US market by units, 20% by value (the difference showing how expensive they are), while worldwide it is much smaller.
Now Apple has introduced native support for Exchange as a key feature of Snow Leopard, apparently giving admins one less reason to deny would-be corporate Mac users. Is it enough?
Unfortunately the Exchange support still falls short. I've spent several days working almost exclusively in the new OS, and explored the new Exchange support in Snow Leopard. Although there is a lot to like, such as deep integration with Mail, iCal and tasks, there are snags. For a start, you need Exchange 2007 SP1, and earlier versions remain common. Even if that is in place, Snow Leopard's Exchange support still falls short of Outlook on Windows. The new feature is based on Exchange Web Services (EWS), which do not expose all the features of Exchange.
I found myself missing features like the ability to send on behalf of another user, and access to public folders. Another practical problem is that unless Exchange is configured with EWS in mind, it might not work at all, especially when trying to connect over the public internet. Outlook has its problems, but its ability to use RPC over HTTP, avoiding the need for a VPN connection, is a brilliant feature. It is also strong at seamless online/offline support, stronger than Apple Mail. I'm also not convinced that Mail's new Exchange support is quite done, as evidenced by several crashes like this one:
The real issues are broader than this. Macs still fit awkwardly into Windows-based networks. System administrators like standardisation: standard application deployments, standard operating system builds that can be zapped and re-imaged; standard configurations that can be enforced using Windows group policy. The presence of Macs adds unwelcome complication.
There's also the matter of application compatibility. If your business depends on some little application written in Visual Basic 6 or Microsoft Access, for example, you have to figure out a way for Mac users to run it, by emulation, or terminal services, or some other route.
In the short term then, Snow Leopard will not transform Enterprise Mac adoption. Nevertheless, the Mac is a huge influence, beyond what its market share implies. Further, if a significant number of users are using Windows grudgingly, wishing they were not, that is not good for productivity.
Here's three suggestions. The first is to think cross-platform. The past is the past; but for new applications it is short-sighted to target only Windows. I suspect this lesson has largely been learned, but it still bears repeating. Have a cross-platform client - Silverlight may help for .NET developers, or there is Adobe Flash/Flex, or Java, or pure Web applications, to mention a few solutions.
Second, learn from Apple. Microsoft is doing so, and Windows 7 is the evidence. An interview I did with Bill Buxton last year gives further background.
Third, is it really so hard to accommodate Macs? Yes, there are still issues, and different factors apply in every organization, but few problems are insurmountable.
Incidentally, I am no Mac Zealot. I actually like Windows, and although I'm currently immersed in OS 10.6, I intend to go back to using a PC most of the time. Some things are better on the Mac, some things are not, and most things are more expensive. It does pay though to have users working in the environment they prefer; and where that is possible, it makes sense to allow it.
Question: which is best for cross-platform, managed code using a runtime such as Java, .NET, or Flash, or is it native code? When Java arrived in 1996, Sun promoted write-once-run-everywhere as one of its key benefits. The arrival of just-in-time compilers for all the runtimes mentioned above removes many performance concerns. So is managed code the best solution?
My assumptions about this were challenged when I spoke to Embarcadero's CEO Wayne Williams last week. His company is the one that now owns Delphi and C++ Builder, the RAD software development tools, after acquiring Borland's Codegear division last year. Williams told me that taking Delphi and C++ Builder cross-platform is now the top priority for the team working on those products. Concerning native code, he said: "It's crystal clear. If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town." That means at least x86 code for Windows, Mac and Linux, and he added, "there's no reason mobile devices shouldn't be on that roadmap as well."
What's wrong with Java then? "There's always been two approaches to target multiple platforms. One is interpreted, where you shield the code the developer is writing from those differences. The Virtual Machine is responsible for that, and if you want to add another platform, it's all centralised. It's easier, but the result is poor, it's a least common denominator approach.
"It's a bigger investment and it's more difficult to cross-compile, where you natively target these platforms, but the end result is much better. You're running true native code with full access to whatever hardware there is on that platform."
It was like going back in time: I recall similar arguments about Java back in the nineties. Since then, we've had not only JIT compilers but also huge increases in hardware performance. Is Williams living in the past?
Before dismissing what he says, it's worth noting that native code has never gone away. I use cross-platform native code applications all the time, from the SQLite database engine to the Audacity sound editor, and I enjoy their small size and fast performance. Over at Google, the Chrome team is hard at work delivering a new web browser, and it is mostly written in C++. Most of Windows is written in C++, despite Microsoft's commitment to .NET; and Java is an afterthought in Apple's OS X.
Although hardware performance has improved, the increasing numbers of mobile devices with constrained resources is a counter-balance to the idea that hardware takes care of inefficient code; and although managed code is fine for many business applications, it's hard to quibble with Williams' contention above that "If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town."
There is another argument for managed code, which is that applications are quicker to write and safer to run when they are under the control of a runtime virtual machine. That is generally true as well. Still, Delphi does a great job of hiding the complexity of native code development. It may be just a little anachronistic, but if Embarcadero successfully deliver a cross-platform Delphi compiler, I think there will be plenty of take-up.
Williams says we may see cross-platform Delphi as soon as next year.
The Web is broken in lots of ways, one of which is that its content is mostly unstructured. Most web pages have a title and some content, and that is about all you can assume. Researchers and standards bodies have been trying to impose more semantic order on the web since its earliest days, by adding metadata so that web crawlers can parse the content accurately, rather than relying on inference. These efforts have had little success outside academia; and the semantic content of typical pages has arguably got worse rather than better, thanks to the trend towards richer pages using JavaScript and Flash, rather than simple text marked up with HTML.
Microformats are a softer approach to adding metadata, using standard HTML but with conventions that identify certain types of content, such as name and address details (hCard), events (hCalendar), or even CVs (hResume). If you have web pages that include content of this type, you can usually mark it up according to the microformat specification without damaging the appearance of the page. The benefit is greater searchability; in fact, you could think of it as a kind of search engine optimization.
A good example is hReview, a draft specification for reviews of anything from products to events or places. If I'm considering a purchase, I often type in a search for "product x review", and then find myself sifting through lots of useless results, because all the ecommerce and affiliate sites know we do that kind of search, and pretend to have reviews when really they do not. If all the sites used hReview I could do more precise searches, perhaps specifying "only reviews in the last 12 months", and sorting by rating, and the search engine could structure the results nicely so I can see at a glance the author's name and an extract from the review itself.
Simple standards like this can have a huge impact. The whole blogging revolution was driven by RSS, which itself is a kind of microformat for news.
The snag is, they have to be widely adopted to be useful. I first wrote about microformats in 2006, but despite my enthusiasm they have had little impact to date. That may be about to change. On Tuesday May 12th the mighty Google announced a new feature called Rich Snippets, which means it will be exposing microformat metadata in its search results, along with another more generic type of metadata called RDFa.
It all sounded familiar to me, as the previous weekend I attended Yahoo Hack Day in London, and heard about its Search Monkey project which also uses microformats and RDFa. Yahoo was there first; but it is Google that has the power to shake up the web.
Should you care about microformats? If Google is serious, then it will have a wide impact. Business names and locations should be marked up with hCard, for example. Anyone designing an Ecommerce site with user reviews should be looking at hReview. Although the list of microformats Google is taking note of is small at the moment, if it catches on that list will inevitably grow.
The message that Google is giving an advantage to sites that use microformats and RDFa will be heard loud and clear by the SEO community, and given the commercial importance of effective search ranking this could grow quickly.
Then again, I may be over-optimistic now (and yes, I do think it is a good idea) as I was in 2006. Watch this space.
Too strong? Maybe, but the ASP.NET Web Forms programming model has run its course. It was hugely impressive when it originally appeared - I remember it being announced as ASP+ in 2000, and how phenomenal it seemed. You can build a web page visually, using a rich set of controls, and have ASP.NET abstract away much of the problem of managing state. It also lets you write code in any .NET language, which is just-in-time compiled at runtime for fast performance.
ASP.NET works the same as ever today; but the web has moved on. The Web Forms model makes programming the web more like programming Windows, which was cool at the time but not any longer.
Fortunately for Microsoft, it has an alternative, called ASP.NET MVC. The first full release was announced at the Mix09 conference last week, and you can download it now. I took the opportunity to ask some of the delegates what they thought of it.
The reactions I got fell into two broad categories. The first group found it difficult to puzzle out what it really was, even those who had attended sessions on the subject. The second group loved it, and never ever wanted to go near Web Forms again. In fact, such was the frustration with Web Forms among some developers, that they had developed their own alternative frameworks but were now moving to the official one.
So what's wrong with Web Forms? Complaints I heard include that it is not testable; that it is not really compatible with AJAX; that it is inflexible; that ViewState, hidden form data which preserves state across page refreshes, is a nuisance; and that it is hard to write REST-style applications or those which properly support the Back button.
Enter ASP.NET MVC, which answers all of these complaints. MVC stands for Model View Controller, though having played with it a little I find the name somewhat misleading, as well as being a mouthful (contrast the delightfully-named MonoRail, which is an interesting alternative). Why misleading? Well, it doesn't have much of a Model, as this post observes. It does have views and controllers; but I think one of the reasons developers find it hard to grok is that starting with a discussion about MVC architecture is not the best way to teach it.
I think the place to start is with URLs and routing. It also helps to know that ASP.NET MVC follows the principle of convention over configuration (though not to the same extent as Ruby on Rails). In a nutshell, ASP.NET MVC breaks the link between the URL in the browser and aspx files on the web server; instead, it processes the URL and returns what you want it to return.
A "View" in ASP.NET MVC is an .aspx page, but in the form of a lightweight template, not a Web Forms with a complex page lifecycle.
I've been playing with ASP.NET MVC recently, and it is a delight. Yes, there is more manual coding than with Web Forms, but it is worth it for the additional control you gain. Even the performance seems better, a consequence of the lightweight approach. As it happens, I'm also a believer in test-driven development. I guess I'm in the second group that I spoke to at Mix09.
Microsoft is not killing off Web Forms; rather, it is very insistent that they remain under full development. I get the impression that the company expects ASP.NET MVC to be a minority choice.
Nevertheless, if you work with ASP.NET do not hesitate to check out the new framework. Personally I think ASP.NET MVC might just rescue its web platform from a slow but inevitable decline.
There is a kind of Windows 7 fever sweeping the Web right now. Some observers are getting carried away:
As a person who performs almost every computing task on a Mac and tells anyone who will listen that at this point, the average consumer should be using a Mac instead of a Windows machine because of security and usability, I'm starting to prep myself for the single moment that I thought would never come: I'll be using a Windows 7 machine as my main computer and telling anyone who will listen that, believe it or not, using the latest Microsoft operating system really is worth it. [Don Reisinger]
I've spent a lot of time in Windows 7 these last few weeks, and in some ways I see what he means. It has a smoothness and elegance that is lacking in Vista, though it is there to some extent in Server 2008. But let's be clear: the popular view that Vista is rubbish and Windows 7 is great does not stand up to close analysis, for one simple reason. It is just not sufficiently different. Microsoft actually makes a positive of this characteristic, explaining how preserving the core architecture of Vista ensures good application and driver compatibility and therefore a smooth upgrade.
What about Windows 7 versus the Mac? I agree that Windows 7 is superficially more Mac-like; and more important, that the factors that made Vista such an unpleasant experience for some (not all) early adopters will not apply. I'm thinking of things like laptops that were underspecified, or had buggy drivers, or barely adequate graphics hardware, or that were weighed down with so much foistware that Windows would hardly run. However, other factors that make users prefer Macs will not have changed. There is the control Apple exerts over both hardware and software; its design excellence; the fact that Apple is less tolerant of legacy software, whereas Microsoft has Windows jump through hoops to keep it running,adding complexity and inconsistency; and there is the absence on the Mac of the culture of chaos that afflicts Windows. I'll leave aside religious arguments about Unix vs Windows, though it is a matter of record that OS X has to date proven far more secure, for whatever reason.
Let's ask some awkward questions. Will a substantial number of Windows 7 machines fall victim to viruses, worms, trojans and botnets? Almost certainly. Will Windows 7 from time to time flummox users with obscure errors like "the system could not find the file specified"? Almost certainly. Will some Windows 7 machines be built down to a price and be sold with obvious design flaws and insufficent attention to quality? Almost certainly. Will some vendors wreck the sweet install experience Microsoft has created by imposing their own clunky utilities and third-party trialware on top? Almost certainly. Will the Windows 7 event log become populated with perplexing entries like "The Workstation service terminated with the following error: The redirector is in use and cannot be unloaded." (plucked from my Windows 7 beta 1 laptop)? Almost certainly.
Let me add that I realise how smooth and reliable a well-managed Windows machine can be. Further, while I have had some frustrations with Vista it has always been stable for me and I have never wanted to go back to XP. Vista, then, is better than its reputation; Windows 7 is better than Vista but will have trouble living up to the proclamations made by its more enthusiastic admirers.
Last week Sun launched JavaFX, its Java-based platform for Rich Internet Applications. Sun picked up the high level of interest in Adobe's Flash as an application runtime, and perhaps Microsoft's Silverlight as well, and hurriedly developed its own equivalent. JavaFX is a new scripting language that runs on the JVM (Java Virtual Machine) and is optimized for graphical effects and multimedia. It brings to Java animation features like timelines and motion paths, support for a variety of audio and video codecs, and a way of coding a graphical user interface without the supposed complexities of Swing with its Model/View/Controller (MVC) design. JavaFX applets can run within or outside the browser. One innovation is that you can drag an applet out of a web page and onto your desktop. If you close the browser, the applet keeps running, thanks to support for out-of-process plugins in Internet Explorer 7 and Firefox.
So far JavaFX has received a mixed reception, and it is easy to see why. The launch was rushed, and some early visitors to the site had a bad experience, with videos that would not play or samples that did not run. Videos running in JavaFX flash unpleasantly if you resize the browser. The install experience is not as smooth as for Flash or Silverlight in my experience, because you need to install the Java Runtime Environment (JRE) as well as the JavaFX plugin. The download size is larger, although this is disguised by Sun's slimmed-down initial install. The idea is that you get up and running quickly, while the rest of the JRE installs in the background. The SDK does not yet run on Linux or Solaris, although the applets themselves should run because they only require the standard JRE plus a runtime jar (add-on library) and can be executed using Java Web Start. The latest NetBeans has JavaFX support, but another downer is the lack of any dedicated visual design tools. Sun only offers an export add-on for Adobe's Photoshop and Illustrator, or a converter for SVG (Scalable Vector Graphics). There is no 3D API yet, though it is promised.
It is easy to be negative; but some of these problems will disappear as JavaFX matures. A visual design tool is in the works, as is a mobile version that will be shown at the Mobile World conference in February next year. JavaFX will have a place for Java developers who are envious of what Flash and Silverlight can do. While it may not match Flash in terms of broad runtime deployment, I'm guessing that Sun will outpace Microsoft in this respect. JavaFX also has a couple of advantages over Flash, including more sophisticated client-side security and better code performance in some scenarios. The Java VM is mature and well optimized. Adobe's ActionScript virtual machine does have a just-in-time compiler, but seems slower than either Silverlight or Java for code execution. Speed of graphical effects is another matter, and while I have not seen any comparisons yet, I suspect Adobe's long multimedia experience may come into play here.
JavaFX will be welcomed then by Java developers who need more expressive graphics in their applications, and will be an interesting option for those developing games for mobile devices. Try as I might though, I'm finding it hard to believe that this is a huge section of the market, or that Sun will have much success persuading designers to target JavaFX rather than Flash, or that JavaFX will win much market share from Adobe for web-hosted video. Swing works well these days, its MVC architecture has merit, and it is well-suited to the kinds of Enterprise applications which commonly have Java clients. JavaFX is a useful addition to Java, but I doubt that Adobe is losing sleep over its likely impact. That said, I'm keen to hear from developers with plans for JavaFX applications, so don't hesitate to let me know.
Adobe's MAX conference in San Francisco this week was focused on what it calls the "Flash Platform", a technology stack oriented round the Flash multimedia runtime. The "platform" word highlights the fact that you can code for Flash and have your application run everywhere that Flash runs, including Windows, Mac, Linux, and some mobile devices as long as they are not from Apple. It is not a complete platform, being essentially an Internet client, though there are some server-side pieces such as LiveCycle Data Services, to simplify and optimize communication between Flash clients and Java middleware. You can also blur the distinction between browser and desktop with AIR, which runs Flash outside the browser and adds a local database engine.
So what's new? There was the usual set of announcements. The key ones are as follows:
AIR 1.5: an update to the desktop runtime which adds support for Flash Player 10 features such as Pixel Bender, for runtime graphical effects, and an option to encrypt local databases. There is also the SquirrelFish JavaScript interpreter - though this only comes into play if you are running JavaScript within HTML, rendered by WebKit, rather than ActionScript without the Flash runtime, which has its own just-in-time compiler. AIR 1.5 is available now.
A new version of Flex and the Eclipse-based Flex Builder IDE, code-named Gumbo. This has a new skinning and component architecture, more advanced text rendering, easier two-way data binding and a new Client Data Management (CDM) feature which from early descriptions looks reminiscent of a .NET dataset. You work with data on the client, storing updates locally, then zap the updates back across the wire in a single update operation. One thing that is not yet clear to me is the extent to which CDM requires LiveCycle on the server; I'll be sure to clarify this in a couple of weeks at MAX Europe (I was not present at the US event). The database aspect is significant, because so many enterprise applications boil down to CRUD (Create, Retrieve, Update, Delete) in one form or another.
Catalyst, formerly code-named Thermo, was previewed. This is a fascinating product which converts Photoshop artwork into Flex code; it also allows designers to create and preview a degree of interaction in their designs. Catalyst shares the same project format as Flex Builder. Again, I will be taking a closer look at MAX Europe. Here's a preview screen grab:
Cocomo (yet another codename) is a cloud effort from Adobe, focused on conferencing. Adobe hosts the services and provides Flex components to enable file sharing, text and VOIP (Voice over IP) chat, whiteboards, and data messaging; there is also user management built in.
Alchemy is a tool that converts C/C++ code to ActionScript, for execution within the Flash player. It's intended for re-use of existing libraries, not for general development.
Third-party announcements that caught my eye included Ensemble's Flex add-in for Visual Studio (though I was underwhelmed by the preview), and Zend's addition of AMF (Action Message Format) into its PHP Framework. AMF is a binary format that optimizes data transfer between servers and Flash clients.
Although none of these announcements is spectacular in itself, taken together they show the momentum behind Flash as a client for applications as well as video and multimedia, as I have mentioned here before. A good thing? Designers love Flash because of the freedom it gives them, along with the excellence of Adobe's design tools - Creative Suite 4 really is spectacular. Nevertheless, I have a nagging concern that if we adopt Flash rather than AJAX - interactivity in HTML and Javascript - for our next-generation clients, we are giving away the openness of the Web, because Flash is proprietary technology. I recommend this thoughtful post from Google's Brad Neuberg, which recommends not only open-sourcing the Flash runtime, but also integrating it more deeply with the browser and embracing web standards. There's little chance of Adobe adopting Neuberg's proposals, but he does a good job of spelling out the issues. Flash is compelling, as is Microsoft's Silverlight, but each is controlled by a single vendor. Do you think that matters? I'd be interested to hear your opinions.
