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
