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

[D John Anderson]

+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