OSCON is the conference that I seem to attend the most regularly. In particular, the hallway conversations are great.

Not being a Perl guy, I never went to the Perl Conference, but I was involved in organizing the first Python track at the first OSCON IIRC, and I think I’ve been every year since.

This time, for the first time, as a Mozilla rep. Dan and I will give a talk about Thunderbird, but I’m expecting we’ll talk about Thunderbird 18 hours a day!

See some of you there!

Who do we need to build and promote an open internet?

To jump in in the discussion between e.g David Eaves, Marc Surman and Mitchell Baker about what the open internet is, let me try and insert a bridging perspective.

Mitchell, very grounded in the Mozilla project, comes at the problem from the technology angle. I certainly agree that without a technological basis, it’s hard to make any kind of internet. In particular, I believe that trying to mandate openness through policy is very likely to fail. Cynically, I don’t place much faith in a pure activism-based approach. To carry forward the analogy of the environmental movement, I think progress will require a combination of technology, advocacy, policy, and the resulting market forces.

To me, a healthy open internet requires a multi-faceted approach. Mozilla has been successful at building enabling technology and getting people to adopt them. That product-based approach is what gets me up in the morning — how can I make a particular bit of technology so much better that people choose to use it because it’s fun or useful.

But I also think that if all we have are people “like me”, the open internet is at risk. It’s at risk because the better technology doesn’t always win. People like me need to collaborate with activists who look at the open internet less from a technical point of view, and more from a social discourse point of view. We need folks like the EFF, to advocate on policy stuff, we need folks like the creative commons folks, to push both legal frameworks for content and build communities of non-technical contributors, and we need a lot of other folks besides, including infrastructure providers, ISPs, hardware vendors, etc.

None of the above strikes me as controversial. One of the less clear-cut questions is whether Mozilla should expand its scope beyond building and promoting products.

To me, that is a “people question” — the people who have naturally “accreted” around Mozilla over the years have self-selected to be part of a (mission-driven) open source project and more and more, a product-building organization. Grossly generalizing, it seems likely that those people are likely not the people who will be the most effective at tasks that require quite different skills, mental models, approaches, experiences. Do we want to expand the size of the Mozilla tent, or do we want Mozilla to collaborate with other groups in a more federated model? The latter is likely the simplest, and is closest to what Mozilla has done for a while, I think.

The “broaden the tent” approach could, ideally, let us apply the leverage built up through the product in other, less technically grounded areas. However, spreading ourselves too broadly could threaten the integrity of the existing, essential communities. Some early participants may feel that “this new stuff” is too far removed from what first attracted them to Mozilla. Alternatively, maybe these same Mozilla participants would gain pride and energy by feeling that they belonged to a group that had such different yet cooperating tacks. I find it very hard to predict how people would react, in part because I suspect it depends crucially on the details of what such a broadening would be. Building a picket fence

I’m personally attracted to ambitious, risky, change-embracing endeavors, but I know I’m slightly abnormal there. Many Mozilla folks, typical of software developers, exhibit this “perverse and often baffling” combination of change averse behaviors in the pursuit of being change agents.

[apologies to Malcolm Gladwell]

Linux smoketesters needed

UPDATED: see the end

As part of a release (say, for the sake of illustration, the next alpha of Thunderbird), we try to run the software through a set of tests. The more widespread the release, the more tests. Nightlies don’t go through any non-automated tests. The final release will go through a lot. For an alpha, we like to have a few people poke at the software on each of the major platforms, to make sure that the major bits work.

We have volunteers covering Mac and Windows, but we’re short a couple of Linux volunteers. All it should take is 1) access to a linux box (the more mainstream the better), 2) experience with Thunderbird and ideally with Linux, 3) a bugzilla account, and 4) a couple of hours of free time.

If you’re interested, contact me (email is findable from my blog home page), or contact Wayne Mery directly if you know how to do that.

UPDATE: We’ve had overwhelming response to this post, in part thanks to a mention in Linux Magazin in Germany. We don’t need any more Linux smoke testers specifically, but we’re always eager to see more people help with Thunderbird testing. If that describes you, please subscribe or join or follow the mozilla.dev.quality newsgroup/mailing list/google group, and check out the Thunderbird:Test wiki page. There are lots of ways to help, and some of them take only a little bit of effort. Thanks again for the enthusiastic response!