OSAF Hosted Service Operations Open Issues

Ads early or ads later?

Background:

• One purpose of the service is generate revenue.
• Advertising is likely to be a major source of revenue for the hosted service.
• The timing of the integration of ads into the hosted service is not clear. Reasonably people could disagree on when ads should be integrated.
• Integrating advertising on at least 1 page within the next 6 months would be "ads early".
• Waiting until a threshold number of users is achieved, say 1,000 regular users per week, would be "ads later".
• Arguments for ads early: Agile development; gain earlier knowledge of maintaining ad account; drive some missing functionality and design like "where to put ads"; earn real money
• Arguments for ads later: Careful planning; service not interesting enough yet to have ads; more OSAF's style

Decision: What should be the entry criteria for placing our first ad on an OSAF page?

What is an open service and are we building one?

Background:

• As an mostly-open organization, OSAF should at least be considering how that openness relates to the new "Hosted Service" venture.
• Much of the provided functionality (Scooby, Cosmo) will already be open.
• One model is a social contract with the public that discusses the actual code being run; could have Scooby be one "blade" in an OSAF Hosted Service portal, allowing in theory for individuals to propose code that might get pushed to the live service and made available to all.
• Conventional network security wisdom is to not leak any info about servers, locations, services, etc.
• Questions: Just how open can one reasonably be? Is it possible to achieve a vision of a sustainable community resource? Is it possible to develop services using anything approaching a bazaar model? Are we brave enough for something like open book accounting?

Decision: What elements of openness, if any, should be incorporated into an OSAF Hosted Service?

What email-based functionality is viable?

Background:

• We're pretty sure we want to provide some email-based functionality through the hosted service.
• It's not clear the extent of the infrastructure required to support Hosted Service email functionality. There are tight interdependencies between function and operations.
• The current research plan is to prototype a kind of email-based submission of new events to a Cosmo-hosted calendar.

Decision: What email functionality will be included in the Beta of the Hosted Service?

What service-specific functionality is viable?

Background:

• Much of the Hosted Service will rely on "upstream" functionality provided by Cosmo and Scooby.
• There is likely to be at least some code running which is specific to the service, such as email processing.

Decision: What specific functionality and code, besides Scooby and Cosmo, needs to be written or integrated for the service?

Any non-ad revenue to pursue?

Background:

• Our business model is not well defined currently.
• Operationally, advertising is pretty much the easiest thing to build.
• There's a general leaning towards focusing on ad-based revenue.

Decision: Should additional investigations of non-ad-based revenue be explored and placed on the Hosted Service roadmap?