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