[Chandler-dev] desktop priorities (next steps for desktop)

[Katie Capps Parlante]

I had a conversation last week with Philippe, Grant and Mimi about OSAF 
priorities and how they might frame desktop decisions. This is all in 
the context of answering the question: how should we be allocating 
desktop developer time right now?

High level priorities:
1. Get users
2. Pursue revenue opportunities to sustain the project
3. Get developers

I've listed the above in the order of importance, but we can acknowledge 
that they are all related. A larger user base changes the options for 
revenue opportunities. An active, engaged developer community might help 
evangelize and build a user base. Plugins developed by people external 
to the project might be connected to a revenue opportunity. Revenue 
opportunites give us funds to do more work to make users happy. And so on.

Work priorities in the short run (not necessarily in prioritized order):

A. Fix a small set of high level usability problems. (Mimi will send out 
this list -- these problems are larger in scope than a small bug, but 
smaller in scope than a new feature).

B. Add the most minimal set of new features. (Right now, only month view 
is on this list).

C. Fix performance and memory problems.

D. Shorter release cycles.

E. Support plugin developers.

F. Improve developer productivity.

G. Fix problems with reliability and data integrity.

H. Improve testability.
    - improved framework for functional testing
    - better layering/APIs to be able to test at different layers
    - culture of test driven development

Bigger features that we might be called upon to implement if they led to 
a revenue opportunity (but we won't do without some driving reason):
- Email
- Mobile/sync
- Exchange
- Scheduling/calendar interop

Some thoughts on how these pieces fit together...

- We don't yet have a clear direction for the revenue opportunities. We 
are working that angle, but that will take a little time to play out. In 
the meantime, developers can be actively working on the "getting users" 
angle by fixing blocking bugs, working out obvious usability problems, etc.

- Until the revenue opportunity picture develops, we shouldn't be making 
large feature investments. We should only be adding (small) features 
that people are clamoring for. Right now, "month view" is the only 
feature that fits that criteria -- we've heard from several people that 
month view is the only feature blocking them from trying to adopt 
Chandler desktop.

- Shorter release cycles are really important for supporting agile 
decision making. At some point (in the near future I hope), an 
opportunity will come up where we want to add a feature or do some other 
work in pursuit of a larger set of users or a more direct revenue 
opportunity. We want to be able to jump on that kind of opportunity.

- To support shorter release cycles, we need to pay attention to the 
testability of the system as well as developer productivity (which are 
related).

- Reliability and data integrity problems interfere with developer 
productivity and shorter release cycles. If they are a big enough 
problem, it also interferes with keeping users. They can prevent plugin 
developers from being successful as well.

- Performance and memory problems may or may not be a problem getting 
and keeping users. They may interfere with going in some direction or 
other in pursuit of revenue opportunities (e.g. becoming full fledged 
email client).

- We're an end-user application above being a platform, so supporting 
plugin developers is secondary to developing a user base. That said, I 
still think it makes sense to allocate some resources to plugin 
development (and supporting any developers who show up and want to write 
plugins). Why? Enthusiastic developers can help evangelize the project. 
Plugins could be a mechanism for revenue opportunities (e.g. a plugin 
that talks to Exchange). That said, I don't think we need big 
investments here right now -- we already have the basics for plugin support.

- It is perhaps worth spelling out -- if we have users and developers, 
the project can live on and provide value even if OSAF itself isn't 
providing all of the funding over the long run. Our primary goal isn't 
to make money as an organization, it is to have created something of 
value. Happy users is the primary metric for knowing that we have 
created something of value.

I'll jump in the threads with more specific responses -- I just wanted 
to give everyone that context about how I'm thinking about it.

Cheers,
Katie