This MozCamp was filled with excitement about B2G and the many other initiatives Mozilla has going on. Beyond the product building we’re doing, there was a lot of energy and enthusiasm for growing the Mozilla community and building on the ideals that Mozilla stands for.

During MozCamp, I spoke with a few people about conferences in general. I think there’s a lot of room to make MozCamp and other conferences better than what we’re used to. These ideas are not new and didn’t originate with me, but they’re worth repeating.

The Format Today

MozCamp was structured like most other conferences that I’ve been to: a packed schedule with multiple tracks of presentations. You get interesting people presenting on useful topics. That’s not a bad thing, but I think it can be better.

If I’m going to deal with the hassle of air travel and spend days away from my family, I’d like to get the most I can out of that time.

A typical presentation slot is 30, 45 or 60 minutes. Of that, there’s maybe 10 minutes of questions and the rest is an “eyes-forward” presentation. I don’t think this is the best use of time. The unique thing about MozCamp (or any conference, for that matter), is that I’m physically there with the other people. The communications bandwidth is much higher. To use that bandwidth for one-way communication seems suboptimal.

There were other issues that I noticed as well:

1. Attendees at MozCamp had varying levels of English proficiency. This can make it hard for some to keep up with eyes-forward presentations from native English speakers. Plus, a whole day of constantly translating in your mind can get tiring… by the time the second day rolls around (after a possibly late night followed by soccer in the morning!), I would imagine that keeping focused would be difficult.
2. No slack time for checking email and having hallway conversations. The schedule was packed, leaving mealtime and snack time as the only times to talk (short of skipping sessions). Some of the evening activities suffered from high noise levels as well, eliminating that chance to talk easily.
3. No slack time also causes issues with schedule slip.. On Sunday, the Q&A session threw the rest of the day off by 30 minutes. That’s not surprising, since it was an interesting two-way communication sort of session… but it meant that the rest of the schedule needed to be pushed by half an hour and never got back on track (causing some sessions at the end of the day to be dropped).

The Two-Way Conference

I think conferences, including MozCamp, should try to become more “two-way”. One formula for a session could go something like this:

• “speakers” are more like “hosts” or “invited experts”.
• The expert prepares a page with links to background material and probably a presentation. This page should be available a couple weeks in advance of the event
• That page can also include some suggestions for areas that could benefit from discussion.
• That page could also have an etherpad or wiki associated with it to collect more ideas in advance (as attendees view the material).
• At the beginning of the session, the expert provides a lightning talk-sized intro and, possibly with the help of a facilitator, gets people organized to usefully talk about things or work on something

A parallel is the recent talk of “flipping the classroom”. The students watch a video outside of class and then use class time to work together or get help from the teacher.

Wouldn’t it be awesome if, instead of 50 minutes of eyes-forward presentation followed by questions, we had 5-10 minutes of organizing, level-setting and topic choosing, followed by 50 minutes of two-way communication?

Some unconferences go so far as to not even have predefined topics and time slots. I’m not going that far. I think that a little bit of structure with some constraints on time can help make the most of the time. Additionally, I have heard from some conference organizers that you can’t even get some companies to sponsor sending people to a conference without presentations from industry experts.

Boriss had a user experience workshop that followed a good format: she did a few minutes of intro followed by demonstrations of applying her UX research suggestions to projects that people were working on. William Reynolds told me that he also ran a workshop session on the topic of getting people involved with Mozilla. Individuals can take matters into their own hands this way, and I wish I had done so myself (there’s always a next time!). I’d like to see conferences that encourage and support this even more.

How can this format help with the problems I talked about?

1. the sessions spend most of their time in a two-way exchange between the “expert” and the participants, thus making better use of the bandwidth
2. when communication is two-way, there’s more opportunity to overcome language issues than when you have a presenter following a predefined outline. In fact, sessions that involve group discussion could possibly take place in the group’s native language. (Of course, if everyone involved speaks the same language, then there’s no problem. Some of the MozCamp sessions were held in Spanish… of course, that left me, and some of the Brazilians, out.)
3. More of the stuff that might get discussed on the “hallway track” can now get discussed by more people during sessions
4. Ideally, there would be a bit more buffer time to handle schedule slippage and sessions that are so good that people just don’t want to stop

I still find conferences valuable and will continue to attend them, but I think we can do better.

Firefox is very fast. In fact, Firefox and its competitors are so fast that most web developers only care about one aspect of web application performance: network access. Latency and the amount of data transferred are the biggest issues for most web developers. We’ll be working on providing insight into network access soon in Firefox.

Developers working on three sorts of web applications in particular are asking for deeper insight into what the platform is doing:

• games
• complex layouts involving large amounts of data
• applications that have features you’d traditionally associate with “desktop applications”

Each browser has different performance characteristics, and these developers need tools that give them hints on how to make their apps responsive on each browser. They care about things like garbage collection pauses, repaints and reflows and hot spots in their JavaScript code where the just-in-time compilers aren’t able to make the JS zoom.

Most web developers aren’t working on these kinds of apps, and we’re focused on building tools that are useful for the “most common tasks”. However, we want these kinds of applications to run well on Firefox. Firefox developer tools really serve two groups: the web developers who use the tools directly, and the hundreds of millions of Firefox users who are looking to experience the web in the best way possible.

I think that our focus needs to remain on building the best tools for the most common tasks. But we also need to accommodate these sophisticated developers. Fortunately, we have more options than just “build it” or “don’t”.

For a feature to ship in Firefox, it goes through a lot of work to ensure that the feature is of a quality that is ready to ship to many millions of people and in many languages. The developers building these performance intensive apps do not number in the millions, and they are capable of installing add-ons. Some are even willing to produce their own custom builds of Firefox, if that’s what it takes to get the performance data they want.

In my opinion, that’s the planning lever we need to pull here. We can try to get these developers the data they need, albeit in a rough form, in add-ons as soon as possible. Along those lines, Brian Hackett has made his JIT Inspector tool available as an add-on.

If you need help figuring out performance issues with your application in Firefox, get in touch.

I’ve been working on developer tools for a while now, and I’m really proud of what we are shipping in Firefox today and the new features that are right around the corner. Browser tools are one of the most important parts of a web developer’s toolbox.

But, there’s a lot more that goes into web development than the browser tools. The video above and the text that follows are some thoughts on the whole of the web developer’s experience.

Web development is great because the platform is so high level and dynamic. That makes it easy to get started. There’s a massive collection of libraries, tools, books, tutorials and more to help web developers get things done once they’ve moved beyond the first steps. In fact, there’s so much out there that it can be hard for someone getting going to decide how to go from idea to done. The riches of the web ecosystem are both a blessing and a curse. It’s more blessing than curse, but that doesn’t make it any easier for newcomers and, in some instances, for experienced developers that are moving into a new area or applying a new technology.

Mozilla’s non-profit mission is to protect openness and innovation on the web. We want to make the web better for everyone, and I think we’re in a good position to help guide developers from idea to published app. Doing so is especially critical for our Apps initiative.

To that end, Daniel Buchner and I will be looking beyond developer tools in our product plans to include the whole of the developer experience. This will first show up in an Apps context, but we’re going to look for ways to apply what we do more broadly.

This week, the Firefox 2012 Roadmaps went live. Mozilla has a lot going on and huge goals for 2012. We have a lot to do and the web will be in a better place as a result.

Developer Tools in 2012

It’s been two months since I posted the 2012 developer tools roadmap. I thought that the new attention on the larger Firefox roadmap gives me a good opportunity to reflect on where developer tools is now and what’s coming in this year.

I want to start by saying that I think the Firefox developer tools team is doing amazing work. They’re shipping big features, great refinements and handling the growth of the community well.

This year, we’re filling in a new set of bundled tools for the most common web development tasks. Two weeks ago, we had our first big release of the year. I’ve been watching the feedback in various channels and it has been overwhelmingly positive. People have seen that we’re offering:

• Streamlined user interfaces on…
• Fast and well-tested tools that…
• Meet the common needs in new and better ways

I really appreciate all of the constructive criticism we’ve gotten. Ryan DeBeasi wrote in “New Developer Tools in Firefox 10 and 11” for Web Designer Depot:

There’s no user agent switcher, no “edit as HTML feature,” no performance-testing tools, no way to inject new tags into a page, no way to activate an element’s hover state. There’s not even a “layout” panel for viewing the dimensions, padding, and margins of your element.

Despite all those limitations, I keep coming back to the Page and Style Inspectors. I come back for the uncluttered interface, the thoughtfully placed panes, and that funky purple chrome. I come back because they’re a pleasure to use, and because they meet my needs most of the time.

Yep! That’s all true. And Tyler Herman’s recent Impression of Firefox’s New Developer Tools offered similar sorts of feedback. Those two articles are representative of much of the reaction I’ve seen surrounding Firefox 10’s release.

We’re happy that you think we’re off to a good start. We know we’ve got more work to do, and we’re listening. In the coming months, watch for new tools and improvements to the ones we’ve shipped.

Along those lines, a huge chunk of work for the new JavaScript debugger has recently made it into Nightly. It needs some more work before it’s usable and shippable, but the debugger is coming. As Panos mentions in that blog post, this debugger builds on entirely new infrastructure. More on that in a moment.

Mobile

Mobile is huge in Mozilla’s roadmap for 2012. We’re working to ship a new Firefox for Android with a screaming fast native UI. The Boot2Gecko project is working on an entirely new mobile phone OS that is truly open source from top to bottom and from the very beginning of the project. Plus, B2G is open web all the way.

Our focus in developer tools is on tools that live in the desktop browser for the common web development cases. That doesn’t mean we’re not thinking about mobile. We don’t think that people want to do mobile phone development on their mobile phones, hence the need for great desktop tools. Tablets are another story, but we still think that desktop OSes will rule development for some time to come.

The new debugger that I mentioned is built around a client/server architecture. In other words, an app running on in Firefox for Android could be debugged by a desktop Firefox browser. There are infrastructure changes underway in the Web Console that will help make remote access possible in the Web Console as well. We need to do non-trivial user interface work to expose this kind of feature, but the technical underpinnings are falling into place.

There’s another option that works especially well for Firefox: making the desktop browser pretend to be a mobile device. Firefox on the desktop and Firefox for Android generally follow the same release schedules and rely on the same rendering engine, which means that the desktop should be able to behave quite closely to the way the mobile device does. Again, there’s work to be done before we can ship this and that work depends on us having our core desktop tools fleshed out.

Apps and Add-ons

From the perspective of the code a developer creates, Mozilla’s “Apps” initiative is not all that different from standard web development. Apps use the latest web specs and have a little bit of wrapping around them. But, Mozilla is working to build a whole bunch of infrastructure around Apps to make the end-to-end user experience fantastic.

The tools that we’re building for web developers should be immediately applicable to Apps. Beyond those tools, though, providing the best possible end-to-end developer experience for Apps developers is something we’d like to pursue.

Similarly, Firefox Add-ons built with the Add-on SDK are mostly built from the same kinds of technology web apps are built. Ideally, the tools that developers can use for the web could also be applied for Add-ons.

Daniel Buchner now reports to me as the product manager for Apps and Add-ons Developer Tools. He’ll be helping to identify the best opportunities we have in these areas.

Firebug

I also wanted to give a shoutout to the splendid work coming out from the Firebug team. Firebug 1.10 (currently in alpha) is going to be the first ever restartless version of Firebug. The code organization changes that they’re making will make Firebug an even easier project to contribute to than it has been in the past. And, of course, new user-facing features are part of 1.10 as well.

Many ways to get involved

Everything we do at Mozilla is open source and for the betterment of the web. Those of us working on developer tools at Mozilla want to make web development easier and more fun. You can help in a variety of ways:

• Run Firefox Aurora. Aurora is two releases up from the current Firefox release. In my experience, Aurora is remarkably stable. By running Aurora, you get a sneak preview of coming features and a chance to help us spot minor irritations before they go out the door.
• Give us feedback! Feedback helps guide us, and we love to hear from web developers.
  • Hit the feedback button on the toolbar of Firefox test releases (Aurora and Beta).
  • email dev-apps-firefox,
  • join the weekly meeting,
  • talk to us on IRC,
  • email me,
  • send me a tweet (@dangoor)
  • plus me (is that a thing?).
  • It doesn’t matter how. Just get in touch.
• Blog your feedback. If you can fit your thoughts in 140 characters, go for it. Apparently, I’m too verbose for that!
• Show off cool stuff. Like a little city that magically appears in the Page Inspector 3D view (you’ll need Firefox Beta for that).
• File bugs
• Pick up a “Good First Bug” or otherwise get involved in the code

I hope you enjoy the new tools in Firefox 10 and beyond. They’re just the beginning of what we have planned for 2012.

Firefox Aurora has a fairly small audience, but it represents a good time to start collecting feedback on new features. Firefox Beta has a much larger audience. Both Aurora and Beta have a handy “Feedback” button in the toolbar, and I thought that now was a good time to dive into that feedback since we’re reaching the end of the Firefox 10 beta cycle. Firefox 10 is a big deal, because it adds the Page Inspector and related tools for web developers.

In this post, I’m focused on the input that we’ve received from the Feedback button. We get input from many other sources as well:

1. user studies
2. blog comments
3. Twitter/G+/Facebook (mostly Twitter)
4. Google Alerts (blog postings, press articles)
5. Bugzilla
6. dev-apps-firefox
7. irc.mozilla.org #devtools
8. surveys
9. and, of course, the Feedback button input from Aurora and Beta users

I’m probably forgetting some input channels.

Those of us working on Firefox developer tools have ideas of what we (as developers ourselves) would like to see in the tools. Hearing from other web developers goes a long way toward making sure that we’re doing the right things to make tools that work well for many people.

Keep the input coming!

Summary of Input

The entries from the Firefox Feedback button are collected and searchable at input.mozilla.com. I went through the input for a variety of searches going back to mid-December to get an idea of what the sentiment was like.

During that time, I counted 63 positive feedback entries for our new built-in tools and 22 negative entries. That’s 74% positive. Across Firefox as a whole, most people (between 55-65% over the past month) who hit the Feedback button did so because they found some aspect of Firefox they didn’t like. People are going out of their way to say that they like the new tools, and that’s fantastic.

Firebug has its own feedback channels (a mailing list, bug tracker, etc.), but we get some input about Firebug via the feedback button. I saw 36 positive and 22 negative entries, which is a 62% positive rate. Again, this rate is much better than the overall and the sentiment that I’ve seen toward Firebug in other channels has been super positive.

More interesting information comes up when you look at some of the specific feedback…

Recurring comments about Firebug

Of the 22 negative comments about Firebug, 10 were about Firebug crashing, or the browser crashing in conjunction with Firebug. People working on Firefox and Firebug take crashes seriously, so I hope that people file bug reports or ask for help for these kinds of problems. It turns out that there is a known crashing problem that is fixed in Firefox 10 (due on Tuesday). Let’s see how these numbers shift after 10 is released.

Five comments about Firebug reported a problem getting Firebug to run on the user’s version of Firefox. I find this a bit unexpected, because Firebug has broad compatibility these days. See the listing at the top of this blog post about Firebug 1.9. If I had to guess, I’d say that this problem is because some people did not get their copy of Firebug from addons.mozilla.org. Hopefully, the number of people getting Firebug elsewhere (getfirebug.com) has been dropping. Firefox Nightly users need to get Firebug from getfirebug.com, but those of us running Nightly generally know the risks we’re taking, right?

All of that said, the majority of comments about Firebug were along the lines of “I love Firefox because of Firebug”. Some of them were marked as praise with the simple comment “Firebug”.

Recurring comments about the Firefox Developer Tools

Three people stated that the tools should live in add-ons because the user is concerned about memory bloat and speed. On this point, it’s worth noting that every commit to the mozilla-central repository (from which Firefox is built) is checked for memory usage and speed. The tools we’re adding to Firefox do not negatively impact Firefox’s memory use and speed.

On the flip side, six people stated that they like having the tools built-in.

Three people said that they don’t think we should be duplicating Firebug. I’ve written about this already, so I wont rehash it here.

Four people want a “layout view” that shows margins, padding, etc. for an element. Those people are in luck! We’ve got a patch in progress.

Quotes like “THE NEW DEVELOPER ELEMENT INSPECTOR IS SO SLICK!!!” and “3d Web Developer Layering. (Ctrl + Shift + I) This is SO helpful!” reflect a lot of the sentiment in the positive feedback.

Thanks, and I’m looking forward to more!

The release of Firefox 10 and new notices for Aurora and Beta users will likely net us more feedback in the coming weeks. We’ll be listening!

I’ll close with this tweet from Brian Blakely:

“Perhaps the next-generation webdev IDE will be a browser. Somewhat related, FF’s dev tools are really coming along”

Since my last update, I had some back-to-back busy-ness. First, I was prepping and presenting at the 1DevDay Detroit conference. I spoke about a number of web developer tools there.

That was followed by a work week in San Francisco and Mountain View. Mozilla’s product team is working on the product roadmaps for 2012. You should start seeing drafts coming out for review and comment soon.

I also did three more user interviews. These have been very interesting, and will undoubtedly improve our product plans. I’ve also heard about some other user research going on at Mozilla around app development that may have some interesting information for developer tools as well. Once I figure out the best way to package up the research we’ve been doing, I’ll get it posted.

Aurora 10

The most exciting news is the release of a new Aurora build last week. Five of our feature pages landed for Firefox 10. You can find a more coherent version of what’s exciting about Firefox 10 (due January 31, 2012) in this Mozilla Hacks article that I posted yesterday.

New Feature Pages

Consistently, the users I’ve interviewed use the console, CSS tools and network request timeline the most. We have other data that shows a great many users also use the debugger features of web development tools. We now have a console, CSS tools and a debugger in the works. That leaves a network timeline, for which we’re figuring out scope and a plan.

In the meantime, I added feature pages to cover a couple of things that didn’t make it into Firefox 10. The enhanced property views page is about making the way CSS properties are displayed and edited in the Style Inspector even better.

The Layout In Highlighter page is for adding a feature that web developers find useful in other tools: being able to see margins and padding around an element right around the element itself on the page.

I had created a page to track against our plans for multi-process (“electrolysis”) Firefox. The engineering team has decided to take other approaches to improve Firefox’s responsiveness, which means that we don’t need to tackle multi-process rearchitecture work right now.

A Comment on the Feature Page System

Something that has felt a little awkward to me about our feature pages system is that improvements (like the “enhanced property views” above) to previously shipped features need to either get glommed together into a feature page or just live as bugzilla bugs. So, there are actually two places (feature pages and bugzilla) where useful work to be done or things that have been done can appear.

The line for me seems to be that bugzilla is used for the details of implementation and prioritizing the parts of the implementation that need to happen. The feature pages provide higher level context of what we’re trying to accomplish.

If you’re interested in helping out with Firefox web developer tools, I’d suggest looking at our Get Involved page which has links to both our feature pages and to our bugzilla bugs.

As the product manager for Firefox developer tools, I am most heavily involved in the creation of these feature pages.

We had a feature page that conflated two different concerns with a joint user interface. While the user interface we talked about might be a great way to go, the two features have different priorities and it’s worth considering other approaches properly. The more important feature is the ability to lock in a pseudo-class when working on the styling of a page element. For example, viewing the styles for the element as if you were hovering over the element. This is high priority because web developers have no way to peek into the details of hovered styles without tools support. Once they’ve moved the mouse from the page element to the tools, the element is no longer hovered!

The Web Console’s queued messages display is a feature that will allow the Web Console to display messages logged from before the console was opened. There was some complexity found during review of the code and, given the other things on the plate for Firefox 10, this feature is not likely to make that release. This is definitely still a feature we want, but I have dropped it down to P2 to reflect that the other items on the list are higher priority.

There are also some recent additions to the feature pages:

• Tilt in the Page Inspector adds a 3D view to the forthcoming page inspector (aka highlighter). Victor Porof recently wrote about the add-on which has a whole bunch of interesting features. The core 3D view is something we want to be directly available in our tools, as it will help people solve nesting problems in their markup.
• CSS Source Mapping The buzz around source mapping continues to grow (see this recent issue for HTML5 Boilerplate) and CSS needs source mapping for exactly the same reasons that JS needs source mapping.

I created some other stub feature pages, and I’ll write more about those as they’re fleshed out.

I’ll be writing more about Firefox developer tools feature ideas from this point onward. Your feedback is always welcome. You can talk about ideas on dev-apps-firefox or contact me via email, Twitter or G+ (see the sidebar on my site).

Tony Chung (far left) talking to a student. That’s Julie Deroche on the far right.

I had a good time talking with the students and I’m sure that many are laying a path to successful careers in software. At the end of the day, one thing stuck out in my mind as being unexpected: where was the open source experience? I think that only a single resume I saw mentioned a GitHub account or some open source project that a student was involved in.

Many students just had their coursework to talk about. Here’s the problem with that: every other student has that same coursework. Using different paper for your resume is not going to make you stand out. Having something beyond your coursework will.

US News ranks the University of Michigan as one of the top 15 grad schools for computer science and in the top 30 undergrad colleges overall. Ann Arbor is not a big city, but the University of Michigan is a big, well-regarded school. UM is not a JavaSchool as almost all coursework is in C++. While I can’t say for sure, I doubt that this lack of open source experience is limited to UM.

I’d also expect that many students who are fans of open source software would likely gravitate to a Mozilla booth.

The students that seemed the most promising to me came across as loving to code. They did things beyond their coursework, in their spare time… They learned Haskell or programmed robots or compilers.

A great way to show your enthusiasm and your code is to be involved in open source.

It would be good for universities to offer a course specifically designed to introduce students to open source and get their code out there. Students would learn about:

• distributed version control
• working with people around the world
• navigating open source projects (using GitHub, mailing lists, IRC, etc.)
• possibly bits about licensing (it’s good to know the basics, at least)

And, they would even end up with code samples out in the wild that they can show to potential employers.

Remember what I said about everyone having the “same coursework” to show to potential employers? Not so for a class like this if the students are allowed to dive into different open source projects. You’d have students hacking on Rails or Node, Couch or Mongo, CoffeeScript or nginx. It’s good for the students, and good for the projects.

If you’re a student, don’t wait for this magical class to show up. The catch 22 of “can’t get a job without experience, have no experience because can’t get a job” no longer applies: anyone can step into open source. Just do it!

Poor Bugzilla. It started life as an innocent bug tracker and has come to be counted on as the source of truth for a collection of significant software development projects, and the workflow tracker of Mozilla’s development process.

As manager of Mozilla’s developer tools group, I was responsible for keeping an eye on how our projects were moving toward completion. It very quickly became apparent to me during the Firefox 4 cycle that getting code through the process was just as important as writing the code in the first place. At the time, “through the process” meant gaining blocker/approval status in addition to getting a slot on the super busy review queues of browser peers and successfully managing the back-and-forth of the review process. There is no query you can run in Bugzilla’s web interface to show you how bugs are doing in this process.

Enter Bugzilla’s REST API. Using this API, you can gather whatever data you need from Bugzilla and munge it any way you want. Even better, you can use this API entirely in client side JavaScript, even cross-domain. For my initial report, which showed where a given bug was in the Firefox development process, I had a bunch of code in the page to gather and format the data.

More recently, I’ve made that code more generic and given it new superpowers. It’s called Buggerall, it’s lightly documented CoffeeScript and it’s available on GitHub.

In my new role as product manager for developer tools, I want to be aware of how things are going with the projects, but at a higher level. I also want to be able to track developer tools work as it relates to Firefox features. To that end, I have created a project status page that builds on Buggerall to give me (and anyone else that’s interested) a view into developer tools work.

Some interesting features of Buggerall:

• run queries easily
• you can serialize the result so that reports (like my status report) can use cached data and load very quickly
• but you don’t have to! queries can be live and cross-domain
• new Timeline object lets you gather a feed of events for the bugs in a query

My status page has an updater script (invoked from an update page in the browser) that runs the queries using Buggerall and then mashes the data down to a simpler format used by the status page. The updater uses a Firefox-specific API for saving files which I found in TiddlyWiki.

The status page is built around project metadata that I set up. This metadata allows me to group together arbitrary collections of bugs, which is very handy. This can be done with meta bugs in Bugzilla, but it takes a lot more work to do so. Also, since this is all in git, it’s easy to collaborate with other people on the metadata.

I’m always interested to hear about other techniques people have for getting useful info out of Bugzilla. The query interface that Bugzilla provides is quite powerful on its own, but the REST API makes it easy to gather any data you need and present it any way you want.

I’ve had a lot of fun this past year and learned quite a bit along the way. A year ago, I knew very little indeed about Firefox development. I’ve come to have a good handle on the process, which has changed dramatically along the way, and a decent grasp of the technology used in Firefox and how it all fits together.

The team has been fantastic: Rob Campbell and David Dahl got things rolling before a DevTools team even existed. My Bespin partners-in-crime Joe Walker, Patrick Walton and intern Julian Viereck joined the effort. New intern (now full-time) Mihai Sucan was characteristically sanguine about being told he was going to work on Bespin only to find out just before starting that he’d be working on Firefox. We worked hard on the Web Console and Inspector tools for Firefox 4, with the Web Console making the cut and shipping in March along with Firefox 4.

Along the way, Julian left for the university and Patrick moved to working on Rust.

We knew we wanted to go a lot further. Jan Odvarko, who is one of the lead developers of Firebug, officially joined the team. Dave Camp, a long time Mozillian, returned in February with a desire to make developing for the web better. In April, we were joined by Cedric Vivier, Kyle Simpson, Mike Ratcliffe and Panagiotis Astithas. In June, Paul Rouget joined the team, bringing his considerable insight and experience as a longtime developer evangelist at Mozilla. We’ve also been joined by Nick Fitzgerald as an intern for the summer and Victor Porof who is working on a Google Summer of Code project for developers.

This is an awesome team of people and I’m very proud to be working with them.

This blog post is not one of those “it’s time to move on to bigger and better things” posts. Web developer tools is an area with a lot of work to do and boundless opportunity. Taking care of the team and the projects as we’ve grown is easily a full time job and, in May, I raised my hand and told my manager that there’s work that needs to be done that I don’t have time to do.

Luckily, we had someone willing and able to take over the work I was doing in managing the engineering team: Dave Camp. Dave is a sharp engineer and is excellent at helping people lay out a path from point A (nothin’) to point B (working feature). He’s also got a very good sense for Mozilla and working out in the open.

Product Manager, Developer Tools

Which finally brings me to my new position: Product Manager for Developer Tools. Product management is one of those roles that shows up in different places in different organizations. At Mozilla, we have a dedicated product team led by Jay Sullivan. As part of this team, I’ll be able to do the work that I have had little time to do over the past few months, but is necessary for our success.

My responsibility as product manager is to represent the interests of web developers in designing and prioritizing features that will help them build better sites and applications more easily. I’ll do this by taking input from a great many sources (in no particular order):

• Mozilla’s developer engagement and market research teams,
• the developer tools engineering team,
• web developers I talk with directly, and
• things I read (and I read a fair bit)

With that input in hand, I’ll boil it down to roadmaps and ready-to-build feature specs. Dave Camp and the engineering team will take it from there to iterate on the features and get them to users. And we do all of this out in the open, ready for feedback and help all along the way. Mozilla really is an open organization and community. New product development is among the most secretive parts of most organizations, but not for Mozilla.

I also see communicating about what Mozilla is doing in developer tools as an important part of my job, so you can expect to see more blogging from me here and on the official devtools blog.

Now, onward to the new challenges!

Update: holy cow! I forgot to mention the three most recent additions to the devtools team (sorry Paul, Nick and Victor!) That’s what I get for blogging quickly while I’m still digging out after getting back from vacation.