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

[D John Anderson]

+1

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  
> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev