I’ve been involved in the judging pipeline for three competitions now. Today, I judged for an inspiring competition called Node Knockout, held by Joyent and Fortnight Labs.

The first two competitions I participated in didn’t scale. I wasn’t even a judge for the first one—we had a tiny handful of celebrity judges who couldn’t possibly review all of the submissions, so me and some colleagues furiously attempted to cull the list down for them. It wasn’t fun, and there wasn’t any way for the public to participate in the judging process. It also wasn’t really transparent—I was part of the process, yet everything I did was hidden from the public, including any valuable feedback I may have been able to give the entrants.

In the second competition, I was a judge for one of the rounds, but there were so many entrants that I simply didn’t have time to carefully examine each one. It was exhausting, and I didn’t even feel like I was able to give each entry the time it deserved.

In stark contrast, judging for Node Knockout was an amazing experience on three levels.

Knockout judging was participatory. Instead of a tiny handful of judges, Joyent and Fortnight Labs actually enlisted a small army of industry experts, including three of my coworkers. The public could participate, too: ultimately about half of an entrant’s “rating” was determined by them and the other half was determined by the judges. In some sense, the judges were just a pool of “trusted voters” whose votes were weighted more heavily than everyone else’s.

Knockout judging scaled. Since there were around a hundred entries total, the contest runners only required each judge to evaluate 6 or 7 assigned entries, allowing them to carefully examine each one and provide useful feedback. This allowed me to spend lots of time on each one and come out of the evaluation process feeling excited about the competition instead of exhausted.

Knockout judging was transparent. Furthermore, everyone’s comments and ratings were completely public, effectively constituting a body of valuable feedback the entrants could use if they wanted to continue working on their project. Every entrant’s team had a page on the Knockout site that listed all the comments and ratings submitted so far; it read a lot like the comments on a blog post.

In short, Knockout wasn’t just a competition about the Web; it was a competition held in the spirit of the Web, too. Thanks to Joyent and Fortnight Labs for holding such a fun event!

I’ve recently been proud and inspired to see two new features land in the latest Firefox 4 betas: Web developers can now access the raw audio data in <audio> and <video> elements, and Firefox Panorama helps users manage their tabs.

In his excellent post Experiments with audio, conclusion, Dave Humphrey mentions the following Tweet from Joe Hewitt:

Bottom line: we can currently only move as fast as employees of browser makers can go, and our imagination is limited by theirs. @joehewitt

Dave goes on to say that not one person who did the audio work in Firefox 4 was an employee of the Mozilla corporation. He also mentions the following:

As much as Mozilla made it possible for me to experiment, they also made sure that what got accepted was of the highest quality. I haven’t blogged about audio much over the past three months, mostly because we’ve been too busy getting the patch fixed up based on reviews. Before it could land we had to think about testing, security, JS performance, DOM manipulations, memory allocation, etc. To get this landed we needed lots of advice from various people, who have been generous with their time and knowledge.

As far as I can tell from my discussions with individuals in the trenches at Mountain View and throughout the Mozilla community, this process of getting advice and approval from various people is the biggest bottleneck of innovation in Firefox. Some of my talented coworkers created an excellent feature called account manager that won’t be making its way into Firefox 4 because the feature’s patches weren’t able to be reviewed in time for Firefox 4′s feature freeze. The core work was done, but the team couldn’t find the human resources to make sure it passed Firefox’s technical standards.

Other colleagues of mine are working on new built-in developer tools for Firefox, but as I understand it, there are only one or two people in the world who can review their patches and approve them for landing in Firefox’s code repository.

Within Mozilla, I see my coworkers vie for the attention of this tiny handful of gatekeepers. People in charge need convincing; the clever social engineer has a lot of power when it comes to navigating this landscape. I don’t know how much of this happens publicly via IRC, newsgroups, demos, blogs, bugs, wikis, or other backwaters of the Mozilla megaverse, as opposed to private conversations. I’m not sure how much the distinction matters, really; it’s just unfortunate that after working at Mozilla for two and a half years, I still have no idea how high-level decisions are made, who the gatekeepers are, and how they are to be convinced.

Yet I’m also sure that convincing the people who hold the keys to change a product used by hundreds of millions of people is non-trivial at any organization, and probably with good reason.

At a broad level, Hewitt’s tweet was about the notion that there exists some kind of bottleneck between people’s imagination and the ability of browser makers to keep up with it. Dave Humphrey pointed out that the bottleneck has nothing to do with paid employees of Mozilla, since anyone can contribute. My observations indicate that the biggest choke-point at Mozilla right now is a social problem that Clay Shirky might call fame: an imbalance between inbound attention and outbound attention. Lots of people want to get great features into Firefox, but a very limited set of people are actually able to pay attention to them and get those features out the door—much less determine which features are actually appropriate for the hundreds of millions the product is broadcast to.

That’s all I’ve got for now; I’ll write about some possible solutions to this in Part II.

On Friday I attended CrisisCamp Silicon Valley. I didn’t really know what to expect, since I was unfamiliar with the nascent field of internet-facilitated crisis response and was unable to find a high-level overview of how people—both techies and non-techies—can really make an impact.

The Bird’s Eye View

As I understand it, this is the big picture of internet-facilitated crisis response:

1. People on the ground in a disaster are told, through various channels, to report what they’re seeing to the public through a variety of media: SMS, Twitter, Facebook, whatever’s easiest and most understandable for them. In the case of the floods in Pakistan, for instance, people are encouraged to report by sending an SMS text message to 3441, making sure to add FL to the beginning of the message.
2. These raw reports are collected or found by programs on the Internet that send them all to a site for processing by humans, who classify and categorize them in various ways: for instance, does the report represent an emergency that needs attention, or a dangerous obstacle that aid workers should be aware of? Does the report need translation from a different language? To what area of the disaster area does the message refer? In the case of the Pakistan floods, you can visit pakreport.crowdflower.com right now to do this yourself—all you need to enter is your email address, and you’re presented with a brief message that someone on the ground sent.
3. Multiple people actually process the exact same report, which allows a computer program to correct for errors and combine information in the various responses—much in the same way that having two eyes is better than having one. This means participants don’t need to get too stressed-out about accidentally providing inaccurate information.
4. The processed reports are then collected at another site on the internet, where they effectively constitute a public resource that anyone can use. The most obvious consumers of the data would be the relief workers on the ground. The public data set, its associated software, and its user interface is sometimes referred to as Ushahidi or an Ushahidi instance—check out the Wikipedia entry on Ushahidi for more background on why. There’s a Ushahidi instance for the Pakistan floods at pakreport.org.

If you’re familiar with real-time strategy games like StarCraft II, this whole process could be envisioned as crowd-sourcing a mini-map of a disaster area. The people involved in the crowd-sourcing aren’t directly helping in the sense of actually rescuing people, but their mediation between people on the ground is providing a valuable set of “eyes and ears” for everyone involved.

The Dirty Details

In practice, this process is a lot more chaotic than it seems, which creates new problems that need solving. For instance, while I’m very used to Google Maps containing highly accurate data about where I live, many of the cities, towns, roads, and other places mentioned in reports from Pakistan either aren’t visible on Google Maps at all, or are known by multiple names, depending on language and locale. Because of this, one of the ways people familiar with the disaster area can help is by using OpenStreetMap, a sort of cross between Wikipedia and an atlas, to add information about places that conventional commercial sources don’t contain.

While I was at CrisisCamp SV, one of the technical problems that needed a solution was the fact that Facebook was reportedly much more popular than Twitter in Pakistan; relief workers on the ground wanted to be able to tell the public that they could join a Facebook group and post their reports on its wall, but they didn’t know how to import the data from the wall into the site that processed raw reports, so I wrote a simple Python script to convert the wall data into an RSS feed using Facebook’s Graph API.

Crowd-Sourcing and Communities of Practice

The interesting thing about my contribution is that it was just one possible solution to a problem: humanitarian agencies on the ground didn’t actually know if posting to a Facebook group’s wall would be a solution that the population would use, but just having a solution available was better than complete uncertainty. I don’t typically write code when I have a low degree of confidence that the code will actually be useful to someone, but I nonetheless decided to write it up.

In general, a number of people I talked to at the CrisisCamp had a less-than-ideal degree of confidence that their individual contribution was providing concrete aid, but there was a lot of faith in the sum of what everyone was doing as a whole, the belief that people on the ground would benefit immensely from this crowd-sourced radar we were creating.

I’ve typically been very skeptical of the term “crowd-sourcing”, primarily because its use in language has a tendency to abstract away the notion of human individuality: people become fungible processors or gadgets that are doing things that we simply haven’t figured out how to do with computers yet. In a lot of ways, the language surrounding it dehumanizes us in the same way that assembly lines and mass production dehumanized the nature of work during the industrial revolution.

From this perspective, one of the greatest strengths of events like CrisisCamp, and organizations like CrisisCommons, is their ability to provide group membership, to create meaningful connections between people who want to help, and to create new kinds of communities of practice. If I hadn’t attended the CrisisCamp event, I certainly wouldn’t have written that Python script, but because of the social context—the notion that I would be creating something that could be recognized by people with similar interests and lead to connections with them—I found a lot more meaning in it than I otherwise would. This is, of course, the same kind of motivation that engages people to volunteer, to create resources for their World of Warcraft guild, or to contribute to an open-source project.

How Mozilla Can Help

A few days ago, Mitchell Baker wrote a blog post in which she wondered how Mozilla could help with humanitarian crises. One thing I noticed about the chaos surrounding the Internet-based efforts was that, like Mozilla, they were formed very organically: this meant that there were a plethora of activities going on which anyone could participate in, but the picture presented to a newcomer was confusing and messaging wasn’t always consistent. Tasks needed to be completed urgently; the changing landscape on the ground meant that problems and solutions were constantly changing, and assumptions were frequently challenged. Keeping the Web in-sync with reality could be difficult, especially since the Web doesn’t forget things.

Combined with the distributed nature of the solution, acquainting newcomers with a reasonably humane workflow for contributing was non-trivial: just processing a report on pakreport.crowdflower.org, for instance, often meant switching between tabs containing getlatlon.com, OpenStreetMap, and a Google Docs page containing advice and other resources. There was a lot of copying and pasting involved.

There’s many ways browsers could help with this. For one thing, addons or GreaseMonkey Scripts could make the experience of contributing easier. While I didn’t get around to it, for example, I could easily imagine an addon or Ubiquity command that mashed-up pakreport.crowdflower.org with getlatlon.com, OpenStreetMap, and other services to provide a streamlined interface, potentially eliminating the need to learn how to use those other websites and copy/paste. In other words, since the solution to these problems is on the Web, we can use the inherent hackability of the Web to make the solutions much easier to use.

Another thing I noticed was that the vast majority of browsing activity occurring while helping out was largely privacy-insensitive: reports were submitted from the ground with the expectation that they would become public, the CrisisCommons wiki was completely public, as was any activity on Twitter or even the Facebook group. There was also a lot of link-sharing and people looking at one another’s screens as they figured out workflows and discovered solutions, so the notion of a sort of “public browsing mode”, or perhaps a separate browser tweaked to broadcast all its activity to the internet or a specific group of people, is an interesting one.

Aside from that, some of the affordances present in the Mozilla community and other open-source projects seemed like they could help the CrisisCommons efforts a lot. As far as I could tell, for instance, there wasn’t any kind of real-time virtual space or chat room where the community could hang out. There also wasn’t any kind of issue tracker, which seemed like it could be useful, too.

In any case, CrisisCamp SV was a really interesting experience, and I’m looking forward to attending more events like it.

Early this year, I had to start using Mozilla’s Bugzilla, an issue tracker that, while incredibly powerful, nonetheless confused and intimidated me to no small degree.

One of my most basic needs was to have a simple display containing bugs of interest to me. I couldn’t find a page in the product that satisfied me, so I used Gervase Markham’s excellent Bugzilla REST API to create an HTML page that fetched the information I needed and displayed it.

The page is designed to be read from left to right, with the most important information appearing earliest. The first column, Things to Review, contains patches and other artifacts that I need to provide feedback on—it’s most important because it’s blocking other people from getting their work done. The next column, Assigned Bugs, contains items that I’ve elected to work on. The columns continue through Reported Bugs (open issues I’ve reported myself), CC’d Bugs (open issues I’m interested in), and finally Recently Fixed Bugs, which contains resolved issues from any of the previous columns that have been closed in the past week. Issues that might appear in two columns, such as a bug I reported and assigned to myself, appear only in the more important column to avoid redundancy.

I’ve also added a few features on the panel at the top-right corner of the page to help with some other pain points of Bugzilla that I ran into: Find A User makes it easier to locate someone in the system and view their dashboard, while File A Bug makes it easier to file a bug when you don’t know what product or component it belongs to.

The page, which a number of friends and coworkers have been using for the past several months, is now hosted on GitHub:

Feel free to use it. Since it’s all client-side HTML, CSS and JavaScript, you can also easily fork it and tinker with the code. Please file a bug if you find any.

One of the most interesting uses I’ve found for this tool is actually to get a bird’s-eye view of what other people are working on. At the login prompt, you can type any email address and leave the password field blank to see the public bugs that someone is subscribed to, which makes it an excellent window into Mozilla’s mostly-transparent ecosystem. For instance, here’s what I’m working on.

This is what a social network looks like.

Each dot represents a human being. Each line represents a social connection between two people, such as acquaintanceship, financial exchange, friendship, or love. The picture can become arbitrarily more complex as we take one-way relationships into account and add more dimensions to model particular interests and behaviors.

Much of the attention around technology these days has something to do with this picture. Authors like Clay Shirky write about amazing things that can happen when the amount of effort needed to transmit information through the lines is drastically lowered. Companies like Google harvest information from the dots to offer better services to them; products like Amazon’s Mechanical Turk harvest little slices of spare time from the dots to quickly complete otherwise unwieldy tasks; games like Zynga’s Farmville are designed to propagate through the lines like a virus.

Advertising companies and some advocates of open-source software don’t even refer to the dots as human beings: they call them “eyeballs”. The involvement of just one pair of eyeballs means just a few cents to a revenue stream or a single bug-fix in a software program, but when the process is scaled, it results in billions of dollars of profits or bug-free software.

Jaron Lanier, the author of You Are Not a Gadget, is not interested in dots and lines. Indeed, he finds it strange that the relationship between two people is reduced to a mere line, and that the people themselves are just dots.

Instead of reducing things, he claims, we should be using technology to deepen the connection between two people and make it more meaningful.

You Are Not a Gadget is a complex book. I originally bought it because, flipping through its pages at a bookstore, I found random fragments to offend me. Even though I don’t agree with everything the author has to say, I still found it a fascinating read that I’d recommend to anyone with an interest in technology and where it’s taking us.

I recently wanted to create a short, two-minute and thirty second “pitch” for the Herdict-Firefox integration prototype I’m working on with Jennifer Boriss, Laura Miyakawa, and Jeffrey Licht.

Here is the result. It turned out that the pitch itself was an experiment for me: after fiddling around with Screenflow and iMovie for a bit, I got frustrated with their limitations and decided to just use HTML to put together the presentation.

After writing out the script for the pitch, and recording my narration with Audacity, I saved the file as both Ogg Vorbis and MP3—different browsers support different formats—and set up a directory structure.

As with Mozilla: The Big Picture, I basically stuffed everything into the structure of an HTML page. The first two slides of the presentation, for instance, look something like this:

  <div id="slides">
    <div data-at="0.0">
      <a href="http://www.mozillalabs.com"><img
         id="logo" src="images/labs-logo.png"/></a>
      <h1>Firefox-Herdict Integration Pitch</h1>
    </div>
    <div data-at="4.0">
      <img src="images/server-not-found.png"/>
    </div>

The data-at attribute is an example of the HTML 5 data- attribute and records how many seconds into the audio the slide should be displayed. I marked up subtitles for the presentation in a similar way.

After that, I wrote some JavaScript that just attaches a timeupdate event listener to the presentation’s audio element and synchronizes the current slide and subtitle to its position. The result is something that looks and feels to an end-user like a YouTube video—one can even “scrub” the position slider to quickly rewind and fast-forward. However, I’d argue that this approach is actually superior to standard video in a number of ways:

1. Slides can have any valid HTML content embedded in them. Text can be copied and pasted, their look and feel can be altered through CSS; images can be hyperlinked to their original sources.
2. It’s easier to eliminate compression artifacts without sacrificing bandwidth and download size. Text, for instance, is always super-crisp.
3. Since everything uses HTML, CSS, and JavaScript, anyone can view-source or use a web inspector to investigate how things are put together; as I explain in The Open Web is Magic Ink, they can take it apart, see how it works, and put it back to together in a different way. Doing such things with a pure bitmapped video representation wouldn’t be possible: you’d need the source “project files” for whatever program was used to compose the video, not to mention access to said program.
4. Subtitles can be toggled on or off, and adding new languages isn’t hard.

This approach has its downsides, too, of course: there wasn’t a really easy way for me to embed the presentation in this blog post, for instance, and it can’t be viewed at all on Internet Explorer, as far as I know.

Still, it was a fun experiment to try, and for this particular use case I actually found it easier to compose everything using Open Web technologies than with the proprietary tools at my disposal.

Please be sure to check out the actual presentation, too, as the stuff we’re doing with Herdict is way cool.

Firefox’s extension platform is incredibly powerful and generative, but when I created my first extension in early 2008, I found a number of barriers to entry—difficulties echoed by a number of other newcomers I talked to.

For one thing, extensions were difficult to get started with. Perhaps the best indicator of this is Myk Melez’s video tutorial titled Extensions Bootcamp: Zero to “Hello World” in 45 Minutes, which actually ended up being 90 minutes long.

In May of 2009, we tried to resolve a number of issues for newcomers with our original Jetpack Prototype. The complex (but powerful) Gecko API was hidden behind a much simpler facade; no tedious setup was required to get up and running, and the effect of changing any part of your code was nearly instantaneous, obviating the need for restarts when developing or even installing a new Jetpack. Familiar, well-documented technologies like HTML and CSS were used to build interfaces.

Yet there were a lot of things lacking in this prototype. For one, Jetpacks created by developers required the Jetpack extension to be installed in order to use them. There was no mechanism for code sharing and reuse—not even any kind of packaging system, which made building on another person’s work or creating more complex Jetpacks very cumbersome. It also had no security model, which meant that Jetpack developers were effectively playing with a loaded gun: a single mistake in a Jetpack’s code could actually blow a security hole in Firefox that might expose the user’s computer to all kinds of threats from the web.

We wanted to fix all of these problems, but the one that presented the most challenge to us was that of solving what Jonathan Zittrain calls The Generative Dilemma: is it possible to make Firefox Extensions safer without compromising generativity? The sheer inventiveness of the Add-on Community—NoScript, Adblock Plus, Greasemonkey, and the tens of thousands of other add-ons out there—never would’ve been possible if Firefox’s extension platform wasn’t as powerful as it is. Enforcing some kind of “top-down” security model on Jetpack that told developers what they could and couldn’t do simply didn’t feel right.

Instead, it felt like a better solution would be to create the conditions for a secure platform and allow anyone to create capabilities that securely expose privileged functionality to it. Such capabilities, or superpowers as we sometimes call them, can expose any part of the Mozilla platform—which means that it’s theoretically possible for a Jetpack to do anything that a normal extension can do, while still obeying the Principle of Least Authority.

There’s a number of other features present in the latest in-progress iteration of Jetpack, which we’re calling the “reboot” because rebuilding it from the ground-up with the new goals in mind was much easier than continuing to hack on prototype code. We’re now using the CommonJS standard to make it easier to reuse code between Jetpack and other JavaScript-based platforms like the Web and narwhal, for example; Jetpacks are also now fully self-contained XPIs that require nothing but a Mozilla-powered application to run.

There’s a lot more to the reboot, but it’s all a little overwhelming to write up in one blog post. This is an indicator that I should’ve started blogging about this a lot earlier than today, and I apologize for that.

While the reboot is still in-progress and won’t be ready for “prime time” for quite a while, you’re welcome to check out the in-progress Reboot Quickstart and the various JEPs it links to. Please feel free to leave comments on this blog or post them directly to the Jetpack Google Group.

Back in July, the Mozilla Developer Tools Lab released an experimental memory tool that allowed a web developer to get a better picture of Firefox’s memory usage. That tool was a great start, but it had a few issues:

1. It was slow.
2. It showed the entire Firefox JS heap, which included lots of objects internal to Firefox that weren’t of much use to web developers.
3. It was a bit of a hassle to set up, as it involved freezing Firefox and accessing a local web server from a different browser.

I’ve spent some time trying to resolve these issues, and have a usable prototype for Firefox 3.5 that you can try out. The new tool has an entirely different front-end from the last one and runs in Firefox itself—no need to launch a separate browser. It also runs a lot faster, and allows you to profile the JavaScript memory use of individual browser tabs.

Here’s a screenshot. You can also click on it to read some annotations I’ve added through Flickr:

The above profile was taken while this page was open in a tab. Feel free to look at the page’s source code and compare it with the profiling output.

One of the first things you’ll notice is that there’s no information about actual bytes used. This is partly because we need to add more instrumentation to Firefox in order to get you really accurate information about that—something that’s currently being done with the advent of about:memory. But it’s also because raw byte counts aren’t necessarily helpful in debugging memory leaks in web applications: what’s really useful is information about what kinds of objects are staying in the page, which this new iteration of the memory tool tries to provide.

If you’re interested in learning how the tool works or hacking on the code, check out the wiki page and my Fun with SpiderMonkey blog post.

What I’m really interested in knowing is: do web developers find this useful? What could be added to it to make it more useful in diagnosing the memory use of a web application? If you’re a web developer, please download the addon, choose “Memory Profiler” from the “Tools” menu in Firefox, and let us know what you think!

Since learning JavaScript over a year ago, it’s become one of my favorite dynamic programming languages alongside Python. And as I’ve mentioned before, I think the two languages actually complement each other pretty well.

Python, at its heart, is a platform that’s built to be extended. The evidence for this is plentiful: there’s modules and packages out there that offer practically any functionality you want, from web servers to 3D game engines to natural language processing toolkits and more, all instantly accessible through a simple command or an installer download. Yet one of the costs of all this generativity has been the fact that Python doesn’t really have much of a security model to speak of: any Python program has as much access to the underlying system as the current user does, which, compared to the Web, is basically omnipotence. Creating programs that obey the principle of least privilege is pretty hard.

JavaScript, on the other hand, has many of the opposite problems. For one thing, it’s really built for embedding: until the very recent advent of CommonJS and Narwhal, for instance, the language has always lacked a general-purpose platform and standard library. A Pythonic way of saying this is that the language doesn’t come with “batteries included”, but this can actually be a good thing from a security standpoint: because the simplest possible embedding has no privileges and needs to be explicitly given all its capabilities by its embedder, it’s very easy to follow the principle of least privilege. Recent work on membranes and capability models puts JavaScript way ahead of many other languages in the security realm, yet the lack of a mature general-purpose platform has meant that anyone who’s wanted to leverage these strengths has always had to muck around in C/C++ to create the kind of embedding they wanted.

Well, to an extent. One of the many aspects of Java that I’ve frequently been envious of has been Rhino, a JavaScript engine written entirely in Java, which allows anyone who knows Java to create their own embedding solution that leverages Java’s strengths. But I prefer Python to Java, and moreover, the engine itself isn’t worked on with as much intensity as the JS engines that power real-world consumer products like V8 and SpiderMonkey—so new language features are slow to be implemented and performance isn’t great.

I’d briefly tried resurrecting John J. Lee’s Python-Spidermonkey last year but I soon discovered that it wasn’t really what I wanted. For instance, JS objects were copied into Python approximations as they crossed the language boundary, which resulted in a “lossy” transfer and prevented features like identity perseverance. It was essentially a high-level wrapper created to solve a specific problem, rather than a low-level tool intended to enable any kind of wrapping based on context (e.g., how trusted the JS code is).

Introductions

In part because of all this, and in part because I’d always wanted to write a Python C extension from scratch, I’ve decided to create a new Python-Spidermonkey bridge: Pydermonkey.

Pydermonkey’s mission is pretty simple and straightforward: it’s just meant to wrap Spidermonkey’s C API as faithfully as possible—including its debugging API—while enforcing the memory safety that Python is known for. This makes it awfully low-level for casual programmers, but thanks to Python’s awesome support for magic methods, it’s not hard to create high-level wrappers that provide much more convenient bridging between JavaScript and Python code.

Where It’s At

Pydermonkey is currently at version 0.0.6; its API supports a decent subset of the Spidermonkey C API, but it’s still quite lacking in places: operation callbacks will allow you to run untrusted code that runs in infinite loops, throw hooks allow for full Python-esque stack tracebacks of JS code, yet property catchalls haven’t yet been implemented, which means that security is constrained to conventional sandboxing (membranes and object capabilities aren’t currently possible). There’s also the nasty problem of not being able to detect reference cycles that cross language boundaries, which means that such cycles need to be broken manually for now.

Getting It

Pydermonkey is available at the Python Package Index in source form, and as a precompiled binary for the few platforms that I happen to have access to at the moment.

You should be able to type easy_install pydermonkey at the command line and everything should “just work”: I’ve set up the Paver build script such that the Spidermonkey source code is automatically downloaded and built before the C extension if you’ve got the compiler toolchain on your system, though there are a few snags on Windows to circumnavigate. For more information, read the Pydermonkey documentation. And please feel free to file a bug if you run into one!

Where To Go From Here

If you’d like to see an example of a high-level wrapper, check out my Pydertron experiment. It provides a simple interface to expose untrusted JS functionality to Python code and also contains a CommonJS-compliant implementation of the SecurableModule standard. I’m also playing around with creating a Pydermonkey engine for Narwhal on github; contributions to any of these codebases are more than welcome, and there’s some low-hanging fruit in Pydermonkey that would be perfect for students or first-time contributors.

Finally, if you do anything interesting with Pydermonkey, I’d love to know about it.

Every time I think about why I like the open web, I basically think of how well it fits with the way I learned to use and program computers as a kid: my first computer, an Atari 400, came with everything I needed to do programming, and I (or my parents) didn’t have to spend hundreds of dollars or sign an NDA to get a development tool.

My favorite technical book as a child was Creating Adventure Games On Your Computer, which contained plain BASIC code for games that you could play, augment, and make your own. A column in one of my favorite magazines, 3-2-1 Contact, featured the same kind of content.

All of this was easy enough for a child to grasp—often far easier, as Jef Raskin observed in The Humane Interface, than today’s development tools. But being able to use a tool that provided an incredibly low barrier to generativity is something that I value a lot about my childhood. It’s in part where a lot of the real passion and excitement for open source and the Open Web come from: people like me see in them the qualities that made them truly excited about computers as a kid. Qualities that we’re constantly in danger of losing today as the field becomes more professionalized and controlled.

So that got me thinking about Drumbeat again: what if promotional materials for the Open Web focused on how it makes lives better for children who are budding hackers? Lots of adults aren’t tech savvy, but they know that their kids are, and if we can prove that the Open Web is better for their kids, and that they can make their kids’ lives better by choosing a standards-compliant browser, maybe they will.

After playing around with this idea for a bit, I came up with this:

The photo on the page is taken from Flickr user .sick sad little world.’s The Taste of Ink. Feel free to get the source and remix!