[Chandler-dev] desktop priorities (next steps for desktop)
D John Anderson
john at osafoundation.org
Tue Oct 2 10:54:11 PDT 2007
On Oct 2, 2007, at 10:21 AM, Katie Capps Parlante wrote:
> 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
> 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
> - 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
> - 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev