It seems like I've written dozens of drafts of sketches of designs for a new music website, with this just one more step in the series. However, events -- admittedly not all that well understood by me -- have conspired to make this a do-or-die proposal. Or more likely, a final, soon-to-be-forgotten, stake in the ground.
In 2001 I built a website forRobert Christgau. By that time he had written three decade-spanning Consumer Guide books based on more than 30 years of more-or-less monthly columns. They totalled over 10,000 short album reviews with letter grades, so the first thing I wanted to do was to collect them into a database that could be queried in various ways: by artist, by title, by label, by release year, by grade, etc. I added to this an archive of Christgau's numerous essays (or "pieces"), grouping them variously by subject or publication. These, too, were indexed in a database, but I never wrote the code for flexible queries of that database, so they were only accessible by browsing directories or using search tools -- one of many unfinished design intents.
As I was working on the Christgau website, I came to recognize various flaws in the design or problematic limits, and started to think about how a Version 2 would address them. One big problem which has confounded me ever since is that my simple artist and label tables were overnormalized: in the real world there were extensive clusters of related artist (and label) names -- just to pick one example, Christgau has reviewed Peter Stampfel records released under eleven different artist name variations. It then becomes very difficult to turn those separate entries back into a coherent listing for Stampfel. (I did eventually come up with a hack for this problem but it isn't a proper solution.)
While I was thinking about the design of a Version 2 of the Christgau website, I was fleshing out a generalization of the same concepts that could be used for other writers to generate websites similar to Christgau's. I called this the Writer's Website Project. If you look atHullworks.net you'll still see a slogan for the project ("Dedicated to making free content on the web cheaper") and a broken link promising further info. That project foundered on some fairly pedestrian technical problems -- e.g., I never got the user management code worked out, which is a basic piece of every CMS package ever developed. But I also didn't get a lot of writers to work with, some who were sympathetic had already tied themselves up with a paywall outfit calledRock's Back Pages, and I was getting increasingly sucked into my own writing.
Parallel to the above, I had been cobbling together my own website. I started in 1998 when I was working for SCO -- they hosted employee pages under the "ocston" disclaimer -- and I turned them intoTomHull.com after I was sacked in 2000. One of the first things I did was to take an old file called "records.txt" which listed most of the records I owned and grades as best as I recalled and turn it into a primitive (flat-file) database. I added both new records as I heard them and recommended records from various references sources (the current totals are 48882 records listed and 22955 rated). I also collected my old rock critic writings into anarchive. In 2003 I started adding to them by writingRecycled Goods, in 2005 the floodgates opened withJazz Consumer Guide (and its spinoffJazz Prospecting), and in 2007Rhapsody Streamnotes. In the course of those three columns I've probably written over 10000 short reviews -- enough to stuff into my own Christgau-like database, if only I liked that database.
Several reasons I haven't done that yet. One is that while it would be handy for me personally to have such a database, I've become convinced that what the world needs is a music website where many people can come together to share their knowledge and opinions about music. Rather than doing something personal -- or, as the Writers Website Project proposed, having lots of people do something personal -- I would rather contribute my data as a seed for something other people can build on. One thing that has become clear to me is that while tracking individual critics has a distinct advantage in coherency, no single critic can cover a broad enough range to satisfy many other people.
On the other hand, I'm not looking to cover everything (like All Music Guide) or to take a neutral position (like Wikipedia). I'm looking at least for the coherency of a tribe -- a group of people who approach music in sufficiently similar ways that their opinions are likely to be of interest to each other. Who these people has never seemed like much of a problem -- I know dozens of obvious candidates -- not that getting them to work (and to work together) is easy. But it's long seemed to me that the basic principle of "build it and they will come" applies here. The problem has always been building it.
The following section is a brief sketch of his I imagined doing that:
When I built the Christgau website, I used the basic free software platforms of the time and coded the entire site from scratch. I used PHP as the coding language, and stored the data in a MySQL database (plus the file system). The web server itself was Apache, although I hardly did anything at that level. My first inclination has always been to follow that same approach, which meant expanding the website by developing an increasingly sophisticated data model. Indeed, most large music websites (e.g., All Music Guide, Discogs) are so closely bound to their data models that you practically reverse engineer them by looking at how the pages are organized. The major exception to this is Wikipedia, which has a vast amount of music information without any specialized data structures at all.
I ultimately decided that there are three main problems with the hard-coded "from scratch" development model:
- The data model is really hard to design and get right.
- The bigger a "from scratch" system gets the harder it is to maintain and evolve -- to add new features, etc.
- When working "from scratch" you wind up having to write a lot of extra support code (e.g., for common tasks like user roles) that is readily available in kit form.
Since I built the Christgau site, a lot of people have written, using the same free software tools, more general "content management systems" that can be used and then customized for a wide range of websites. I've used several such packages over the years, and they vary depending on what sort of interactions they support, how much collaboration, and how easy they are to customize. I did an extensive search and review of these packages 5-7 years ago, picked out a couple, and unfortunately they didn't work very well -- a setback. At this point I'm hopeful that two packages I don't yet have much experience with will work out better: Mediawiki and WordPress.
Mediawiki is the software used to implement Wikipedia, and web's vast online encyclopedia to everything. The main purpose of the music website is to provide a reference resource: an encyclopedic guide to all worthwhile (in the tribe's opinion) music. Mediawiki imposes no fixed structure on this, although it leans toward atomicity: one page per album, one page per artist with links to each album. Index pages can be grouped any way that makes sense: a list of albums under labels, a list of artists under genres, lists by year or period. One feature I regard as particularly important is recommended album lists, which again are just hand-edited lists. Adding a new feature, like a section on music books, is as simple as doing it.
Mediawiki is focused on collaboration, and by default allows anyone to edit pages (although this can be restricted). As protection against sabotage, it provides strong revision control. Each page has a discussion page, so you can keep a running log of notes about proposals for editing pages. It has useful templating features: it's very easy to create "stub" pages (e.g., when you need to add a musician or album) and it's easy to identify stub pages needing further revision. One could, for instance, start by generating stub pages and dumping my review data onto the discussion pages, relatively quickly creating a substantial start.
I have other questions about how to use Mediawiki: in particular, how to extend it. One essential part of the website is a rating system, combining the ratings of dozens or hundreds (or potentially thousands) of contributors. To do this we need a special database which has album information, grader information, and grades. The main complication to album data is release info, which sometimes matters for graders and often doesn't. I'm inclined to limit qualified graders to people who fill out a fairly extensive profile (not all of which need be public) and who are able to grade a substantial number of albums (at least 1000, maybe more). We would need hand-coded pages to maintain the database, and some code which can be embedded on Mediawiki pages to pull out the current grading summary. Also pages of links sorted by ratings data. From a development standpoint, the ratings database could be developed separately and merged at some future point.
We should also give some thought to licensing. I'm inclined to use a license compatible with Wikipedia to make it easy to move data back and forth, helping both websites.
Mediawiki provides fairly minimal tools for identifying recent changes, but they would make for a very dry news source. Accordingly, I suggest using WordPress in a blog mode for providing a news feed -- both about the reference site and on current music news. (I assume this would be more reviews than gossip or download links, but that may just be me. It could also have a non-review focus likeOdyshape.) It looks to me like the front page of a WordPress site could present multiple streams (virtual blogs), so these could be blocked out with a reviews stream, one for news, one for reference site change activity, one for new ratings data, and so forth. Several of these may require custom code to be written to create custom plugins. (I haven't looked at the plugin interface, but there are several thousand plugins readily available, so how hard can they be?)
It's not clear to me whether there are any incompatibilities to running two CMS systems on one website: the packages are designed to install each in its own directory, both use MySQL but each picks a distinct table prefix so they can share the same database. The user systems would be distinct, resulting in the inconvenience of having two login names and passwords (but only if you work on both parts). Links from one part to the other may be a bit trickier, but no more so than linking to external websites.
I currently lease a fairly low-end dedicated server, so I assumed this site could be built there. And I own a usable domain name,TerminalZone.net, so there would be very little cost (work is another story) to setting up something. I never tried putting a business plan together, because I've never had a sense of how to raise money off such a website. One could, presumably, beg more money to buy more bandwidth if that becomes an issue, but funding staff (and freelance writers) is not something I personally worry about: while nice for those receiving, I'm not sure that it really helps much.
But then that may be one reason I'm just throwing this out, and expecting nothing to come of it.
After MSN dropped Robert Christgau's Expert Witness blog, I promised to write something about what I thought it would take in a music website for people of similar tastes to move forward in a post-Christgau world. This is (more or less) the post I had expected to write, but much water has passed under the bridge since then, including some things that may (or may not) be confidential (but that I don't understand well enough anyway). The stuff I do best understand is that I've dropped my Jazz Prospecting and Recycled Goods columns, so I've started to back peddle as a music critic, and will before long become as washed up as anyone else. (In the meantime, I have moved part of those efforts into Rhapsody Streamnotes, and have what I think is a very nice and possibly even useful column coming out next week.) So my personal desire to keep the world informed on new music has started to wane.
On the other hand, I am leaning towards doing more technical website work. I'm looking at WordPress for a couple very different applications. I'm also likely to do more programming, so I'm shifting focus a bit, and that's led me to described the website above more in terms of tools than content.
About two years ago several acquaintances asked me to put together some sort of webzine. We had, at the time, a mailing list with about a dozen names on it, but it gradually became inactive through nothing like a conscious decision. That could easily be resurrected to talk about this. As I said, I'd be willing to contribute some technical resources and coding skills (although possibly not up to the entire job) and a lot of data if other people would take it over and drive it forward. Nor am I terribly rigid about any aspect of this -- not that I haven't spent a lot more time thinking about this than the few hours it's taken to throw this post together.