As of Dec'2011
- last blog entry Jul30'2009
- no commits since Nov'2009!
- download binary app at http://chandlerproject.org/Projects/DownloadChandlerDesktop
- download source at http://downloads.osafoundation.org/chandler/releases/1.0.3/
Created in 2002 by Mitch Kapor
nice alternative design-list archives
Repository Access Protocol (RAP) will resemble an extended version of IMAP, and so would be especially suited to use as a IMAP server, and the similarity is partly driven by Lou Montulli's appreciation of IMAP. It is also driven by our appreciation of IMAP as a message based protocol that is trivially easy to use in modeling items as messages, because they are simply objects composed of attributes. We have talked about using a RAP server as the implementation of other kinds of servers, including ones you mention as well as CAP.
My current (Oct'02) recommendations, mostly meta-process stuff:
- think like a "PlatForm" vs an "application"
- start by documenting some User Scenarios (see Collaboration Ware for some rough notes I did months ago). That way discussions about how/why to do things like scheduling meetings or browsing remote data will be grounded.
- get the platform code out there before the application is ready (e.g. RDF/ZODB). Let other people start working on complementary apps. Keep code modular, and define APIs, so that other EMail clients can be used.
- push out lots of info, don't worry about cleaning it up. Publish notes from every meeting/decision immediately, via Wiki. Have each developer use that as a WikiWeblog. Make all this read-only for the public.
- have some mechanism for making public input manageable.
- The goal is to improve the delivered code, not have a kibbitz klatsch.
- I'm not sure a Mailing List is manageable. But it's probably the optimal high-volume channel.
- I don't think a Wiki works for discussion (see WikiForCollaboration Ware). It's too hard to follow/find new comments. Having to re-read a page to find the refactored bits is annoying.
- Maybe a public wiki that parallels the controlled wiki? (e.g. the team has its site which the public can only read, there's a parallel wide-open wiki) see WikiWeb ideas (esp Sister Sites)...
- Maybe use SlashCode to filter user comments? (You could auto-generate a SlashCode item for each wiki page! Of course that could get weird as the content of a wiki page changed, or even moreso if pages get renamed...)
- Paul Snively recommended the Advogato engine. Whether that engine/model is responsible for the signal/noise quality on that site is maybe open to debate. It also seems to focus on limiting spam potential of people more than providing feedback on the quality of individual postings (though I could be wrong, I've haven't paid much attention to the workings of the site).
Specific feature requests
- OSAF:OptionalWiki NameForEveryItem (also see WikiMail, WikiProxy)
- hierarchical tasks - see Project Flux
- Universal Inbox
- either publish subset of thoughts out to multiple wiki spaces, or have very granular controls of outsider access to local items.
- Visual input/output: Mind Mapping, Graph Drawing, Touch Graph
User Scenarios, personas, etc.
I've been (Nov'02) kvetching about a lack of requirements-context documentation, and Mitch replied that he thinks the current site docs do a pretty good job, asking if there are specific questions I think are relevant. So I'll have to think about that a bit.
Some user attributes:
- individual Free Agent, member of small team (SmallCo), or multiple small teams
- have a primary "real computer" (desktop or laptop), but may also use additional machine (home desktop, etc.)
- any philosophical/logistical issues with having lots of data, personal and "group", sloshed together in a single repository running on a company-owned machine? Maybe philosophical issues are less of an issue on smaller teams, which presumably value their members more as autonomous humans, vs BigCo cogs. But lawyers can make this an issue (esp where outside investment is involved, I suppose).
- may also have a PDA. Willing to switch from a narrow/closed model like the PalmOS to something that could more realistically run an OSAF (lite) client, like a Sharp Zaurus? Or do we have to plan on having a model that can Data Synch to PalmOS core PIM applications? Will lack of any PDA support be a signficant barrier to adoption for many people (besides me)?
- some searches to see if people are having success with the Zaurus (which uses PyQt instead of PyWindows)
Product definition, Positioning, etc.
- PIM similar to MsOutlook, Evolution, but...
- free, Open Source
- won't require a server (other than EMail) for sharing info (e.g. Group Calendaring)
- some superior Rocket Science features
- Lotus Agenda organizating capabilities
Hmm, I think Mitch may be right that the basic mission/vision is reasonably well defined. Looking at some specific email threads I've found frustrating, maybe what I'm looking for is a mid-level context for those threads, like which specific User Stories are being targeted. For instance, in this thread about existing P2P systems and synchronization, is the goal to get updated contact information for another OSAF user, or to get updated versions of a bunch of note items on another OSAF user's machine, or something else? Expecting one approach to solve both problems efficiently may not be realistic.
My short-term desires (Nov'02): deliver as soon as possible a tool which provides:
- basic single-user PIM features comparable to MsOutlook
- a mechanism for Group Calendaring (personally, I don't even need that yet, but I suspect it's important for others) (a first pass could be extremely simple)
- a PDA solution
This means I'd rather see not dealt with until v2:
- EMail client (I'll use Mozilla for that)
- fancy view and auto-categorizing features (I actually think that being able to optionally assign a Wiki Name to every item, and have any Wiki Name in any field be automatically a link to that named item, would provide plenty of Intertwingularity for now)
- other P2P/sharing features beyond basic Group Calendaring
Here's Mitch's posting about the schedule, made later the same day as the notes above...
thoughts on licensing
As of Apr'03, the OSAF:LicensingPlan is to emulate MySQL: a developer can use/build on OSAF with an Open Source arrangement (meaning that all code developed on top of it be returned (with ownership rights) to OSAF, or the developer can purchase a commercial license and build his own proprietary stuff on top of it.
Weird thought: what if the code were completely Public Domain (or some other structure) and thus any developer could build his own commercial/proprietary apps on top of it without paying a license?
What would be the downside?
- that licensing revenue stream lost, reduces viability of OSAF long-term existence (given that Mitch probably doesn't want to play Gold Owner forever).
- another potential revenue stream: OSAF team would be considered the world experts on the platform, so they'd probably be getting requests for custom development all the time, so they could spend part of their time on revenue-generating contract work. The Zope team does this - that custom code doesn't go back into the platform, though a lot of it tends to result eventually in development of generalized platform-level code (e.g. ZopeCMF) which they then put into the base product. It's also not clear to me whether Zope's license requires changes to be delivered back to them.
- many improvements to underlying platform would be hidden in proprietary implementations, so platform would not improve as much - which might also keep underlying platform from reaching community Critical Mass.
- maybe there's some sort of Compatibility Test that could be defined, which a proprietary app would have to pass in order to be "OSAF-Compliant", which might add marketing value to such products. Thus any low-level changes which would break compatibility would negate this compliance - so such a developer would have an incentive to donate back platform-level stuff, while keeping app-level stuff to himself.
- Well, to some extent it's not about my options, it's about wanting OSAF to get used by lots of people. And not having EMail keeps that from happening.
- want address book integration
- want to build a Universal Inbox - 2 of the key incoming message types are RSS and EMail. Mozilla's too big a pain for me to consider building a good RSS handler in (now if someone built high-level Python wrappers for everything - not just PyXp Com - I might feel differently)
- don't want to end up with 2 Gecko engines running in memory at the same time
See these events:
- 2003-06-26-Mitch Kapor Interview
- 2003-07-18-MozillaCutFromAol - probably what led to my notes above
- Dreaming In Code says that they had internal discussions about this issue at this time, and lays out some of the arguments, but then just says it was "settled" within a month, without giving any meaty sense of the key reason.
- I finally asked about integration 2004-02-27-OsafMozMail