The history of Drupal use within the pubic access/community media space is a long story with a lot of colorful characters. One reoccurring theme in this story has been one group driving innovation for a period of time before running out of resources, staff members moving on, and/or the organization just shifting priorities. Eventually other groups pick up where the last group left off. Sometimes the new groups continue the to develop an existing module. More often, they start new modules with a new name that do basically the same thing.
An example of continuity within a module/project that I love is the Creative Commons module. That module was started by Peter Bull while he was working on the Digital Bicycle Project at Lowell. References to Digital Bicycle are still in the code.
An example of constant renaming/refactoring has been airings. When the Open Media Project started, we looked at how PegEvent and airing content type from MNN's Access Center worked and wrote similar functionality into the Open Media Broadcast Synchronization module, then some of that functionality was moved into the Open Media Airing module, and again into the Community Media Airing module.
What I wish we would have done when the Open Media Project started was determine where the functionality of these modules overlapped and define that in a separate module we could all used. Instead, when I committed om_broadcast_sync, it was the third module defining yet another airing content type. While there are differences between all of these modules, the fields that define an "airing" are basically the same. This is in large part because all of these modules were designed to either play video at a specific time or record when it played. Each of these variations on airing stored the start time, end time, channel, and video. I am as much to blame as anyone for not defining that core commonality regardless of the self service/staff driven/30-60 minute grid/themes/voting/whatever other code was written on top of it, but I have been determined to at least try to avoid the same mistake again.
There is absolute no right or wrong answer about when a module should be renamed and hindsight is often 20/20, but in this community there is another issue with module names because some names imply ownership.
What's in a name? If that name is Open Media, a lot. When the Open Media Project started the organization awarded the Knight funds was called Deproduction. It wasn't until the second year of the project that Deproduction changed their name to the Open Media Foundation. Naming the organization after the project created a problem for any other organization that wanted to contribute. When the Knight funding ended, we had a project with a foundation named after it and Tony was making statements like these...
http://groups.drupal.org/node/79709#comment-249109
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...
http://groups.drupal.org/node/93809#comment-301999
the City of Denver allocated about $15,000 for DOM this year from the PEG fund to upgrade a few modules (whether to D7 or just general upgrades and new functionality). That number is doubled for next year, so we definitely plan to keep upgrading. Its still not a lot of money, so obviously it would be great if we could cooperate and different stations tackle different modules.
During that time, other stations continued to contribute, but that stopped in March of 2011 after this post...
Over a dozen stations (and other entities) have implemented aspects of the software, though at least half of them are using the open-source nature of the tools to revise the code to fit their old ways of doing things -- essentially stripping away the aspects of the software that position us to capitalize on the strategic advantages tied to cooperating with other stations, mobilizing the community, and designing your station to be more constituent-led.
The next phase of the Open Media Project will revise the approach, offering a more pre-packaged option for participating stations. Modeling after the example provided by NPR's core publisher effort, the next phase of the Open Media Project will enable stations to benefit from our inherent strategic advantages on a level that hasn't been possible before.
That announcement was made without any input or communication from the original Open Media beta stations. It's true that many of these groups wanted to implement the "old ways of doing things", but often as a first step before moving to a producer driven solution. channelAustin now has a member driven, self service workflow for Memberships, Reservations, Projects and Classes. MNN will launch as a staff driven solution and turn on the producer options as staff have capacity to train the producers.
This has never been a case of using om_ modules if you want a producer driven workflows or cm_ modules if you want a staff driven workflow.
When I created the cm_ modules I asked staff from stations that had been using the D7 version of the om_ modules if they would be interested in co-maintaining a cm_ version module. I pushed for that to happen before the MNN project started to ensure there would be a common core that no single organization controlled. The responsibility of maintaining and documenting that core belongs to the organizations using the code and funding additional development. Today, most of the modules included in the Easy Starter Kit for Community Media are now well documented (thanks Craig Sinclair and everyone else who contributed to that!).
Any organization can customize on top of the cm_ modules, because unlike their om_, peg_, and access center predecessors the cm_ modules were designed with very little defined in the modules themselves. The plan for cm_ has always been that there would be layer of customization on top of the common cm_ layer.
This model allows each station the option of adding and configuring fields in a way that works best for their producers and staff. I've started exporting some of these customizations in the Community Media Examples. This demonstrates some of the how. We still need documentation to explain the why as well as finishing the documentation of modules included in the Moderate and Difficult versions of the Starter Kits.
While the OMF's vision for what Open Media must be and how it will get there makes it difficult for other organizations to play a meaningful role, there is no technical reason the OMF can't contribute to the cm_ core. Just like we developed mnn_show, mnn_project, and mnn_airing for MNN to add the staff driven interfaces they've used for years and workflows that make sense for large stations, om_show, om_project, and om_airing could be developed to extend the cm_ contrib layer for smaller stations looking for an out of the box configuration.