Active development?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
popmechanic's picture

Has development of the Open Media Project stalled in the new year? I notice that of all the modules, only the Timeslot Scheduler and MERCI have seen code commits in 2010:

Open Media Project
Last commit: 2009-Dec-05

Open Media Show
2009-Nov-24

Open Media Broadcast Synchronization
2009-Aug-18

Open Media Timeslot Scheduler
2010-Feb-03

Open Media Support
2009-Oct-15

MERCI
2010-Jan-14

Install Profile:
2009-Nov-13

Can someone provide the community with a status update on the project's timeline? And if there are any issues that could use some assistance from the developer community, let us know.

Comments

Thanks for pushing me. I've

kreynen's picture

Thanks for pushing me. I've been meaning to post something like this for awhile.

The Knight NewsChallenge funded "beta" phase of the project has basically ended. We are now working with the Bay Area Video Coalition to implement the modules we've written there and revise our approach based on what we learned from working with the 6 beta stations.

One thing we've learned is that the technical skill level required for the system administration was too high for most stations. We've revised our documentation to reflect that...

http://www.openmediaproject.org/handbooks

Each feature set now includes the skills you should have. While om_project and MERCI can be configured with basic Drupal knowledge, just adding CiviCRM to that is a lot for one person to manage. om_show with it's dependency on Media Mover, FFMPEG, symbolic links, mounted SMB shares, etc is just too much... and largely unnecessary for stations with external encoders like Austin or Portland.

In 20/20 hindsight, we designed something that would do it all for the stations that didn't have expensive, external encoders, but found that most of those stations lacked the system administration skills to configure and maintain a completely open source solution. The stations with the staff, didn't need or want an external FFMPEG encoder.

The other thing we've learned is we can't build so many dependencies on TVframe. With the exception of MERCI which was designed to be stand alone, every other module got so tied to TVframe it wouldn't really work without it.

I'm still actively working on om_timeslot_scheduler and om_timeslot_princeton. I think the latest releases are very close to providing a stable structure for an om_timeslot_cablecast or om_timeslot_synergy. What I'm working on right now is adding a om_ext_resource content type to deal with overlays, switch events, and even video. om_ext_resource can be added as a leader or trailer to a Timeslot Theme, Timeslot Event, or even at the Show level. When working with external resources, it occurred to me that om_show could be modified to see its MPEG as external resources as well. For Princeton users with only one server, this would allow them to mount the Princeton's vol1 on their webserver and eliminate the need for FFMPEG beyond creating the web preview and thumbnail. This would also make om_show work better in Synergy or Cablecast environment where shows don't need to be pushed to specific servers. In Denver we have 3 Princeton's that each control a different channel.

Of course there is little reason to standardize on a content type like om_show if stations can't agree on the metadata that makes a show valuable. This is the main reason om_show hasn't been updated. I've made several changes to the version Denver's using, but was waiting to commit those until we finish the process of standardizing on how metadata will be defined between DOM and BAVC. Once that process is complete, om_show will be updated without a dependency on TVframe and only using Media Mover as an option, not a requirement.

The other module that's being largely rewritten is om_project. It will still leverage og, but will focus on improving the UI of adding content_types to a project and give more control over permissions to the project's manager. This update will also eliminate the dependency on TVframe as well a the pseudo region approach we used in node-om_project.tpl.php. The new module will allow users to add blocks to their project page using the standard Drupal approach. As part of this change, we are also eliminating the content types like Project Event, Blog, and Wiki from the default configuration. While everyone involved in the initial design of project thought producers would use those to organize their projects, that hasn't happened. Individual stations can easily add those content type back and the update won't delete the content type from stations that have started using them, but they will not be included in the Views created by the module or the new .tpl files.

As far as getting involved most of the modules are getting major rewrites based on conversations happening here so I'd steer clear of those. There are no plans to rewrite MERCI. It is stable and is really the first Open Media related module stations should be using anyway. While stable it still has issues and half implemented features that could use some developer time. Specifically...

Another module that isn't indirectly tied to the Open Media Project is the new Creative Commons module. We're still using cc_lite on Denver Open Media. I'd love to see a migration option if you install creativecommons on a site running creativecommons_lite.

Anyone looking for a hardcore challenge could look at adding Archive.org S3 support to Media Mover.

Lastly, we can always use help with documentation. We completely reworked the structure of our documentation after the beta implementations. Despite many offers to help with that, it never gets the attention it needs to make it really useful. I've written a large part of that and know I'm too close to the code to write documentation that help may people. If someone with even minimal developer skills can work through what we've already written to clarify areas that don't make sense and fill in missing, it would be very helpful and APPRECIATED. Shoot me an email or use my D.O. contact to get premission to edit the handbooks on http://www.openmediaproject.org/handbooks

Anyone interested in getting involved should also log into #drupal-openmedia on IRC.

In 20/20 hindsight, we

forestmars's picture

In 20/20 hindsight, we designed something that would do it all for the stations that didn't have expensive, external encoders, but found that most of those stations lacked the system administration skills to configure and maintain a completely open source solution.

This is reminiscent of the lessons learned from the "digital bicycle" project where it was discovered that many such stations lacked even the wherewithal / technology resources to do simple things like reconfigure their networks for basic* file sharing. (for some definition of basic that includes torrenting.) In some cases you're talking about just needing someone to go into a Linksys router and open some ports.

Also, I am very interested in the idea that of the stations participating or interested, there is some great hurdle to each one having at minimum one "go to" technical person to handle such system administration tasks.

This speaks to my larger surprise that each station would not have just one developer capable to contributing to the code base. I am thinking specifically about OMF's 'Bounty' system, which seems to me a great idea in theory-- so why is it that only a couple people made significant code contributions when there was an established financial incentive on top of everything else?

This speaks to my larger

aaron's picture

This speaks to my larger surprise that each station would not have just one developer capable to contributing to the code base. I am thinking specifically about OMF's 'Bounty' system, which seems to me a great idea in theory-- so why is it that only a couple people made significant code contributions when there was an established financial incentive on top of everything else?

I can't speak for the stations, but I am aware (as are many, I'm sure) of a shortage of available and proficient Drupal developers in general. That's got to be a factor.

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

The option to do commercial

kreynen's picture

The option to do commercial work that pays much better is an issue, but the need to either make things easy enough for non-developers or steer them away from that part of the project is also important. Maybe we need a 'you might be red neck' for the Open Media System...

  • If no one at your station knows how to mount a smb share on your webserver... the Open Media System might not be for you.
  • If no one at your station knows if the web and playback servers are in the same subnet... the Open Media System might not be for you.
  • If no one at your station knows the Event module is dead... the Open Media System might not be for you.
  • If no one at your station knows the difference between MPEG2 and H.264... the Open Media System might not be for you.
  • If no one at your station wants to start scheduling shows that aren't 30 or 60 minutes... the Open Media System might not be for you.

Even if we configure this for a station once, lacking the skillsets to troubleshoot any problems with the system really makes the station dependent on us. We can't write all the documentation to explain the system administration and network configuration required in any environment.

All of that said, it takes more than developers to make this work. If Brian or I had to work with producers to explain how to add shows and make reservations, we'd have failed long ago. We don't have the patience for that. I'm quick to admit that I'm not great at end user documentation. It takes different people with different skillsets to make this work. Just having someone technical or someone who's good with people isn't enough. You need both of those AND a community of producers submitting content that someone wants to watch. If you have all three of those, the Open Media approach to running a station could work for you.

om_timeslot_cablecast

raytiley's picture

Hello Everyone.

This topic is very timely for me as I've been trying to browse through what I could find of Open Media Project source to figure out how I could help. I recently wrote an extension to Tightrope's Cablecast that allows the creation of shows / schedule events / producers / projects through the Cablecast Web Service.

I'm traveling to Amherst Mass a Week from Today (Friday the 12th) to work with Craig Sinclair and install the new version of Cablecast and spend the day doing whatever I can to integrate there cablecast install with Open Media. I currently live in Portland, ME and I would be more than willing to travel into Boston also where I understand there is another Open Media install?

I've sent some emails asking for direction.. but maybe I didn't reach out to the right people. What module in particular should I be adding to to integrate Open Media and Cablecast... and where can i find the most up to date source.

Thanks!

-ray

Nerd at work

Everything I'm working on is

kreynen's picture

Everything I'm working on is committed to...

http://drupal.org/project/om_timeslot_scheduler

The documentation that exists is at..

http://www.openmediaproject.org/handbooks

Specifically...

http://www.openmediaproject.org/handbooks/scheduling/configuring-playbac...

The idea has been that using the general Timeslot Scheduler to figure when a show could be scheduled as well as the permissions for who can scheduled it and then call the specific submodule to handle the playback server specific functionality for adding videos and scheduling information.

The type of playback server is already being defined on the om_timeslot_server, but I'll need to do another update to make sure om_timeslot_scheduler can call something other than om_timeslot_princeton

The best place to bang out the details is over IRC in the #drupal-openmedia channel. Darrick spends a fair amount of time in the channel and has written started a cablecast module. His approach is a little different because I'm trying to keep this playback server agnostic even to the point we can register multiple server to the same channel.

OMF's Status/Update

deproduction's picture

This recent blog post I wrote for the PBS IdeaLab is a pretty thorough update on our activity with the Open Media Project.

As Kevin mentioned, our remaining Knight Funding (which ends entirely in June of this year) is focused on content-sharing solutions. We had a great visit with Archive.org last month and we are moving forward on that front. Our whole team will be able to visit with Archive when we're out in SF to work with BAVC and attend DrupalCon in April.

The 6 beta-test implementations (7 including Denver) are complete, and further implementations will likely be on a fee-for-service basis. Not only OMF, but also Gus Austin (Drupal Kata) and CivicActions are currently exploring OMP implementations for various clients. We will continue to work on cost-savings analysis of the system as it improves, as we hope to show that in the end, the OMP will pay for itself for organizations willing to shift their staffing structure and workflow to focus on a more participatory, community-driven, self-service, web-based process. For very small stations, such as those with only one staff member, the best hope is for us to develop a more self-contained and supported solution, which we are working on. This is not likely to happen any time soon, unless we receive another significant grant to support it. We're in the final stages of applying for one such grant, also detailed in the blog entry below.

http://www.pbs.org/idealab/2010/02/moving-on-after-the-knight-news-chall...

Whatever your first issue of concern, media had better be your second, because without change in the media, the chances of progress in your primary area are far less likely. http://denveropenmedia.org

Open Media Project

Group categories

Audience

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: