+1
On Sep 9, 2007, at 2:27 PM, Andi Vajda wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
