Mikeal Rogers wrote:
I think this hits directly at the heart of our questions about the
"eco-system".
-Does the eco-system include other clients?
-More importantly, can the eco-system, and the osaf hosted service be
successful without other clients and open interfaces.
Elliot Lee wrote:
I think a calendar server needs a web interface, but I am slightly
concerned because I don't understand the merits of the "ecosystem."
Inigo Montoya once said:
You keep using that word. I do not think it means what you think it
means.
I'm guessing that there are some hidden assumptions around the word
"ecosystem". I'd certainly like to see us avoid using it as a word that
raises the emotional stakes of a given conversation. It may be
helpful to be explicit about specific concerns (as Mikeal has done above).
Sometimes we've used "ecosystem" to mean that we're planning Chandler
desktop, Cosmo, Scooby, and the hosted service together, with shared
target users, release cycles with dependencies on each other, etc. Our
primary focus as an organization needs to be getting people outside of
OSAF to use the Chandler desktop client and OSAF's hosted service (which
of course runs the server [Cosmo] and the web client [Scooby]).
Making good on my promise to be a broken record about this:
GETTING END USERS OUTSIDE OF OSAF IS THE TOP PRIORITY
Sometimes we use the term "ecosystem" to suggest a relationship to other
clients and servers not written by OSAF. While not always the immediate
top priority, this is also of long term importance.
It never means that we expect users to live in a hermetically sealed
OSAF universe. That wouldn't be much of an ecosystem. It also wouldn't
be very realistic.
To me, "ecosystem" implies these things:
- Cosmo and Scooby are important projects for OSAF, not side
experiments. Consequences: more engineering resources, more design
resources, etc. John and Priss joined the team, and we have two more
open positions at OSAF.
- Desktop Chandler, Cosmo the server and Scooby the web application are
linked by more than a protocol. We want all three projects to support
features like stamping. (Just one example). Consequences: We have one
design team working with both projects. We have engineers on both
projects collaborating on the information model/sharing format, etc.
- OSAF's overall strategy incorporates all of the projects, looking at
them together. We are planning for one set of target users and thinking
about how each one uses the desktop app, the web app, or both (when and
how). The target users help us determine the workflows we want to
support. The workflows impact features on the desktop client and the web
client. The workflows determine how we prioritize features.
Consequences: Feature priorities for the web client, the desktop client,
the server, and the hosted service.
- OSAF is starting up a "hosted service" project, which will run the
server and the web client. This allows us to make sure we provide a good
experience for a set of users, and to start getting users and learning
from them. It also gives us options for different revenue models to
sustain OSAF in the future. Consequences: The hosted service will add
requirements to the web client, the server, and the desktop client. In
the short term, supporting this service is a high priority.
To answer Mikeal's questions:
- Does the ecosystem include other clients: Yes, in a couple of ways,
even in the short term. More ways in the long term.
- Can the desktop client, web client, server and hosted service be
successful without other clients and open interfaces? I honestly don't
know, but a completely isolated "solution" is not the strategy we're taking.
SHORT TERM (BETA):
Interop: The "hub", "coordinator", "apex" and "assistant" interact with
"visiting collaborators", who very likely use some other calendar
client, mail client, etc. We're looking at supporting some interop
scenarios with iCal and ".mac", for example.
Email: Most users will use some other mail client. As per the "bridging
the gap" thread, we want to give users some way to get some mail into
their "dashboard".
LONGER TERM:
- Other services may run Cosmo; the desktop and web clients may
subscribe to calendars on these other services.
- Other clients may run against Cosmo, using a variety of protocols.
(This may mostly work even in the short term for some clients.)
- End users of the desktop app and web app can to publish and subscribe
to collections on other servers as well as Cosmo servers.
Note that some work being done on the various projects falls into this
long term goal, including several of the intern projects, interop
events, etc. Also, we're interested in collaborating with folks outside
of OSAF who share the long term goals. That said, we have short term
goals ahead of us that take priority for folks at OSAF: making the
server scalable, getting dashboard features to the point of usability,
getting the web client to be dogfoodable, etc. It is important that we
focus and get these things done.
To answer Elliot's question: What are the merits of the ecosystem?
The desktop client, the web client and the server all play a role in
enabling the target users to collaborate on shared projects. We want the
features that make this compelling (beyond just calendar) to show up in
both the web client and the desktop client, and to be available to other
future clients via the server. Some users will be using the desktop
client, some users the web client: each is collaborating using the same
data.
I'm sure that specific scenarios/workflows make this more concrete --
Sheila is working on a presentation about stamping workflows that span
the desktop and web client.
Bottom line: OSAF is way better off once we have end users using
the desktop client, the web client, and the server. Offering the service
is a way of getting users and learning directly from the experience of
running the service. This needs to be our focus, and it means that some
things we'd otherwise like to do have to get put off until next year or
later.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
