Time is the only truly non-renewable, non-discoverable resource.  For any other physical thing, one can imagine a future in which such a thing is renewed, discovered somewhere out there, or produced from something else, but time can only be conserved.  It is this focus that has driven me to keep getting better as both a businessperson, manager, and programmer.

A few years ago I realized that I had the technical ability to build whatever I wanted, perhaps not as efficiently or elegantly as more experienced developers, but I could get it done.  I got pretty complacent for a while, and I lost the understanding of why I am developing software.  It was then that I fell in with a bunch of user experience people after the bubble burst and I had to find a normal job.  I was building online classes for the Academy of Art University.  I met some of the most amazing graphic and user experience designers I have ever worked with during that time.  They exposed me to another function of code, one that has stuck with me and has become part of my technical focus, that code could provide a better interaction through transferring some value to an end user.  Namely, a well-designed efficient user interface could reverse the clock as it were for some users.  A good UX design could give time back to the user, time spent learning an arbitrary interface with no organic mapping, no feel, time spent being made to feel ignorant, all of that could be given back to the user of the software.  Bonus points could be awarded if it were to make something that the user wanted to do more efficient, such as finding a good restaurant, or figuring out who in the organization was the best person at solving their specific problem.

I became a user interface builder, hoping to figure out some of the magic of user experience design, as this is clearly the most important part of any application.  I got pretty good at it, and being able to make users smile was definitely what kept pushing me to get better, but once I got married, and had kids, I became one of those users, the ones with no time, the ones who wanted stuff to just work.  Some interesting changes began to occur.  The first was that I ditched more complicated tools that provided less value for the time invested and started using Apple computers and software, not because I couldn’t understand the PC stuff, but because I didn’t want to waste the time on making it work the way I wanted it to when I could be spending time with my wife and kids instead.

As I rose in various organizations, I found an entirely new level of wasted time, work consisted of aimless meetings that propagated like a bad virus, developers didn’t document or test their code, leaving me to have to read for hours just to figure out what the code path was in some cases.  In other words, while the goal of the company was to build products to provide value to their customers, that wasn’t what they were spending the bulk of their collective time on, it was just in organizing itself, or fighting divergent agendas.

It is this last set of issues that has once again given me purpose.  I want to give hours back to working people through the code that I write, the teams that I lead, and the businesses that I associate with.  I believe that it is through good internal processes, healthy channels of communication, and heavy use of technical efficiencies that I can give time back to the people that I work with.  I believe that it is through developing software for regular working people at all levels to remove obstacles and to enable them to accomplish more in less time that we can all spend more time with our families, playing video games, developing new businesses or technologies, or just plain loafing around, whatever makes you you.

Part of that is a focus on making every user interaction as excellent as possible given the technology available, and the rest is to choose to build software that has a direct and measurable impact on organizational efficiency.  Some people say that having a family and responsibility slows a developer down, in my case it has sped me up.  I have learned how to delegate, how to focus on what is important.  Most importantly, I have figured out how to execute.  I think that I have learned how to spot time wasters and find / build ( or ask someone with more experience ) solutions to get rid of them.  Only time will tell if I have actually got a handle on this, but I think with some good strategic alliances to shore up my blind spots, I have a good shot at building software that can help keep our time expenditures down.  Time saved is time saved, no matter how difficult it is, its worth making every effort on this front.

The above questions are a devil of a problem that creeps in fairly suddenly and often without announcing itself.  The result is clear enough, most of us have seen it before.  Reduced output, fewer, and fewer new product ideas bubbling up, or at least, fewer and fewer product ideas bubbling up to the executives.  No risk taking from anyone in the company, way too much time spent in meetings.  Most of the prevailing wisdom is that you just have to stay small, do not get large.  I completely agree, that it makes sense for companies to stay small if possible, but sometimes you can’t stay small.  I would argue that it simply isn’t possible for a company like Facebook to be small, the demands and requirements from their customers require lots of construction and cohesive solutions.  What should they do?  Should they break themselves into separate companies? Breaking up is typically not a solution that makes sense.

I’m not certain that I have the answers to these questions either, but I have experienced these issues in most of the places I have worked.  In all of these places, the intent is always good, people want to overcommunicate, they want to make sure that everyone is heard and that all ideas are considered.  Being good listeners and accommodating a marketplace of ideas are what all of the management books talk about.  The issue is that when a company gets too large, the sheer time it takes to do that becomes prohibitively expensive.

The solutions that I have seen put forth, and I intend to use is initially to keep teams small and allow those small teams to retain ownership of some critical pieces of the solution.  In addition to that I want to keep people building by allowing time to develop along their own relevant interests and for them to sharpen their pitch skills by presenting to other teams and gathering feedback.  That will hopefully help the teams grow, and will make it clear who the people with leadership skills are, and allow them to try and occasionally fail in a safe way that keeps the company moving forward.

Having small teams and keeping specific responsibility residing within those teams will help maintain accountability, minimize meetings, and reduce communication overhead, but it requires a lot of work from the vision holders.  Not only do they have to have a stellar and clear vision, they have to have communicated that clearly to each and every person working in the company.  That works fine for a very small company, but when you get larger it is harder and harder to make sure that every understands the goals and dreams of the company.

Funny enough, most of the scaling techniques that are applied to large application servers works well in scaling engineering organizations.  Shared nothing, separation of concerns, etc…  The issues begin to crop up in organizations that are not engineering organizations, and among groups who are not highly intelligent, skilled and motivated like engineers.  I still believe that a company can successfully scale with lower skilled staff, but it requires a concerted effort to decentralize the operations to the point where each small group operates in a largely independent fashion and the company still achieves its goals.

I believe that the answer lies * of course * with technology.  Were senior management to embrace some of the social communication techniques that most teenagers employ, managing large groups of independent teams wouldn’t prove to be so daunting and they could directly provide leadership to a wider group.  It would require for them to work non standard hours, and work longer ones where they are more accessible, but I believe that it should be possible to run a highly efficient and decentralized organization where everyone is actively contributing.

* Update *

Ben Horowitz wrote a great post on how to scale a company.

The funny thing is that much of what is driving my decision is the desire to have my applications have data and interfaces that are available everywhere, mobile, web, desktop, etc… aka, the original promise of the web.  Using local caching, the JavaScript key/value store, and the database will help to allow me to provide a compelling disconnected use experience.  The code that I write will be useful across all of the platforms that I use.  The one caveat that I am making is that I need to focus on one browser, or approach, and for that WebKit based browsers seem to be the logical choice.

Now I realize that not all of my application concepts will be possible with HTML5 and JavaScript, however this recent thought experiment I realized that most of the features that I would have normally insisted needed to be done natively can be done with HTML5.  The biggest issue that I have run across is the 5 MB limit on database sizes in Mobile Safari.  I know it was there in iOS 3.x, I don’t think they have lifted this in the current OS.  The other issue is the forced UTF-16 encoding of characters.  While I understand this technically, it makes it difficult to store data larger than 2.5 MB on a device in the SQLite storage available to JavaScript.  The approach taken in desktop Safari, where you can ask the user to increase the available size if your database creation fails is a much better approach.

Another interesting pattern that I see emerging is that of utilizing HTML5 as the UI tier, and establishing the business logic and control structure behind a HTTP server that would expose additional native functionality to the HTML5 app.  The benefit here is that your local server implementation could match the remote server implementation, such that your client APIs could remain consistent.  This seems to me to be the best architecture for minimizing the work involved with porting solutions across platforms.  I absolutely love Cocoa and Objective-C, I enjoy the concepts behind the Android APIs, while despising Java’s syntax, and I think that .net is pretty cool as well, however when it comes to getting applications deployed to the maximum number of users in the leanest manner possible, I think it makes sense to leverage the web heavily up front, and then backfill the native implementations as necessary.

The Awesomest Phone Ever

I had this problem… whenever I would walk into my house with my Nexus One, and it connected to the internet, my router would slowly die.  I would have to unplug the router from the power and plug it in again to fix it.  I think I’ve found the solution, at least for my DI-624 wireless – N router.

It turns out that there must be some problem with the Nexus One handling TKIP encryption, or at least with the way the D-Link DI-624 is sending it.  The fix for me was first to fix the router to channel 11.  This fixed some other issues with netgear equipment a while ago, secondly, and most importantly, force WPA2 encryption on your connection instead of auto or (WPA or WPA2).  You can try setting the encryption to AES only, but that didn’t work for me, it was only once I forced WPA2 that the issue went away.  I am running mixed B-G-N as well.  Now my Nexus One no longer kills the router.  I am not sure whether or not my PSP will work now on my router since I remember it not supporting WPA2 a while ago, but it may be enabled with the current firmware.  All of my other stuff can connect over WPA2 so it shouldn’t be a problem for me.  If you have some stuff that can’t use WPA2, then getting another router might be the best option.

The fundamental issue is that people who have had success in the past have a hard time considering that what gave them the success in the first place is not likely to continue producing success.  As an example, existing business processes for tracking hours is typically to have each individual estimate ( after the fact ) how many hours they have worked on a specific project on a given day.  The current method, as best as I can tell, is for engineers to estimate via points how much time it takes to perform a given programming task and do a post-mortem if the task takes more points.  But this daily reporting is eliminated, which is a better, more efficient process.  It is also one that revolves around trusting the engineer.

Another example is that it is not uncommon for developers working on a project to push out information about that project to the public via Twitter.  Even down to the level of code commits.  For the users of that product, they can choose to follow the official company feed or they can decide to follow their favorite engineers.  The concept of privacy has been diminished to a large degree in modern companies.  The benefit of this is that users become partners, not only in the debugging and troubleshooting process, but also in the development and planning phases.  You can find, for just about any startup, engineers posting what features they are thinking about and feedback from engaged consumers, either providing amplifications, their own feature suggestions, or strong negations about where the company should be spending its precious resources.  In such an environment, extreme secrecy is a huge liability.  Likewise, within corporations, keeping the status of the company, and what the customers are saying about the products from the engineers is disastrous to engineers’ morale, as well as harmful to the level of understanding of the executives as to what is happening within the company.  In more modern companies, the developers are treated like the partners of the product managers and the executives.

I think most of the fallacy in this regard comes from the manufacturing metaphors that have dominated the majority of the corporate worlds’ view of software development.  When I look at the waterfall method, and some of the organizational structures around engineering departments, what I believe is being attempted is to reduce development to an assembly line with shift managers and the like.  This can’t really work for software engineering  for many obvious reasons, but probably the most obvious is that programmers, even self taught ones have more in common with lawyers than they do with assembly line workers.  Assembly line workers can highly optimize their tasks due to the extremely specific level of requirements, as well as the consistency in their tasks.  Developers, and the product people working with the developers, almost never have requirements detailed enough to complete the given task.  Similarly, developers have a wide latitude to perform tasks in different ways as tools, managerial practices and or technology change, which is nearly daily at this point.  While most manufacturing systems change once every 20 years or so, a particular manufacturing worker can master their skills and have that be applicable for their entire career.

Attorneys are typically highly specialized, and operate with a widely varying set of rules, like software engineers, they need to parse and execute on sets of specifications ( laws ) to the benefit of the person contracting or paying them.  Their interpretation of a given law may not always be standard, but if it achieves the intended goal, then they are considered successful.  This interpretation in law as in software engineering is more of an art than a science.  This variability in going about the job from day to day creates odd management challenges that are being exacerbated for software engineering management as the millennials come into the workforce.  To a large degree, having fewer, more productive, empowered engineers is obviating the need for traditional engineering management.  Of course someone needs to be accountable, but if you have small groups of developers, the group can be accountable for a specific feature.  Small groups of engineers make it easier for them to triage why something went wrong and prevent it from happening again.  Failure is part of the software development process, but it doesn’t have to be a destructive part.

Millennials, and their immediate predecessors appear to be very comfortable with dealing with this sort of environment, they do not seem to need clear guidelines or even a clear goal.  Many software projects that utilized the “agile” philosophy, which even itself is becoming dated, typically manage the process with smaller tasks that everyone in a company seem to be involved in creating.  The new crop of engineers seem to be more comfortable with the self-taught, with it being more about what you can show than what you have done.  Resume’s appear to be losing their value relative to a solid portfolio of open source work and products.  My advice to people in high-school and college about to enter the work force is to work on a portfolio of applications first, or contribute to some open source projects, even more than attempting to get an internship at some big company.  If they can make some money off their portfolio, all the better.  The teams appear to be more distributed, with wide acceptance that each individual is working on their own business ideas not related directly to the company’s goals, or product portfolio.

All of these things fly in the face of the traditional command an control structure, however I believe that it will speed the pace of innovation, and improve the overall level of developers.  Smart companies will harness this multitasking and openness and provide avenues for their developers to contribute new products under a “labs” or a “demo” banner, even if they have nothing to do with the products that the company makes.  These companies will not mind as one of their “labs” projects earns more than their flagship product, and will provide the creator of that product a team and budget to see how far they can go.  That will rapidly become the only way to retain talent as the cost of starting a business online continues to drop.  Executives at these companies will treat their developers as peers in strategy as well as in the software development lifecycle.  It will become clear that this method of structuring a business is correct when not the one, but the many startups offering services begin to completely demolish the incumbents.  It is going to be an interesting ride… are you ready?

While there is a partial-workaround, and the fix was a two-line change to a single class, it is still what I consider to be a severe bug.  As soon as a customer let me know about it, I fixed it and submitted it to Apple, emailing wherever I could to try to get the fix deployed to the App Store quickly.  I am super grateful to my customers for letting me know right away that there was a bug in the update.

I guess what I really want to say is that as a one-man shop, especially one with a day-job, it is extremely difficult to move quickly.  The approval process makes it extremely painful to keep short release cycles and iterate as I like to, because there is a risk that you will have a severe bug.  On the web, and elsewhere, recovering from this is pretty easy, just push an update, boom everyone has it.  With the App Store I can’t, since the review process can take a while, and while you are waiting, your ratings and reviews get destroyed.  Very few people go back and update their one star reviews after you have fixed their problems, so your ratings are unrecoverable.

So I am going to slow down the cycle of releases,  and allow myself adequate time for rigorous regression testing.  My hope is that this should improve the quality of each release.  I think this is Apple’s intent and desire, and maybe they are right.  As for me, I have learned my lesson, this is shrink wrap, not web development, and I will think about it that way.  I’m sorry for anyone who is experiencing a hardship due to this bug, and I hope the fix is approved soon.

Remember, when the first iPhone launched, there was just the iPhone plan, and the only choices that customers had to make was how much extra to pay for SMS, which sucked but at least it was understandable.  Now, trying to explain to regular people what will happen if they buy the iPhone HD is nearly impossible.  When I told my wife about it, not technical, she said, “but wait, it was supposed to be unlimited.”  It doesn’t matter if the cap is high, as soon as people know there is a cap, they will change their behavior.  They will start to think, maybe I should wait to look up this site until I get into Wi-Fi, or maybe I shouldn’t watch this YouTube video, or how many kilobytes per second is the streaming on this h.264 video, all way too complicated.

Going from bad to worse, we were on the verge of a new age for the internet with plentiful, high speed data everywhere.  We were going to start seeing a new class of always connected applications, able to provide real-time data.  Consumers are likely to start self-restricting their mobile data use unless they are on the few and far-between Wi-Fi hot spots.

There is a class of argument along the lines that AT&T was drowning with the amount of data its consumers were using and that no carrier could keep up with providing quality service for the prices they were charging. I can buy that, but the solution is simple, instead of complicating everything, increasing ETFs, and other stuff that is hard to understand for most people, just raise the price of the iPhone plan to $99.99 and give unlimited everything.

Contrast this to T-Mobile, who recently re-iterated that their unlimited was really unlimited.  One could argue that they have fewer customers and can afford to have more aggressive pricing.  That is true, however to the end user, unlimited is unlimited.  Unlimited is better than limited.  It is simple to understand.  I am very glad that I bought a Wi-Fi only iPad, or I’d feel like a sucker who got baited and switched after Steve Jobs got on stage and announced a “breakthrough” data plan for the iPad.  A 2 GB capped plan is not breakthrough, it is hobbled.  The iPad is designed to watch video, stream audio and in general consume the hell out of bandwidth intensive content.

Basically I’m glad I terminated my AT&T contract when I did.  My iPhone 3GS makes an awesome iPod, my iPad can take its place, I will be able to use my Nexus One for tethering when Froyo comes out if T-Mobile does what I expect and make it free.  AT&T’s crap makes the next generation iPhone look less attractive, since after all, the shine wears off on any new technical gadget, no matter how wonderful, but you are stuck with the crap contract.  T-Mobile also one-ups AT&T by offering attractive no-contract rates if you want to just buy your phone outright.  When the Nexus Two, or the dual-core Snapdragon HTC Scorpion or whatever comes out, I can just save up the money, buy the phone, slap in my SIM card and away I go, I don’t have to wait for 2 years.

The cell phone industry ought to be ashamed of itself for what it is doing.  Even with crappier cell service, which is getting better, T-Mobile is a far better carrier than AT&T.  At least they don’t bait-and-switch their customers and partners with half-truths and complicated one-off deals.  If this doesn’t make people look around for an alternative carrier to AT&T I don’t know what will.  You can get overpriced, horrible service, not be able to make calls, not be able to use the data you are paying for, not be able to get out of your contract for a fortune, and still have to pay large amounts each month for garbage service.  What happened to the model where the business didn’t take their customers for granted, where they actually did things to be better than their competition?  Why are we stuck in the US with carriers who just want to squeeze their customers for every penny while providing as little service as possible.  I don’t understand what is good about AT&T’s price changes, and I hope they don’t set a precedent for other carriers.  If so we may find ourselves, in this country, at the far back of the line as far as wireless connectivity goes.

For about the past 20 years or so, computer stuff, anything digital really, has been produced primarily by the geeks at Microsoft, and later by various open source geeks around the world.  It was reflecting their world view, that everyone ought to be able to tinker, and that they might want to.  This caused the severe amounts of confusion that people have had for years.

It would appear that now that consumers have a clear and viable choice in Apple and the iPhone that they are choosing, in droves, really, the closed app store based system.  It would appear that consumers would prefer an app store to the open web, an individual coherent vision to multiple pieces of different developer’s visions of the optimal way to do x.  As Apple likes to put it, they want an appliance, in which applications are just another type of content, and all methods of doing anything are consistent.

I would say that consumers have chosen that, but not because Apple always provides a superior method, or that they like being closed an limited,  I would say that it is because Us, as geeks, have not done a good job of providing clear and usable alternatives.  For developers and geeks, configuration and making tons of choices are just table stakes for getting our devices and software working exactly the way we want them to work.  We have a difficult time creating things that violate the ability to choose a different way.  Part of that is that most of us never have the hubris to think that we can decide for others how to do a given thing, or which thing to choose.  But that is exactly what makes Apple more powerful than Google to the consumer.  Google is catching on, but in a way, at the same time they just don’t get it.

I, personally, understand and prefer many choices.  I like Mac OS X and Linux, particularly because there are so many different ways to set things up, the 3rd party developer community, around the Mac especially, have done an amazing job of filling in the usability gaps that Apple has left.  Should users choose these productivity enhancers, Apple has wisely seen fit to let the 3rd party devs keep doing their thing.  The problem with Android, and the internet in general is that most people are not like us.  They don’t want to seek out and try 5 different text editors and window managers, and text expanding solutions before finding the right one.  They want to just use it most of the time, and they would prefer if the base implementation didn’t suck.

Geeks, and Google, we would prefer to just let the base interfaces and systems suck, since our partners are either going to replace them, or augment them.  That is exactly what shouldn’t happen.  Technical solutions should be like European Socialism… The government provides a generally acceptable set of services that everyone pays for, but it is possible to get better solutions.  This provides something of a floor for service providers.  Likewise, if you are developing a music solution for example, provide a playback solution that works with it first, then give the ability to plug into other services if the user prefers.  That way, they aren’t left hanging initially.

Where I get frustrated with Apple, and where I continue to choose Google’s services, even they are less usable, are that they do not give me the latter solution.  They provide a kick-ass initial implementation, but when I want to go and replace or augment it, particularly around the iPhone ecosystem, there are no options, in fact, they go out of the way to defeat any other option.  If I wanted to use Apple’s music purchasing service, but I didn’t want to use the iTunes application, I am SOL.  Apple feels that they make the best music playback solution as well as the best service.  For some they may, but for me, I would much rather use AMAROK or something else to manage my music, inferior or no.  If I chose the other way, I might want to use Amazon’s MP3 service for buying, but iTunes for managing.  Apple should make that easy for me.

At some point, geeky companies like Google, and to their credit, they are starting to, need to create good baseline solutions that run up to, but stop short of competing with other products and services that are auxiliary to their primary product.  Apple needs to accept that people may occasionally choose to do their own thing and allow them to.

I do not buy the assertion that in order to provide a cohesive solution you have to block all others.  I feel that a system can be aesthetically pleasing and useful, as well as permissive.  Karmic Koala I think gets really close to being there, but there are still too many places that I can get into with the OS where regular users would go WTF?!!?

This is why I am continually working on a new OS that as an ambition would combine the completeness and ease of use of the Mac OS, but honor the internet, as well as user choice.  They are not mutually exclusive, and the only way to prove it is to build something that shows it.  It is a huge amount of work, which is why the only way to do it is open source, but since you have to make clear choices for the user, at least in the initial state, some stuff just couldn’t be committed.

Basically, end-users won’t realize the cost of the choices they are making until they are gone.  In a balkanized, app-store-ized internet, choices will be limited, prices will be high, and satisfaction will be generally low.  That is where we are going, that is the choice that users are making because they can’t wrap their heads around the internet.  It is our fault as geeks, and we are the only ones who can fix it.  The average user is going to pick the shiniest and easiest widget.  There is no reason we can’t make that.

I agree with Joe Hewitt about Cocoa, the framework is awesome, for someone who has been fighting browsers for control of the UI for years, it is like a breath of fresh air.  However, this is true for any native rendering solution.  It is part of what makes it hard for me to go back to developing web applications.  I like JavaScript, but HTML and CSS not so much.  Talking it over with friends, and thinking about it further, I think that HTML5 may be exactly the wrong direction for us to be taking the web in.  Before you click away, this is not some “Apple should allow flash” argument.  I am thinking about this on a deeper level, about the types of applications that we are making today on the web, and some of the issues we are bumping our heads against.

The web has been good at delivering applications with zero-install, as well as presenting formatted documents.  The latter is what HTML was designed for.  XHTML was created because HTML was overstepping its bounds.  Currently I believe, even though native developers tend to look down on web developers, that developing a web application is one of the single most difficult challenges for modern development.  There are multiple languages that one needs to master, each with a different metaphor, syntax, and implementation.  There is overlap between the languages.  There are latency issues, networking issues, lack of resources on the client, these are all incredibly difficult things to deal with in general even with native implementations, the problems with the web exacerbate these issues.

At the heart of the problem is that with native frameworks and systems, you expect for everything to be different as you move across platforms, business stakeholders have an appreciation that moving from a Windows app to a Mac app will be hard, and they will staff up and provide the appropriate resources to do that.  In truth, coding a cross-browser application is no easier, however the issue with web development is that it appears to be easier.  HTML looks like a ubiquitous rendering language, it appears as though it would work exactly the same across the board, but it doesn’t and it likely never will.  JavaScript appears to be the same language across the browsers, but nothing could be further from the truth, it performs, and behaves differently in each.  CSS seems like it would be identical since all browsers comprehend the same syntax, but the same style can appear vastly different across the browsers, and in some not appear at all.

That is the current situation, and we are pressing further into the problem instead of dealing with it.  My opinion is that HTML should be present in browsers as a legacy rendering system.  What I would like to see is a raw vector based rendering engine, similar to the canvas tag, as the browser view that will give me, as the remote agent, the size of the window and the capabilities of the browser, such as audio, OpenGL, Sound, DirectX, etc…  It should also tell me what the origin of the screen is, UL, UR, LL, LR so that I can give the correct rendering directives.  It should send me a list of the languages that are supported, or are enabled by the user, binary, javascript, ruby, python, etc…  Then the browser should progressively download the code and execute it as it receives complete instructions.  The binary stuff could be jitted using LLVM + an appropriate front end, and cached.  The memory addresses could be sandboxed and virtualized.  The user could set heap sizes for the amount of memory that the applications were allowed to use.  Google’s native client is a step in this direction, but it doesn’t go far enough.  Scripting language code could be executed pretty much as it is.  This would allow the frameworks to control everything about the experience, as opposed to the browsers.  Innovation could happen overnight, and browsers would be more responsible for enforcing security policies than rendering.

The benefits of this approach, full on applications could be developed as one stack and would appear on the client as the developer wished.  The performance would be insane, the execution environment would be simplified such that we could develop an adequate sandbox.  Authentication would be up to the developer and would be native, many of the security issues would go away.  One could code their application as code + data to render as pages easily.

What are the issues with this approach, no one has managed to build an adequate sandbox, however as we have seen JavaScript + HTML isn’t really a great sandbox either, there are tons of exploits out there.  The delay in downloading the initial code, although with progressive execution, this should be mitigated.  The biggest issue is lack of crawlability.  This is where XHTML 2.0 comes in.  If your content is available as resources through a service, instead of crawling your app, your content could be crawled.  This would dramatically improve the value of search engines.  If you give an appropriate resource id, the engine could point the user to a URI that would render the content in your application instead of raw, or the crawler could be an application that shows your data in a slightly different format.

I think that native jitted code + data mixed together are likely our future, especially watching how the App Store is taking off with consumers.  Even they seem to be choosing native applications delivered over the internet over web apps.  I think that this is a primitive method of what I am describing, but the benefits to the end user and for the user experience are clear.

A friend suggested yesterday that Palm had bought Be a while back, but in reading further into it, it seems that BeOS is owned by a holding company called Access Co. At any rate, what I hope happens is that HP uses the webOS for some of their media devices.

It is interesting, to say the least, but I don’t know if HP operating Palm as anything other than Palm makes any sense. WebOS is interesting as well, but it really needs to track the chromium project more closely, maybe it is and I just don’t know, but much of the HTML 5 stuff doesn’t seem to be fleshed out really well.