Responses to the PubForge Open Source Collaboration Survey

Back to Survey Main Page

Respondents:

The survey received 64 individual responses as of September 4, 2008. Respondents were well distributed throughout the United States. 59 were based at US public broadcasting stations and networks, including community radio, NPR affiliates and joint licensees. Three worked at broadcast program entities, and two at public radio distribution entities.

Of 62 respondents, 24 respondents held new media titles, 12 were station managers, seven held IT/engineering titles, six were program directors, four were in operations, four were volunteers positions, two were outside consultants, two were news staff, and one was a program host.

WEBSITE MANAGEMENT

Website hosting:

The largest group of respondents (26) use commercial hosting services, followed closely (23) by self-hosted sites. 14 were hosted by university or other affiliate networks, and 12 by platform hosts such as Public Interactive.

A majority of respondent's sites (33) run on Apache servers, 12 run on Microsoft IIS servers, one runs on Zope (Medusa) and one on lighttpd. 17 respondents did not know what type of server was used.

A plurality of web servers (29) used the Linux operating system, followed by 20 using Windows, four using Mac OS, and one using Unix. 14 did not know what type of OS was used.

Scripting languages:

A substantial majority of respondents (39) use PHP scripting within their sites. 10 use PERL, eight use ASP, four use Python, three use Ruby, two use Cold Fusion, two use Visual Basic, and one each use java and DHTML. Six did not know the answer.

Content Management:

A large majority of respondents (41) use a local content management system for all or part of their web site. 32 manage all or part of their site manually using an html or text editor. 10 use a platform host's CMS, such as Public Interactive. One site manages content through RSS/XML aggregation. Two respondents did not know how content was managed.

A plurality of respondent sites that use a CMS (20), use a common open source application, and three use a custom-built open source CMS. 16 use a custom-built proprietary CMS, and two use a common proprietary CMS. 9 use a mix of CMS solutions for different needs. 14 use the Public Interactive platform. Two did not know, or are in development.

Of those using common proprietary or open source CMSs, eight use WordPress, eight use Drupal, three use Joomla, and one each uses Simple Machines, MT, iTools, Zope, Expression Engine, Public Media Manager, Ellington, Ning, and dokuwiki.

New media staffing:

A majority of respondents (32) had no full-time employees dedicated to website creation and management. 15 had one full-time employee, eight had two full-timers, and four respondents had three to five full-time employees in new media. 18 had one part-time position, 10 had two part-timers, and seven had three to five part-time employees.

Half of respondents (29) had two to five staff contributing content to the site in some way. 15 had six to 20 contributors, and six had more than twenty. For eight respondents, only one person contributed content to the site.

Staff skills:

Most respondents (37) had staff skilled in web design and (29) in web standards/CSS. 26 had staff expertise in programming/scripting, and 25 had staff with database administration skills. 16 had expertise in Javascript/AJAX.

WEBSITE CONTENT

Content types:

55 respondents listed the following as varieties of content they manage on their sites:

Program guide 49

Broadcast stream 47

News/feature audio 45

Event information 43

Complete program audio 38

Pledge drive content 38

Playlists 34

Pledge/membership management 29

Music audio 27

Blogs 27

Text/transcripts 25

Web underwriting 24

Election resources 24

Surveys/polls 23

News aggregation 21

Comment 20

Web buildouts 20

Additional content streams 16

Social networking/citizen journalism 13

Assorted video 14

Online store 14

Interactive games/widgets 9

Other 6

Content syndication:

Of 51 respondents, a majority (30) use outside content syndicated via javascript modules and widgets into their site. 29 use content syndicated via RSS feed and 24 via podcast or other XML feed. One site imports playlists, and one uses AP syndicated news. Eight sites use no content syndicated from outside.

Of 46 respondents, 35 export some of their content via podcast and other XML feeds, and 34 syndicate using RSS feeds. Four produce javascript modules and widgets to syndicate content. Six respondents do not syndicate any of their content to other sites.

Audio asset management:

Of 50 respondents, a plurality (17) manage audio for broadcast using Enco DAD. Next most common was AudioVault (9). Homegrown open source solutions were used by two respondents. Dalet, DA/VID, Simian, DirEltore, Campcaster and and MegaSeg were each used by one respondent. 16 either did not know how assets were managed, or used nothing to automate the audio asset management process.

Streaming Audio:

Of 54 respondents, 33 use a dedicated box to stream their broadcast audio. 32 use a Shoutcast/Icecast server, and one each use Flash Media Server and SimpleCast Encoder. Some stream using third party services such as Public Interactive, Streamguys and backbone.com and one uses multiple encoders for different formats. Three respondents do not stream, or don't know how it is done.

A large majority (41) produce an mp3 stream, followed by half (27) who stream in Windows Media format, and 14 who produce Real Media format streams. Seven stream in Flash format, five stream in QuickTime format, four stream in Ogg Vorbis format, three in AACPlus, and one in MPEG4. Three did not know the answer, or do not stream.

Web analytics:

Of 52 respondents, half (26) use Google Analytics to record Web metrics. Of those 12 participate in the Public Media Metrics project to share data. Five respondents use other page-tag based analysis packages. 18 use assorted log file analyzers, and nine use Feedburner to record RSS/Podcast traffic. 15 listed Other as their response, including five who used Public Interactive stats, and various users of NetTracker, SuperStats, Streamguys reports, NPR podcast reports, Sawmill, Webalizer, Real server logs, Ando Media, Abacast, and homegrown analysis solutions.

When asked about metrics specifically for audio archives and podcasts the same wide variety of services was listed, excluding Google Analytics and other page-tag based systems. Only one respondent used link-tagging to capture audio traffic via Google Analytics.

Playlist reporting:

33 respondents described the methods they use to capture playlist information for Sound Exchange/RIAA reporting. 12 did not report playlist information, seven created palylists manually, four used Public Interactive's Composer, five used homegrown databases or CMS solutions, and two used radioactivity.com.

Video assets:

Of 55 respondents, nearly two-thirds (36) use no video on their sites. Of the 19 that do use some video, 14 use YouTube to serve video, seven hosted some video locally, most using a Flash player, two respondents used blip.tv, and one created video slideshows using SoundSlides.

Content for handheld devices:

Of 55 respondents, a large majority (46) do not now format any content specifically for handheld devices, but 13 plan to do so in the near future. Only nine respondents are currently creating such content.

OPEN SOURCE COLLABORATION

Using open source software:

Of 49 respondents, 18 do not use any open source software. Of those, all respondents except two said they would consider using" well-documented open source software." . A majority (31) do currently use open source software for some aspect of their online service. These users list the following open source assets:

1. phpBB

2. Drupal for Content Managment System.
3. WordPress, SMF formum
4. linux, apache, mysql, drupal, php, perl, firefox, thunderbird open office available, but no push to wean users off MS. (yet)
5. for audio editing, audacity
6. We use SQLite to store a simple music schedule that is used for our automation system. We also make use of cron to run Applescripts to automatically create iTunes Playlists. We would like to port this over to be a Linux based solution, with the emphasis on simple setup and use it for starter radio stations that are intersted in automation, but don't want to spend a lot of time setting anything up.
7. See earlier.
8. php and a javascript HTML content editor
9. Icecast for streaming
10. ListGarden RSS generator, Shoutcast, etc.
11. We use Python, Zope and MySQL. Various Zope Products, and python libraries and scripts.
12. We use OpenAds for banner ads.
13. Wordpress
14. Expression Engine, FFMPEG, many others. Our site works off a lot of open source options.
15. WordPress
16. Public Media Manager, PHP/MySQL, MagPieRSS
17. wordpress, drupal
18. Our second service, Vocalo.org is built using Drupal. Frustrating experience so far.
19. Audacity is the open-source program we use the most.
20. typo3
21. Whenever we can -- From Linux to studio scheduler to e-news to BBS, etc.
22. joomla
23. PHP Joomla
24. apache, php, linux, postfix, mysql...
25. Gentoo and Ubuntu Linux pulseaudio network audio server (studio) XMMS player (main studio player) amarok playlist editor Icecast stream server darkice stream encoder
26. you name it.
27. Audacity
28. entire system is open source
29. Drupal CMS is the bulk of our site.
30. WordPress and a bunch of plugins that are also open-sourced, Apache, PHP, Atlassian's Confluence and JIRA (limited testing at the moment); have used some Plone in the past; have tried SugarCRM
31. WordPress for hosting the site, plus numerous WP plugins

Concerns about using open source:

Of 41 respondents, nearly half (20) said they had "No concerns that need to be addressed about implementing open source solutions." 21 did express concerns, including these:

1. Need for a backup person that knows the software.

2. staff and training
3. support concerns
4. I would like there to be more collaboration amongst radio stations in regards to open sourcce software. It would also be nice to link with Linux User Groups, and community minded software developers to produce software for community radio.
5. Because we do not have a programmer on site, we would need dedicated support available if we were to use an open source solution.
6. We need a way to pay for the tech support - intallation AND maintainance. Installing software we can't support (no PHP techie on hand) is a SERIOUS issue that needs to be address. Even if we can get it into our budget, who will be able to offer support? CPB should help with open source development because individual station cannot keep up with technology to be current in the online space.
7. That they be properly documented and relatively well adopted, secure and easily implemented.
8. The concern is always support. . . will the app stay around or will it be lost to the sands of time.
9. We have concerns about implementing any solution, as it takes time and expertise that is in low supply with us.
10. I think we need to define a few standard server configurations: Microsoft/IIS, LAMP, (other?) and implement an industry-wide training initiative around these approaches. I think we need to make it easy to share code, and to do so with the appropriate licenses (GPL/BSD/etc.)
11. security, documentation and support
12. In terms of the CMS, I would be concerned that, because the target community is so small, development, especially of add-ons would be terribly slow and generally poorly supported.
13. Windows compatibility
14. support
15. Security and customer service
16. security and development
17. Time management for staff working on website. Being able to customize open source modules.
18. Just the learning curve. As I think about it, you know, "open source" typically suggests documentation that amounts to scouring the Web for readme files. - Fine for tech geeks, but a real impediment to learning software for those in a station who might typically be posting content to the site.
19. Programming and instruction assumption of industry literacy
20. Proprietary lock in. Radio stations seem to accept expensive proprietary applications even when adequate open source applications are available.
21. Only that the packages selected are widely used and are under active development by the largest user base possible. That's how I selected WordPress over other options -- it seemed to have a bigger community with more overall activity going on.

Open source development priorities:

When given the chance to express interest in a preselected list of potential open source projects, 44 respondents ranked them as follows:

1. Freestanding player for streams, archives and user created playlists 32

2. Tools to integrate existing social media networks into public media sites 32
3. Complete CMS website solution, including audio file management 30
4. Software to enable more community participation for public media 29
5. Application for supporting micro payments (granular giving) to enable giving around specific content 27
6. Open source tools to gather playlist info for reporting to Sound Exchange 21
7. Player/browser specific to the whole of public media network 15
8. Create a non-commercialized social media network, akin to
   an open source twitter client 12

Of 31 respondents who listed projects of their own choosing, the following projects were listed as the top open source development priority:

1. Drupal Modules that support our needs. Especially those that are good for joint licensees.

2. Playlists Let me know, and I wll do this!
3. Online Auction System
4. radio automation system
5. archive database with metadata and podcasting
6. audio streaming
7. CD library database
8. Audio archiving, with members-only option
9. a player with playlist functionality
10. easily embeddable blog with moderation and comments
11. CMS
12. CMS for audio archive
13. Customizable Flash Audio Player (I know flash isn't open source)
14. CMS for Windows/IIS/PHP(or .Net)/MSSQL
15. Public Radio-specific CMS
16. parser for nprml
17. customizable public media flash player
18. public radio content- widget for embed
19. Media Player for audio and video
20. A radio automation system, a la TuneTracker.
21. Archiving software for windows
22. program logs
23. Playlist data from AudioVault -> XML -> Database -> SX Reports
24. Online audio asset management
25. a really good linux based automation system
26. Integrated playlist management and playout
27. mp2 encoder
28. Manage all audio content from one place
29. EAS
30. Easy to use standalone audio player (like NPR.org uses)
31. Flash audio player, akin to the new NPR player (may not be possible)

22 respondents listed these projects as their second highest priority:

1. Audio Stream archive system

2. online gving
3. content management system
4. Program guide/now playing module
5. social engagement tools
6. easily embeddable banner ad impression tool
7. Software to enable public participation/input
8. Collaboration software, although I just started using Google Docs.
9. Shareable, Customizable Widgets for All Social Networking Platforms
10. geotagging tools for open source CMS
11. public radio series episodes- widget for embed on station sites
12. Powerful Ad serving tool/platform
13. A playlist logging system capable of generating reports would be top notch
14. on air scheduler that can autorecord for web archives
15. Audio CMS
16. CMS usage for main page
17. network audio router
18. flash media player
19. Archive all air product 24/7 in broadcast quality format
20. transmitter control
21. Easier photo/image management
22. PBCore-based CMS focused on digital asset storage and federation -- without visual features

13 respondents listed these projects as their number three priority:

1. coverage map generator from FCC data

2. HD Song tagging that can read another database/ doesn't rely on automation system (we actually still play CDs)
3. micro payments
4. Pub media "branded" media player
5. Standard Templates / Integration with Payment Gateways for Pledging
6. creative commons and public domain content repository
7. Software to manage the archiving/web publishing of audio
8. make our site interactive yet can easily take off unwanted content
9. Web content CMS
10. membership management
11. Timed Archive retrieval
12. Easy to implement weather interface
13. Automated transcription system designed to create basic transcriptions that can be handed off to a transcription service for cleanup

These nine projects were listed as lower priorities by respondents:

1. generate a png of program schedule from data table

2. Local / National news aggregation system
3. help in reporting requirements
4. granular giving tools arounds pubmedia content
5. Easy programmer editing of archived content
6. VRM-like system (see Doc Searls) to allow audience to self-manage relationship with us in public media
7. user generated content
8. video podcast tools
9. VRM-backed micropayments / subscription system

What are the most important thing(s) missing from public broadcasting websites in 2008:

22 respondents replied to this open-ended question as follows. They have been organized in groupings for Technology, Content Area and Community Needs:

Technology

• user customizable homepages, like igoogle. system wide search (of all pub stations)

• Site registration that is tied to membership databases. We need to be capturing more information about our online users and convert them to members. Otherwise, our web efforts will remain a money drain on our organizations.
• Audio playback on demand, more user friendly navigation, ability to stream high-quality audio, ability to accurately track number of listeners, allow listeners to customize their public radio website experience to their needs
• Universal search.
• compatibility with open source browsers.
• Fully transcribed media, for searchability. Simplified multi-site content search / aggregation. Ability to sell some digital assets or packages.

Content Areas

• Style. Sense of ownership/caring about the site, instead of taking the proud Luddite stance.

• Consistency.
• Feeds of national content that gives the local site specific description of what's on the national shows. -Embeddable, universal (open source) players and audio format.
• The public media networks lack a geographical dimension to their content offerings. Station.org sites are woefully behind in exposing all their local content in useable/findable/distributable ways. Stations, networks and listeners together comprise a potentially powerful social network that is underutilized. Online rights management is an unnavigable disaster.
• Adequate local news content beyond features, i.e. it would be nice to have ever local newscast available much like NPR's hourly cast Easy access to content.
• Efficient flow of data (music sites); Way to search/index/find audio content (music and talk)
• content
• well formatted, accessible, community produced syndicated content. http://www.builtstlouis.net/ http://www.eco-absence.org/ http://lofistl.com/ http://blog.makezine.com/podcast/ http://shralp.com/ and so on. (customize for your market area) Public media for the web by the web.
• For me, it's a complete lack of access and support that results in virtually no content on our website from the W*** Newsroom.

Community

• Software to enable more community input around events/issues, though staffing to moderate such input is a must.

• Social engagment tools better player options - with playlists drawing from archives aggregator for news and music micro payments user generated content more mash-up ideas
• Visitors.
• A sense of community.
• social networking
• The voices of the people behind the shows or stations. It's amazing how much of the content is delivered as if from on-high with no personal voice.

Interest in open source collaboration activities:

Of 48 respondents, the vast majority (43) were interested in participating in a webinar or group discussion organized around open source collaboration. Fully three-quarters (36) responded positively to the question: "Would you be interested in traveling to an initial/periodic training sessions on developing/maintaining an open source collaboration for public broadcasters?"