dave.ofmassdestruction.com

There were a few reasons I stalked, and worked hard at getting hired at Mozilla a little over a year ago. First, and foremost, I believe in the mission and love the work. However, one of the top reasons was a handful of Mozilla people whom I already knew or knew of. In the top 5 of that list was one Chris Blizzard.

Chris and I met, back in the day, when we both worked at Red Hat. At a point in the very late 90s we found ourselves in a whirlwind of craziness with the company going public then the technology world collapsing with a hard thud (dot bomb). During that period we also had made the decision to merge the Red Hat Advanced Development Labs into the greater Engineering team which was a controversial, and dramatic decision. By that time I was the Director of the Labs and part of that decision. We kept a version of the Labs as a Desktop-focused group though there was great deal of pressure to make sure we didn’t “waste” money, the future of which was uncertain in terms of supply. Labs just had a bad connotation to share-holders in a down economy.

At the same time all this was going on… Netscape had opened the source to their browser (whoa!) and there were rumblings of something called “Mozilla” going back and forth. I remember someone (was it you Jonathan Blandford?) telling me that Chris Blizzard had been poking around the Netscape/Mozilla code… and making good progress. To be honest, a few Red Hatters had taken a look and been scared off of what was a giant tangle o’ code. It was apparent at that time that if this Mozilla thing failed, we (Linux) would be without a browser. Like… no browser… save old Netscape versions and Lynx.

I remember a manager’s meeting in which I suggested that we get Chris Blizzard to work on the Netscape/Mozilla codebase full-time. I am pretty sure the CEO’s first thought was that I was going to waste some money, but a couple other managers came to my side quickly and brought up this idea of Netscape/Mozilla failing.

So Chris moved over to our area of the building and sat right behind me for a while. And this was when I really got to know Chris and come to love the guy. After that he moved to Canada, Boston and then away from Red Hat and on to Mozilla itself. I wouldn’t see him much for years, but I always followed what he was up to with pleasure.

I remember this, not because I feel in any way responsible for Chris working on Mozilla – Chris did that on his own – but because I like that there is a connection to Mozilla for the both of us that goes back sooo many years.

Now Chris has decided to move on from Mozilla after all this time. Honestly, I celebrate it despite being bummed at not being able to work on the same team with him… again. Still, change is good for people and I feel like this will be great for Chris. While we will be sad, Mozilla is strong and we’re doing awesome, awesome things. In part, thanks to all those years Chris put in.

So I say… Thanks Chris! Good Luck! and don’t mind me bugging you from time to time!

The one caveat to any stories I tell about those RH years is that my memory is CRAP! – please correct me where it fails!

by dangzy

The best part about Mozilla All Hands meetings is that it is quite easy to find people who have similar interests and passions. What’s harder is to take those passions home and keep some momentum going on ideas that spring up during these weeks. Nonetheless, one group that has been slowly forming over a few months is a group that wants to start engaging developers, users, and all people in Africa.

There are a lot of ideas for what this means as there are so many issues in Africa that could use some participation by an organization such as Mozilla. Still, the group is growing and we are going to meet sometime today or tomorrow to try to figure out some first steps for making this happen.

If you are at the Mozilla All Hands and want to join in, just find me (dcm@), dietrich, or dees and tell us you want to join. If you aren’t a Mozillian, or aren’t at the All Hands – jump in an tell us how you think Mozilla should engage with Africans.

Update: I have set up a new Google Group to provide a forum for more conversation on this – please join in!

I had hoped by this time that this blog would have been added to http://planet.mozilla.org – but alas, the open bug sits untouched. Nevertheless, I’m going to post my latest work here in case someone stumbles in after I am published there, wanting an update!

…

Its been quite a few months since we shared the greater vision for the Jetpack project and the Add-on SDK as a product. A lot has happened since then, including the release of Add-on SDK 1.0 and the growth of a team of talented people to keep the momentum going. Still, its always good to take some time, think about where we are going, and decide which parts are most important. So let’s do it!

You know, this is a roadmap… In my mind that means its *always* in draft form. We will always need to take a look at what things are important and how they should fit in to the ongoing work. So let’s make a deal and consider this thing dynamic and living – then we don’t have to worry about labeling it a draft.

The list of goals here are many and not easy and while we’ve grown the internal Mozilla Jetpack team, we still want and need contributions from you Rocketeers out there who are using the SDK on a regular basis and identify missing pieces or are just interested in helping out with some or all of these goals.

Keep in mind that we’ve always had the plan to keep the core of the Add-on SDK small and relatively conservative when it comes to features. What we would rather have is a large set of contributed, and shared, libraries to extend the functionality for add-on developers. This opens up a far more extensive set of tools and a better community for anyone who wishes to create an add-on, and frankly, just feels like the Mozilla way!

Let’s reset for a minute

The Jetpack project has always had the goal to make extensions easy to develop, and easy to install. While it started out as an experiment in 2009, we soon did a rewrite and moved on to product development while graduating the project from the Mozilla Labs in 2010. With the release of Add-on SDK 1.0 we have made a set of APIs that allow for the majority of add-on use-cases to be developed easily and with open web tools (html, css, & javascript). In addition, as they are restartless by default, add-ons developed with the Add-on SDK are definitely easy to install. To be sure, the Add-on SDK is no longer a prototype or experiment but the tasks ahead of us, while filling in holes in some cases, will be every bit as challenging as the initial creation of this project. We can’t say that the Add-on SDK is the answer for all of your add-on development needs yet, but we want to get there. For that, we want your help!

The Priorities

So lets get to it. Many people may have noticed lately that the Mozilla project has done a bit of shifting to make sure we are answering the changing landscape of browsing and computing. To that end, we have to focus more on emerging mobile devices and how people want to use these devices. We Rocketeers have to make sure we are also making that shift. This means that our support of mobile has to be at the top of our list. Keep in mind that just because a feature didn’t make it to the top of the list, doesn’t mean it won’t get done before some of the top items. Its hard for people to focus solely on one thing for a long time, and some of the other items (or pieces of the other items) are easier to develop and test than the top priorities. Nonetheless, I expect that you will see a great deal of movement on these higher priority items even though they are the more complicated tasks.

The Mozilla Products team has also been hard at work on new set of processes and tools to help explain new features and why we want them. The new “Feature Pages” are being used by the Jetpack team so for any of the priorities listed below you can click on the link to the Feature Page for it and see more detail and what the latest plans are with them.

By the way, any time you want to check on the latest changes to the Roadmap, you can always look here: https://wiki.mozilla.org/Jetpack/Roadmap

Top Priorities

Our top priorities for the second half of 2011 into 2012 are:

1) Support Firefox Mobile. As we now all understand, the web experience is moving towards smaller devices, we have to make sure that any developer creating an add-on via Jetpack will find that their add-on just works in mobile. Mozilla cares as much about user choice and personalization on mobile devices as it does on the desktop, Jetpack must reflect that with no work from end-user developers.

https://wiki.mozilla.org/Features/Jetpack/SDK_Support_for_Firefox_for_Mobile_Addons

2) Enable jetpack to always create add-ons that take advantage of Electrolysis (e10s) to run in a separate process. Running an add-on in a separate process is important for users and the add-on developer as it makes it much easier to determine if an add-on is affecting the browser’s performance. In addition, there may be some security enhancement as its much harder to exploit a vulnerability if its being run in a separate process. For Jetpack, we want to ensure that our users never even have to think about e10s or how to use it for their add-ons to run in a separate process.

https://wiki.mozilla.org/Features/Jetpack/Out-of-Process_Addons

In addition, we also need to ensure that for the elements the Add-on SDK exposes that need to run in particular processes that are *not* the add-on process, they are doing so (again, without any worry from the add-on developer). We recognized that these two bits are related pieces of work despite the orthogonal approach we plan to take in developing them. Nonetheless, a new feature page is being developed for supporting the other processes we need to support.

https://wiki.mozilla.org/Features/Jetpack/Browser-e10s-Support

3) Add-on Localization API and Service. Its important that Jetpack no longer lingers behind in the the world-wide reach Mozilla has worked hard to obtain. We must have a localization solution that allows our developers to get localized add-ons with minimal effort on their part. Add-on localization in the SDK comprises a simple, high-level API for specifying the strings to localize, a localization service to which add-ons distributed by addons.mozilla.org (AMO) are automatically submitted for localization, a web application through which localizers can localize add-ons, and automatic repackaging of AMO-distributed add-ons with new and updated localizations.

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Localization_API_and_Service

Secondary Priorities

1) Create a path for developers using the traditional tools to move to jetpack. If we are successful in bringing in new developers to creating add-ons for Firefox, we must not forget the developers who have been using the traditional toolset. With the inclusion of features such as e10s and mobile, it becomes imperative that we offer the easiest methods possible to create add-ons that work with these new technologies and platforms. We see Jetpack as being a great path for our current add-on developers to start taking advantage of these new features – as long as we can make the porting equally simple. This work may include creating tools which will automatically help developers port their existing add-ons, as well as a good set of documentation and examples to help them understand the differences in approach.

https://wiki.mozilla.org/Features/Jetpack/Traditional_Addon_Conversion_to_SDK_Platform

2) Simplify the Add-on SDK. While Jetpack is a simple development tool to use as compared to the traditional add-ons tools Mozilla has offered, we have to recognize that simplicity opens the door for more participation. With more participation comes a greater democracy of ideas and implementations – all of which can benefit the open web. Simplifying Jetpack even more is a high priority because it is one and the same with Mozilla’s mission.

https://wiki.mozilla.org/Features/Jetpack/Simplify_the_Add-on_SDK

3) Add-on SDK: The missing pieces. There are several notable Firefox features we do not yet support. These would be simple APIs to offer support for:

• Prefs API
• Places API
• Sidebar API
• Add-on Tab API
• Tab Groups API

• minimal XPIs
• packed XPIs
• add-on testing without browser restart

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK:_the_Missing_Pieces

4) Add-on SDK as an Add-on. We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with addons.mozilla.org which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to “eat their own dogfood” – testing the packaging and performance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot’s work of porting the SDK to an add-on we can start to offload some of the Builder’s time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users.

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_as_an_Addon

5) Add-on SDK Debugging. Debugging has come a long way since the old style of dumping errors to printf. However, Add-on SDK users might notice… we dump to printf! There are many debugging additions we can make to the SDK, especially if we take a cue from our awesome web dev tools team. Some of these items could include:

• introspection
• profiling
• setting breakpoints
• stepping through code

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Debugging

6) Make Add-on SDK Hug the Web Harder. Jetpack has done a great job in embracing open web technologies to create a robust development toolset. However, developing an add-on is still more different from developing a web page than it has to be. We need to make sure we are supporting the most common and useful elements of web development to ensure the platform is as inclusive as it can be.

https://wiki.mozilla.org/Features/Jetpack/Make_Add-on_SDK_Hug_the_Web_Harder

Non-Goals

If you still have a copy of the last roadmap around you might notice that the non-goals are pretty much the same. Keep in mind though, that just because we have these items listed as non-goals for this roadmap doesn’t mean they can’t become goals at some future date. Its just important to remind ourselves of the constraints of which our current development needs to fit in to. To that end, here are the things we are not trying to accomplish:

1. Deep extensibility. The traditional add-on platform, with features like XUL overlays and XPCOM components, was designed for deep extensibility. Indeed, you can do almost anything to Firefox with the traditional platform. But the vast majority of existing and potential add-ons don’t need this capability; the remainder can still be implemented using the traditional add-on platform; and projects are better positioned to explore a potential future replacement. The Jetpack project will leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments. Having said that, its important to remember that deep extensibility is possible with the SDK; it just requires you to dive under the covers of our supported APIs.

2. Apps. Mozilla, other browser vendors, and other industry participants are hard at work defining standards, UX affordances, and distribution channels for the next generation of web apps. But apps differ from add-ons, even if they sometimes bundle themselves as such for lack of better distribution channels. The Mozilla Open Web Apps team is kicking ass here and is much better positioned to identify and address the exposure and distribution needs of apps, while Mozilla’s developer tools team headed by Kevin Dangoor is the right locus for activity around tools for web developers. The Jetpack project will not build tools for app development and distribution.

3. Firefox-SDK integration. The SDK and Builder bundle API implementations with each individual add-on. This strategy has worked for us so far through the 1.0 release and is still a good plan for our needs. Having said that, there is a good deal of ongoing discussion about integrating with firefox we are taking part in with the community. At this point, it is still too early to include any steps on this roadmap related to any of the conclusions coming from these discussions so it will still be listed as a Non-goal.

Recently, as a part of the conversations around integration and the development and distribution of the Add-on SDK, the Jetpack team Tech Lead, Myk Melez, wrote up his thoughts on why the Add-on SDK doesn’t land in Mozilla-central: http://mykzilla.blogspot.com/2011/08/why-add-on-sdk-doesnt-land-in-mozilla.html

Development Plan

The Jetpack team decided during the 1.0 release that we would move our development to a train cycle that closely follows the Firefox development cycle. This was done mostly for maintenance reasons, which allow us to keep up with the new versions of Firefox. This will ensure that developers can have their add-ons rebuilt automatically on the Add-on Builder or addons.mozilla.org to work with the new versions of the browser. In addition, we will be working on our top three priorities with an outlook of 3 to 6 months for each item. Our version numbers will only increase by dots until we land major changes or breaking changes. This will be done to make sure that people recognize that there is something important to recognize with the release. More information about our development plan can be found here: https://wiki.mozilla.org/Jetpack/Development_Process

I am super-excited to see that Christian Legnitto has hacked together a mediawiki extension to embed bugzilla data. One of the things I’ve been interested in is making sure we have good tracking tools and a handle on the bugs coming in for jetpack. This extension is something that will allow us to visualize whats going on automatically. Awesome.

In addition we recently contracted with a person to become our bugmaster. He is also working on some tools to help us understand and measure our bugs – combined, I think we are going to end up with something very interesting from a project management point of view.

Thanks, in part, to my friends at New Kind, I took part in an interesting, collaborative exercise over at Mix Management to explore new ways for people and companies to do business. Along with Jonathan Opp and Gunther Brinkman, I wrote a “Management Hack” based on the idea of “forking” in business as represented in tools like Github in open source software development.

Our entry has been picked as a finalist in the Harvard Business School/McKinsey Management 2.0 Challenge – which is pretty awesome. Feel free to give it a once-over and vote or comment on it. Feedback is welcome… so is forking!

My co-worker, Atul, has written an amazing plugin for Firefox. Its called collusion and it shows you who is tracking your web browsing, and through which sites. It shows all of this in an easy-to-read, interactive graphic.

This is mine for just one morning (about 4 hours)

I went to facebook only once today and yet look at all of those sites that tell facebook I am there. There have been a few reasons why I’ve thought of leaving facebook, this creepy exhibition adds to those reasons.

Head over to collusion.toolness.org, watch the demo, install the add-on, and be ready to be feel like someone is looking over your shoulder.

Over at Mozilla we have released the Add-on SDK and beta version of Add-on Builder. This is what I’ve been working on these months I’ve been at Mozilla on the Jetpack team. These tools allow you to write add-ons for Firefox with just javascript, html, and css. Pretty awesome.

In addition, I did an embarrassing video introduction to these new development tools – watch and ridicule:

Untitled, a photo by dmason on Flickr.

I like to think that we’ve found a particular breed considering how much she looks like our old dog. Still, she behaves very differently.

Her name is Chelsea!

Last night we lost our best friend, and family member, our dog Zola. He lived a very good life and was very dear to us. Zola was the third dog in my life, and I loved them all, but I think I was closest to Zola. He was bursting with personality, both good and bad. He would make a quick decision on whether you were in the pack or not – look out if you weren’t – if you were, he was the sweetest dog on the planet.

We picked him up from the shelter 12 years ago. How old he was then was just a guess (and I think a wrong one at 6 months – he was a year or more). He had shotgun shot in his hind quarter, the mange, and had been a stray. Despite a beautiful and princely yellow lab in the first bay, this skinny dog cowering in a cage with a more lively dog caught our eye… and chose us. What a lucky dog – from that sketchy beginning he would go on to live 12 perfect doggie years. He made us smile up until the end.

He was a good boy.

by Phil Myers

My friend Mark is the bug-meister over at mediawiki. Recently he and I have had some conversations about software projects working through bugs, specifically the process. I believe that Mark is simply collecting all the different ways big open source projects go about keeping their bug reports in-line and prioritized. You can see the start of his process here

Jetpack is a relatively young project within the larger Mozilla/Firefox realm. We have the luxury of youth to keep our bug numbers in a manageable number. Nonetheless, we did take time to have a few bug-triage days where we spent hours looking at our bugs, prioritizing them, and putting a timeline to them. The process was simply to accomplish those two things, priority and timeline. Anytime we would get off track discussing the bug we simply had to stop and figure out those two things.

Now the job becomes looking at the timeline items (E.g., current beta release bugs) assigning someone, and keeping track of the work on release-blocking bugs. In addition, the tech-lead and I are having weekly conversations to triage all the new bugs coming in as we want to ensure that the 1.0 release doesn’t go out with any glaring holes.

That’s our process.

However, the more I have thought about my conversations with Mark, and really, about Mark’s position at mediawiki I find myself wondering about this position of bug-meister.

I haven’t really asked Mark about his particular job description but the more I think about it, the more I see value in having someone on a team whose job is to keep tabs on the bugs. Perhaps this person gets initial prioritization rights, perhaps assignment rights, maybe even timelines. As long as they are working with the person driving the direction and priorities the work would be invaluable.

I’m starting to wonder why I’ve never worked in an organization that didn’t have a “bug-meister”.

UPDATE: My friend Luis reminded me that a long time ago he wrote about the bug master idea. Once I started reading it, I realized I had read that back when he posted it! What a bad memory I have. Still, I like that he brings QA-engineering into the role – there are some good things in what he wrote.