WebSeitz/wiki

OSAF

Mitch Kapor's Open Source Applications Foundation, creator of Chandler, the WorkGraph PIM for Free Agents.

http://www.osafoundation.org/

As of Dec'2011

RemoteWikiURL:http://wiki.osafoundation.org/bin/view/Main/

Created in 2002 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 MsOutlook!

Technologies (at least initially): RDF, ZODB, Python, WxPython.

Road map uses Crossing The Chasm model for prioritizing feature development.

OSAF:OSAFStatusReports

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

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:

Product definition, Positioning, etc.

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?

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 GroupWare/PIM features. It also really needs to be a MicroContent 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 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:

Edited:    |       |    Search Twitter for discussion

Made with flux.garden