Bread and Circuits

Tomorrow (or maybe today if you’re reading this on Tuesday) is a big day.  It’s the day that Firefox 3.5 will be released, and with it, an upgrade for the entire web.  Mozilla’s done a fabulous job of showcasing some of these new things here and here, so I won’t repeat what you can read all over the web.  Suffice it to say that Firefox 3.5 is truly amazing.  I know this because I’ve been using it for a long time.  Long before it was in alpha or beta release, long before it became available for download, long before it had a name.  I’ve been using it as long as it’s been developed, and I wanted to tell you why that’s significant.

A little over a year ago, I blogged about how Firefox 3.0 “represents a new kind of software project: a project welcoming of student involvement.”  A lot has changed since then, and I’m happy to report that the change is for the better.  Since writing that I’ve had the pleasure to work with many more students at Seneca on Mozilla development.  They’ve found and fixed bugs, worked on enhancements in the platform and browser, done quality assurance, written documentation, improved the build system, and created extensions.  They’ve worked as Mozilla Corporation interns or become employees, they’ve done Google Summer of Code projects, and they’ve been a part of the development of Firefox 3.5, and active members of the Mozilla community, all before graduating.  How many students can list that on their resume?

Together, along with thousands of others around the world, they’ve proven that Mozilla isn’t simply a company making a product, but a community building an ecosystem based on shared values around open participation and collaboration.  I can say this with some authority, becuase I’ve been present every day that it’s happened, helped the students contribute to, and connect with the community, and contributed myself.

It’s common for open source projects to tell people that “patches are accepted.”  In Mozilla’s case that’s true too, but they go further: patches, and patch authors, are encouraged, mentored, and valued.  That’s not something every open source project can claim.  I haven’t found another open source project so dedicated to supporting the next generation of developers and contributors–and I’ve spent a long time looking.

I’m proud of these students, and proud of how far they’ve pushed the envelope.  I’m inspired by their drive and creativity, and encouraged to do it all again in September, when we’ll continue work on another as-yet unnamed browser with a new group of students.

I’m also encouraged that through Mozilla Education we’ve been able to extend this model to other parts of the world, and found educational partners who dream as big as we do.  France, Spain, India, Singapore, Pakista, Serbia, Japan, and across the US and Canada–we’ve found students and professors, or they’ve found us.  Together we’re building something unique that, much like Mozilla, shouldn’t work, but does.  Students want to work on meaningful output, and Mozilla is one of the best examples in the world that this can be a lived reality.

Part of how we’ve gotten here is by dreaming big, and following through on those dreams.  Mozilla does that too, and tomorrow’s a day to celebrate the results of pushing hard to finish something awesome.  I offer my congratulations to all those who worked hard to make this possible, and count myself lucky to be among that group, and to have been allowed to bring my students along too.  Great work, Mozilla, and great work Seneca.

For a while now, whenever I’ve had spare time, I’ve been “building a boat in my basement.”  Today I’m pleased to bring it out and launch it:  I’d like to announce the first public release of DXR, version 0.1.

DXR is a two things.  First, it’s a method for collecting type, member, statement, macro, etc. information about C++, IDL, and soon JavaScript using Mozilla’s static analysis tools (e.g., Dehydra), a hacked build system, and a bunch of scripts.  Second, it’s a web-based tool for mapping this information back onto source code, and allowing users to query and look-up this information.

There are already some really well-known tools for creating source code cross-references, from LXR to MXR to OpenGrok.  While these are all based on “search” and various ways of indexing text,  DXR is about reducing the need to do searches, and instead being able to look-up data.

The best way for me to describe it is to show you, so I’ve put together a short demo (watch on YouTube or if you’re using a snazzy Firefox 3.5 beta, you can view this .ogv file directly).

I’ve put together a live demo of DXR at http://dxr.proximity.on.ca/dxr/ which has both mozilla-central and comm-central available.  A couple points to be aware of with this site.  First, this data is not being updated daily, and I’m using revisions 7a8502b70fdf and 7b153b079c94 respectively.  Second, it’s not running on a proper server, so I don’t guarantee up-time or performance.  Once the code is improved a bit we’ll hopefully move it to a proper box, use something other than SQLite for the back-end, and start doing regular indexing.

Having said all that, it’s quite usable.  If you’re a Mozilla developer, you’ll be able to navigate your way around and quickly see how this is different from what we have today.  If you’re not familiar with the Mozilla code, here are some examples you can look at:

• Where is nsIDOMNode declared?  What members does it have?  What else derives from it?
• Who implements this method call nsILink::GetHrefURI?  Who else uses calls it?
• What is this variable named tmp?
• What is the value of the NS_ENSURE_SUCCESS macro?

You can get the DXR source code here, (using Mercurial: hg clone http://hg.mozilla.org/webtools/dxr/) and patches and contributions are indeed welcome!  The current release and code represents a lot of experiments and poking around in the dark to see if this was even possible.  While the code is still very much demo quality,  I think it’s safe to say that we’ve moved from “I wonder if this is doable” to “there are still a bunch of bugs.”

A few other things I’ll point out about this release:

• The data represents a Linux-only C++/IDL analysis (i.e., no C, no Mac- or Windows-only code).  To date this has not been done on Mac or Windows.  As such, you’ll probably hit files where there seems to be incomplete data, and this is probably why.  Dehydra works on Mac, and we’ll likely us cross-compiling to get a Windows analysis.
• This code is heavily tied to eccentricities in the Mozilla code base (I can tell you first hand that our code has many strange and scary corners!).  Could you use this to index other large C++ programs?  Yes, but not without modification.  If you’re interested in trying, get in touch and I’ll help guide you through the process.
• There are lots of places where we have bugs in the data.  Some of them are due to GCC bugs, some to Dehydra bugs, and lots are due to my bugs using these tools.  For example, I don’t currently deal with globals, C++ fragments in IDL, etc.  If you wonder why something isn’t clickable, or why you click and get an empty pop-up, “it’s a bug.”
• I’m still struggling for a way to show all the data I have.  The current UI is based on my own ideas, and the feedback of a small group of Mozilla developers.  There’s more we could collect and show if I could figure out how, and I’d love some UX/UI people to give a hand with that.  If you have recommendations, also let me know.

I said earlier that DXR is two things, and the web app is just one way I can imagine using this data.  Could this data be integrated into Eclipse or Komodo or emacs?  Sure it could, and it’s only waiting for you to do it.  I’d be happy to provide pointers or work with you to get the data in a form that makes this possible.  Speaking of which, you can download my SQLite databases, mozilla-central.sqlite.zip and comm-central.sqlite.zip, on their own.  The database schema is here.

I’m really happy that this is finally in a state I can share with others.  My next steps will be to improve the code and quality of the data.  I’d also like to start adding other data: anything that can be mapped to source code lines and tokens is a potential candidate (performance data, bug info, documentation links, hooks for rewriting tools, etc.).  Maybe you’ve got ideas and would like to get involved.  I look forward to hearing from you.

The best way to get in touch is either via email, the Mozilla Static-Analysis mailing list, or on irc (I’m humph on moznet and can be found in #static, among other places).

After scoffing for as long as I could make up excuses, I decided to try twitter.  I’m @humphd (I don’t know who @humph is, or why he/she has my nick and no posts!).

A number of people sent me a link to this story about Kyle Brady and his ordeal getting his school to let him post the source code to his assignments.  In the spirit of the academy, Kyle wanted to share the results of his work.  His professor said no and threatened to fail him, and it was only through escalating it to upper administration that he was finally allowed to do it.

This story amazes me.  Here are a couple of quotations that resonated with me:

The most important lesson from it for me is that students want to produce meaningful output from their course-assignments, things that have intrinsic value apart from their usefulness for assessing their progress in the course. Profs — including me, at times — fall into the lazy trap of wanting to assign rotework that can be endlessly recycled as work for new students, a model that fails when the students treat their work as useful in and of itself and therefore worthy of making public for their peers and other interested parties who find them through search results, links, etc.

…

I’ve always thought it was miserable that we take the supposed best and brightest in society, charge them up to $60,000 a year in fees, then put them to work for four years on producing busywork that no one — not them, not their profs, not other scholars — actually wants to read. Might as well get them to spend four years carving detailed models of ships from sweet potatoes (and then bury the potatoes).

There’s an important lesson for educators here.  Students want to:

• work on things that matter.
• have the chance to participate in the production of knowledge.
• share.

I’ve written before about the idea of permission in an academic context.  This is proof that there are still serious barriers to mixing education proper with the web.  At the same time that we’re hearing stories like this one, there are an increasing number of stories about the opposite, and people who see the value of letting go of closed approaches to knowledge in favour of collaboration.

Take the example of Srirang Doddihal in India.  Srirang, or brahmana as he’s known in the Mozilla world, was a student when he did a Google Summer of Code project.  After completing the project and graduating, he kept going with Mozilla as an active contributor working on things like the Download Manager.  He also had a vision for his old school: if he could work on Mozilla as a student, why couldn’t other students?  Over the winter he’s worked with Mozilla Education and his old professors to work toward establishing a new course in the fall on Mozilla at his old school.

Srirang’s story is unique, but not singular.  We’re talking with other schools interested in doing the same thing, and the only thing stopping us from working with you is that first email you need to send.  It doesn’t matter if you’re a professor or an individual student, you can start working on things that matter right now as part of Mozilla.

For Kyle and his professor, it’s worth noting that Mozilla provides some significant solutions to the problems they faced:

1. Mozilla source code is freely available for study, modification, and contribution.  The ambiguity of what you can and can’t do has been removed, helping students and professors alike avoid these sorts of battles.
2. Mozilla is large enough that you can give different assignments all the time but still use the same content.  For profs it’s hard to come up with variations on the same thing year after.  Mozilla is an endless supply of similar but unique types of work.
3. Mozilla does significant and important work, both from a technical and public good point of view.  Working on Mozilla means a lot of different things.  You can work on enhancing the open web, accessiblity, graphic design, compiler optimizations, static analysis, web tools, build systems, HCI and UX, cross-platform development, mobile, localization and internationalization, automation, quality assurance, testing, technical documentation, extensibility, etc.  The list is as varied as the people who do it.
4. You aren’t alone in finding things you can do or getting help doing them.  Mozilla keeps track of its work using a public bug tracking system, and even flags bugs appropriate for student projects.
5. Over the past 10 years, Mozilla has proven that you can succeed by doing things in the open, using the web to collaborate, and sharing what you know.  We’re beyond the point where people like Kyle’s professor can claim that this is a nice idealism with no practical benifit, or not how the real world works.  In fewer than 35 days, Mozilla will show you how well this approach works in the real world.

More students need to follow Kyle’s lead and take their learning seriously.  What he did is what Mozilla does every day, and if you’re ready to try this, we’re ready to help you succeed.

This is the story of the time my wife and I decided to mount her 24″ iMac to the wall.  I’ll just cut to the chase: you can do it; don’t try it.

Straight, plumb, square, centred, level–pick any eight.  That’s what we were after.  Our goal was to perfectly fit this iMac as tight to the wall as possible, and do it properly.  The iMac is highly adjustable for people built exactly the right height to use it (I haven’t measured Steve Jobs, but I can extrapolate his height based on the design of this stand).  For everyone else, including my wife, it’s totally wrong.  For my wife, it’s too high, and the depth of the stand takes up too much space on her desk.  “Why don’t we just mount this thing to the wall?”

Let’s start with what you need to do this (or some of what you need):

• Apple VESA mount
• VESA wall mount, we chose this simple one.

Now, the very first thing you have to do is remove your precious iMac from its stand.  If this was any normal computer company, you’d grab a screw driver and remove 4 screws.  Think Differnt.  What you have to do instead is tip your monitor as far forward as you possibly can, and then insert a specially designed (it had it’s own custom plastic wrap even) credit-card shaped piece of plastic that comes with the Apple mount kit.  I love that it’s a credit card you have to use, reminding you of how much you’ll need to spend if you get this wrong.

So you have to slide this card at this impossible angle to release a “switch” which isn’t visible.  My wife and I both tried in vain for 15 minutes.  Eventually we got it and the monitor was able to move even further forward, revealing 8 small screws.

Next use the Apple Torx Tool provided in the kit to remove the eight screws.  OK, so first one is out like butter.  Second one, “Wow, not moving.”  Third, “Uh oh, I’m starting to strip it.”  Fourth one, “This tool just snapped off in the screw!”  OK, don’t panic.  It has two ends.  Just get pliars and remove the broken tip, and try the other end, using pliars for leverage.  Five, six, seven, eight.  Done.

Next you have to attach this perfectly machined metal plate over the spot where you took the screws out.  Nothing you can do causes it to line up with the holes on the mounting plate you’re attaching it to.  “Why don’t you just try it and if it’s wrong we can take it off and turn it?”  “Well, I’m down to 1/2 of a Torx Tool.”

We experiment every way possible, and decide to reject the diagram in the instructions, and just go for it (we were right, by the way, come on Apple!).  The plate is on, the Torx Tool is still in one piece (well 1/2 piece), and the next step is to use the Torx Tool again to crank down the plate until it basically bends the plate such that two perfectly machined screw holes line up on the sides.  Great.

At this point the instructions admit that this tool isn’t up to the challenge and recommend you find a Torx screwdriver.  Luckily I have one (which I didn’t know until this project!), but forget about using anything other than a socket wrench with Torx attachment.  You have to really go at it, and it’s not a good feeling hearing the sounds the back of the iMac is making.

I get it down to the point that I can insert the right-hand screw, and after much work, I get it 98% of the way in.  You have to use their special Hex Tool for this, and I’m not loving how much I have to push to make it happen.  I decide to go to the other side and try it.  It doesn’t come close to lining-up.  So I go to work on the top screw again with the Torx and eventually strip it clean.  “I guess that’s as far as I’ll go, then.”

It’s do or die on the left-hand screw now.  You know when you’re into a project far enough that there’s no going back?  I’m 2 hours and 1 Torx Tool past that point now.  So I have two empty cylanders of metal that aren’t quite lined up.  This isn’t wood, I can’t just drill a new hole.  So I give it everything I have with the socket wrench, and it catches a thread and jumps into place.  So now the plate is mounted, and I’m shaking with “this has to work.”

On to the wall mount.  We open the box.  “I think we’re missing some screws here.”  At the store, I asked the guy, “Is this everything I need to get this mounted?”  Of course it is, am I crazy?  Yeah, I’m crazy.  I’m crazy like a guy with no screws and an iMac that isn’t going back on its stand.  Ever.

So I look again at the Apple mount kit.  Four perfectly drilled holes, not a word on what size screws you need.  Now honestly, Apple.  You’ve drilled these damn holes, surely you know what size they are?  I mean, charge me an extra $10 dollars if you want and give me the damned screws!  No screws.  And there are no screws in the mount kit.  Do both Apple and the company who made the mounting bracket both expect me to use double-sided tape?  Can’t one of them take responsibility for the fact that I’m going to need these?

“Wait, they are listed on this parts manifest, they just aren’t in the box.”  So the mounting bracket is supposed to ship wtih what I need.  Except, I don’t have anything except a little picture of them, and a fake plastic credit card from Apple to buy them with.  It’s very dark outside.

It’s to the point where I get desperate.  My youngest daughter has a screw collection.  “Go into her room, and grab it without waking her!”  My wife gets the contraband screw collection, and starts looking.  Meanwhile I go to the basement and look through random screws I have from other projects.  “I think these are 4mm, maybe 5mm”  I try them.  The booklet says, “DO NOT FORCE SCREWS INTO THE BACK OF THE MONITOR”  Too big.  “Wait, what are these?”  Like manna from Heaven, my wife locates 4 mounting screws exactly to spec:  “These are 4mm x 25mm!”  I have no idea where they are from, or what they are for.  I don’t care, they are going into this plate.

I now have a plate mounted to the back of the Apple mount kit mounted to the iMac.  We’re almost home.  Now I just have to drill and seat 3 x 3/4″ by 3″ lag bolts into our wall.  Let me take you back, though.  When we built our house, we prepared for this day.  We knew that we’d want to do this in the future, so we had our builder put wood backing between the studs, and then we took pictures of the walls before they closed them up.  Fast forward to me sweating with a drill in my hand, and a picture in the other.

We take the backing plate and measure, level, and trace the holes we need to drill.  Then we quickly realize that two things have happened.  First, there is a metal plate over a stud directly under the bottom hole.  Second, there are 2 electrical wires going somewhere between the second and third holes behind the backing.  I look at the 3″ lag bolts.  Trouble.

The guy at the store, the one who sold me a mounting bracket with no screws, did give me four extra lag bolts.  “These ones look too big, use these smaller ones.”  I wasn’t planning to use them, but now that I can’t use the bottom of three holes, I have to.  I decide to do two large lag bolts, and then extra smaller ones on the sides.

But I have no washers.  Why would he give me washers for these lag bolts?  Exactly.  So back to my daughter’s screw collection, and there’s one.  I need three more.  “Phone my dad, and see if he has them.”  A quick trip over to my father-in-law’s produces four washers, all a little bit different.  Think Different.

I drill six holes, and use the socket to seat them into the backing.  When I’m done, we get out the level again to see how much we’re off.  I can’t look, cause there is no correcting this mess.  It’s dead on perfect.  I could cry.  We try inserting the iMac, and it’s magic how it just sits there on the wall perfect height, perfectly level.

“That was easy.”  Don’t try this at home.

This year’s Free Software and Open Source Symposium (FSOSS) is now accepting presentation proposals.  In addition to the regular talks and and workshops at FSOSS, there will also be a 1-day Teaching Open Source Summit.  If you’re working in open source or open source education, consider submitting a talk proposal to one of these two amazing events.  In fact, that entire week (Oct 24-30) is packed with related events in the city (watch http://opensourceweek.ca/ for details over the summer).  Great time to be working on ‘open’ in Toronto.

Three months ago Mozilla Education started a project to actively look for student projects.  Each morning I get email from bugzilla with the list of newly added student-project bugs (I got 11 this morning).  As I write this we have 61 potential projects.  I’m hoping to have that hit 100 before the end of June, and here’s why.

Mark blogged a month ago with a map of the students we know about who are working on Mozilla, and where they are.  Since then, James and I have been trying to keep it up to date, and today it looks like this:

Over the past few weeks, we’ve gotten to know more students from Romania, Serbia, Pakistan, India, Morocco, and the US.  When they show up, they come with energy and interest, and in most cases they are looking to start working on something–they need a project.  Each one of them has different interests and skill levels.

It’s fine for us to say to them, “there are lots of things you could do with Mozilla.”  But that’s not why they’ve reached out and made the connection: they already know that’s true and want to become part of the project.  What we need in order to help them get to the next step is a list of projects that is both deep and wide.

Right now, if a student looks at the list of student-project bugs, he or she is able to choose from:

• 12 Bugzilla projects
• 13 “Core” projects
• 3 Firefox front-end projects
• 15 Thunderbird or SeaMonkey projects
• 5 Mozilla Web Site projects

There are other miscelaneous ones too.  It’s not a bad start.  But it’s also not enough, and I would argue, not necessarily a true reflection of the “width” of Mozilla.  There’s lots of stuff not on this list, and some things which are there are underrepresented.

So I want to encourage you to spend a few minutes looking at your bug lists and project ideas.  In order to break 100 by the end of June, we need you to be part of this.  School is out in most parts of the world, and over the summer and fall, profs and students will be planning for their next courses.  We need to be ready to take part in that, not scrambling to find projects once it’s in full swing.

This morning I read Luke’s discussion of the threshold, and his use of a quotation from Heidegger (“The threshold is always stony…“) put me in mind of something I had wanted to write this weekend.  On Sunday my wife and I worked to finish some gardens around our house.  Actually, we worked to finish some flowerbeds, as we’ve planted nothing yet.  As we neared the end of the task, my wife asked me to go and get some large rocks, some for features, others for beneath downspouts.  My father-in-law has a tractor with a large bucket on the front, so I borrowed that and set off in search of field stone.

We live in farm country, and there are numerous old fields on our property, some of which were farmed until very recently (we’ve reforested them all now).  If you haven’t spent time walking farmers fields you may not know this, but stones in a field always migrate to the edges.  Sometimes they take the form of a low wall or pile, other times they lay on their own shaded by large trees.

I drove around to the back of one large field where Maple and Elm trees, perhaps 150 to 200 years old, mark the comings and goings between field and woods.  In the furthest corner I found a huge cache of field stone.  The size of some of the stones left me wondering how on earth farmers had managed to move them here–I had a large tractor with hydraulic bucket; what did they have 150 years ago?

Most of the rocks are now covered in lichens and mosses, and twisted trees grow between them.  They are some of the most beautiful rocks you could want as a gardener.  They represent a state impossible to cultivate or produce: they are the result of being left alone for a hundred or more years.  As I looked for ones small enough for me to carry by hand, I reflected on their presence there.

These stones had once been scattered through the field itself.  The field is defined by them: in terms of their absence in the field and the need for good soil to grow things; and also by their presence around the sides, creating an edge.  To the farmers who moved them, they served no purpose.  Their focus was on the middle, on the field.  What happened at the edge was simply that which wasn’t in the middle.

To someone who has now taken over a piece of land that was once partially farmland, the edges form the most interesting aspect of the place.  It is a known fact that one of the best places to see wildlife is at edges: beside waterways, at the entrance to forests, along the edge of fields.  We walk the edges of these fields a lot, and my girls love to play there.  My father-in-law has even built a swing in the huge limbs of one of the Maples at the back of a field.

What strikes me whenever I go to the edge is that by leaving my focus there, by ignoring the middle, I recentre the space.  What I love about the edge is that it has been ignored, that it has aged, that massive stone and trees have remained untouched there.  I love it for having not been examined, for keeping secrets.  And I feel uneasy allowing the edge to become my centre, worried that I somehow endanger a magic I don’t understand.

I spend a lot of time thinking about what I call seeing. By seeing I mean a sort of intentionality of purpose that pays attention to what might be there.  I distinguish it from similar modes of being–looking, finding, the parables of the pearl or lost coin.  Where looking is concerned with the discovery of that which cannot be seen, that which is there but hidden from me, seeing is an openness to that which is there now.

Wrapped up in the idea of seeing is also that of the common vs. rare.  The willingness to see is often hindered by a lack of understanding about the common.  I can remember one of the very first times I took my daughters walking in the woods, when they were old enough to walk on their own, and we could experience it as three individuals.  As we rounded the last corner on our way back to the car, there in front of us was a bird I’d spent my whole life looking for, but never before seen.  I not only wanted to show the girls this amazing bird, but also to infuse the situation with a sense of its rarity: this bird is one they would not likely see again, perhaps in their lifetime.

But the experience was not the same for all three of us.  For my girls it was, after all, the only bird in their path.  For me it represented an absence as much as a presence.  But it wasn’t either of these things.  It was simply what was happening now, right here.  Experiencing it after a lifetime of looking, or as one of the first birds you ever see, is not what this was about.

That experience, and the impossibility of reconciling our two perspectives, changed how I walked in the woods.  First, it reinforced for me the importance of hoping for, and expecting, something to come.  Second, it revealed to me the significance of the common vs. the rare.

The rare is what is not common.  The common what is not rare.  Together they are what is.  My experience of the world is a mix of the two, and not necessarily a mix that is weighted how you’d expect.  Much of how we are taught to live in the world is to look for what is rare.  The rare is hidden, is findable, is to be sought after.

But I live with an awareness of the common.  I am deeply interested in what is common, what is here, what happens.  This is not to say that I don’t also take great pleasure in the rare–I was physically touched when I saw that bird in the woods with my daughters, and will remember the moment my entire life.  Instead, I’ve learned that the common reveals the rare, and that I can only hope to see the rare if I learn to see the common.

Yesterday, I was eating breakfast with my youngest daughter on the porch, and she paused to look at a duck.  We live on a small lake, and take great pleasure in watching the variety of wildlife that lives here, or passes through.  She studied the duck for some time, and eventually stopped eating so she could go and look more closely:

“Dad, there is something different about that duck.  Look at its head and beak.  It is very big.”

I paused too, and quickly identified a bird that shouldn’t have been here at all: the Common Loon, iconic Canadian bird.  I saw a bird that didn’t belong, that was too far south, that must have been resting over night on its way back north in spring.  My daughter saw a duck (we get hundreds, and dozens of species) that was not like any duck she had seen before.  It only became a Loon to her when I taught her its name and told her how rare it was.  Before this moment, it was what was happening here now, what she could glean from her own four-year old understanding of the common.

I wanted to take a picture of the Loon and include it in this post.  I went out this morning to look for it, and found that it had gone.  As I walked home I enjoyed the irony in this, and was content with having seen it, and knowing that some day may see it again.

This past Thursday and Friday I led a short workshop on getting started in Mozilla from a professor’s point of view. I’ve put up the outline of what I presented, along with notes and links. You are welcome to improve and correct this, since I’ll likely use it again.

It was an interesting time, since we had everything from “never worked with open source before” to “active in many open source projects.”  It reinforced for me that there is no true linear approach that is going to work for all professors, nor students.  It was also nice for our converstations to get pulled off topic, as interesting questions arose from things I had planned.   For example:

How does one manage risk when having students work on real projects with Mozilla?

Great question!  From personal experience I was able to share that I have student projects from last term that are still waiting for review (the course ended a month ago), others that managed to get as many as 9 bugs closed, still others who totally vanished mid-project leaving Mozilla asking “where’s so-and-so?”, and everything in between.  Doing real things means that successes are more significant, that failures can cost more, and that there is rarely a “do this and everything will be OK” guideline.  Having said that, there are things I’ve learned:

• Don’t let students pick projects.  Offer projects that have been recommended by the community, and which you know will be reviewed, accepted if done well, have support from the community, etc.
• Don’t (or don’t only) mark end products: mark process.  I’ve had students get to the end of a project, and the conclusion was, “This can’t be done.”  Failure is data, and good failure will have a long paper trail and evidence of participation and honest attempts.
• Work out in the open where people can see what you’re doing.  That’s true for the profs, and also for the students.  People will read your blog, properly filed bugs will get attention, wikis aren’t called collaborative for no reason, irc is bi-directional, etc.
• Don’t put students into oncoming traffic.  That feature that’s so hot Mozilla would slip the ship date for it–that’s not the right one for your student
• Don’t put your students in the parking lot.  Things that are so far from shipping (or at least landing on trunk) are unlikely to get you the kind of community contact you’re after.

A lot of this hinges on an implicit assumption on my part: the Mozilla community will engage with a serious attempt to connect.  I could give you lots of examples proving this, but here are a few from the time while I was leading the workshop:

• Joe Drew pinged me on irc to let me know that he’d found two good bugs for student projects, and marked them appropriately using the student-project keyword.
• Mark Finkle wrote a great post with links to a lot of great resources for new Fennec add-on developers.  It was nice timing, given that one of the profs was there to start working on Fennec.  “Does Fennec want new people working on this stuff?”  Yeah, and enough that they are documenting it for you.
• Two guys named Mike took time out of their day to sit down and explain their work, and how it might connect to the interests of these profs.

Making the point and having it made for me are not the same thing, and I was glad these profs had a chance to feel what it’s like for themselves.

We’re excited about how much progress we’re making, getting profs and students hooked into Mozilla.  We’re also really excited to see where you fit, and what you getting involved might look like.  Let us know how you see yourself conneting with Mozilla Education.