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