I had eight people waiting to be admitted to the SharePoint Syndication GDN Workspace. Sorry for the delay folks – my workspace was maxed out on users and I had to get upgraded by GDN. Anyway, I’ve been given more membership slots, so the people who’ve been waiting – some since January – are now in.

There has been a lot of interest in this project and others like it. Jonathan Malek has his SpsRssGen project. Sig Weber has an RSS Generator for SPS. All in all, there is quite a bit of interest in this developing for SharePoint in general and creating syndication feeds in particular. Too bad I can’t get more involved. With my new job, I just don’t have the time to work on this project anymore. 😦

Since I can’t keep the project up, I’m wondering if someone else would like to take up the reins. I posted all the code to the workspace, but so far there’s been little traffic other than people wanting to join. I was hoping for more participation, but then I haven’t done anything to foster that so I really can’t complain. So let me ask explicitly: If you’re interested in being an admin on this project, please send me email. Once I get an admin (or two) and a core group of interested developers, I’ll start hosting chats / email lists / live meetings / conference calls / smoke signals / whatever to discuss the project direction. Personally, my #1 feature is an admin interface for creating the syndication feeds integrated directly into the existing SharePoint admin interface. Not sure how doable that is, but let’s find out. After that, I’m open to suggestions as to project direction.

I spent yesterday in content repurposing hell. As part of my community role, I’m pushing for making as much content available in as many different channels as possible. However, right now, repurposing content for the different channels is handled with an expensive and time consuming manual process. Want a new publishing channel, we need a new manual processes to repurpose the content for it.

Of course, one of the reasons for this is that the data formats used by these programs are proprietary. Even in places where there is a standard, the files don’t all follow it exactly. For example, I’m having issues converting a bunch of EPS files to JPG. According to Ghostscript, the files have several structuring errors which is making it difficult to open in other programs. Plus, much of this content was authored on a Mac, so trying to bring things like fonts over to PC is a major pain. It doesn’t look like any of the XML or web services standardization work has crossed over into content production or graphic design.

However, there is a more fundamental reason that all these processes are manual – they weren’t designed any other way! Automatic process doesn’t happen by accident, it needs to be explicitly designed. So while having open data formats would make it easier to go in after the fact, it’s no substitute for designing the process from the start.

Going forward, I’m going to explicitly design a multi-channel publishing process for my different content types. The analogy to enterprise software is obvious – explicitly design your process for automation and extensibility. It won’t happen any other way.