Entrepreneur, executive, and investor; octo-dad; former Googler, now VP Product at

A Road Leading to the Clouds

Whoa. It seems to me only a few weeks have passed since I previously posted on my blog back during those first few crazy days at Palm when I jumped onto the moving train; somehow, it also feels like ten years ago. Being a part of the Palm story has been a whirlwind adventure. And now, that adventure takes a new form.

Starting Monday, Dion and I are leaving HP / Palm as full-time employees but staying involved with HP webOS in a consulting capacity. Our post on the Palm Developer Blog goes into more detail on this transition and look to Dion’s blog for his own perspective.

As for me, “bittersweet” perfectly describes my feelings at this juncture. Working alongside the talented team at Palm has been a tremendous opportunity, and the chapter being written now with HP is ripe with extraordinary potential. Leaving the company of this crew is certainly a bitter cup to swallow.

At the same time, I couldn’t be more excited to be starting a new venture with my good friend and colleague of many years, Dion Almaer. We’ll post more on the details of our new company soon, but we plan on spending our time creating quality software and helping others to do the same. A particular focus of ours will be to help folks realize high-quality mobile and desktop app and web experiences using HTML5, JavaScript, and related technologies.

What a fascinating time of change for our industry! The Web has been challenged as the dominant platform for mainstream consumer software experiences–though the contest with apps is far from over. The predicted mobile convergence (with the desktop) is happening now. Independent software developers are now re-empowered to earn a living at their craft in a new and interesting way–they join musicians, directors, writers, and other artists whose products command the attention of large swaths of the general public. The opportunity has always been there, but now the complexity of so much infrastructure required to distribute those experiences has been swept away (though the trade-off has not been without cost).

While at present we see a diverse set of incompatible software platforms competing for the right to distribute the produce of these new and revitalized app artisans and businesses, history tells us that consolidation of these platforms cannot be far in the distance. Reducing the number of app platforms in the marketplace–the “content formats” of the app world–is unquestionably a good thing for developers in the short-term. However, I hope that we can evolve to a place where the content format and device manufacturer are not irrevocably coupled. When you think about it, the status quo is comparable to a sort of bizarro world where, say, Sony MiniDiscs achieved unparalleled ubiquity but Sony never licensed the format to other device manufacturers.

Of course, this “bizarro world” I described is how the world played out in the last set of consumer software platform wars, but perhaps this time around a large set of developers will choose portable content formats and ensure that competition and innovation thrive for the next exciting decades to come. And hopefully, Dion and I can play a role in shaping that outcome.

More soon.

(* The analogies above aren’t perfect, of course; cut me some slack. 🙂 I’d love to write another post that goes into detail on the similarities and differences between traditional content media and interactive content, etc.)

There’s no better way to start our careers at Palm than by getting reamed by open-source pioneer and legend Jamie Zawinski, one of the driving forces behind the release of the Mozilla source code and someone we’ve talked about in recent months in another context.

While a blog post isn’t the right avenue to talk about all of the issues that Jamie brought up, we’re following-up with him directly and will bring it to a conclusion. We obviously goofed in how we communicated with Jamie, and Dion and I take some of the blame here as our staff had been waiting for us to come on-board to get to some of these items.

We do want to take this opportunity to clarify a few things and share with you a bit about where we at Palm are with our developer program.

Our App Catalog is very much in beta right now, precisely because we want to take time to get it right prior to a full consumer launch. We have been collecting a bunch of feedback from developers and it is helping us prioritize and structure the program. In the brief three months since the launch of the Palm Pre, we have learned a great deal from the community!

We’ve seen some folks assert that Jamie’s case indicates a general pattern at Palm that we don’t really care about developers and aren’t operating in a developer-friendly manner. While we undoubtedly have some work to do here, we hope that people do notice how we treat the “homebrew” community (e.g. PreCentral) and how our current SDK agreement calls out the inspectability and reusability of our own Palm applications. (By the way, several applications from the homebrew community have already made it into our App Catalog.)

While we have yet to finalize and announce our developer program, we hope these points demonstrate our general attitude of embracing developers and empowering them. We’re trying to strike the right balance between locking down our device and making it a free-for-all. Like all great things, this will be an iterative process and we are eager and open to your participation and input to make it better for everyone.

We are sorry that Jamie feels the way he does, but we’ll fix what’s broken and are going to deliver a fantastic opportunity to developers as they in turn help create a fantastic experience to users.

We have a lot more to say on this topic, so watch this space. Dion and I are part of the developer community; we’re listening to what y’all say and we’ll speak up and participate in discussions.

And hey, look for an announcement soon that goes into more details on our developer program.

Do you remember how much the Web used to suck?

Not so long ago, we Web developers would have to constantly educate product managers and other business stakeholders about the limitations of HTML; we would often contrast it with so-called “rich client” technologies.

Over the past few years, we’ve all watched with wonder as these boundaries have disappeared and the Ajax revolution brought us a never-ending supply of rich web applications.

And while Ajax started out as web developers leveraging little-used so-called “latent” browser technologies, browser makers haven’t been sitting idle. Modern browsers are acquiring new abilities at a pace not seen since the early years of the Web–most of which are largely unused by today’s web applications.

Dion and I started a few years back when we like many others felt that a revolution was about to take place, and we’ve been fortunate to be able to chronicle a bit of it as it happened. We feel like the Web is similarly positioned today, ready for another expansion as developers discover and leverage the next generation of browsers.

Bespin Logo

We’ve been fortunate to do a bit of that expansion ourselves at Mozilla with the Bespin project. What Dion and I started as an experiment to see if we could create a code editor on the Web as responsive as the desktop has turned into a full-fledged project team aiming to revolutionize the way the world writes code.

At the same time the Web has been expanding, we’ve all been blown away as desktop computers have somehow shrunk down to pocket size. Clearly a revolution in hardware is taking place and it doesn’t take a prophet to work out that the future of computing lies along this new trajectory.

However, my enthusiasm for this amazing new world is tempered by some unfortunate decisions made by some of the players in this space. It seems that some view this revolution as a chance to seize power in downright Orwellian ways by constraining what we as developers can say, dictating what kinds of apps we can create, controlling how we distribute our apps, and placing all kinds of limits on what can do to our computing devices.


And so as my good friend and long-time collaborator Dion so eloquently explains over at his blog, he and I have taken an opportunity to work at Palm–at the very intersection of these two exciting technology arcs–and we have the opportunity to run Palm’s developer program and to do things quite a bit differently than some others in the industry have done.

Dion and I believe in the Web platform–an open platform that no single vendor controls–and we believe in empowering and enabling developers. We have been honored to work with so many who feel the same way at Mozilla, we will continue to advocate those values as members of the Mozilla community, and we can’t wait to put these ideals into practice in our work at Palm.

Chuck Finley

As prognosticated earlier, the next release of Bespin (named “Chuck Finley”) schlepped out the door this week. One half maintenance release and the other half feature release, Chuck Finley adds a “deploy” command and support for SVN commands while fixing various glitches with the once-shiny-now-lusterless “H. E. Pennypacker” release we put out in late August. The deploy command takes Bespin one step closer to the vision of developing entirely in the cloud and we’re absolutely thrilled to move in that direction.

Kevin Dangoor goes into Chuck Finley’s new features over on his blog, including a look at an enhancement to collaboration that shows you the current location of your collaborators’ cursors (a fancier version of this is coming soon).

Named Cursors

Next up is 0.4.5 “Bubba Ho-Tep”, a planned maintenance release for next week that may gain a few features as well.

Today we shipped the next release of Bespin: the 0.4.2 “H. E. Pennypacker” release. As discussed in my recent “Bespin Roadmap” blog post, H. E. Pennypacker is primarily a bug fix release focused specifically on issues related to the new collaboration engine. The key fixes in this release include:

  • Work towards ensuring that we never lose your data (bugs 511289, 511217, and 511291)
  • You can now export projects from Bespin (bug 511828)
  • Various other stability enhancements (bugs 511125, 512044, 511539, 509496, among others)

We’re now focused on shipping Bespin 0.4.3 “Chuck Finley” which will deliver deployment and SVN/HG commands (right now we have our own VCS commands that map into SVN and HG; we are working on implementing the actual SVN/HG commands you’re used to).

Command-line Only?

In the bespin mailing list, I saw a message or two lamenting that we are too focused on the command-line at the expense of the UI. Take heart, gentle fans. We have plans to implement GUI equivalents for nearly every major command we can think of; it’ll take us a while to get there.

We hope you enjoy H. E. Pennypacker, and I look forward to telling you more about Chuck Finley in a week and a half or so.

Bespin Roadmap

With the recent release of Bespin 0.4 “Stratospheric Stratus” last week and 0.4.1 “Fletch F. Fletch”* on Monday, it’s a good time to post an update on the Bespin roadmap.

0.4.2 “H. E. Pennypacker” – August 26th

Minor release that aims to whack any major bugs reported in the collaboration engine; if we have resources left over, we’ll add support for a subset of native SVN and HG commands to Bespin’s command-line.

0.4.3 “Chuck Finley” – September 7th

Includes a new feature: a “deployment” command. We plan to support SCP (and therefore SFTP and FTP) to start and build up from there.

0.4.4 “Bubba Ho-Tep” – September 14th

Minor release to fix bugs and introduce small enhancements and feature polish.

0.4.5 “Ash Williams” – September 21st

Adds “colorization” to the collaboration engine: the ability to track who has changed what in a file and visualize that in a configurable fashion, probably with foreground or background text color. While this may sound like a minor feature, it actually represents a significant enhancement to our existing functionality.

Also includes “cursor tracking” to show you where collaborators are currently hanging out in the document.

0.5 “Brisco County Jr.” – September 28th

Follows-up with additional social development features, such as:

  • “Live file history”: the ability to scrub back and forth along a timeline that corresponds to the history of the file to see what it looked like at any point since its inception. This is vital for collaboration because undo/redo doesn’t undo changes to the document made by your collaborations; using this feature, you can essentially do this by going back in time to revert a change made by someone else.
  • “What are my friends doing right now?”
  • “What is everyone else in this project doing right now?”


Follow along with us on the Bespin mailing list as we update the community if (when?) we deviate from these plans, and please do give us feedback here on this blog or on the mailing list.

* We neglected to update the UI’s codename label in 0.4.1 to Fletch F. Fletch from 0.4’s Stratospheric Stratus.

Roadmap image adapted from Jemimus’ IMG_2699

Michael Mahemoff recently wondered about whether Bespin will ever have more than one back-end. That’s a good question! We’ve waffled a bit ourselves on the back-end bit. The initial back-end was Java, but we migrated to Python. Michael pointed out that we’d need to solidify and publish the API for alternate back-ends to be viable.

At our launch, we documented the server API, but we’ve changed it a touch here and there since. We need to keep the Wiki up-to-date. But in addition to our back-end, there is MobWrite, which powers the collaboration engine. MobWrite’s protocol is documented, but we’ve altered it a touch and published our alterations as well.

If you’ve an interest in implementing a back-end server, please do let us know and we’ll put more effort into updating the published documentation.

Bespin Collaboration Screenshot

We just launched collaboration in Bespin today; it’s come a long way since the initial prototype we had working earlier this year. That progress is due primarily to the hard work of our own Joe Walker and Google’s Neil Fraser, the latter of which created Mobwrite, an editor-neutral diff-and-paste collaboration engine that Joe integrated into Bespin underneath the beginnings of a set of social collaboration features that Joe’s designed and implemented over the past few months. As Joe mentioned in his blog today, this is but the first step in a journey towards a very social coding experience on-line with Bespin.

With today’s (beta) launch of collaboration, you can now use to check out an SVN or HG project from any public repository, hack on the code with a whole bunch of friends in the same session, and commit the code back to the repository. We’ve tested around twenty sessions collaborating on 10,000 line files and things seem stable, fast, and fun–but before you get too carried away, collaboration is to be considered beta, and you may lose some data while using it until we have a chance to examine bugs filed by the community and fix ’em.

We definitely need to implement some sugar to track cursor positions of collaborators, colorize text according to author, and so forth. Watch for some of this soon.

Here’s to more social, collaborative coding experiences in the browser!

Open Web Tools Directory

Several weeks ago, I blogged about the Open Web Tools Directory, another Mozilla Labs experiment we launched to explore making some sense of the huge and diverse web tools ecosystem. Thanks for taking a look at the site, for telling us about your favorite tools and your own projects, and for all the feedback!

We’ve just pushed out another minor update to the directory, including the more updates to the tools database and some tweaks and bug fixes to the user interface. (We’ve still got more tools to add and will do another update next week.)

So what’s next for this project?

At Mozilla, we try hard to do things out in the open and engage the community in the development process very early. We’re a mission-driven organization and that mission is to maximize the Internet’s benefit to the public, so we like to get the public involved as much as we can in telling us what we should be doing.

Can you help us decide what the next steps should be?

The Open Web Platform

To get the conversation going, let me share our vision for this project. I’ll start with the big picture, and work back towards the Tools Directory.

At some point over the last few years, the web browser evolved from being a way to render hypertext documents and has become an application run-time platform. This new emerging web-based platform has been called the “Open Web Platform” with increasing frequency; I like the name and have used it for the past few years and will use it throughout this post to describe the technologies available to web applications (provided to them by the browser and occasionally plug-ins).


I’m extremely enthusiastic about the Open Web Platform and its potential to liberate: to liberate applications from the shackles of operating systems (e.g., you must own [Operating System X] to run this application), to liberate developers from the tyranny of learning multiple SDKs (e.g., you must learn n entirely different technology stacks to get your app onto n different platforms), and to free users to customize their applications easily and to share those customizations freely (e.g., the Greasemonkey / “user script” vision). As the web platform gains in capabilities, it frees us from traditional unnecessary barriers that sap our productivity and block our progress. I’d like to expound on each of these “liberations”, but it’s a bit orthogonal to today’s theme, so I’ll move on for now and circle back another day.

(Don’t get me wrong: I fully support empowering application developers to chose the platform that allows them to best express their vision and meet the needs of their customers, and I want people to be able to profit from selling software. But I’m working as hard as I can with thousands of other people to make the Open Web Platform be the platform of choice for as many developers as I can. Because when that choice makes sense, we all win. Big time.)


One of the reasons folks call the web platform “open” is that it’s beyond that control of any one person, entity, vendor, government, etc. As a consequence, knowledge about the platform is fragmented. There’s not one resource you can leverage quite like the developer networks of other platforms. There have been some attempts by the market to meet the obvious demand created by this void, but it’s pretty difficult to make money selling developer tools or developer-related services. A few companies succeed at this, mostly at a small scale, but much larger numbers of companies fail.

We’d like to do something about this.

Open Web Developer Center?

We think the web could really use something like an “Open Web Developer Center”, a site where you can go to find integrated documentation for the various browsers and specifications that compromise the platform and learn more about its capabilities, where you can find the tools that can increase your productivity and augment your capabilities, and where you can socialize with other developers.

Perhaps most important of all, we want a place where that helps more people get engaged in influencing the future of the platform in direct, tangible, and meaningful ways–to help realize the vision of the Open Web Platform as the People’s Platform, of the people and for the people.

The Tools Directory

So the tools directory is a first step towards realizing this vision. We’ve got a lot of work to do, but we think the next immediate steps are:

  • Provide great ways to navigate and filter the data. Seeing a centralized mass of tools is useful, but it’s much better to sift through the noise to find just what you want. Crowd-sourced tagging (i.e., folksonomies) are one step in this direction; we’d also like to add features that show you the tools that your friends use, the most popular and highest rated tools, and tools that industry luminaries use. What are useful filters / discovery techniques should we employ?
  • Crowd-source the data. What’s the right mix of data stewardship? Submit revisions and have them reviewed by “trusted editors”? Allow each tool to have an “owner” that modifies the data? Wikipedia-style free-for-all?
  • Efficient and accessible interface. The current UI is certainly… graphical but has a bunch of usability and accessibility problems. We think the right move here is to focus on a more traditional data-centric UI for the main view, but provide one or more graphical “explorers” for a different perspectives onto the data set and a bit of fun and whimsy. We’re making the data open to anyone to consume (we have a JSON-producing MySQL-backed web service we’ll make available soon, once we nail down the API a bit more) so we’d love to see folks create their own explorer interfaces on top of the data in addition to the one we’ll provide.

What Do You Think?

Are these the right immediate next steps for the tools directory? What do you think of the overall vision of the Open Web Developer Center?

I really wish all of us interested in this sort of thing could get together and brainstorm about all this. In fact, we should do just that. Look for another post on this topic shortly.

In the meantime, please do send in feedback, either via our mailing list or comments right here. Thanks!

Open Web Tools Directory

Just published a couple of blog posts earlier this week announcing the release of another project we’ve been kicking around here in Mozilla’s Developer Tools lab: a directory of the universe of tools to help web developers. The Ajaxian post goes into some detail on the technology behind it. Like Bespin, the directory uses HTML 5’s canvas element extensively. Unlike Bespin, there’s no compelling technological reason for this decision; we’re exploring different ways to visualize the data and we wanted to achieve a dynamic floating universe of tools.

We’ll be spending a great deal of energy in building up the directory and turning it into a vibrant, living resource for web developers, and we’d sure love to get your feedback on what you think we should to do it. Because the data is all available via a simple JSON format, we’re also keen to see other folks create their own custom front-ends for it. Who knows, perhaps a few other alternative interfaces will land in the coming weeks or months (we’re releasing a fully accessible version for the vision-impaired soon, btw).

I also want to give a special thanks to Mike “Morgamic” Morgan and Laura Thomson, two members of our incredible web development team at Mozilla, for tons of help getting this project going.

It’s been nothing short of a blast to work on this project. I’ve spent a good deal of time developing software on desktop platforms and here the web platform delivered the best of both worlds: easy-to-use graphic rendering API coupled with trivial network access built-in. And the performance! While a GPU-powered version would blow away the performance of the current version of the directory, I’m fairly certain that the web’s software rendering performance is comparable with the major desktop platforms software equivalents (e.g., Java2D, GDI, etc)–and I can’t wait to do a canvas 3D version to compare GPU-backed performance.

Go Web.