Open Media Federation?

I'm really excited to see continued energy for the project and grateful that Kevin was able to go out to Austin and help make your implementation functional. It's really amazing to see so many contributions in the past month or so, between the Austin updates, Darrick's significant contributions, the recent work done at Amherst and the numerous other contributions that I'm probably not even aware of.

I know we're extremely interested in participating and supporting any structure that has support from the active community. We've hired a new full-time developer to fill the position left by Kevin at OMF, and are currently devoting 40/hrs week of development time on the OMP. Of course, with the end of Knight funding our development time will be focused on the elements of the system that fall highest on the priority list for Denver Open Media, which is currently om_timeslot_scheduler so we can get our producers self scheduling and replace our old auto-scheduler code with the work that Kevin started.

I think this will be the route that most stations take, for instance the recent changes to om_show to accommodate your ContentAgent/EditShare workflow. As developers, I'm sure we will continue to do our best to make the changes in a way that supports all of the active partners, but I do believe that some sort of structure that makes the decision making process more transparent, and gives everyone a chance to express their opinions and 'vote' before changes are made would make our efforts more productive and is critical in the long term. Particularly in the sense of maintaining some shared standards, and deciding which long term goals to continue / new ones to pursue. Without this structure and a shared vision that the active partners support, we would be better off doing custom implementations.

What structural components would this new group involve? At OMF we like having the http://groups.drupal.org/open-media-project group, but it does seem to be missing a lot. Conference calls? Some sort of suggested structure for all contributors(documentation,code,design,etc) to write summaries of planned-work and completed work at the beginning of each month? A system for voting on controversial changes? A 'board' of decision makers / people responsible for specific OMP support tasks?

Brian

This month I will be working on a report and evaluation of the successes and failures of the 2-year beta-test project, and the current state of the partners and other players in the project. That should provide a pretty in-depth look at OMF's perspective and prognosis. We have to assume the BTOP grant is a long-shot. The success of the Open Media Project does not rest on BTOP, but without it, the project will likely evolve the way many decentralized open-source projects do. Its a shift, and probably a good one.

Even without BTOP, we can probably count on OMF investing $25K to $50K annually in the tools. I think its reasonable to assume that BAVC will invest many times that amount. They have a much larger capital budget. Combine that with their low tolerance for the glitches OMF has accepted as part of a nascent open-source effort, and they are likely to be investing heavily in improvements to build the kind of "mature" solution Ken has stated they were expecting.
Of course right now, they aren't very happy with OMF or the OMP, but besides starting from scratch, there just aren't a lot of options that are designed to help automate their station to function with their lopsided funding structure (almost all capitol), and I think they'll come-around and realize that this is just part of the process of creating a new software solution. Austin may be in a similar situation in a few years, and like us, may see that investing capitol dollars into open-source development is a more sustainable choice than buying fancy new equipment.

My point is, like any open-source effort, the "leadership" lies mostly with the people doing the most development work. I anticipate that BAVC, Austin, MNN, and other stations will be investing more into OMP development than OMF in the coming years, and we will all have to take some cues from other successful open-source efforts in keeping the efforts efficient and coordinated as the picture changes.

At Davis Media Access I currently can only support from one quarter to half of my time toward the project. I'm hoping to partner as much as possible with Kevin Reynen in pursuit of funding so we can devote full time to the project. During the beta testing I worked quite a bit with Kevin and feel we are both very passionate about the value of the project and wanting to see it move forward. Davis Media Access supports my work on the project because the goals of the OMP align well with DMA's mission.

My vision for the OMP is first to help create a replacement for Facil. MERCI, om_project and CiviCRM are the main components of this. After that strong integration between the Drupal CMS and the PEG stations playback equipment via om_show and om_broadcast_sync. Integration with CDNs would also be included in this step.

Accomplishing the above two goals will require minimal changes in the workflow of stations and doesn't require anyone to reimagine PEG. It will just make PEG stations more efficient. The above should include up to the minute reporting on resource usage and content creation. I consider this to be basic core infrastructure for any station.

Once the above base in place, the om_timeslot_scheduler module can be used to automate the programming manager position. Either assisting them or doing away with the position entirely. A good option for stations with limited operational funding.

IMHO anything beyond is outside of the scope of the OMP. Drupal already has modules implementing facebook, SMS, twitter and every other buzz word out there when people talk about envisioning Public Access in a Web 2.0 world.

Moving forward I think the largest difficulty is making sure the modules do not get over loaded with implementation specific features. This is a difficult issue as most development is driven by contracts with specific requirements. Kevin and I have discussed this quite a bit lately. As an example the MERCI module was recently split up into multiple modules due to BAVC specific code being committed to the core module breaking the module for DMA. When DOM started the project everything was in one monolithic module dependent on their site. Through their work with the beta testing sites things have come along way toward developing robust modules which can be easily shared by stations.

I'm a bit on the outside, but from what I can gather there's still a big need for documentation, training, and awareness of the project. One approach would be to capture and create training opportunities from the open development of the platform on actual stations. Now that the OMP feature set is more modular with less dependencies, it should be easier to provide useful solutions to smaller stations, community centers, schools, and others in the community who would benefit.

Looking forward to hearing more from Tony and others on lessons learned from the first phase and how we can move ahead.