The first presenter, Jeremy Roberts (who worked on the PBS Flickr Factory) presents a detailed description of Zope 3. He points out that Zope 3 is a complete rewrite of Zope 2 (if you mention Zope 2 Jeremy will literally wince. Zope 3 is that significant of a departure). He points out that many lessons were learned in creating and building zope, and that after four years of testing Zope 3 has been released with dramatic and fundamental improvements. I don’t need to be sold on this. Our site has run on Zope 2 since 2002 and is still in production today. For all it’s acronymy detail, I loved everything the presenter had to say. Especially the last slide outlining “When Zope 3 is for You.” Although, I wonder if all this expertise was lost on this audience – that to properly present Zope to this audience would require a different take. I would have loved to see a glimpse into the ZMI (the zope management interface) for instance.
The next presenter, Bill Overall, has a great sense of humor. I’d like to get a link to his listing of local services. He recommends using mediawiki for an intranet – end of discussion. He also recommends assembla for version control which gives you a hosted solution for using trac/subversion. He said that “Even in Georgia they understand PHP” however, finding good drupal developers was somewhat of a challenge.
His slide of Drupal Challenges is a great reality check. His slide of Drupal Lessons contains some great information as well.
Matt McDonald was given $10,000 and 2 months to make a user generated site… And then not slow down the PRX, their main bread and butter.
They looked around at a lot of possible soutions (recommends looking at free services like Ning.com and Kickapps.com).
His slide on What We Looked For was very carefully considered. Listening to Matt, it’s clear how accurate he is in his thinking. And how protective he is of his developer’s time.
They learned a lot of things on the fly. One thing he did not like about Drupal is that there is not a clear way to move from an integration to ta production environment… This resulted in their doing some things on the live site that they were not comfortable with.
Big news on the future of the Public Radio Talent Quest social networking site… It’s going away!
Tim O’Shea, the presenter from Public Interactive, offers some intersting paradigms to consider. He presents a handful of specific profiles of the people who are building station web sites. These scenarios are presented as a bit of a cautionary tale. As an employee of PI, he presents Public Interactive in a positive light but he also acknowledges some limitations of the service.
Tim’s slides on Key Considerations is certainly good to consider. Although, in a discussion about open source, but they bring up some valid points and theirs is a voice that should be heard equally as well.
At this point in the presentation, I am a bit disappointed that open source was presented as something of a boogeyman. I agree that a station should take a sober view of the resources and skills that they have available – along with their particular circumstances to evaluate if an open source solution would help them to accomplish their specific goals. While I think the slides that Public Interactive present are valid points I don’t think they sum up completely the discussion of open source. I think there are some potentials that implementing open source programming at a station would present, which was not framed by their discussion, and which I hope to express at the end of this post.
The next presenter discussed Sitecore, a SAS CMS Provider using ASP.net. This service appears to offer a middle ground between a one-size fits all solution like PI and an unsupported open source CMS solution (although there are CMS solutions that are based on open source technologies which can also be subscribed to – Ellington and Brightcove come immediately to mind – and which offer a degree of support ).
Sitecove appears to be a solution where you have a higher degree of flexibility in designing your web solution, yet you benefit from having their developers working on the core software, and how you implement it is up to you. The presenter describes how the “backend housekeeping” is all done for you.
He points out that Sitecore embraces a long list of standards, XML, XSL, etc. He presents this service as very granular, modular, flexible, standards based, and accessible compliant.
He points out a welcoming offer if a station would want to get started using the service. He mentions that they are likely to have sitecore service providers in your area.
He fact that he talks about how this service allows you to integrate the site into your existing membership database is quite intriguing.
These guys are providers to Hertz rent-a-car and other corporations who have no time for failure.
The session is then opened up for questions.
Darleen Wilson from WGBH asks Matt McDonald “would you do it again?” and Matt responds to the question with a backhanded compliment. That, “as much as he hates Drupal, he would do it again.” Because he knew that the site would go away in a year he would do it again using Drupal. What are his reservations? He says that Drupal is “unmaintainable.”
There is a question about Plone and how it fits into all this. Jeremy responds that Zope 3 is a development framework. Plone is designed to work on top of Zope. But Plone is kind of like Drupal in that it’s built to accomplish a specific task. The Zope framework is intended to give you the flexibility to accomplish the specific tasks that you define – and one of those tasks could be to function as a CMS for a station web site, although there are a myriad variety of tasks that Zope could be put into service, a station web site being only one. It is then noted that PHP programmers are more easy to find than Python. Zope 3 programmers are an even smaller minority still.
I asked about the potential of open source to offer an economy of scale if we were, as a network of public broadcasting professionals (in conjunction with the larger developer community at larger) were to decide to collaborate on similar solutions.
Session moderator Nowell Strite, who uses Django in his work at PBS Interactive, answered that his personal opinion was that collaboration really would not occur at the cms level but at the widget level, at the web 2.0 level.
Jeremy Roberts chimed in about the need for us to define our requirements – then see if someone has already made the application that you are looking to create. He says that this is the point at which we would gain economy of scale.
I talked briefly with Nowell Strite after the session. I impressed upon him, if there was a station who was in the position to make a change in the software they were using, if they wanted to pair, for instance, with a national organization such as PBS and use Django (or some other common platform) to implement a standard set of solutions to common problems that public broadcasters face in creating their station sites, this could open up many opportunities of an economy of scale – it could offer opportunities for ensuring best practices in server administration for support and communication among stations and in professional growth. Nowell responded that he would love to have that discussion.
Somehow the conversation turned briefly to the idea of a system wide survey of what backend solutions people are using – the idea that if the CPB might sanction such a survey – and if cost and time savings were to be identified, and if it were to be found that there would be a benefit for finding common solutions – be they offered as a subscription service – or be they open source.
We shake hands and we go on to the rest of the conference. It’s great to see these people in the hall and it’s good to know that there are such thoughtful and competent people finding solutions for public broadcasting on the web from all camps.
There will be a Thursday night dinner hosted by Jake Shapiro from the PRX discussing these very topics. I personally am looking forward to the discussion that tomorrow night – as well as for the future – holds.