I read an account of an event I attend recently that gave me pause. In it, the author argued that he had observed a gathering where technology formed the only basis for the interactions in the sessions, and that those in attendance were all of a kind, without diversity, and, on the whole, not interested in people, society, history, etc. This assessment was leveled against a community in which I find myself deeply situated, and as such I wanted to reflect on my own position within such a crowd.
We are told that open source is about “scratching an itch,” creating software to solve personal problems, and the culture the surrounds such an enterprise. This is true, in my experience; however, it is not my experience. Where open source is most often taken to mean source code, I have been primarily interested in what is meant by open, whether that be open education, open source, or open data. For me, and I speak intentionally as an individual among a much larger crowd, open is about people more than technology.
Where some people choose software projects in order to solve problems, I have taken to choosing projects that allow me to work with various people. I have given up the comfort of being an expert , and replaced it with a desire to be alongside my friends, or those with whom I would like to be friends, no matter where I find them. My history among this crowd begins with friendships, many of which continue to this day. I love almost none of the technology I use, and view it as a means to an end: working on things, for me, is about working with people.
This way of working, where collegiality subsumes technology or tools, is central to my personal and professional work. Even looking back over the past two years, most of the work I’ve done is influenced by a deep desire to work with rather than on. I need almost none of the software I build, I have no itch to scratch. In order to be effective, working with requires that I be attentive to the other more than to the thing we do together. Working with demands that I recast myself in the shape of the other, and vice versa, that I be willing to change, that I love and allow myself to be loved. I cannot succeed if my gaze is only on the thing, especially if this thing is allowed to come between us.
In the context of working with, technology once again becomes the craft I both teach and am taught, it is what we share with one another, the occasion for our time together, the introduction, but not the reason, for our friendship.
And it can be difficult to observe what I am describing, for it will always show up as something much more mundane to those not working this way. To watch us work, it will seem that we only build things, that we talk only of certain things. It is possible for someone to work on something together with others who are working with each other. But it is not the same thing. It is not what we do. Looking only at the thing we build together, it is easy to miss what happens around it, and who is there.
Experiments with audio, conclusion
I’ve been working with an amazing group of web, audio, and Mozilla developers on a project to expose audio data to JavaScript from Firefox’s audio and video elements. Today those experiments are over.
In December a few of us working on processing.js had an idea–what if we could visualize sound data coming out of an <audio> or <video> element? My colleagues were good at thinking in terms of “how can we make what we have now work?” but I had another idea. “Let’s try and teach Firefox how to do this.” In December I set myself a challenge:
Yesterday, the end result of that work landed in mozilla-central, on its way to inclusion in Firefox 4. I’m immensely proud of the work we’ve done, and thrilled that my peers in the Mozilla community have also accepted it. I’m also very tired
There’s lots of things that I could talk about in terms of the code and API, and probably we’ll do some of that soon (you can already use the API in a Firefox nightly, read about the API, and try live demos). But what I wanted to end this series of posts by saying something about how Firefox, the Mozilla community, and the open web, make what we did possible.
The other day my family had some friends over, and we got talking about what I do. Of course they had heard of Firefox, and used it themselves. “But can you explain the difference between this and the other one I use, Internet Explorer.” One of the big differences, I explained, is participation, the community of involvement, and the accountability that comes with this.
When we started these experiments, we did so without needing permission. I didn’t have to sign an NDA, go talk to and convince the right people, or get approvals. I just grabbed the source code and started messing around. And I did make a mess, at first. I learned as I went, and we iterated on the API a lot (I have over 80 versions of it here, not to mention the various implementations of those). We weren’t judged for doing it wrong, or for the pace or directions we took. Instead, we heard of lot of “this is very cool!” and “have you thought about this?”. We were able to take one of the world’s premier applications (Firefox) and rework it. It’s hard to overemphasize how significant this is. We couldn’t do what we did in very many other contexts.
I said above that participation is paired with accountability, and this is also very important. In the early months we built something that worked, but not what we have today. 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
What’s different about Mozilla? I think of something Joe Hewitt wrote on twitter back in the spring that struck me:
Not one of the people who did this work is an employee of the Mozilla corporation. When we decided to get serious about trying to include this in Firefox 4, one of the people working with us filed a bug, and the response was, “I don’t think we have the cycles to get this done in time.” “That’s OK, we’ll do it then,” was the reply. And we did.
The web is too big and too important to only go as fast and as far as a small group of employees can take it. Mozilla gets this, and values community involvement like ours. What we did is not unique–there are other great features and bug fixes coming in Firefox 4 that were done by community members vs. employees. In fact the distinction between the two is often hard to see when you’re working on this stuff–we all work together.
Having said that, let me publicly congratulate my amazing audio peers, without whom this work wouldn’t have happened: Al MacDonald, Corban Brook, Yury Delendik, Charles Cliffe, Ricard Marxer, and our cheerleader and supporter, Chris Blizzard. Also thanks to the dozen others who wrote demos with our stuff in the early days. Demos are how you win (Chris Blizzard taught me that).
I’ll end with a video someone shot of my keynote talk at the recent Mozilla Summit. I was doing a quick demonstration of what is possible with this API. I look forward to seeing what the rest of the web will do with it.