sorted by: recent | see : popular

Content Tagged with editorial + front

I found myself pondering the Open Web recently, and I posted about my thoughts as I revisited why the Open Web matters. The piece is not about the Open Web being better, or for Open Web people to feel high and mighty. Rather, it is working out why the Open Web makes sense, and how it fits into the world at large.

I am curious to hear your thoughts. Does the Open Web matter to you? Or, do you just want a productive place to get stuff done?

Here is the piece:

I have been thinking more about the Open Web recently, and decided that it may be time to go back to first principles and work out why I am such an advocate for it. The Open Web has plenty of flaws. I wish it was more productive, more seamless, and more beautiful :)

This came about as I pondered the same thing for feeling an association to a political party. Why do people associate themselves as Democrats, Republicans, a member of a smaller party, or just independent? How often do you join a team and just stick with it? It feels like there are a few types of people, including (sorry for a football analogy!):

• At birth: I was born in Tottenham, so I will be a Spurs fan for life
• Fair weather: I never liked Chelsea particularly, but after that Russian guy got involved I go to games and cheer them on
• First principles: I like teams who play attacking football. I used to hate "boring boring Arsenal" but after that French bloke go involved, I have changed my mind.

Things change. The party of Honest Abe kicked into gear with the "core values" revolving around abolishing slavery, rather than all of the conservative values that the party espouses today.

Of course, within a party there are many factions. The Neo Cons and the traditional fiscally conservatives may share a party, yet be at odds on various decisions. The exact same goes for the Democrats and their beliefs.

Because of this, I am trying to regularly take a step back and match my belief system to the current politics of the day. Often parties use deep wounds and values to try to tie people together, but in other times we see the need to be reborn. Tony Blair famously did this recently in the UK by creating the "New Labour" brand. He ended up doing what Neil Kinnock never could, and becoming prime minister.

How does this all fit into software?

It is easy to get sucked into the same trap. "I believe in the Open Web!" Things change, so you can challenge yourself on why that matters to you.

As I look into why I care so much for the Open Web, a few core thoughts come out.

Power will lead to bad things

If I look back at the recent history of software and platforms, I come to the conclusion that at various points on the road the interests of developers and vendors align for awhile. Ben and I have been talking about this. For example, Microsoft nails the productivity of Visual Basic, and developers take that gift and run with it. But, over time, developers get frustrated and some of them feel like Microsoft uses their power to do bad things. Many lose trust and look elsewhere. Others don't care and keep listening.

When the Java community came to the realization that Applets weren't the killer app, but rather the JVMs, the "better C++" for the time, and the write once, run anywhere promise took hold quickly. Despite Sun, the Java developer community is still strong to this day. The problem though, is that at some point the vendors got too involved in a way that created EJB. Forget solving developers problems, it is time to argue over what to standardize, where the game is having your approach be the standard. IBM, Oracle, Sun, and many others fought about EJB and thus we ended up with the monstrosity that would create fortunes for consultants. Once the success of Java kicked in, everyone jumped on how to make money for it. Sometimes the companies that innovated were able to both make money for themselves, and help developers. Other times, not so much.

The power of the Open Web is in the fact that no one company controls it. When the interest of developers and The Uber Company aren't aligned, developers are no longer screwed. They have choice.

This choice can come at a cost though.

Mussolini may be a dictator, but he made the trains run on time!

There is a notion that the less voices that we have, the faster we can move. A dictator that owns multiple sides, or the entire stack, can make a more productive, technically superior solution. In some ways this makes sense of course, but remember that Mussolini set the trains perception by changing the clocks. It doesn't have to be this way.

One key is to keeping the democratic process moving appropriately fast (but not too fast).

I have talked about the Fly wheel approach in the past, and I think that this is a key issue for a healthy democracy, and a healthy Open Web.

There are reasons why Winston Churchil said:

Democracy is the worst form of government except for all those others

On the bad side, you get the issue of it never being able to become pure (just the same as communism). We are dealing with people. Once people get in power they have reasons to tweak the system in their favour. Obvious examples exist such as redrawing the congressional boundaries to do what you can to keep your party in power.

In technology you get the same thing. On the Open Web for example, we only have a few viable browsers (like the few number of viable parties issue). This gives huge power to these browser vendors, and it can break the fly wheel. Browsers have barely had a chance to innovate in the last decade. Imagine using a cell phone from 10 years back? It is crazy! The silence in the chasm is frustrating as hell. Even when the browsers change, we still have the lead weight of the users who don't update. We need to solve that problem.

Microsoft got such a huge leader in the browser war, that they turned off. This cut off the circle of healthy Web life:

• Vendor creates technology
• Developer uses technology
• Developer pushes boundary of technology
• Vendor sees what is being done, and works on newer better technology
• REPEAT

It turned out that developers have really kicked this into live again via the Ajax revolution. With poor dhtml support, many developers moved from the client side of Web browsing, and ran screaming from dealing with Netscape layers, and IE equivalents (IE was quickly better in fact). They made their home on the server for the coming years, spending time on Web frameworks in every language camp out there. We went from CGI to NS/ISAPI, to mod_*/Servlets/PHP, to Rails/Django/and more.

It took the joining of Mozilla implementing XMLHttpRequest, and visible applications such as Google Maps and Gmail (among others) to wake up the developers to the wasted CPUs and functionality available in the browser. Only brave folks such as Dean Edwards, Alex Russell, Erik Arvidsson, Emil Eklund, Dan Pupius, Aaron Boodman, Scott Isaacs carried the flame and pushed during the lean years.

With developers back in the game, thanks to Ajax, the browser vendors had the push they needed to really kick into gear again. Richer Web applications required better JavaScript and APIs. If a browser got really good at powering these rich applications they could set themselves apart.

This wasn't enough though. Web developers were frustrated. We had teams at Google that mirrored many others. They wanted to add more functionality to their applications, and they needed a vector to make that happen. This is how Gears was born, and I bet the case was similar for what became the Yahoo! BrowserPlus team (am I right Lloyd? :).

Now that we are back in sync, and the flywheel has been turned on again, my thoughts are on how to keep this effect going. How can we put developers first and make sure that the cycle continues and doesn't get derailed? We need to balance the power and constantly be watching it. No one company can get to a point when the power can corrupt. This is subtle, as it isn't just watching out for the Sheriff of Nottingham and seeing how he is taking all of the money. These things often happen by mistake. You can easily think that you are doing a "good thing for the community" and yet you are creating a very unlevel playing field. One simple example that shows this is if we put CSS and JS from Google properties directly into Google Chrome. We could argue that this would be good for users as it would make the experience faster. How harmless is that? I believe that it would destroy the level playing field.

This isn't to say that you can't innovate, far from it. We need to be very clear that we require innovation. We just need a path for taking the evolution and moving it into the standards. In the above example, we could create a system for richer caching of resources. We could implement the hashing work that Aza Raskin and Douglas Crockford talked about. Good work will stick and will become part of the Open Web naturally. This is the beauty of the Open Web. Someone can come up with a piece of technology and others can share and use it. An independent developer could think up OAuth and make it happen. If it is worthy, big companies can come along and implement it too, and we can standardize. It doesn't have to come FROM the huge companies first though. Think about how rare that is.

This is why I come full circle to realize that the Open Web is important. We all need to do our best to make sure that this deeply evolving system doesn't get cancer. We need the bursts of innovation to kick out new DNA that allows us to try experiments.

With all of the work being done right now, it feels like the end of the Dark Ages. I can't wait for the next chapter, can you? What have I missed?

But fighting the web is like holding back the ocean; it will route around you or it will wear you down, but will never go away, and it will never tire or give up. Yet in spite of the futility of fighting the web, Silverlight is being positioned in opposition to the web, not in support of it

This is one of a few great quotes from DeWitt Clinton's post On Fighting the Web itself. DeWitt is a colleague at Google, one that I have shared offices with, and great conversations. He has very strong ethics, but at the same time is very practical. But, back to his writing.

This is not a post saying "the Open Web rules and the proprietary Web is evil". If you actually read this carefully you see a very interesting argument that covers:

We can't be blind:

The short answer is that the technology behind Silverlight, and most certainly the company creating it, has the potential of changing how the web itself works.

The Web has strengths, but man it is tough to work with:

If you’re a web developer then you’ve felt the acute pain involved in writing applications inside the browser. Even armed with the most state-of-the-art toolkits, such as jQuery, Dojo, etc., you’re still limited to the available runtime of HTML, CSS, and JS, and worse, the absolute morass of cross-browser incompatibilities and restricted access to native client-side capabilities. I remain in awe of what people have accomplished in this environment, but I’m sad that this is all we’ve been able to accomplish so far.

Man, if the client is involved... evolution is slooooow:

The web revs slowly. Very, very slowly. In 10 years we’ve seen virtually no meaningful advances in the the ubiquitous web client; just a painful slog forward as web developers learn to eek out just a little more functionality in a constrained environment. Progress is slow because revving the ubiquitous client requires the coordination of multiple parties, not all of whom have shown consistent interest in working together to move the web forward.

There is some hope for an Open Web-style speedup:

More recently we’ve seen some earnest attempts at breaking that cycle. Rather than wait for the entire web to catch up, projects like Gears seek to rev the client from the inside out. It may take several years for standards like HTML5 to be widely deployed, but if developers can gain a toehold inside the client and start forcing the issue immediately then we’ll quickly see what works and what doesn’t, and be that much more informed about what to standardize and adopt as part of the long-term web platform.

The proprietary folks have a huge advantage, as they can just innovate and run without getting consensus:

But there’s another approach, an approach best exemplified today by the Flash runtime, whereby one doesn’t seek to improve the web from the inside, but rather replace it entirely. Sure, technologies like Flash take advantage of the web via http-based delivery mechanisms and in that they run inside the browser, and yes, they can use network connections like anything else, but these alternate runtimes fundamentally divorce themselves from the web ecosystem, and in doing so gain a significant advantage, but at a cost.

In spite of circumventing the web — no, because they circumvent the web — these new runtimes have the potential of offering a far better developer experience, and hence, a far better user experience, then the least-common-denominator of the standard widely-deployed ubiquitous browser runtimes of today.

And, thus, the proprietary stuff can be very good indeed:

Which leads us to Silverlight: Silverlight is positioned to take the fork-and-forget approach to the web pioneered by Flash and bring to it an unprecedented wealth of technology and corporate might. With a better underlying runtime and VM, better tool support, far superior multi-language capabilities, and more marketing muscle, Silverlight has all the potential to make rapid and noticeable inroads over the next several months, cleaving a large section clean out of the web.

And the scary thing? That this isn’t entirely a bad idea. The browser itself is anemic, the dependency on a single language is a handicap, the security models simultaneously constricting and flawed, the development environments underpowered, and frankly, the whole ecosystem is deserving of a major disruption. We’ve lived too long thinking that what we have today is good enough.

And will get better, fast:

Granted, these technologies won’t be perfect at first. On the contrary, they might be slow, cumbersome to deploy, buggy, and feature deprived. But right now that doesn’t matter. The strategy is all about getting a wedge in place, a bit of leverage that can be used to further pry open a vector for escaping the existing ecosystem. And over time, as the technology improves and adoption grows, so will the size of that tear in the fabric of the web.

But, there is a reason why the Web does so well:

But fighting the web is like holding back the ocean; it will route around you or it will wear you down, but will never go away, and it will never tire or give up. Yet in spite of the futility of fighting the web, Silverlight is being positioned in opposition to the web, not in support of it.

Why in opposition to the web? This stems from the principle that the web is axiomatically defined as an open system, where the underlying technologies are resistant to the centralization of control, where the protocols and formats are extensible and malleable, and where the power to effect change is shared and distributed. The DNA of the web is one of ceding control, and of learning to work with, rather than against, the collective wisdom and power a larger community.

Whereas a development monoculture, a centralization of control, and a tight grasp on the ability to change and adapt, all stand against these basic ideals, and give rise to the forces that, given enough time, will erode and eat away at any temporary advantage gained.

A violation of these principles does not necessarily make for a bad technology, but it does make it something other than the web.

And finally, and this is so key, the answer isn't to try to destroy the innovation in Flash, Silverlight, and others. Instead, the biggest win will be for us to make technology from those worlds into the Web itself. If we can do that, I think it will be a win-win, and we will have a much better Web to show for it:

But the call to action here is not to go and try to fight the disruptive technology. On the contrary, the ideas are sound and the improvements are very much needed. No, the call is to discover ways in which these ideas can become a part of the web, rather than working to tear it apart.

I do not want to see ambitious attempts like these fail. Just the opposite — I want to see them succeed. But success on the web requires a different kind of DNA, the type of DNA that is difficult to adopt when one’s attention is focused on fighting the web itself.

Alex Russell has another one of his insightful posts titled Power and Authority. He talks about the core tenets and then ties it to the W3C, and who we should be "blaming" for the slow upgrade of the Web, and it requires a look in the mirror:

As a case study in putting your faith in the wrong idols, you can’t do better than posts like this which “blame the W3C” (via Molly). Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. I’ve written about this before, but fundamentally you can’t blame the W3C for failing to act because it’s not the W3C’s job to act. An MBA should be able to tease this out a bit more effectively – any decision only requires that you have answers for five questions: why? what? how? when? who?

Answering these for pushing the web forward is straightforward, even on a simplistic level:

• Why?: it’s too hard to build reasonably sophisticated interactions with current web technology
• What?: new tags, JS and DOM APIs, CSS syntax, and renderer support for all of the above. Eventually, a spec or five reflecting these new technologies.
• How?: we could try asking the W3C to do it, but they don’t have any power. When they’ve been left to their own devices, the W3C has failed. Miserably. Over and over and over again. Instead, browser makers should introduce new stuff and then agree to agree on it (via the W3C or similar organizations).
• When?: introducing new features in any given browser seems doable in short-order. In the case of Open Source browsers, the answer is “as soon as someone decides to invest in them”. Competition has even spurred Microsoft to some level of action. The likely time-scale for new features over all, though, appears to be on the order of 5+ years. That’s clearly not soon enough.
  TODO: investigate ways to speed this up.
• Who?: browser makers and others in a position to affect the code that goes into the renderers we use.

Figuring out “how” leads you directly to “who” in this case. The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. The “web standards community” has made it clear that they’ll need the imprimatur of some authoritative body where agreement can be forced, but that hasn’t kept the browser vendors from taking the initiative there, either. The big, open questions then center around how the “web standards community” can make enough room for renderer vendors to try out new stuff, since that’s how we get new things. Demanding agreement on what to do before trying it out demonstrably doesn’t work, so it’s then imperative that there be a mechanism for the web to iterate prior to standardization. In fact, I’ll argue that this is now the biggest reason that Paul Ellis isn’t getting the improvements he wants out of the web: there’s no mechanism in place by which any browser vendor can take significant risks without incurring the wrath of a swarm of WaSPs, or worse. Attempts to even begin to lay the groundwork for such a mechanism have been shot down forcefully by may folks who, like Paul, view “fixing the web” as the W3C’s job.

Standards bodies are animated only by the needs of industry to reduce costs by forcing vendors to agree on things. Like Open Source, they can act as a back-stop to the monopoly-creating power of network effects by ensuring that the price of software commodities eventually does reach zero. In this context, then, the W3C’s only effective function is to drive consensus when visions for how to go forward diverge or lead down proprietary ratholes. Asking the W3C for more is the fast path to continued disappointment.

The W3C is just a sail and all sails need the wind to function. You can’t blame the sail for the wind not blowing.

Michael Mahemoff has a nice little post on the rebranding of JavaScript. It kicked off when he was listening to Steve Yegge on rebranding:

He talks about how languages are branded, e.g. “Java” is enterprise. One of his main points is that brands are “const identifiers”, i.e. it takes an entire generation to change brand perception, so it’s often more effective to simply re-brand. e.g. GTE had a poor brand, so they tried a self-deprecating ad campaign, which backfired, and subsequently re-branded to Verizon.

He then mentions Javascript has a branding problem, because it represents “browser” and “toy language” and “damnit, I gotta learn Javascript” and it’s the language no-one wants to use. He also notes the name itself isn’t great either, nor the rhino imagery. (I’m not sure why Steve assumed many programmers would associate Javascript with rhinos; the Rhino product and O’Reilly cover weren’t really promiment enough to do that; rhino ain’t camel!).

But, wait a minute, didn't we already have a rebranding?

Javascript has already been rebranded. In fact, I’d go so far as to say “Ajax” was one of the most successful rebrandings in software history.

Although technically Ajax != JavaScript, and the rebranding is really DHTML, he is right. Ajax rebranded the Web, and we have all benefited from it.

I also think that this is just the beginning, and we haven't seen the best of the Ajax revolution yet.

A couple of posts from my personal land that are related to the Ajax world:

First up, I am building an application that uses some canvas and ran into an issue handling events which sent me down a merry path that took me through: initMouseEvent, error fun (Component returned failure code: 0×80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.dispatchEvent…..] ), tabindex=0 (thanks Alex), and finally Event.stop(e).

It reminded me of how much I have forgotten, and how debugging can be too hard for Ajax applications. The good news, was that the solution was simple, and the event system does have some very nice properties.

Secondly, some folks tried to make a story out of Passpack adding an AIR application, but we quickly saw how they ended up with both an AIR app, and Gears support in their browser based application. I talk about how this is a valid choice:

I also expect to see more joint applications. Gears functionality is working into HTML5 the standard, which will end up in WebKit (as Apple is great in that regard), and AIR uses…. WebKit as its renderer!

I really hope that AIR will be able to bridge to those APIs, and you get the best of all worlds. I would love to use the Workerpool API from within an AIR application that is doing a lot of JavaScript work for example.

The Passpack team also announced a new open source Host-Proof Hosting Library that has a lot of nice encryption routines packaged up allowing you to:

Webmonkey was a great resource for us when we the Web took off, and it was a shame to see it die out. Today we saw that Webmonkey has been re-born as Conde bought it back and put the content back online.

We have also republished the bulk of Webmonkey’s vast library of tutorials and reference guides on a wiki. With very few exceptions, every page in the tutorials, reference and code library sections of the site is publicly editable. We’re using MediaWiki’s open source software to host the content.

Some new things you’ll notice:

* Articles can be tagged and rated.

* Each page has its own backchannel for comments and discussion.

* Registered users get profile pages where they can talk about their projects and list the sites they’ve built.

* We’re still in the beta phase. Webmonkey is, and will continue to be, a constant work in progress. If you run into trouble, check the FAQ or drop us a line. We’ve set up a wiki page for bug tracking, so if you see something that doesn’t quite look right, let us know.

Welcome back. Now you can join the other Web monkeys out there (from Tamarin to ActionMonkey).

There has been a lot of noise revolving around Ext JS and the open source license decisions. Under the original license (LGPL-ish) many thought that it wasn't actually an open source license at all. Jack changed to GPL last week when he announced version 2.1, but others have been upset with views on forking the old code-base.

I have publicly tried to stay out of the discussion, but today Jack published his thoughts and timeline, as well as frustrations with personal attacks.

This is all such a shame, as Ext JS is great stuff, and I wish that Jack could be spending him time on building more great functionality, and growing his business. I am sure these debates have taken way too much time and energy.

Here is the history from Jack's point of view:

• For 7 months I wrote yui-ext full time from my home, gave it away under a BSD license and loved every minute of it. There weren’t many donations and no official support from Yahoo. With my third child due, and savings running low I had to find a way to continue building what was now changing to Ext JS and also find a way to earn a living from it.

  At this time I contemplated switching to a strictly commercial framework. I openly discussed this decision with the community in the Ext forums. If you want to read the discussions, they are here:

  “Official Commercial License Input Thread”
  http://extjs.com/forum/showthread.php?t=2194

  “Official Open Src License Thread (Commercial License Part 2)”
  http://extjs.com/forum/showthread.php?t=2253

  In the end, after much discussion with the community, I decided to go to the LGPL.

• Shortly before 1.0 is released, there numerous Ext “clones” started popping up that were hacking Ext themes, css and other resources from 1.0 - before we had even released 1.0. Here I had 4 new themes for Ext JS 1.0 that I had spent countless hours working on (I am not a great designer) and what could now be considered competitors were already using it before I even have a chance to release Ext 1.0.

  That’s why the proprietary license on the “Assets” (CSS and images) was introduced in Ext 1.0.

• Ext JS 1.0 is released under the LGPL, minus the Assets license as mentioned above. Shortly thereafter 2 major publicly traded corporations (names withheld) embedded Ext JS into their development frameworks. With no mention of Ext JS except in credits files that no one ever saw. No support for all the work that had been put into the framework. Neither one of them even contacted us. How can that be possible? Can they do that? How can we compete with them taking such a large chunk of our potential customers? These are the questions I was faced with and so began my “Intro to Business 101″.

  The next release of Ext JS was released under the Ext License, to serve as proxy to the LGPL and add the additional “no framework/toolkit” restriction that was present until 2.1.

Then things got public:

• This blog post comes out on CNET out of nowhere:

  http://www.cnet.com/8301-13505_1-9878693-16.html

• Alex Russell publicly bashes the Ext License on Ajaxian (sorry no link, I could’t find it) and then continues his attack on the license with me personally over email. He then follows with this blog post:

  http://alex.dojotoolkit.org/?p=654

• Matthew Garrett decides in his infinite wisdom to completely disregard our Ext License or Assets license:

  http://mjg59.livejournal.com/84586.html

• Dion Almaer of Ajaxian privately informs us of concerns he has about the Ext License. His points are very clear and sincere and he is only interested in the open source community as a whole.
• Several private conversations were held with customers regarding the license, spurred by the links and discussions above.

Then Jack talks about some personal attacks, which I won't go into here.

I really hope that this can be worked out, and we can move on. The last thing that Jack, the Ext community, and even the open source JavaScript community needs is for this to go forward. It needs a quick solution, and I think that a message about the past code base can take care of this.

This reminds me of my old days running TheServerSide. These kind of situations happened pretty regularly. Controversy was the norm, especially with characters like JBoss around... oh and CocoBase brought a lot of hilarity too with their fake legal stupidity.

Anyway, I have been very happy to see that Ajaxian hasn't had the same level of controversy in the Ajax community as I saw in the Enterprise Java one. Controversy is great for page views, but life is too short. I hope that our community stays strong and united around the simple goal:

Let's grow the Open Web. The bigger we grow it. The bigger the pie. And, then we all succeed.

Many of us use the term "Open Web", yet what does this actually mean. There isn't a Wikipedia entry on it yet. When you start to think about it, you may be surprised to find out how hard it is to pin down. It is HTTP, HTML, JavaScript and CSS? Brad Neuberg argues that they are just technologies that right now happen to implement the core philosophies behind it in his opinion piece What's the Open Web and Why Is It Important?

• Decentralization - Rather than controlled by one entity or centralized, the web is decentralized -- anyone can create a web site or web service. Browsers can work with millions of entities, rather than tying into one location. It's not the Google or Microsoft Web, but rather simply the web, an open system that anyone can plug into and create information at the end-points.
• Transparency - An Open Web should have transparency at all levels. This includes being able to view the source of web pages; having human-readable network identifiers, such as URLs; and having clear network entry points, such as HTTP and REST exposes.
• Code Hackable - It should be easy to lash together and script the different portions of this web. MySpace, for example, allows users to embed components from all over the web; Google's AdSense, another example, allows ads to be integrated onto arbitrary web pages. What would you like to hack together, using the web as a base?
• Open - Whether the protocols used are de-facto or de-jure, they should either be documented with open specifications or open code. Any entity should be able to implement these standards or use this code to hook into the system, without penalty of patents, copyright of standards, etc.
• From Gift Economies to Free Markets - The Open Web should support extreme gift economies, such as open source and Wikis, all the way to traditional free market entities, such as Amazon.com and Google. I call this Freedom of Social Forms; the tent is big enough to support many forms of social and economic organization, including ones we haven't imagined yet.
• Third-Party Integration - At all layers of the system third-parties should be able to hook into the system, whether creating web browsers, web servers, web services, etc.
• Third-Party Innovation - Parties should be able to innovate and create without asking the powers-that-be for permission.
• Civil Society and Discourse - An open web promotes both many-to-many and one-to-many communication, allowing for millions of conversations by millions of people, across a range of conversation modalities.
• Two-Way Communication - An Open Web should allow anyone to assume three different roles: Readers, Writers, and Code Hackers. Readers create content, Writers create content, and Code Hackers create new network services that empower the first two roles.
• End-User Usability and Integration - One of the original insights of the web was to bind all of this together with an easy to use web browser that was integrated for ease of use, despite the highly decentralized nature of the web. The Open Web should continue to empower the mainstream rather than the tech elite with easy to use next generation browsers that appear highly usable and integrated despite having an open infrastructure. Open should not mean hard to use. Why can't we have the design brilliance of Steve Jobs coupled with the geek openness of Steve Wozniak? Making them an either/or is a false dichotomy.

He goes on to talk about the importance of the Open Web, and details of a talk that he is giving at the Open Web Vancouver conference.

What are your thoughts on the Open Web? What do you agree or disagree with in Brad's thoughts? I am curious how divergent we all are!

Robert O'Callahan has a nice recap of BaaCamp down under.

Robert talks about various talks that he went too, for example on AIR which touted:

features that can and should be provided by browsers too, possibly via extensions like Gears for the laggards, ideally via standard APIs like HTML5.

Robert feels like there is still a bit difference between the browser and Flash:

There are few philosophical differences between AIR and the browser. The biggest one is that AIR doesn't sandbox apps, so users have to make a trust decision to use an AIR app. I don't know how high a barrier that is to AIR app adoption; I hope it's a high one, because users should be reluctant to let applications abuse them! Another, related difference is that AIR lets apps escape browser chrome such as the forward/back buttons and the address bar. I can see that app designers would love that --- yay for integrity of artistic vision! --- but I'm not sure users would. Browser navigation (back, forward, bookmarks, addresses and autocomplete) is a powerful mental model that is not only deeply entrenched but is actually very useful.

He then goes into detail on the IE 8 features, and finishes up on bug hunting with Firefox 3. I have been using that on the Mac, along with Webkit, and I am impressed. It is fast, and doesn't churn the memory as much. I couldn't use Firefox 2 anymore!

Over on my personal blog I kicked off a series of articles on some future APIs that are on the table for Gears, and how in my opinion, Gears is mistakenly seen to be about "offline", when that is just the surface.

I started off by discussing the Image Manipulation API, "is a module to give Javascript a way to resize, crop and compose images together on the client side. This will allow, for example, images to be resized into a web-friendly format before being uploaded to a photo album. Another use is for composition of images together as an efficient alternative to server-side composition or CSS layering. Yet another use is for basic photo editing - a user can edit a photo with instantly applied changes before uploading it to the server."

Then I went on to the Desktop Shortcut API where you can:

The Location API provides a means