The Chandler Project is running an open service named Chandler Hub. Or at least, that’s what we’ve been telling ourselves.
The term “open service” does not have the clear definitions and history of its cousins “open source” and “free software“. We’re trying to figure out, just like everyone else, what it means to be an open service.
There has been a recent surge of chatter about “open services“. The current focus seems to have two branches: 1) attempts to define the term “open service” and 2) discussion of the impact of closed services to the larger Internet public good. This surge was probably triggered by Luis Villa’s recent work for the GNOME Online Desktop project. Luis takes care to catalog excellent references to earlier work as well. There’s a healthy conversation on the Open Knowledge Foundation’s okfn-discuss mailing list, where Rufus Pollack just posted a draft of an open service definition.
How the new titans of web services approach the openness of their offerings has an importance it did not have five years ago. Tim O’Reilly has promoted the view:
…the fundamental challenge of the Web 2.0 era may not be free software but free data, and the right of users to view, delete, modify, or freely transfer to a competing service the data that is stored about them in centralized databases…
OSAF (the Open Source Applications Foundation) with its Chandler Project and related hosted service Chandler Hub, seems positioned within both these areas: free/open software as well as free/open data. The ideals of freedoms and the public good are embedded in OSAF’s DNA and our self-standards are high. We would love to hear about areas we can improve.
A persistent criticism of many of the most popular web services is “Where’s the source?!” Whatever Google’s goals for openness are otherwise, no one realistically expects them to release their revenue-center source code. So people focus on the most important substitute: data access through open standards and open protocols. Groups like MoveMyData envision a generic tool for bulk download/upload of “your data” to sites like Flickr, YouTube, MySpace, and blogger, including your own web servers. Others dream that application-layer protocols like Atompub, CalDAV, or CardDAV, etc will be widely adopted and provide user freedoms through interoperability. Others worry about identity management, so links to treasured pictures online don’t go bad when a service changes operations (the broken URL problem).
The Chandler Hub service though, is the “full package”, multiple open apis for data and fully open source. (We have not quite solved the broken URL problem though.) The Hub is a straight install of Cosmo (the Chandler Server). Cosmo is an Apache 2-licensed open source “PIM sharing server” with a built-in web UI. Coupled with consumer-friendly terms of service, we have the makings of a fully-open hosted service.
OSAF, a non-profit organization, did not build Cosmo specifically to run a service; the original thought was that workgroups might run their own (like SMTP and web servers) and that they would form a loose network of cooperating servers. (The original Chandler vision was even framed in terms of true peer-to-peer, similar to Kragen Sitaker’s 2006 proposal for how to achieve open services).
As OSAF approached its Preview launch, it seemed clear that running a free service, providing easy sharing, synchronization, and a web interface was an important enabler for people trying out the Chandler Project. Some people will not have access to a private server, so without a low-hassle (and free-to-use) service, they would be blocked from using some parts of the Chandler Project.
Whatever the history, we find ourselves today launching a remarkably open service. Do we measure up to emerging definitions of open services?
Villa’s model for open services asks for the full package, source code included. It contains three preconditions:
- data access (ability to retrieve data in open formats)
- source access (ability to interact with your data locally once retrieved)
- hardware access (ability to run on various sized-hardware)
and three rights: use, modify, redistribute.
Users of Chandler Hub have full data access via multiple open standard protocols (Atompub, CalDAV, and Webcal). Full source access available in OSAF’s public subversion repository and hardware access spans from laptops through large, clustered servers. Even our admin scripts and runbook are available.
So it seems fair to say that Chandler Hub rates well on Villa’s preconditions for an open service. Huzzah!
How we’re judged for the three rights of use, modify, and redistribute should depend on our exact and our adherence to those terms. We want to provide every consumer right expected in this area.
The issues in crafting an open terms of service are trickier than they appear: while you own your data, you can’t be mad at us if we “break your stuff” if there were say a server corruption or downtime. It turns out you actually need to grant the service important rights (store, transmit, etc), not the other way around. Also, when you share an item with others where you both have a right to edit, who has a right to delete it later? Some open service definitions expect community-generated data to be licensed under say the Creative Commons licenses, how does that apply to what Chandler Project is doing (with shared, but possibly private data)?
It turns out, that while drafting this post about open services, the Chandler Project just posted our first public terms of service and privacy policy. Experience suggests that there will be at least a couple of places where we did not write down what we actually meant. We’ll need a longer track record before we can be judged on our implementation of our terms, but we encourage you to let us know how our terms of service document looks, how the privacy policy looks, and how you think we’re doing on this critical dimension of an open service.
So there’s our claim: we’re running an open service, providing both open data and open source, backed by a non-profit motivation and consumer-friendly terms. We’d like to accomplish a few things here:
- Get community feedback on our terms of service and privacy policy
- Highlight the importance of the other end of the browser connection in Mozilla’s vision of the Open Web
- Have people working on “open service” definitions consider how the Chandler Hub ranks on their openness scales
- Encourage open service definitions to address further the thorny problem of appropriate terms of service
- Plug the Chandler Hub service. Check out our system and tell us what you think!
Thanks in advance for any feedback you can provide and also thanks for your interest in the Chandler Project!
