Modifying Vim's choice of syntax highlighting by file type
I've often wondered how to tell Vim that files with a given extension should have a certain syntax highlighting applied to them. Now I've finally gone to the trouble of finding it, and it's pretty straightforwards. Adapted from vim's online docs:

1. If you don't already have one, create your user runtime directory. In Unix,
   mkdir ~/.vim
2. Create a file called "filetype.vim" in your user runtime directory that contains autocommands to detect the file type. Example:

   if exists("did_load_filetypes")
     finish
   endif
   augroup filetypedetect
     au! BufRead,BufNewFile *.rhtml     setfiletype html
   augroup END
   

[/code]

Northeastern Free Culture forum

I took advantage of my itinerant freelancer lifestyle to do some coding while sitting in on today's kickoff forum for Free Culture Northeastern. A general account of the forum, with linky goodness, can be found here.

I estimated 200-300 people in attendance, which packed the room. The vast majority appeared to be students, with a few staff/professorial types thrown in, and the odd straggler such as myself. I made it just in time to hear Lessig. Most of the crowd stuck around for Derek Slater, slightly less for Nelson Pavlosky, and the crowd shrunk down to maybe 1/3 its original size for the Q/A part (not bad after 100+minutes).

As a coder, I was interested to hear Lessig's argument that the Free Culture movement, among other things, should aim to support Free (vs. Open Source) software developers, since software does in fact determine policy (as explicated in Lessig's Code). Nelson had previously noted that from a consumer standpoint, cars with welded hoods are bad.

Apple was repeatedly called out for its poor behavior with regards to DRM. An example I'd never thought of: it's impossible to get media from ITMS under any kind of flexible copyright agreement. You can't get stuff available for remixing, etc.

Part of Lessig's message was clearly that DRM is wrong, and there's a huge need for students and the general public to fight it. However, insofar as we have it, it's important to architect DRM so that it allows freedom. At least, that's what I took away from his response to Mako's question (which was presented live by Mako himself).

Someone who I think was faculty at the NE business school asked about what happens to the economy if culture is all free. Lessig's response: you're thinking of the wrong kind of free. Not free as in beer, free as in liberty. Free speech doesn't mean the New York Times can't sell you a newspaper or Times Select. Nelson's response: look at web comics artists, they're producing cultural artifacts on the web and many are making a living at it, with no DRM in sight.

It'll be interesting to see if Free Culture Northeastern takes off as a going concern. Given that this was a successful and high-profile forum, the opportunity seems ripe for members of the Northwestern community to get something going.

[/boston]

a historical perspective on Social Software

I was just introduced to Clay Shirky's A Group Is Its Own Worst Enemy (via Jeremy Keith), and it's got me thinking. Go on and give it a read, it's worth it.
From 1/3 through:

Now, this story has been written many times. It's actually frustrating to see how many time it's been written. You'd hope that at some point that someone would write it down, and they often do, but what then doesn't happen is other people don't read it.

This resonates with my personal experiences. I've seen this story play out a few times, including on slashdot and on BBSes in northern Minnesota - but this may be the first time I've read a persuasive explanation of the morasses that online groups often fall into. In particular, Shirky's summary of W.R. Bion's work is of interest, as he seems to have nailed a big chunk of the phenomenon 50 years ago.

So it's interesting that Clay has recorded these lessons and presented them at ETech three years ago. Here I am reading them, and 273 other people have bookmarked them in delicious... but it doesn't seem that a significant portion of the people building and operating social software are aware of them yet.

Though I'm not clear on how directly the conclusions Clay draws are based on W.R. Bion's results, they sound good and I think they're worth considering. First, the inevitable features of social software systems:

1. Technology and social structure are inevitably intertwined; you can't think about one without the other.
2. Out of the greater mass of users, a subset will be qualitatively more involved. If the code doesn't treat them special they'll come up with their own ways of being special.
3. The core group of users has rights in and of itself other than those of participating individuals.

Second, the factors you ought to include in your system's design, if you want it to work consistently with the above lessons:

1. Some form of identity, at least strong pseudonymity.
2. Recognition of good membership.
3. Barriers / costs to participation. Optimize for ease-of-use for the core group, rather than any arbitrary individual.
4. Limit scale to a reasonable number, so that the community doesn't deteriorate due to excess size.

[/general]