techno.blog("Dion")

Steve Jobs didn’t hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out “stupid keys” (print screen, F keys, and the like) and swore a lot.

We love to paint with broad black and white brushes these days don’t we? Whenever I hear people talking about Google being “evil” or not…. I sit back and think about how interesting it is that companies become “people”, especially in this country.

It makes sense when you look up Corporation:

Corporations are recognized by the law to have rights and responsibilities like actual people.

That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn’t a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.

I have been thinking about this ever since the recently surprise court decision the other day that “allows corporations and unions to pour unprecedented amounts of money into elections.”

Lawrence Lessig had some interesting commentary:

The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.

Fun aside

My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on “the mind”.

The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.

Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn’t just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren’t solely based on profit. They want to create a different kind of legacy and company.

That being said, I think it is quite easy to fall into a trap such as:

If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!

Google will sometimes do things that could be considered “evil” by some. That is life.

The good news with Google is that their search and ads business deals in a trust economy. It doesn’t take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.

Not all corporations are profit driven

I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make …. you think of the mission.

It was interesting to work there knowing that I actually wouldn’t want Firefox to be a 90% browser. You can fall into the similar trap as above and think:

We are mission based! If we had that domination we would use it for good!

But, not having that power in one hand is even better. Imagine working somewhere thinking “in my wildest dreams, the market would be shared somewhat evenly with the competition.” The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can’t move as fast as a dictatorship, but there is a reason we don’t want dictatorships in our government (even if the trains run on time!)

And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn’t dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.

I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don’t want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can’t Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.

I don’t want to “kill” these other platforms as they offer competition and spur on the industry. I just don’t want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?

Erm, no.

And thus I find myself torn. I really want to go out and by that iPad……. but when is it “too late”. Surely I have a few years right? I can enjoy the shiny new toy? :)

I spent a lot of time advocating Gears. I loved the engineers (folks like Aaron Boodman who is doing great stuff with Chrome Extensions, and Chris Prince who now works on the fantastic Google Voice, and many many more…. many of whom are working on Chrome in some fashion).

Today the press is picking up the fact that Gears is dead, even though Google moved its efforts awhile ago (keeping life support turned on) and Linus talks about the focus on HTML5 and Chrome:

“We’re very focused on moving HTML 5 forward, and that’s where we’re putting all of our energy,” Upson said. “When we started the Gears project, three years ago, maybe three and a half years ago now, we did it because we couldn’t get the browser vendors interested in building offline applications. And so, so we said, okay, we’ll build a plugin that could do it. And lo and behold, once we shipped Gears, suddenly the browser vendors got very interested in adding capabilities to build offline applications.

“And so, I think Gears has accomplished its mission very well, in getting these capabilities into HTML 5,” Upson added. “In fact, the team that designed Gears was also instrumental in designing the HTML 5 versions of those APIs. You can almost think of what’s in HTML 5, with app cache, and database, and those things, as essentially Gears 2, and that’s how we view it.”

Many people are happy to wave good bye to Gears and look to the future of HTML5. I feel that too, but I do have a pang of “what coulda been”. The Gears team was incredibly pragmatic. How can we get Gmail Offline? What about other Google properties? This practical experience delivered Gears and the push for support of real APIs that developers need to deliver compelling experiences through the Web platform.

Although it is true that Google can push the cause through their own browser, their properties still need to deal with other browsers. ChromeFrame is one answer there, the new “Google Plugin”. The browser vendors are kicking into gear nicely now. Mozilla, Google, Apple, Opera, and even IE teams are working hard on new features and HTML5 support. When Gears started we (the Web developers) were in the dark ages of browser development. The IE team had moved on to WPF and Silverlight. The other browsers were fighting the fight against a huge IE6 dominant entry with lots of ActiveX keeping it in style.

Does this mean there isn’t a place for a Gears like solution? Yahoo! has BrowserPlus which has the additional benefit of allowing developers to write services. This was one of the issues with Gears. You got APIs that Google gave you. You had no way to extend the experience. Browser Plus allows that and I hope that Lloyd and team have a good 2010.

There is also JetPack (and Chrome Extensions) that allow you to extend the experience in a different way. If I had my way, Gears and Y!BP and JetPack would all have joined forces. That world would then look like:

• Gears/Y!BP allow functionality to work cross browser and offer a services framework to allow you to write new components that also work cross browser. This is fairly low level work, with some nice sugar for certain APIs.
• JetPack would give you access to low level APIs in a nice high level JavaScript API. Since it would run in Gears/Y!BP it would run cross browser too.

My wish for Santa? Have JetPack and Y!BP pickup and work together. Give developers a platform to create new services on the Web and have them work cross browser. We shouldn’t have to wait for browser vendors to implement APIs. We should be allowed to experiment more. Gears started its job with the zipper running higher, but there is always more room to run. If we worked out a way to get more people playing with the platform we could get so much more done. We saw what came out of “how could we do Gmail Offline” what about your application needs?

I will raise a glass to Gears and the new HTML5 overlord, but I will miss the vehicle for cross browser experimentation and what coulda been.

“Just what the world needs—another sucky JavaScript library,” he said. When I asked him what made it ‘sucky’, he elaborated. “It’s a JavaScript library written by Java developers who clearly don’t get JavaScript.”

This quote is by Kevin Yank, talking to Dmitry Baranovskiy, author of the fantastic Raphaël graphics abstraction library. He writes up more on the issues they see with Closure. This is the few of one side of the community towards the open source release of Google Closure and its tools.

It was bound to happen. When I started at Google I quickly wanted to learn about how Gmail, Google Maps, and all the revolutionary front ends that helped make Ajax happen. Closure was the heart of it, and I quickly wanted to see a way to get the knowledge out there. This was years ago now, but the same reasons permeate through. Even at the time there were a ton of great JavaScript libraries. It wasn’t that I wanted Google to come down the mountain like Moses and bless the world “thou shalt use Closure!” However, some smart people had worked for some time refining their use of the browser runtime and Closure was the art and science of that ongoing experiment. Having the world able to at least see the experiment would be a good thing. Other libraries could learn from it.

No one from Google has said that you should, or must use Closure!

I realize that we live in a world of heros or zeroes. There isn’t room for much in between. You are either going to be a X killer, or you are killed by X. There is no time to tell the longer arching tale. Closure came to us late in the game, where folks are often perceived to be in their camps. I love JavaScript because it allows a diverse group of libraries to do what they do best. Developers and designers can find what suits both their personalities and their particular project.

If someone asks me (and they often do) “Which Ajax library should I use?” there isn’t a simple answer. It is nuanced. It is complicated. It is frustrating! How many of you have even changed libraries in a project? It is embarrassing to go back in time and see what happened with Bespin. At various times we had MooTools, Prototype, Dojo, and SproutCore. Is that productive? Obviously no.

You build many things on the Web. A web site isn’t a web application, and then blend together so you often can’t tell when you go from one to the other (and it doesn’t of course matter at all). jQuery has made a living starting out as a fantastic DSL for sprinkling behaviour onto web sites and going from there. SproutCore and Cappuccino are the other extreme, and Dojo was the kitchen sink of JS development a long time ago. Speaking of Dojo, I really wish that Dojo and Closure had collided a long time ago. I think that it would have benefitted both sides, even though I know that it would have added some overhead for both too. When you are on an internal framework it is built for your needs. If you take a look at the Closure components they feel very Googley out of the box. At the end of the day though, Dojo and Closure are so similar in many ways, that having them joint at the hip a few years back would have been really exciting. C’est la vie.

One tricky thing about Closure is that you can’t look at all of the widgets and packages equally (same for most libraries to be fair). Some are battled hardened to the hilt as they are on important production systems acting as core functionality. The keyboard handling and localization support is top draw. Others may be cool but placed in via an interesting 20% project that isn’t as mission critical and hence battle hardened. Not all code is equal. In fact, I find the line by line code criticism tiring. It is so easy to take someones code and find fault with it (at least perceived fault). I am sure there is bad code in Closure. That is true for all code. It is much harder to be a creator though. Don’t get me wrong, it is good to point out potential issues, but there is a big difference between:

“I noticed that code X does Y. I think there is a bug there that would affect ….”

and

“Code X SUCKS. Mwhahahahahah. SUCKS!”

My new years resolution for 2010: “Say *sucks* less”.

The criticism that made me laugh hardest was the assertion that the Closure engineers were Java folks who wanted JS to be Java. They are far from it. They are old school JS engineers who have done amazing things on the Web and have just learned a few things along the way as they build huge scale JS systems.

Google is of course a big place with engineers with opinions :) When you have the creators of various languages and platforms under one roof that is always going to be the case (From Python to C++ to Java to Go, and then Closure, GWT, etc on the JS side… even jQuery ;). Many of the frontend engineers aren’t fans of Closure (as in: doesn’t fit them) but they do understand where some of the strengths are. Some of the engineers have even weighed in:

NOTE: The following quotes were taken from a Facebook comment stream. There is context missing (for example, Joel talks below about how he didn’t use the term ‘natives’ for example

Joel Webber, GWT guru: “I’m unfortunately not too surprised to see self-appointed “Javascript natives” pissing all over Closure, because it tells them something they don’t want to hear — namely, that you can’t get enough optimization leverage on large applications without some constraints on your code’s structure. The kind of stuff that you see in many Javascript libraries (e.g. lots of dynamic tests to figure out what to do in a function) pretty much guarantees that you’ll have an unoptimizeable mess.”

Gavin Doughtie, Dojo and Google Photos: “As one of the Javascript natives, I must say after three years of using Closure that it gives you a nice split between development-time dynamism and deployment-time optimization. I have found few Javscript idioms unavailable to me when coding, yet still benefit from static checking and optimizations once I’m ready to ship.”

I am more of a JavaScript native than anything else. I am not going to be rushing to use Closure on a project any time soon. It doesn’t fit many of the projects I work on to be honest, and it doesn’t fit me as well as some of the other libraries.

That being said, I am thankful to Google for putting this code in the commons (and the fantastic tools around it!) so we can all check it out (and some of us use it). I hope that the hard part of open sourcing a project kicks in and we see a community form around it, including taking in contributions. I still also harbor the hope that Dojo and Closure joined forces, but that is hard to do (a lot of people using both code bases!)

When it comes to getting closure, I hope that you don’t jump to the extreme and ignore and abuse it, and I also hope that you also don’t think that you SHOULD use it without checking it out and understanding the tradeoffs.

For example, this is crazy:

“I hate to admit but I “might” have switched from jQuery to Closure strictly because of the Google brand.”

Roundup on Closure

• Erik Arvidsson, founder of Closure, awesome JS hackers, on the history
• Alex Russell, founder of Dojo and Chrome Frame
• Dimitry presentation on JavaScript libraries
• Google Closure: how not to write JavaScript
• Learning Closure with goog.net
• Inheritance Patterns in JavaScript

I have been watching the work of Aaron and the Chrome Extensions team for awhile. I love that with that effort and Jetpack we are going to see extension creation made simpler and more approachable for Web developers.

I realized that I hadn’t written a Chrome extension, so I wanted to try it on for size. I thus created an incredibly simple extension that tells you the size of the window on the fly: Chrome Win Size.

In an ideal world this extension would be as easy as:

• Create a bit of HTML for the tooltip
• Attach an onresize handler to the window that changes the HTML

Unfortunately, it wasn’t quite that easy…. but it was pretty close. The only difference involves the fact that you can’t easily get the window object to resize.

Here is the entire extension to show how simple it is:

Web page for the tool strip

For now, I wanted to put the windows size information in the toolstrip. This isn’t ideal, especially if you don’t have other extensions that turn on the toolstrip. It could be nicer to either: have a subtle grey width/height in the background of the URL bar itself; show the info only when a certain keystroke is pressed. That is all for version 0.2 :)

As you will see below, the extension is just a Web page, and the toolstrip is just a div. You could use class="toolstrip-button" but for now a click doesn’t do anything, so I didn’t use that. Instead I have a title attribute that uses plain English to explain the info.

Once you have the HTML itself, you also have some JavaScript to do the work. The init kicks things off the first time, but the interesting code is the chrome.extension.onConnect.addListener piece that sets up the extension so that a content script can talk to it via postMessage.

<html>
<head>
<script>
 
// Query the current window (anyone will do) and set the window size in the toolstrip
function showDimensions() {
    chrome.windows.getCurrent(function(w) {
        var el = document.getElementById("windowsize");
    	el.innerHTML = w.width + " x " + w.height;
    	el.setAttribute("title", "width: " + w.width + "px, height: " + w.height + "px");
    });
}
 
// Listen to the content script and when told there is a change, query again
chrome.extension.onConnect.addListener(function(port, name) {    
  console.assert(name == "resize");
  port.onMessage.addListener(function() {
      showDimensions();
  });
});
 
</script>
</head>
<body onload="showDimensions()">
  <div id="windowsize"></div>
</body>
</html>

Content Script

Why do we need a content script? Ideally, we would be able to grab a window in the extension and add a resize listener to it and be done. That isn’t the case right now though. In the code above, the window object that we get in w from chrome.windows.getCurrent(function(w) {... isn’t a DOM Window, but just something with a few properties (width, height, etc).

To get an actual DOM window, we need to inject a content script and have that talk to the extension. The code is as simple as below… which does the postMessage() back to the listener that we setup in the extension:

// When the window resizes send a quick message to the extension
window.addEventListener("resize", function() {
	chrome.extension.connect({name: "resize"}).postMessage();
}, false);

Manifest

Now we need to put it all together and that is where the manifest comes in. It is here that we tell Chrome where the files are for the toolstrip and content script, and what permissions they have (e.g. give it the tabs permission), as well as metadata:

{
  "name": "Window Size", 
  "version": "0.1",
  "description": "Displays the size of the main window",
/*  "icons": { "128": "gmail-128x128.png" }, */
  "permissions": [
    "tabs"
  ],
  "toolstrips": [
    "winsize.html"
  ],
  "content_scripts": [
    {
      "matches": ["http://*/*", "https://*/*"],
      "js": ["contentscript.js"]
    }
  ]
}

Caveats

Even with the content script hack, it is pretty easy to do this kind of thing. It would be nice to do more with the window object as the hack has limitations beyond the extra code. For one, if you are on a page such as chrome://extensions/ nothing kicks in (due to the matching). Rather than matching on pages for content scripts to embed, it would be much better to declare that you care about windows themselves.

The toolstrips themselves are a little bulky and ugly, at least on Chrome for Mac (which is very much in beta) and as mentioned earlier…. unless you are using a bunch of extensions, it feels very unChrome-like to use that space.

FYI: To package an extension on Mac/Linux use this handy script as the built-in functionality isn’t there yet.

All in all a decent experience already. Really nice to just work on an HTML document to kick out the functionality. The idealist in me would love to see Jetpack and Chrome Extensions coming together so Web devs had One Way to extend the platform…… The Web is in a fortunate position to have folks like Aaron Boodman, Aza Raskin, Atul Varma and many others on the case of Web extensions.

It was exciting to see Fitz launch dataliberation.org today. You probably saw it:

Users own the data they store in any of Google’s products. Our team’s goal is to give users greater control by making it easier for them to move data in and out.

It is a pretty big deal what Fitz and his “Data Liberation Front” has done. Not only do you have the politics of making it happen, but think of the logistics involved in getting teams at Google to prioritize import/export in front of other features. It takes a lot of time. Good on you for fighting the fight guys.

Ragavan has posted some thoughts linking to the Guardian article and Glyn Moody.

I agree that this is a huge step, but very much the first step:

• Being able to import/export data is a good start
• Being able to say “delete all notion of my being here” is important
• Having fine grained control of access is great
• Being the center of the gravity of your own data, where you grant access and rights to it, would be awesome.

It is great to see a light shining on the issue. Hopefully this is the start of a conversation. One where we can discuss who owns our data, and where we can clearly recognize the rights that we have. I want to be able to understand your business model and see the value that you give me. Then, I can decide what access to my data I want to give. Ragavan has some good words here:

Personally, I think Data liberation (or data portability as it has been called formerly) applies as much to your data as it does to data about you. One of the big concerns about Google (and a number of other cloud computing players) is the amount of data they have compiled about you – online profiling, if you will. What sites you visit, what you buy, your likes and dislikes, your email – everything is mined, processed and used to improve your web experience (and to serve you ads).

So, while you may be able to liberate your data and move it to a different service, it is unclear what it means with regards to your online profile. I guess you could export your web history, but is that all Google knows about me? In fact, what does Google know about me? A related question that would be good to get clarification on is whether there is an option to permanently delete your data once you’ve exported it.

Another factor to consider is how you define what “your data” is. For example, if you look at it as just exporting your photos out of Picasa and importing them to flickr, I’d posit that’s a rather simplistic view. A large part of what makes your data useful and valuable is all the relationships associated with it. I share my photos with my friends and family, I license some under Creative Commons, I group them, I tag them – all of these make my data very context rich. How do you liberate this context? And if you do, what does it mean to import them elsewhere?

These are hard questions and I’m sure there are several more to ask. But these are the very questions that need to be answered as we move towards the people-centric web (or the you-centric web as some of us like to call it).

I had the pleasure of being at the Google Campfire event that launched the worst kept secret, App Engine supports Java and Google has a preview for you to check out if you signup in time.

Java is a huge ecosystem, which is a big win, but what interested me was the nuance. The Secure Data Connector feature that gives us a glimpse of “on premise” type functionality (that Microsoft is touting with Azure) is a big one, and something that enterprises need.

The GWT pitch and the Google plugin for Eclipse is another interesting one. I am always so incredibly torn here. GWT is fantastic technology. Because of the way it works, it gets to do things that pure JavaScript libraries would love to be able to do but can’t. The team is great, and the hard core tech is incredibly impressive. I understand why people use it.

My personal issue is that it feels so funny to see the two messages from Google.

• HTML5! It’s here! We are building on it, we are believers
• Use GWT and Java! It is productive!

Now, these aren’t mutually exclusive of course. GWT can wrap all of the HTML 5 stuff and both can be happy. But it just feels weird to me. The idea that JavaScript is the assembler of the Web, when it is such a high level language is hard to wrap my mind around. It can be moulded to do so much more than Java can with its static nature (which has downsides too of course!)

Another thing. Writing your applications using Java in this world is about the source code and the language but not about the VM. For me this is hard to wrap my head around too. I get to use a language I *personally* don’t like as much (Java the language) and have it run on a runtime that isn’t as good as the Java VM. Hmm. And, since there isn’t the VM there (on the client, there is with App Engine!), I don’t get the pleasure of writing in any of the very interesting languages available on the JVM (Scala, Clojure, JRuby, Groovy, etc). They have picked the wrong Java for my taste!

Now, Paul Hammant has a very detailed post about building a rich Ruby application on top of AppEngine4J. He flips from a jQuery view to a Ruby client using Swiby to a Ruby Shoes app and beyond. Then, at the end, he says something very interesting:

If Google made changes to GWT to make it a viable thick/desktop/offline technology then AppEngine might shift up a gear with online/offline apps.

Since you are writing Java code, why not ship down a jar file for browsers that support Java (still a fair few) and run the application natively within the browser? Kinda bizarre, but imagine if Gears had been done in Java, and people could add functionality easily that way (this is where Yahoo! BrowserPlus is interesting… how you can write services in Ruby and the like). And now you are sending down a jar, you could write the applications using any JVM language you want. Huh. That would be an interesting direction.

Who knows where this ends. When you get practical though, Google have delivered a nice experience for people that like Java, and that is a large group still.

I am still in the camp of DSLs and lightweight and all that jazz, and agree that one great thing about the Web is that some people can come in and make a change here and there at a very high level and make something their own.

Fun times!

The new multipane view for Gmail by Vivi will change my workflow for the better. I have placed views to the right of my inbox that show me:

• My starred items (is:starred)
• Emails sent to me (to:me)
• Notifications. This is a big one. These items are things that I kinda want to see fly by but don’t care too much about. In the past they would clutter my inbox as I didn’t want to “skip inbox” and not see them (I never pro actively check out labels). Now that I can have the list scanning by, I CAN change my filter to skip the Inbox which will keep it cleaner!
• Skipped content. I have a bunch of mailing lists that I tell to skip the Inbox. The end result is that I rarely see it, so it is really quite silly. Now though, I can have a small window into that world.

Very cool indeed. There are pain points though. If you are not plugged into a nice 30″ monitor, your real estate gets cramped fast. You can choose to put items on top, bottom, or right, but right is the only option that makes sense to me.

I want to be able to have fine grained control here. Gimme a splitter so I can choose how much space to give. Let me put some on the right, some on top, some on the bottom. Let me show and hide items so I can shoot open my inbox to be full screen when I need too.

Selecting items on the other panes is strained. You don’t have checkboxes and the arrow keys to help you over there. I wish that I could click on a space on the very left and have the “>” item show up there so I can move around and select things. I hate the mouse.

I am curious to see how I like this, and how it changes me Gmail usage. Do you like it?

Google Latitude is cool indeed, and will have folks from Loopt and beyond watching (see Dodgeball didn’t die, it’s just slowly becoming a feature of Maps!).

Even with all of the privacy controls, you KNOW that there are going to be fun cock ups in the future, just like we see on Google Maps Street View. It just has to happen. But, it’s worth it :)

Shame the iPhone version didn’t come out on day one, and the Palm Pre version will be cool :)

Paul Buchheit has a really nice post on the power of code over talk and has one item that resonated with me:

This is where Google’s “20% time” comes in — if you want innovation, it’s critical that people are able to work on ideas that are unapproved and generally thought to be stupid. The real value of “20%” is not the time, but rather the “license” it gives to work on things that “aren’t important”. (perhaps I should do a post on “20% time” at some point…)

That is exactly how I felt about 20% time. It wasn’t about the time. In fact, I didn’t actually know that many people who took the time! The key was the following effect:

• In order for 20% time to work, anyone must be able to see what is out there
• In fact, if you want to get some people working “for free” you need to both advertise your project, and write it in such a way that it is easy to get ramped up and productive (end result: better code)

The end result is the culture HAS to be kept very open. The ability to see the projects that are worked on, check out the code, see presentations and design docs, is a key reason why Google does so well at engineering in my opinion.

Compare this to companies such as Apple where you don’t know what the chap sitting on the other side of the cube is doing. Therefore, even if you have some amazing wisdom that could be game changing for his project, it will never happen.

20% time means that sparks of genius can happen. If you copy anything about it, ignore the “time” part, and go with the open culture part.

Whenever I saw projects that were secret within Google it irked me. It stopped this from happening. It was as though that project was going walkabout instead of joining the party.

A lot of people are talking about the interview with John Lilly that discusses the relationship between Mozilla and Google.

People like to paint think black and white. Either Mozilla is Google’s poodle (Mozilla is to Google as Tony Blair was to George Bush) or there is a falling out and they hate each other.

Of course, the answer is grey as John points out. From my standpoint, focusing on the Open Web, I see more areas to collaborate on than to fight over. When I was at Google I knew that the Open Web was very important to the long term future. Now I am at Mozilla, the same is true. At the micro level there will be differences, but at the macro-level there is alignment.

Switching gears a little, I have had some folks talk to me about responsiveness issues with Firefox 3. I have had a fantastic experience, and currently I run Mozilla nightlies / Minefield / Shiretoka (3.1.*) and WebKit nightlies side by side. I am very happy with the shape that Minefield is in.

Of course, the issue with the extension mechanism with Firefox is that you get a window to the entire world (which has also been a reason that lead to amazing add-ons). Since this is the case a bad add-on can do a lot.

Chrome does a good job showing you basic info about a tab (memory etc). What if we did that and more for add-ons. Give me top for the browser.

Now, this is a lot of engineering away, so can we use the crowd to help out?

What if we created an add-on that would track responsiveness information and send it back (anonymously) to the cloud (say, to Weave). We could use math to work out probable culprits and could even ship that information back to the people using the add-on. Thus, you would then find out that FooAddOn seems to be a culprit that slows down the browser. Maybe it could be called Vacinate-addon.

What do you think?