[Chandler-dev] What is next for Chandler desktop?

[Andi Vajda]

So what's next for Chandler and OSAF ?

It looks like we actually released Preview on Friday. Yes !!
Congratulations to everyone and everybody :-D

We, at OSAF, have had a long tradition of being harsh on ourselves. How about, 
for once, for a change - pleeeeease - patting ourselves on the back about our 
accomplishment ?

Yes our architecture sucks, yes our UI sucks, yes our implementation sucks, 
yes our features suck, yes our schedule sucks, yes our product sucks, yes we 
all suck, yes software development sucks, yes the world sucks. Now what ?
The tone of this thread so far has been rather depressing.

Instead, I'd like to suggest the following as our next steps until 1.0.
I'd like to suggest something I'm actually looking forward to.

As was said before, our most important goal is to acquire new users. Without 
users, we have no purpose. Personally, I've worked all these years on this 
project because it's had the promise of being usable by the general public 
from the very beginning and because I can actually explain to friends and 
family what our product is about.

We're four years late in the 2002 promise of getting a user-ready release out 
the door. During this time, we haven't much worked with the outside world 
apart from a committed group of about a dozen very early adopters. It is high 
time we switch gears and become more responsible to our users:

   - No more nine month-long release cycles
     Over the last few weeks, we've been capable of releasing a decent RC build
     every other day or so. Why stop now ? We have about a 100 bugs targetted
     for our next release 0.7.1.

     Our 0.7.1 release is currently planned in about a month.
     Yeah, right.

     This feels so déjà vu. Given our record, I frankly don't see us fixing
     these hundred bugs plus all the additional ones that haven't yet been
     reported and have another release of the same quality ready in a month.

     Instead, I'd like us to continue releasing a new RC quality build every
     few days that incorporates the most recent bug fixes and general
     improvements, small or large, as they get ready.

       . To make frequent upgrades less painful for our users we need to
         implement what many other software products already do, namely an
         automatic check for an available upgrade with an automatic
         export/install/import of the user's data if they choose to upgrade.

       . To make frequent upgrades less painful for us, we need to keep the
         release tree controlled and managed as we've been doing since July.
         Frequent 0.7.x releases need to come from the same 0.7 tree. Either
         we keep 0.7+ on the trunk or make a branch, but - here is the point -
         we're not making, for the foreseeable future - until it becomes
         unpractical or until after release 1.0 - 0.7+ releases from an svn
         tree that was wide open at some point in the release cycle.

   - No more gaping feature holes
     We must plug the most gaping feature holes between now and release 1.0.
     This includes contacts, syncing with various portable devices and whatever
     other feature hole gets critical mass consensus from our _new_ users.

If we can deliver this to our users then we've delivered on the Chandler 
1.0 promise.

Now, about development.

Some have pointed out in this thread and elsewhere, with reason, various flaws 
in our design, architecture, implementation, features and product, in our 
development methodology and in our character that will make delivering on 
these goals that much harder. I sure hope that some of this criticism has to 
do with release fatigue but nonetheless, I have to agree with the gist of it.

A lot of software decisions were made over the years by accretion. Five years 
is a long time. People have come and gone, people have changed, people have 
learned, people have gained experience. The same goes for OSAF as an 
organization. Would we do everything the same way were we to start over ?
I sure don't think so.

The last thing we need, though - right now - is another big bang, another 
let's start from scratch with a new approach project. Instead, I think that we 
should improve, refactor, excise, rebuild, replace, small and large parts of 
the software that need it one piece at time. And we should do so keeping in 
mind users and developers, inside and outside. Our users are normally 
oblivious to the esthetics of our architecture. And now, they come first.

There seems to be consensus about trying a new approach to persisting UI 
elements. I agree. I think this is a good thread to start pulling on to 
unravel some of the bad architecture decisions we've made. Concretely, I think 
that solving this problem will go a long way in simplifying notifications, for 
example. Simplifying notifications will go some way in improving our perceived 
performance problems.

There seems to be consensus that our testability sucks. As has been said 
before, decoupling the UI model from the application model would give us 
a better handle on testability as well.

Starting with the UI architecture problem has a very good chance of leading us 
to solving the next problem, maybe less apparent, whatever it is.
And so on, gradually.

There seems to be consensus that our performance sucks. I don't think that our 
performance problems are _that_ bad. We've come a long way. More could be done 
and more has to be done for sure but I don't think our performance problems 
are a major showstopper anymore. I'm sure some users will disagree with me.
Performance perception has a lot to do with expectations and I'm not sure 
we've set them correctly. How fast can we actually expect Chandler to be ?

One area we've done very little work in so far is memory use. We have some 
serious leaks as for example, bug 9454, but we haven't, generally speaking,
done much memory use profiling yet.

Now last but not least.

We've been promised funding until the end of 2008. Then what ?
Personally, I can't work for free. I'm not independently wealthy. Nor can I 
live off paid consulting and do my OSAF work for free on the side.

Without a user community, I don't see much of a future for Chandler past the 
end of next year. Partly because of the reasons pointed out by Phillip - our 
codebase is not very outside developer friendly at the moment - and partly 
because I don't see much of a purpose for Chandler without users in the 
general public.

Let's not forget that, as least as I understand it, one of the founding 
missions of OSAF's has been to create open source applications usable by the 
general public, not just by and for the itchy hacker out there.

OSAF's ultimate goal, I think, should be a community of itchy hackers 
creating, supporting and maintaining open source applications for the general 
public and not just for themselves.

I strongly believe we need to get users in the general public first.
Only that, I'm afraid, can open new funding doors.

Andi..