Well, fellow web ninjas, you can put your skills to work with Mozilla and help make the web a better place. Our web projects are open, just like Firefox, and we’d love your help!

If you’re a web developer and want to help Mozilla and Firefox users while working on sites that see millions of visitors every day, follow me through the jump and I’ll show you around our shop and introduce you to the tools we use.

Our Projects

Mozilla Web Dev is responsible for pretty much every web site at Mozilla, from Addons to Support to Mozilla.com to Spread Firefox. We also take care of web services like the Application Update Service, Plugin Finder Service and the Crash Report Beacon.

Almost all of our code (everything except Socorro—the crash report beacon—I think) is available on svn.mozilla.org. You can browse around the server and see the source right now. It will all basically run on the standard LAMP (where P is PHP or Python) stack.

Our Tools

The control center of web development at Mozilla is Bugzilla. All our work takes the form of “bugs” here. A “bug” is not necessarily a problem with the software. A new feature or a software update would also be called a “bug.” I’ll talk about the life-cycle of a web development bug below.

IRC is just as important as Bugzilla. Both our staff and our contributors are geographically diverse, and IRC gives us a good way to coordinate and talk to each other around the globe. If you’re new to IRC, ChatZilla is an easy place to start. Most projects have their own channel on irc.mozilla.org, like #sumo for Support and #amo for Addons. We’re also usually in #webdev.

As web developers, are chief weapon is HTML. HTML and CSS. HTML, CSS, and JavaScript. No one expects the… (Sorry.) On the front-end, we chiefly work in HTML, CSS, and JavaScript, and occasionally other technologies like XML. On the back-end, nearly all of our projects are in PHP or Python.

For version control we mostly use Subversion, though git (and git-svn) has gained a bunch of ground lately. (Addons will be moving to git sometime next year.)

To work on your own computer, you’ll probably need to set up Apache, MySQL, and PHP or Python. XAMPP can be incredibly helpful here. Working on Linux (or Mac OS) is usually easier than Windows, and closer to our server environment. A tool like VirtualBox will let you run a Linux virtual machine on most other operating systems. It’s a little slower but switching back and forth is easy. I’ll try to write about my local development set up soon.

Our Workflow

Let’s go over the life of a bug. This is a little long-winded.

A bug is born either when someone describes a problem or when we decide to add a new feature. (Every project has its own way of doing the latter.) Sometimes our Web QA team finds problems, sometimes community members do. Then the bug is created, or filed, usually by the person who discovers it—that could be you!

Once a bug has been filed, possibly after some discussion of the best way to fix it, a developer—and that could be you, too—will “take” the bug, accepting responsibility for fixing it. Fixing a bug means changing the application in some way: changing a behavior, adding a localization, etc.

When the developer believes they’ve fixed the problem in their copy, they generate a patch (Subversion’s “diff” command is useful). They then upload that patch as a new attachment, and request review (r?) from someone else. Who does the review will depend on the project and how busy everyone is. If you’re not sure who to ask, ask in IRC.

The patch will either get an r+ or an r-. An r+ means it’s good to go, and it can usually be checked in to Subversion (unless there are reasons to wait). An r- means there’s something wrong. This can range from a patch containing some extraneous data to a patch not solving the problem, and an r- almost always includes a description of the problem.

When a patch with a positive review (r+) gets checked in to Subversion, the developer will include the revision in the bug and change it from new to resolved: fixed. In a few minutes, the change will appear on a staging server that’s updated frequently with the latest code. Our Web QA staff and contributors will test the bug, compare expected to actual behavior, and with either reopen the bug, if it’s not fixed, or set the status to verified. Then the bug is considered done. Verified bugs rarely reopen.

Once all the bugs for a milestone are done, we “freeze” the source against new commits while Web QA does a final check that everything is in good shape. When QA signs off on the current code, we push the new version onto our production web servers.

So that’s the life of a bug, from filed to production. When it gets to production, your code can be seen or used by millions of people every day.

Join Us

So if you’re a web developer and want to help Mozilla and Firefox, head over to Bugzilla or IRC and get started. We hope to see you soon!

Education generally falls behind every other sector in computer technology integration and internet use. A typical fast food employee uses a computer more during the day than a typical middle school student. (What are cash registers but custom computers?) At almost any business you can expect employees to use networked computers for everything from sales and inventory to customer service to internal work and communication.

But beyond simply using the box, private companies in every sector generally have up-to-date, professionally designed web sites that (at least try to) provide useful information or services to customers. Been to your or your kid’s school web site lately? Universities are usually “OK,” but they get worse as you go down.

In any other sector, you are likely to find online collaboration tools, meeting planners, digital resources for employees, use of messaging tools like internal e-mail (Exchange servers), private IM, Yammer/Laconi.ca, internal wikis, public and private blogs… you get the idea.

But not in education.

Education is part of the problem, but it is not the whole problem. Many people talk about how teachers and schools fail to use computers and the internet well in their classrooms. Many schools treat the computer itself as a goal, rather than as a tool to do new things, or do old things better and faster. Teachers generally fall behind the private sector in computer literacy. Yes, all these things are true.

But we, we the tech sector, the web 2.7.4 crowd, we are part of the problem, too.

How often does a new tool support education? Offer suggestions or support for teachers? Provide educational pricing? Provide the EULA and Privacy Policy education legally requires?

The people who become teachers are often the people who did well in school, who see no reason to change anything because, to them, it works. In the tech world, “where did they drop out of school?” is a legitimate question. Your typical programmer has at least one degree in Computer Science, but the real success stories—Bill Gates, Steve Jobs, Mark Zuckerberg—the ones who made real money, are drop outs. School didn’t work for them—for us—so what do we owe school?

When Yammer launched, they gave a simple business plan: for companies that wanted to “claim” and control their networks, they would charge $1 per month per user. A small start up might pay $5 to $20 a month. Even a big company is probably paying only a few hundred dollars per month. A university, on the other hand, could be stuck paying tens of thousands of dollars per month, or skipping the service entirely. Which do you think they’re likely to do?

What was Yammer’s response? “Our product [...] is not geared toward educational institution [sic].”

Many schools have prohibitions against using Google services for anything work-related because, if you don’t pay for use (update: Google Apps for Education is free, my bad) their educational services, their Terms of Use (read Section 11) could allow them to share sensitive student data.

You’re a school? You don’t matter. Only cool people matter.

Let’s change. Let’s remember that the community of “tech-savvy” users, while growing, is still a minority. Let’s encourage teachers and schools to use the tools we create, so people come out of school ready to use these tools.

It is possible. Ning is experimenting with education. But how do we make tools ed-friendly?

Fix your EULA and Privacy Policy, or provide a second one for education. Don’t be the next Google Chrome. (Frankly, everyone should be reconsidering their EULA right now. Why do some people need so many rights to my content?)

Offer suggestions to teachers. I know: it’s not really a priority. You’ve got bug fixing, paying customers, searching for VC, coming out with the next version. But it’s not terribly difficult. Got a user forum? Add a section for education. Got a wiki? Add an education page. Blog? Throw up a post for teachers once in a while, or better, get guest posts from teachers who use your tool.

Provide educational pricing. Schools have less money every year. If you can work out a deal to make your product free to schools, do it. But it’s not hard: just charge schools less. Think of this as an investment. If they use your product as students, they may well want to use it when they graduate and have to pay.

Or, provide an ad-free version to schools. This is the Ning method. If your business model doesn’t involve charging directly, be aware that schools often take issue with displaying ads to students. It’s the same investment as above: hook them young.

Schools lag on the internet because there is resistance on both sides: educators are reluctant to integrate new things into their curricula, and the new tools rarely give a damn about schools and students as users.

Changing the tech side won’t solve the problem. Schools need to adapt, too. (Where would you look for a Windows 95 computer if you needed one today? I’d check the local elementary school. It’s probably in a lab, or hidden in the back of a classroom.) Schools need to treat computers like tools, and the internet as a tool, and the tools we build on the internet as tools, and use those tools effectively. That will take time.

In the meantime, let’s try to reduce the resistance on our side, so when they come around, educators feel welcome.

Edit: I need to proofread better, even with angry rants.