Seth had some great advice that helped me form my thinking about how I should proceed as a technologist as well as how the folks rallying together at pubforge.org might best proceed as a group.

As someone who has built a good part of a station site using a particular brand of open source technologies (let’s say, I’ve chosen to drive our station around in the open source equivalent of a Ford), I will be facing a decision, given that there seems to be some considerable intertia in the Chevy camp. But now may not be the time to jump from one moving car to another, at least not yet.

Seth suggested that some good first steps would be for us to:

• Identify group of stations (or individuals) who are willing to work together around a specific (technology) or goal.
• Arrange for a week-long training session for the group in a single physical location. Either decide which city you would like to hold this as a group, or decide the city based on where the training is being held. (For plone users, he suggested contacting Joel Burton about a Plone Bootcamp — for drupal users, he suggested talking with Jeff Robbins at lullabot.com).

He went on to say that the benefit of getting together in the same place would:

• be an indicator of commitment - those who would be willing to travel would be more invested
• Getting out of the office would allow us to focus better
• It would be an opportunity to forge bonds socially and increase networking opportunities

He suggested we identify which projects are currently in development (such as the drupal stations modules project, or find/start a broadcasting equivalent to the ploneforartists project). He suggested we identify which aspects of these projects we would like to see improved or added upon. He suggested that we could add an economy of scale by either collaborating on code as a group, or by pooling our cash to pay for additions to the codebase.

He suggested that we check into the pricepoints for training. If we have x number of participants, what will it cost us?

He suggested, in looking for people who would be willing to attend the training, that we should start with the folks who initially put the module together, for instance the drupal station modules were originally designed for KPSU, a college radio station in Portland, Oregon. Maybe this station would be a good place to start with a partnership, and then look outward from there.

I guess that leads to the question, is there a listing of folks from the latest IMA conference who were interested in using Drupal, Plone or alfresco (or perhaps frameworks such as jboss or ruby, or django — or even closed source cms’ like Jack Brighton’s work with expression engine) the list goes on? Do you think such a list should be put together at pubforge.org?

To get a better idea how these discussions might be beneficial to Seth in his work, I asked “what was in it for him?” He replied that he wanted to keep tabs on the progress of these initiatives, that he would be interested in helping us form an organization, for helping us decide how such an entity would be structured, and how we are going to go about making decisions. His emphasis is in identifying the requirements for a product, in product selection, in enabling developers to work together and enabling companies work together using collaborative techniques / open source tools. Perhaps we’ll draw on his expertise again further down the road?

John’s and Dale’s ideas here about using PBCore are excellent, and this is a great place to discuss shaping new practices with media and metadata. I do think XML is the key to unlock access to content, and to expose metadata in whatever flavor and variety is wanted for particular purposes. So an RSS 2.0 feed is good for one purpose, and a PBCore XML record works for something a little more full-blown. In the latter case, we could use PBCore records to connect the dots in a federated collection of public media content at a highly granular level, by developing applications to parse, sift, search, and serve the data. It could look like one collection, but the content could be anywhere. This model is becoming more common in the library world where an XML protocol like OAI-PMH is used. (See http://www.openarchives.org/ )

With this in mind I recently developed templates in my content management system to output various XML formats, including RSS, Atom, PBCore, and Dublin Core. You might have seen me fumble thru a demo of this at the IMA Tech Session Show and Tell. You can see the beta version of this at http://will.atlas.uiuc.edu/index.php/prairiefire/ . Scroll down to find the Syndication menu in the left nav. The PBCore link will generate PBCore XML for the latest 10 episodes of this show we produce called Prairie Fire. When you are on one of the Episode content pages, the PBCore URL reflects just that episode. Same for Segment PBCore URLs. The URL calls the template to display the specific record or set of records, so it becomes the key to everything.

To what end? Right now, it’s just a demonstration or proof of concept. Eventually this could be used by Content Depot or NGIS to suck in metadata and media objects for system-wide syndication. (You know, as in Syndication.) In this case, the primary media item would be a broadcast-quality file, not a streaming archive. Then you’d also have a reference to the streaming archive as part of the PBCore record, along with other versions and related assets like a thumbnail image, etc. But I’m not sure PBCore is the right format to wrap up related media assets, so we could use standards like like MODS or METS which can include PBCore records as nested elements. In fact, when people begin using our media we’ll want to harvest tags and trackbacks, which add valuable metadata to the existing record. So we’ll want a way to encode this metadata and allow the total package to evolve. PBCore can be the item-level metadata format, but all related items might best be encoded in something else. Then everything can live and breathe as an item, a collection of related items, and a collection of collections. (Am I getting too meta here?) I’m suggesting that this method leads to media objects that harness collective intelligence, with metadata records that evolve with use. Our technical systems should allow for preservation of this metadata along with the media object at its core.

So what to do next? I’m going to finish building out my little CMS implementation and see where it leads. There are zero actual PBCore applications that can use this stuff, far as I know. But this is really easy to do, and it might lead to some other easy ideas…which I think are often the best kind!

First off, I agree that the political hurdles to implementing a standardized and centralized media back-end for the public media world are daunting. Further, I think what we see as “public media” is going to shift around rapidly in next couple of years, so determining who is “allowed” into the fold will becoming increasingly difficult (e.g. can a library join, or do you have to be a broadcaster with an active high-power FM or TV license?). There are other challenges as well, but let’s leave that issue alone for the moment. Back to the tech…

I think a centralized storage system is probably a bad idea, or at least one that would be difficult to achieve for all kinds of reasons. It’s also unnecessary. Why does everything have to be stored together, under one roof? The storage can be anywhere. It’s the live, searchable content index that would be most useful to the public, to other stations, to search engines and more. Let’s just remember that storage and indexing do not have to occur at the same place.

Now, about RSS. I think RSS is a great syndication system for short-form and linked media for recently published items. But RSS strikes me as insufficient as a deep-catalog syndication system. For example, how would I syndicate — using RSS — a catalog of 50,000 items or 100,00 items, in which the items are drawn from a variety of subjects and media formats and sources, each with various rights and authors associated with them? Theoretically, RSS could do this, as it’s just a string of XML. However, RSS 2.0 in its baseline configuration doesn’t carry all the data a centralized search system would need. Sure you can extend RSS with your own additional XML tags (just look at iTunes), but it still sounds a little silly to me to do it that way.

What I would propose is the establishment of a standard metadata description and storage pointer language, based on the PBCore schema (which is pretty complete already). Each public media entity would then expose its metadata index and its digital media archive to the public, to other stations, and to a centralized repository that would periodically accept updates from the edge storage and indexing systems. Access to the data could be tiered as desired, exposing only those items you wish to expose to various users or partners.

Using this metadata standard would allow the proposed central index to gather information from repositories both inside and outside the public media world.

In this way, we have the local control required (for whatever reasons) over media assets, yet the central searchability of our content is not impaired. Local entities would be required to meet certain metadata standards (and tests) before being accepted into the central indexing system. And getting into the system would be a high priority for any media companies wanting to be “found” online, especially in areas beyond the reach of any legacy transmitters.

The big plus is that while there would have to be an entity building and maintaining the indexing service, the various players would only have to meet a baseline standard protocol, mostly eliminating the politics. Yes, fights break out at the IEEE from time to time, but in the end, they do reach broadly interoperable standards.

Or… and here’s a subversive bit… do we just implement the metadata standard and then call up Google and tell them how and where to index all our content?

Impossible for a number of reasons; here are a few:

1. Too broad a variety of players with too diverse a set of needs and too great a disparity of resources and capabilities.
2. Too decentralized an organizational structure for there to be a central authority to mandate and enforce adoption of a non-binding resolution, let alone a content management system and accompanying business model.
3. If one could reach agreement on a unified approach, that process, plus the infrastructure development and deployment process would likely take so long that the final result would be already obsolete on rollout.

And it would be undesirable for a number of reasons; here are a few:

1. It would build inflexibility into the system–the platform would have to be renogotiated and reinvented every time a technological surprise comes along.
2. It would enforce a least common demoninator set of features
3. It would discourage the lively development of new media literacy and expertise at the station and producer levels.
4. Where unified platforms exist, as at cbc.ca, the region level (or station-level in the US model) almost disappears. I recall from 2 years ago that CBC presented numbers showing that 95% of traffic went to the national level, while the 16 region sites split the remaining 5%. While this may be less important in a centrally funded service, it would be a killer in a system like ours where most revenue in the system is derived from the station.org level.

The question then becomes, how do we gain for the system the benefits that could come from a centralized platform, without actually having to build one. I propose that we take the focus off how stations and other entities get content into their websites, and put the focus on how to get content out of their websites, i.e. syndication.

I think this is a more fruitful approach because it bypasses the steep hurdles presented by organizational politics, and also because it would be be a necessary process even if we were to create a common platform. The obvious candidate is RSS syndication, since it is already widely understood and adopted. Most of the platforms used for citizen journalism and UGC already have some RSS capability and provide features that can put organizations of very limited technical capability into the game. A wide variety of the content management systems developed or adopted by stations for site management can already use RSS, or could be tweaked to produce RSS for small investments.

Once at the point where all (or at least most) stations can export their content in a common form, exploiting, aggregating and monetizing the result becomes a task divorced from how the content was created. It seems that this is a place where a more centralized approach becomes both practical and desirable.

As a model, I point to the NPR podcast project, which brings in content from a truly wide variety of sources with varying capabilities, and bundles it with national branding, national underwriting, traffic reporting and revenue sharing, and can still accomodate a regional underwriter segment, and doesn’t prevent producers from also distributing the same core content via their own station.org or program.org addresses. With a limited investment in export standards, a similar portal-style approach could be applied to the whole of the system’s output without having to pry station’s longstanding approaches to the web from their cold, dead hands.

Blogger Dave Winer took this picture of Doc Searls. Dave is, in fact, somewhere else in the room right now, ’cause he just took this picture and I’m sitting watching Doc, too. Doc is talking about the metaphors we use to understand the web; they all lead us back to property, to architecture. We have web sites, we find them at addresses, we build home pages. When we go to the web, we think of moving from site to site, from place to place.

But the metaphor is insufficient. The web moves. All of these houses we build on the web have mail now; they can send things back and forth. Dave’s picture there provides a simple example; Dave and I both belong to the same photo-sharing service, Flickr. Because I have Dave listed as a “friend” on the service, his pictures show up in my account, like this one of Doc just did while I was idly poking around.

My point is, Dave didn’t have to tap me on the shoulder and say “Hey, I just took a great picture of Doc; you should put it on your blog.” And I didn’t have to go to his website to find it. The picture just showed up, here for me to use. The things you make — what you write, what you record — don’t just sit, static, in the houses you build. They move, they travel on RSS feeds and show up elsewhere: displayed on other websites, crowding into personal RSS readers, getting sucked into iTunes as a podcast.

For us, in public media, it means that not only do we have to build a website, but we have to know that often our audience reads our prose in ways completely removed from the websites we so carefully build. Your website is not a house; it is a source of information, of audio and video clips, constantly making their way out into the world.

You know, like you’re an Irish family, and podcasts are your children. I don’t know. I gotta go to the PRI reception on the mezzanine and get a drink.

The host is running around the room with a mic in his hand; this is an amazing performance, flexible but choreographed. Producers walk from commenter to commenter; some commenters speak for themselves, some read emails that have been sent to the show’s website. The host talks and gestures; it feels like the flight deck of a carrier.

I sat in this morning on the show’s editorial meeting here in Boston, crowded around a conference phone linked to the BBC office in London and a listener in Nairobi. The meeting’s first question: “What was the most emailed story on the BBC’s web site?” Today it was the jailing of an Egyptian Blogger, but it occurred to me that traffic can be a conversation, every bit as valid as a comment or an email.

When listeners spend time on the BBC web site and email each other stories, they’re actually talking to the BBC, they’re saying “This is important and worth digging into.” Everyone who runs a website and has access to a page hit counter is having a conversation.

What’s challenging about this news? Well, to the public broadcasting old guard, this new entrant into the public media space could be seen as a threat — after all, they’re creating media for public distribution, media of high intellectual quality.

Personally, I find it encouraging to find new teams/groups/companies jumping into the public media game. We need examples of fresh thinking to give us (the old guard) permission to try new things, including (gulp!) new business models.

And, as someone working at a dual-licensee station that’s unsure of where to go on the evolving mediascape, I think it’s high time we re-envision our public service mission. What does it mean to “serve the public” today, anyway? Doug Kaye has one answer, and it works for me (though it’s only one piece of the puzzle for now).

One question Doug… When does the pledge drive start?

We’ll be streaming the sessions that are in the main conference room, including keynotes, lunches, and selected breakout sessions — anything that happens in the main hall. You can check out the schedule at the IMA wiki.

Here’s where to point your media viewers…

Live AUDIO stream (MP3 format)

Live VIDEO stream (Windows Media format)

If you’re a Mac user, you’ll need to download and install an appropriate Windows Media playback package. You can find appropriate players for Mac OS 9 or Mac OS X.

I’ll be working with the fabulous team from StreamGuys to make it all go and ensure we’ve got usable audio. Video? Well, we won’t be able to shoot video straight-on to the presenters — we’ll be off to the side in the presentation hall. Sorry — that’s where the gear had to go for technical reasons.

Enjoy!

Engaging listener communities online looks like a necessary evil. Listeners want to talk online; we are all public service organizations; therefore we owe listeners an online space. Someone from a station just asked me how we handle the volume of comments and emails at Open Source, which made me realized that all of this activity — blogs, wikis, forums — looks like a cost center. Extra work, extra time, extra staff.

But it’s not a cost center. It’s a profit center.

Public radio traditionally has only one point of real contact with the listener: the phone call to offer money. And listeners — enough of them, at least — are happy to call in and pledge. But we’ve found at Open Source that listeners are tremendously excited to be asked for their opinions and stories, too. As Andy Carvin pointed out during our panel this morning, the ten percent of listeners that actually spends time commenting is likely to be the same ten percent that pledges. How much nicer, then, as a potential pledger, to discover that public radio cares not only about your $50 checks, but about what you think about Iraq, as well.

We’ve discovered at Open Source that the more willing we are to open up about what we do — and it takes time and valuable production hours to do this — the more connected our listeners feel to the show.  This isn’t just a warm fuzzy, it’s quantifiable; when we ran into a funding crisis last October, dedicated community members begged us to tell them where they could send money to help us out.

So yes, transparency is work.  Responding to listeners and integrating their comments in your show is work.  But transparency and real community integration can make people really excited to give you money, too.

And if you’re looking for a cup of coffee between 7am and 2pm, try Rachel’s Kitchen, across the street from where I live in Boston’s Bay Village. (Here’s a Google map.) Rachel and Alon make everything in-house, know everyone’s name and once sheltered me for two hours when I put out my trash wearing pajamas and left my keys on the other side of the door. You’ll need some unrecycled air at some point; get it on the way to Bay Village.