The Add-On SDK is pretty slick

I’m somewhat embarrassed to say that, even though I have worked alongside several of the Add-On SDK developers for years (or “Jetpack developers” as we used to call them), I had never used that Add-On SDK (or “made a Jetpack”, as we used to call it). Until now!

F1 is great if you want to share links via Facebook or Twitter. But that’s not how I want to share links; I want to share them via this blog, or for stuff that’s not Mozilla/web/software/usability related, via my personal blog EvilBrainJono.net. For this site, I can use the WordPress Press This bookmarklet that takes the URL of your current page and turns it into a WordPress blog post. But EvilBrainJono.net is a mess of custom Python scripts I’ve been hacking at sporadically since 2004. Nobody’s writing add-ons to interface with that.

Yesterday I realized that I wanted a very simple “share this page on EvilBrainJono.net” add-on, and that it would be a perfect excuse to learn the Add-on SDK.

Add-on SDK 1.0b1 was recently released, so I downloaded that and then followed the tutorial.

The SDK gives you a command-line script to run that adds several commands to your shell environment – commands to run tests, build XPIs, and to “run”, which launches a Firefox instance with your add-on running on a throwaway profile. This makes the development cycle pretty quick as each time you make changes to your source, you just save, alt-tab to the command line, and do a “cfx run” to see your changes in action.

The tutorial holds your hand and walks you in very small steps through building your first add-on. The SDK launches a special documentation server, which lets you browse through the tutorial and documentation – including documentation for your own modules in development, automatically generated from your source code and readme files. The documentation server also provides full reference on all the built-in modules, which handle many common add-on tasks for you. If what you want to do is within the scope of the built-in modules, then writing an add-on requires little more than gluing modules together. I was able to implement my quick-blog add-on very quickly by using the widget and panel modules to make the UI, the tabs module to get the URL of the page to share, and the request module to send the data to my web server. Whenever I got stuck I referred to the examples bundled with the SDK; the Reddit example in particular showed me almost everything I needed to know.

The API is very clean and simple; everything works just the way I expected. It uses a terse, nested, functional idiom that will seem very familiar to you if you’ve ever written web pages with jQuery. The one part that took a little getting used to was using postMessage() to communicate between my add-on’s main.js and the content script running in my panel; and even that was very straightforward once I grasped what I needed to do.

Overall it was one of the nicest experiences I’ve ever had learning a new development environment / API. The batteries were included, the examples were relevant, the modify-run-debug cycle was quick, error messages were helpful, and within a couple hours of downloading the SDK, I had a usable feature. It’s at least an order of magnitude less work than learning the old way of writing extensions with XUL. If you’ve shied away from trying out earlier versions, 1.0b1 is a great time to give it a shot.

This add-on is not exactly something that anybody besides me is ever going to want to run; it’s hard-coded to work only with my admin account on my website and nothing else. But that’s part of the beauty of the Add-On SDK: It makes the cost of development so low that it becomes worthwhile to write a single-serving add-on to satisfy a very specific need.

 

Improving the Discovery Path for New Contributors

One of the reasons that Openness is a lot of work is because you need to create a path for new contributors to A. discover your project and B. figure out how to make their first contribution.

It’s not easy to get this path right! I myself have “bounced off” of several open-source projects, so I know what it’s like. Potential contributors come in eager to contribute something to the project, but they get confused about how to proceed, or they’re met with a total lack of enthusiasm, or they have their contribution rejected due to technicalities like not following correct coding style. (I know that coders have strong feelings about whether to put spaces inside of parenthesis or not, but is it really more important to enforce this than to gain contributors?) Anyway, they get discouraged, lose their motivation, and “bounce”. Even when people are willing to contribute for free, their time is still valuable to them, and if they don’t feel a sense of progress soon, they’ll invest their time elsewhere.

I recently gave a recruiting talk at a university, and met a bunch of students who were eager to contribute to Mozilla. They asked me how to get started, and I realized that I don’t have a good answer. If someone wants to contribute to Test Pilot (yes, please!) do I start by directing them to the Google discussion group? The #labs IRC channel (which is dead most of the day)? Do I point them to the open Bugzilla tickets? Or do I ask them to read several pages of Wiki documentation (some of which is may be out-of-date) just to get up to speed, before doing anything else?

If you want to get involved in Test Pilot, the openness is there and the information is there; but the information is spread out across a world of different websites, mailing lists, and other services, and it’s all rather overwhelming. Where does a prospective volunteer get started? This is not a problem unique to Test Pilot, of course; all of Mozilla struggles with it to some extent.

I’d like to hilight a couple of links that show promising approaches to removing obstacles from the discovery path.

First is the work Richard Milewski, a community member (and frequent Design Lunch participant) who pointed out to me how hard it was for someone outside the Mozilla organization to make sense of the raging river of information we output and figure out what was important. Rather than just complaining, though, he went ahead and did something about it – he built a website called Mozilla Express to aggregate in one place all the information sources he was interested in.

The second is OpenHatch.org, which aims to be a one-stop portal where you can find open-source projects that need help, find something that needs doing, and find out exactly how to do it.

I’d be interested to hear from you about your experiences on either side of the discovery path – if you’re in a project, what have you tried to do to make it easier for newbies to get started? If you’ve been that newbie trying to join a project, what was your experience like and what made you stick with it or give up?

 

Openness is a lot of work

You can’t just make something “open” and expect magic to happen. Openness is a lot of work. This is true whether you’re making an open-source software project, a website with user-generated content, a political movement, a charity, or any other kind of organization where you expect volunteers to show up and start doing work for you.

I emphasize this because openness has become quite the buzzword over the last decade, and I worry that people are starting to attribute near-magical powers to it. I wonder if books like Here Comes Everybody: the Power of Organizing Without Organizations by Clay Shirky, or The Wisdom of Crowds by James Surowiecki are over-selling the idea. Being in Silicon Valley I hear a lot about startups based on a “crowdsourcing” business model, or new open source projects run by people who assume that just because they open-source their code, they’ll magically get contributors. Lately the phrase “… ANYONE can participate!” seems to be de rigueur in every presentation.

Let’s say I’ve got an idea for a software project and I want to make it open source. So I put up a public code repository on my website, write a page about my patch submission policy, and start an email list for discussion. Great! I’m done now, right? I can declare my project “open” and go back to hacking now?

This project may be “open” by a technical definition, but if you look at the commit log, I’m still the only one working on it or using it. Where’s my windfall of free volunteer effort?

If I want to be open in a practical and not just a technical sense, I need to get people interested in participating. That means proselytizing my project, building a community, selling people on the idea: doing marketing. That’s a lot of work right there, and none of it gets code written.

Next, suppose some interested volunteers contact me and ask how they can get involved. If I say “Go read the issue tracker and find something to do, I’m busy”, I guarantee they will not remain interested for long. I need to invest some time in building a connection with each and every volunteer I want to integrate into my project. I need to explain to them how things work, answer their questions, find easy tasks to give them, and continue to act as their mentor until they understand the project as well as I do. I am making a substantial investment up-front that I hope will pay off in the long term. Until then, it’s an additional burden on top of my existing workload.

 

Improving the Mozilla monday meetings: Brown-bag talk this Friday

Mozilla has a general meeting every Monday morning, where each team gives an update on their project status. One of the many things that makes Mozilla so unusual as an organization is that this meeting is public. The video is broadcast live on the web at air.mozilla.com, and there’s also a public phone number which you can call in order to listen in. (All the contact information is on this page.) I once told a guy who works for Microsoft about our public meetings and his head nearly exploded.

Anyway, I was recently asked to take over the role of moderator for these Monday meetings, as the previous moderator is leaving. I was very honored to be asked, and I take it as a very serious responsibility.

As I see it, part of the responsibility of running this meeting is making sure that it doesn’t waste people’s time. Because so many people are taking time out of their day every week to attend this meeting, it represents very “expensive” time, in terms of person-hours. It should focus on only the absolutely most valuable information, not just routine status updates. I think that a couple of small tweaks to the meeting format could go a long way towards making the best possible use of the time. So I’ve been working with various people to come up with a list of proposals for how to do this. Call it “Meeting 2.0, Beta Version”. My ultimate goal is to make the meeting so exciting that nobody is even tempted to look at their laptops during it.

To give interested parties a chance to respond to the Meeting 2.0 Beta proposals, before we start implementing them next week, I’m going to be holding a “brown bag” (what we call lunchtime talks at Mozilla, despite the fact that almost no-one brings a brown bag). It will be this Friday, starting at 12:30pm.

You don’t have to work for Mozilla to be part of this discussion. If you are part of the community or even just interested in following what Mozilla does, then part of the purpose of the Monday meeting is to keep you in the loop about what we’re doing. Therefore, anyone is welcome to attend this brown bag, either in person or on the phone. You can also leave comments on this post if you have ideas for improving the Monday meeting. If you don’t currently call into or watch the Monday meetings, why not? And what do you think could be changed that would make you start watching?

Edited to Add:
If you want to watch, you can go to Air Mozilla. If you want to call in, you can do so using one of the phone numbers on this page, but using the conference room number #202 instead of the one listed there.