Over the last few years, I've been pretty immersed in the world of wikis. A wiki is like a collaborative web site; it lets several people view and edit a web page and link to other pages, maybe new pages that they themselves create. Wikis let tech-savvy people all over the world collaborate on a single web page, a single document. That's a pretty powerful idea, really. The obvious thing to do once an idea like wikis appears is to attempt to cram all of humanity's knowledge into it. Well that's just crazy enough to work. Wikipedia is the gold standard of wikis. It's a collaborative encyclopedia with lots and lots of articles. As the gold standard, it influences people's thinking about wikis in ways that might not be quite true. If Wikipedia were the only wiki you'd ever heard of, you might think that wikis are used to create encyclopedias. If that were true, you'd really only need one of them. If Wikipedia were the only wiki you'd ever heard of, you might be under the false impression that all wikis everywhere are editable by anyone. So if you create a wiki page, it's no longer yours. Other people can scribble on it. Well, some kinds of documents perhaps just aren't suitable for being edited by anyone, and the good news is that you can build a wiki for you and your classmates, or you and your coworkers, and you can decide who gets to edit what. I want to think about a few distinct uses for wikis in different contexts. The most common use is of course to create a knowledge repository; a collection of information written by people who know what they're talking about. That's what Wikipedia is, mostly. That's what the Haskell Prime wiki (which I run) is. And the excellent wiki about the game of Go, Sensei's Library, is also a knowledge repository. But there are other uses for wikis that are pretty cool. I often have to work on proposals with my coworkers. One (horrible) way to do this is to write the first draft in MS Word, email it to everyone, who might edit it and email it back. Of course, only one person can actually edit it at a time, otherwise I have to figure out what everyone did and merge their changes by hand. That's what we, in the computer industry, call teh suck. A better way to do this is to use a version control system, which lets multiple people work on a document at one time. Of course, if you're editing evil document formats like Word, still only one person can edit it at a time, but at least you cut out email, so things are a bit better organized. But wikis are actually a really great way to work on a document with another person. Two or more people can each collaborate on the document using the wiki software over the web. What becomes of the document at that point depends on its ultimate use. Maybe you have to convert it to MS Word or PDF at the end. That's a bit of a bummer. So there are two uses of wikis that I've mentioned: building a knowledge repository, and collaborative writing. Google started a service for collaborating on documents called Google Docs & Spreadsheets, which is probably useful for collaborative writing, but not knowledge repositories. They also acquired a wiki startup a few days ago, so they are clearly trying to get all over this space. There's another very interesting use of wikis that I'll call situation awareness. You can get a really vivid picture of this use of wikis if you take a look at the wikipedia article on the July 2005 London bombings. By the way, I didn't discover this excellent example of situation awareness using wikis. I saw it in the slides for a talk, but I don't know the original source at this point. If you go to that link, you'll see an excellent and up-to-date encyclopedia article about the London bombings. It's not a news article. Go to Google News and try to find a news article from a major news source which is this detailed, up-to-date, and well organized. Most articles you'll find are a snapshot, taken at a particular point in time (when the article was published) that most likely contains an account of the latest developments, and usually brief background in case you missed previous stories. The wikipedia article isn't a snapshot, it's an article that explains things in a logical order, which isn't necessarily chronological. Each wikipedia article contains a link to its own history. You can look back over time and see the article evolve. If you look at the early edit history of that London bombing article, you'll notice something fascinating. The article was created shortly after the bombing, with an account of the information that was known at that time. Within an hour, many people had edited the article, adding information they know about. If you were refreshing that wikipedia entry over & over (or if you were subscribed to it using RSS), you'd see not an account of just the latest developments, but an evolving, logical understanding of the attacks. The article started evolving right away, and it continues to evolve to this moment. That's what I'm calling situation awareness. Don't get me wrong, the mainstream news media is quite good at situation awareness. They do it a bit differently, and their articles or TV stories don't become integrated into a knowledge repository like wikipedia. I've enumerated three somewhat overlapping uses for wikis that I think are pretty interesting to examine:

Knowledge Repositories, which are a lot like encyclopedias,

Collaborative writing, which is a bit like a more elegant version of emailing word documents, and

Situation awareness, which isn't so different from the news; it draws from the news as a source, it can also be authored by the eye-witnesses themselves, and each story becomes an integral part of a knowledge repository. I don't claim that these are an exhaustive, nor are they a partition: Wikis are also used for bug tracking and as web discussion forums, for instance. What other categories can you think of? Email me if you have ideas.

I really enjoy the book The Pragmatic Programmer. One of the suggestions in this book is to learn one new programming language every year. Since the new year is upon us, I though I'd suggest that this year, everyone should learn Haskell. So please apt-get install hugs, grab Yet Another Haskell Tutorial, and get hacking. You'll probably want to have the Libraries API bookmarked. You might want to install the Glasgow Haskell Compiler after a couple of hours. When you get ready to package your first Haskell library for Debian, be sure to check out the state of the Haskell Cabal (the Common Architecture for Building Applications and Libraries). Here's a basic implementation of cat in Haskell. Compile With: ghc Cat.hs -o myCat

import System
main = do a <- getArgs
          contents <- sequence (map readFile a)
          putStrLn (concat contents)

I'd be very happy if folks email me with suggestions on what programming language, API, technique, paradigm, or whatever I should learn this year. You definitely get extra points if you can give me a link to a good tutorial and if an implementation of the language is packaged for Debian.

The idea of breaking programs into functions was taught to some of us with the metaphor of "divide and conquer." That is, make several smaller problems and solve those instead. This approach is now so deeply ingrained that I can just think "partition and solve" which is of course a much more positive and accurate description. One might think of the "partition your program into functions" principal as "the divide and conquer" principal. But of course, they are both instance of the more general "partition and solve". I dare say that "partition your program into functions" is even a more pure and accurate instance of the principal. Evolution may also be an instance of the principal. Different species evolved to solve different problems, or to solve the same problem (survival) in different ways. Of course, when you partition a program into functions, you also define those functions' relationships to each-other. Just because you're partitioning doesn't mean that the problems are not related. When people see several competing projects in the "free software community" trying to solve the same problem, some might say, "Good. We have divided them, now we will conquer them!" In their marketing material (or more likely press-release ranting) they will say that a house divided against itself will not stand [1]. Such people are probably purposefully ignoring the "partition and solve" principal. They ignore the fact that different projects have chosen different paths to solve different problems. They ignore the relationships between the projects, and that we feed each-other much more often than we actually compete. But no good programmer will ignore the relationships between her functions. Even within the Debian project we have lots of different goals. A truly gifted project leader will hopefully not see Debian as a house divided, but rather a very ripe partitioning looking for someone to define the problem that we solve together. A leader should help to define, create, or encourage the relationships that make that solution happen. peace,
isaac
[1] Oh no, I've contradicted the Bible and praised evolution in the same essay! Well, not really. The fallacy is not with the Bible's assertion about the house divided against itself, it's in the interpretation of "the free software community" as a single house. And also, I believe God created evolution :)

I want a cell phone that runs Linux. I've been wanting one for a long time. Why should I care what OS it runs? Well, I have two main reasons: 1) because I want to support commercial ventures related to free software, and 2) I want to write applications for it, and I don't want to be beholden to some vendor to sell me a development kit, and tell me what I can and cannot write. I want to apt-get install the developer kit, write some code, and upload it to the phone. Rock. I've been paying only scant attention to the cell phone market since I got a Treo 600, which I like a lot. It is _not_ a Linux-based phone. It runs PalmOS, which is a pretty crufty OS, but I've been using it since 2001, so I have a lot of data in there. It should be pretty easy to get the data out, though, so I'm not worried. I really like the Treo's thumb-keyboard; It's qwerty, and I can type pretty fast on it. Numeric keypad based phones are lame. I hardly ever type in numbers anyway. Apple recently announced the iPhone, which I shouldn't even mention because it doesn't allow 3rd party applications, doesn't run on a free operating system, and is probably very buggy since they've never done anything like that before. Enough about Apple. As I poke around the intern-webs, I find that some stuff has been happening over the year when it comes to Linux-based phones, but I'm having a hard time figuring out exactly what is happening. It's surprising how little information is out there. Despite this great list of starting places from linuxdevices.com, the rabbit trail never leads to a "buy this phone" button. Look! There's an open Linux-based phone platform called OpenMoko. At least, I think that's what I pieced together from the scant information available on their web site. Maybe OpenMoko is the phone and openembedded is the platform? I had a very nice conversation with some folks on freenode who explained a bit about this really cool project to me. It looks like they even have a phone that it sounds like is going to be released soon, and it's discussed on LinuxDevices.com. That phone looks pretty sweet. It has a GPS built in too. I like the touch-screen idea that I guess it has, based on the pictures, and it's not way too expensive. Maybe that's the phone I'll get. All it's missing is a "buy it now" button. Oh, and "apt-cache search openmoko" doesn't turn up anything. So on to the Green Phone by Trooktech. This looks pretty good, but not as a replacement for my Treo, since the primary interface is a numeric keypad instead of a qwerty keyboard. It looks like you can actually buy a development version of the phone, but it's not overly free; you cannot develop commercial applications on it without paying them a licensing fee. Lamers. According to some folks on freenode, this phone is just a prototype for vendors like this one. (But do you see a "buy this phone" button on that page?) There's a nice article that talks about several of these devices, including the Nokia N800, which is a Linux-based handheld computer / web appliance. I played with one the other day, and it's pretty sweet. Too bad it isn't a phone, or I'd buy one today. So it looks like there's no open, Linux-based, qwerty phone out there yet. If you know otherwise, let me know. Perhaps one is coming out next month. I think I can wait that long.

I'm excited because we're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database. Let's imagine something that would be awesome for the Haskell community. A set of Haskell packages which are all known to work together with a particular version of cabal (the one that GHC comes with), and a particular version of GHC. GHC version 6.6 was just released, and I think we should try to make this happen. Currently, we have a set of 27 "unstable" packages. They may or may not work with each-other. I just created an empty directory "testing". I propose that we start testing packages, starting with the Cabal release that'll went into GHC 6.6, and make sure they work nicely together. Once they're known to work, we can migrate them from the "unstable" directory to the "testing" directory. Once we have a sufficient collection of packages, and once ghc 6.6 is released, we can make a snapshot of this directory, call it "stable-6.6" or something. Then if you have ghc 6.6 and cabal-install, you should be able to "cabal-install p" for any package, and it'll definitely work. So what will we need for this to happen?

An installed version of ghc 6.6 on the hackage/darcs server. Maybe in a chroot or something. Maybe from the nightly build tree or the previous snapshot?

Some initial set of packages (maybe just cabal-install) to start off.

Some script that goes through and builds all of the "unstable" packages in dependency order. I think cabal-install can do this already. In fact, it would be ideal if we used cabal-install for this.

The script should also run ./setup haddock and ./setup test. If the packages seem to work w/ 6.6 and the other packages in "testing", it should get migrated from "unstable" to "testing".

A web interface (lemmih is working on it)

A script to upload packages to "unstable" (Paolo is working on it).

Someone to spearhead all of this! We need volunteers. Please email me if you think you can head this up.

let haskell' = succ haskell98 in
Announcing the Haskell' ("Haskell-Prime") process.  A short time ago,
I asked for volunteers to help with the next Haskell standard.  A
brave group has spoken up, and we've organized ourselves into a
committee in order to coordinate the community's work.  It will be the
committee's task to bring together the very best ideas and work of the
broader community in an "open-source" way, and to fill in any gaps in
order to make Haskell' as coherent and elegant as Haskell 98.
Our task is broadly defined by our mission statement:
    The Haskell programming language is more-or-less divided into two
    "branches".  The Haskell 98 standard is the "stable" branch of the
    language, and that has been a big success.  A lot of progress has been
    made over the last few years in the "research" branch of the Haskell
    language.  It is constantly advancing, and we feel that it is time for
    a new standard which reflects those advancements.
    Haskell' will be a conservative refinement of Haskell 98. It will
    be the work of this committee to adopt a set of language
    extensions and modifications and to standardize a new set of
    libraries.
    We will strive to only include tried-and-true language features,
    and to define them at least as rigorously as Haskell 98 was
    defined. This standard will reflect the realities of developing
    practical applications in the Haskell language. We will work closely
    with the rest of the Haskell community to create this standard.
Your Haskell' Committee is as follows (slightly munged email addresses
follow):
 * Manuel M T Chakravarty <chak at cse.unsw.edu.au>
 * John Goerzen <jgoerzen at complete.org>
 * Bastiaan Heeren <bastiaan at cs.uu.nl>
 * Isaac Jones <ijones at galois.com>
 * John Launchbury <john at galois.com>
 * Andres Loeh <loeh at iai.uni-bonn.de>
 * Simon Marlow <simonmar at microsoft.com>
 * John Meacham <john at repetae.net>
 * Ravi Nanavati <ravi at bluespec.com>
 * Henrik Nilsson <nhn at cs.nott.ac.uk>
 * Ross Paterson <ross at soi.city.ac.uk>
 * Simon Peyton-Jones <simonpj at microsoft.com>
 * Don Stewart <dons at cse.unsw.edu.au>
 * Audrey Tang <autrijus at gmail.com>
 * Simon J. Thompson <S.J.Thompson at kent.ac.uk>
 * Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk>
 * Stephanie Weirich <sweirich at cis.upenn.edu>
The editors are Isaac Jones and John Launchbury.
Feel free to contact any of us with any concerns or questions.  If you
don't know who to direct your questions to, email Isaac Jones
ijones at syntaxpolice.org.
Community involvement is vital to our task, and there will be a way
for members of the community to make formal proposals.  In the opening
phases, please use these more informal resources to help us coordinate
Haskell':
 * The haskell-prime mailing list.  All technical discussion will take
   place here, or (if other meetings take place) be reported here.  Anyone
   can subscribe, and any subscriber can post questions and comments,
   and participate in discussions.  Anyone can read the list archives.
   http://haskell.org/mailman/listinfo/haskell-prime
 * A wiki / issue tracking system to document consensus and to track
   ongoing tasks.  This system is publicly readable, but only
   committee writable so that we may present it as the "official"
   output of the committee.  If you ever feel that the wiki is not
   accurate as to the consensus, please alert the committee!
   http://hackage.haskell.org/trac/haskell-prime
 * A darcs code repository for experiments, proposed libraries,and
   complex examples.  darcs is a decentralized system, so anyone can use
   it, but patches should be sent to Isaac Jones:
   http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode
Please join us in making Haskell' a success.

Are you a software developer? Are you graduating soon? Maybe you should get involved in free software projects! There are any number of reasons people get involved, from altruistic reasons to selfish reasons. Let's approach it from a "selfish" point of view. I assert that involvement in free software projects looks really good on a resume, and is an excellent way to "network". Networking isn't all about schmoozing at job fairs; it's about building a reputation with professionals in your field. There are very few fields where a huge number of professionals are so very accessible. Software developers are very lucky in this sense. Common wisdom seems to indicate that the job market for software developers is very competitive, and it's going to continue to be competitive for a while yet. Any edge you can get over your classmates is going to help. There is plenty of opportunity to contribute, no matter what your skill level. There is documentation to write and there are translations to perform. There are bugs to fix, and packages to create. Of course there are projects that need more "serious" development as well. You don't have to start your own open-source project, and you don't have to learn to hack on the Linux kernel to add something very attractive to your resume. When people ask me how to get involved in free software, I usually recommend that they start out reporting bugs in the open-source software they use frequently. You might install a version of GNU/Linux, or if you want to stick with Windows or MacOS, you should browse around to find out what free software is available. I think you'll be pleasantly surprised. Let's use "Gaim", a multi-protocol IM client, as an example of how this might proceed. Gaim runs on Windows, GNU/Linux variants, and I'd expect MacOS X, and Unix. It's open source and free: http://gaim.sourceforge.net/. Download Gaim and the Gaim source code. Build it for your machine if you want. Notice what language it's written in. Do you know this language? If not, can you understand it (if you know Java, you can probably understand a lot of C, for instance). Try out Gaim, set up your AOL Instant Messenger and your IRC channels. Visit some open source channels. See any problems? Check the bug reports to see if anyone else has seen that problem. If not, report it as a bug (you might want to google for "how to report a bug" first). Now check out the "bug reports" for Gaim. Pick a bug and try to reproduce it. Why are bug reports the first step in improving your resume?

Reporting a bug is a half-hour task.

Fixing a bug is often (not always) a small, weekend-sized task.

Bugs introduce you to the source code on a level where you don't have to understand everything (hopefully).

You will build familiarity with debugging tools which are invaluable for a developer.

You will start to build a reputation with the authors of the software, and in the free software community.

And because developers are always very happy to get bug fixes that they didn't have to work on themselves. Let's take a look at the bug list for Gaim again. Different ways to contribute to fixing a bug:

If you can reproduce the bug, you might add more information to the bug report: What steps did take to reproduce it? Is there a unique combination of features you need to be using to cause the bug?

If you can't reproduce the bug, maybe it's fixed in the version you're using! Maybe you should add that to the report (better read and understand it very carefully first). Pick another bug, repeat.

Depending on your skill level, you might try to fix this bug, or at least isolate where the bug came from. If you manage to fix it, read about the "diff" and "patch" utilities. Send the author a patch, or attach the patch to the bug report. Here is a bug that looks pretty easy, and it doesn't look like the developer is particularly thrilled to spend time on it: "Buddy Pounce does not get removed when user is deleted". I'm going to take a wild stab at how you might fix this bug: most probably, there's a "list" of "pounces" that has a data-structure which contains both the buddy's name, and the pounce action, whatever that is. Find the code where the buddy is deleted from the buddy list (a different list). Add code to search through the "pounces" list to delete that buddy from the pounces list as well. Compile, test, and run diff to create a patch, attach it to the bug report, take a bow. Now add this to your resume. You are now 50% more interesting to me, as someone who reads resumes, than your classmates who have never taken on a project outside of school. You've shown initiative, skill, and maybe even teamwork. Higher levels of commitment If there's a piece of software that you love, that you think is really important, then you might try adding features to that software and joining the development effort. Lots of projects have a page dedicated to information about how to help out. Here is one for the Mozilla project, for instance. If you want to lead a development project, you might adopt one that has been orphaned. Many people recommend against starting your own project off the bat. I've presented you with a method to increase your skill and reputation, and to add something interesting to your resume. Try it out. You might find out why so many software professionals work on free software projects. It's tons of fun! Feel free to send me comments on this document, or to tell me whether this advice has effected you.