The Digital Media Project

 

Source

Philip Merrill

Title

ODF template to analyse Digital Media Business Models (DMBM)

No.

040408merrill01

 

Name: Philip Merrill
Affiliation/additional information: Active contributor, Pasadena, California, US
Date submitted: 2004/04/08

 

# Criteria Description
1. Name of DMBM Open Delivery Framework
2. Summary description of DMBM The Open Delivery Framework addresses each of the interfaces between content originator and the terminal experience so that open source developers (e.g., Helix [1]) can, if they choose, produce software or even hardware that works well both fully and narrowly to be useful and provide good features.
3. Use records of DMBM The Digital Media Open Delivery Framework (DM ODF, or ODF) is based somewhat on Martin's convergence paper [2] and somewhat obviously influenced by his developer-friendly leanings. This approach encourages thinking in terms of four delivery areas:
  • Signal (aka "network" in Martin's convergence paper)
  • Signal content (aka "service" in Martin's convergence paper)
  • Signal content rendering (aka device)
  • Signal content rendering consumption (aka use)
The ODF would standardise interfaces and relationships between these (and other useful divisions) so that the potential for future development is kept straightforward and can be pursued both by proprietary black-box solutions as well as by open-source, patent-free solutions. In addition to our existing RH/MM/EU categories, this envisions similar but orthogonal categories for hardware/software development.

The consumer choice aspects of Category F come close to requiring a bill of rights for manufacturers...that within the DMP ODF they can shape pieces of the puzzle and have them pop right in to the big picture as well-fitting pieces (end-to-end conformance). Economically, for rich and powerful companies, this gives some leeway for vertical-but-benign solutions. Parts of the framework can be covered by this-or-that competitor's proprietary black box solution; these might be the earliest-to-market products; these might aggregate the most compelling content for consumers with little interest in how anything "works"; and most important these would not disrupt the ODF framework or interfaces. Probably lagging well behind, open source types can construct public solutions that cover the same ground, offer their own innovations, and encourage the geek world to fall in love with DMP's platform. The difference between ODF and what we have now in the software real-world would be that the ODF interferes with destructive vertical solutions that force dysfunctional bottlenecks into the delivery chain in order to gain socially destructive competitive advantages in the marketplace (as in, the pursuit of short-term market advantage harming long-term market advantage). So this could be to the best advantage of all the value-chain players provided an even playing field is maintained.

In my opinion, this does not solve the issue of security, but it changes the context in which security issues will continue to be pressing and relevant. Most likely, the issue of security will never go away and is to a degree a never-ending competition between virtue, vice and competing agendas. So the ODF should accommodate rules-of-the-game for ongoing evolution of ever better security hardware/software on behalf of any value-chain players who feel the need for additional security (which some *always* will).

Clearly there is the potential for ongoing standards development in this ODF idea. Just as we now require extensibility of our rights expressions and conditions, there will be a need to update the ODF spec to accommodate unexpected developments. If our first spec is good, then perhaps this can always be backwardly compatible.

4. TRUs used Based on the TRUs in category F as of April 2004:
  • 05 TRU to make playback device
  • 06 TRU to choose playback device
  • 31 TRU of reverse engineering
  • 57 TRU to choose the service
  • 58 TRU to choose the delivery system
  • 67 TRU to make content creation device
  • 68 TRU to assign content description
  • 69 TRU to access content of one's choice
  • 70 TRU to run applications of one's choice
  • 71 TRU to attach playback devices of one's choice to a network
  • 72 TRU to access information about content
  • 75 TRU to choose security
5. DEU used n+1 because the ODF is a DEU enabler, since the interfaces remain the same.
6. Benefits of DMBM ODF benefits everybody except Middle-men; it can disrupt the markets of established players.
7. Requirements Long-term compatibility with DMBM for ODF open source development.
8 References [1] Real's Helix DNA developer community at http://helixcommunity.org/
[2] Martin Springer's "On Convergence" at http://camorra.org/on_convergence.pdf