[Chandler-dev] What is next for Chandler desktop?
D John Anderson
john at osafoundation.org
Sun Sep 9 17:12:35 PDT 2007
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
> 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
> 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
> 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
> . 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
> 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_
> 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
More information about the chandler-dev