My take: this should absolutely be encouraged. How many term papers ever see the light of day after they’re graded? The paper benefits the student, maybe the professor, but rarely anyone else. Can you imagine how many papers college students have written about Rimbaud’s Drunken Boat? Wikipedia needs you!

I’ve thought about the merits of Wikipedia assignments ever since I started editing back in college. The issue of public exposure wasn’t so important. I’ve had that since I was little. It was mostly the idea of not letting all the research I’d done for a course go to waste. I was so enamored with the idea that I gave it a trial run myself. After writing a term paper on two ancient Greek astronomers in the Fall of 2005, I created articles about their works. It was a good but surprisingly time-consuming experience for me. Putting my work on display for all the world to see forced me to double-check everything I’d written, clarify my reasoning, and introduce explanatory figures and tables. But the finished product was great. Those two articles I wrote are undoubtedly the best online source for their two topics. And they’re unexpectedly deep content for Wikipedia, which is not necessarily known for its coverage of original materials or ancient history.

The main problem with this approach is that Wikipedia may not accept these changes with open arms. The professors made some good points about this in their slides. The Wikipedia way is to start small and rough, and edit your way to a finished product. I did this for my two articles. This is the way papers are written as well, it’s just that the process is less visible. What’s more, it helps to be familiar with Wikipedia culture before making major edits. For the students whose articles were deleted or merged, I’m sure they could have asked whether there articles were appropriate on some talk page or another. For contributors not familiar with Wikipedia’s style, their contributions will be a heaping mass of words in need of copyediting. This would be even more important if the students had been assigned to edit an article, rather than write one from scratch.

All in all, if done well, this use of Wikipedia can be great for both the students and the community. Here’s the money quote from one of the students:

This assignment felt so Real! I had not thought that anything I wrote was worth others reading before, but now I think what I contributed was useful, and I’m glad other people can gain from my research.

I read “The Cathedral and the Bazaar” as an introduction to the world of open source software for someone interested in joining it. There’s a history lesson to explain where you’ve come from and what you’ve accomplished. There’s arguments and a case study to show that you’re on the right ship. And finally, the essay serves as a call to arms, to get you excited about becoming a contributor.

I found the history lesson most interesting. I’d had some understanding of this before, but lacked much detail. ESR gives a first-person account of UNIX and software development from the late 1970′s to the present. This is the canonical story of open source. It has its heroes and villains, its true believers and false idols. There’s the Moses figure, Richard Stallman, who freed the users of UNIX from the oppressive yoke of restrictive licenses. But like Moses, he couldn’t enter the promise land. Open source stagnated, awaiting its Last True Prophet. This was Linus Torvalds, who created the Linux kernel, the last piece of the open source operating system.

ESR really uses that of tone. I get the sense that he’s intimidated by Richard Stallman and absolutely idolizes Linus Torvalds. The essay drips with hero worship. Linus is the visionary whose vision he’s writing about.

Beyond the hero worship, there is a clear exposition of the open source model. In order to avoid the problem of N^2 channels of communication amongst N contributors, open-source project have a small set of core developers. These core developers have total control over the project. They decide what gets checked in, and where the project goes. It’s a (hopefully) benevolent oligarchy. Outside of that core, there are occasional contributors and legions of testers, who can submit bug reports. Does this strict hierarchy really sound like a Bazaar?

If you want a real Bazaar, think about Wikipedia. Since I’ve never contributed to an open source project, I kept it in mind as a reference point. It works pretty well, but this perspective has the side effect of making open source development look positively Cathedral-like. Think about it. Rather than having a core set of contributors and legions of users/testers, Wikipedia explicitly aims to make all of its users into contributors. It does this by lowering the barriers to entry as low as it conceivably can, even if this leads to vandalism. All that’s needed to contribute is the ability to write in some language. Last time I checked, English had a few more speakers than C++. Rather than just reporting problems, users are empowered to fix them on the spot. See a typo? Just correct it. Want a citation? Find one and plop it in to help future readers.

I enjoyed “The Cathedral and the Bazaar” for the history lesson, but I find its central image misleading. The development process of open-source projects is as well-organized as any commercial venture.

Edit #2000 feels a bit cheap, since it was actually made by a bot. On the other hand, I personally scraped the data it’s using, wrote the program to generate the bracket from that data, and wrote the MediaWiki uploader program. Still, with this bot and the Grand Slam Project (I’ll write more on that later), I’m probably going to hit 3,000 all-too-soon.

I’ll write more about the math later, but what I find most interesting about it is how it naturally fills in the “boring space” inside the Mandelbrot set:

The interior of the Nebulabrot is also a fractal, as a zoom shows:

Those little buds are all Mandelbrots.

Being a CS-type, once I saw the definition, I immediately set out to render the most detailed Nebulabrot ever seen. It’s 10240×7680 and gorgeous. Here are some zooms (click for full-res versions):

The most “nebular” part

“Island universes” along the negative x-axis

Here’s a link to the full JPEG (4.3MB) and the full PNG (44 MB).

If you zoom all the way in, you’ll see some graininess, even in the PNG. This isn’t a compression artifact. It’s a hint of further structure. If I’d cranked up the dwell limit in my rendering, the noise would have been even more miniature Mandelbrot sets!

Update: MarkCC over at Good Math, Bad Math has a post about MapReduce that discusses the way I generated this at length.

For comparison, here’s the chart for last year:

The overall features are quite similar: the important dates stand out clearly in each chart. The total edit volume in 2007 is about double what it was in 2006, which is consistent with Wikipedia’s rapid growth. The edits were more front-loaded in 2007. Selection Sunday was far and away the busiest day, and the edits decreased steadily into the later rounds. This may indicate that fans contributed content relating to their favorite teams, and then stopped once that team was eliminated.

Shortly before last year’s tournament, I wrote a program to create a basic article for every NCAA tournament, from 1939-2005. The articles had a list of teams, locations, and a bracket. The idea was that, once the tournament got underway, other contributors would spruce the articles up a bit with some individualized content. Here’s a plot of the cumulative edits to the 1939-2005 tourney articles.

There are clear spikes during March Madness each season. Cumulative, there have been 1,493 edits to these articles by users other than myself, an average of 22/article. This is a bit skewed by the more recent tourneys, though. The median number of non-Dan edits is 10/article, which still isn’t bad. Wikipedia has its own flavor of the “release early and often” mantra from open source software. It’s not important that the article be perfect the first time around. It’s more important to just put something out there so that others can improve upon it.

Internet video really is coming into its own. This year, for the first time, you can watch the games online with March Madness on Demand. As with the NewsHour Online Video Archive, there are still some kinks to work out. Biggest gripe: it only works in Internet Explorer 6 on Windows. No love for Mac users like myself. What’s worse is that you don’t even get a message telling you that IE6 is required if you load it in Firefox. It just mysteriously doesn’t work. Hopefully this tool will be better next year. The main thing is that it exists at all.

Oh, and if a game is being broadcast on CBS in your area, you’ll get a message saying it’s been blacked out. Yeesh.

The Wikipedia article on the 2007 tourney has been fun to watch. In the last ten days, it’s received over a thousand edits. Wikipedia edit counts aren’t a bad way to track current events. Here’s what the edit history for last year’s tourney looks like:

The major events stand out in stark relief. One caveat: if an article gets protected by an administrator in response to vandalism, it throws a wrench into the fluidity of edits. I’ll post a similar chart for this year’s tourney after it’s over.

The Signpost was sorely lacking an RSS feed, so I’ve put one together at http://feeds.feedburner.com/WikipediaSignpost. The feed should get updated weekly with the Signpost, with only an hour or two delay from publication.

I set this up as a simple Ruby script, but in retrospect, had I been more ambitious, I would have used Plagger or Dapper.