Ordinarily I don't talk much about webdev, as I simply see much of the so-called web2.0 stuff as mere tools to get jobs done. Additionally, much of the so-called web2.0 stuff tends to deal with nasty vendor lock-in, albeit disguised as ease of use or data brokering. As much as GOOG and flickr and the vast majority of social networking tools espouse to bring people together, I have found that they work very hard to profit off your data and make it very difficult to control your bits.
Case in point, I have become a class rep for my beloved BTHS. We have a reunion coming up fairly soon. As a result we have to communicate all of the events and raise money to support activities for our classmates. The challenge is that we have a very disjointed group of alumni. People on other continents and various regions in the US. Interestingly a fair amount of our high school classmates have found their way to FBOOK, but we also have a group albeit quite small using Y! Groups.
So, my initial task was to help fellow class reps collaborate more effectively and suppress all the annoying email that generates from tasks and scheduling. Email is perhaps the worse means to communicate with a large group. I don't care about email lists and email clients which can generate threaded discussions. When you are dealing with time-sensitive data, email is a very poor communication tool. You can't even archive and share group email easily without setting up some sort of mailing list. IMHO, it would have been overkill to setup a mailing list for a 4-5 month project time horizon. What to do?
Enter the wiki, more specifically tikiwiki. It was fairly trivial to install on my server. Nothing more than PHP and mysql, simple building blocks. I didn't even need to setup accounts or create special directories for data archiving, as tikiwiki provides a means to use the database as a virtual file repository. Once I provided the team with a brief overview of wiki use and its origins, they quickly understood the value proposition. Whenever you have disparate groups that must collaborate to solve problems wikis can be great tools. Since we're not slinging code, versioning is not so much of an issue. To be clear, the wiki does handle file locking and timestamping quite well. So versioning is not so much of a problem. GIT or subversion not required ;-)
Now that I've digressed from the topic, allow to get to point. As stated previously, we have a large number of classmates using FBOOK. Our class reps will be spending a significant amount of time using the wiki to communicate, and if any of them are lazy like me.. Well they will probably get tired of visiting both the wiki and FBOOK on a regular basis to check for new content. The obvious solution is RSS, but here is where the lock-in or walled garden bites you in the ass. To my knowledge, FBOOK does not generate RSS feeds for any of its content. In fact, GOOG bots or other agents scarcely crawl the content that lies therein.
So they've got your data and you can't get it and syndicate it for your use. Enter Y! pipes..
I know the web2.0 shills discovered it long ago. I suppose I first learned of it about 3yrs ago, but I never saw the value. It didn't scratch an itch of any sort. I don't use technology for technology sake, I'm all about application. Y! Pipes allows you to splice disjointed data patterns for repurposing. I suppose a loose analogy would be the venerable and uber useful Unix pipe.
The resulting pipe can be shared as a RSS feed, but the pipes engine is 100% owned by Y! Make sure you read and understand the TOS.
Now, I have feeds for the FBOOK groups, which can then be imported into our wiki for general consumption.