| WebSeitz/wikilog |
| OSAF |
|
| last edited by BillSeitz on Mar 31, 2008 8:05 pm |
Open Source Applications Foundation
RemoteWikiURL:http://wiki.osafoundation.org/bin/view/Main/
Created by Mitch Kapor
The mission includes: carry forward the vision of Vannevar Bush, Douglas Engelbart, and Ted Nelson of the computer as a medium for communication, collaboration, and coordination
Initially building the "Chandler" (code-name) Open Source PIM. P2P data sharing, smarts like Lotus Agenda. Death to Ms Outlook!
Technologies (at least initially): RDF, ZODB, PyThon, Wx Python.
Road map uses Crossing The Chasm model for prioritizing feature development.
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 "Plat Form" 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 Wiki Weblog. 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 Wiki For Collaboration 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 Slash Code to filter user comments? (You could auto-generate a Slash Code 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 Advo Gato 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:OptionalWikiNameForEveryItem (also see Wiki Mail, Wiki Proxy)
hierarchical tasks - see Project Flux
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.
They key source documents are the mission , product description , and feature summary .
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)?
Product definition, Positioning, etc.
PIM similar to Ms Outlook, Evolut Ion, but...
free, Open Source
won't disappear (unlike Lotus Agenda, EccoPro, Info Depot, etc.)
can keep evolving
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 Ms Outlook
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:
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 Intertwingular Ity 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?
This would probably increase the use of OSAF. (By coincidence, here's something Dave Winer wrote 2 years ago.)
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.
thoughts on merging/integrating OSAF and MozIlla (Jul'03)
We (the users) need a decent app that includes EMail and Group Ware/PIM features. It also really needs to be a Micro Content reader and writer. OSAF intends to deliver that.
EMail probably needs to be the centerpiece because that's what people use the most. Any other mode which needs to grab the user's attention probably needs to get to them via the EMail client.
But OSAF has been seeking an EMail guru for months with no apparent progress.
It keeps smelling to me like OSAF and MozIlla should merge. What do I want?
More precisely, why not just use MozIlla and OSAF side by side?
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 [PyXpCom] - I might feel differently)
don't want to end up with 2 Gecko engines running in memory at the same time
See these events:
z2003-07-18- Mozilla Cut From Aol - 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 z2004-02-27- Osaf Moz Mail
| User Options Recent Changes Help Page |