-11620

042006

Commentary: A couple of remarks about Chandler

	Title	Other	Ness
	Scott Mace	This is an article by Scott Mace. His credentials are described below. Since he writes for ISPCON he can be expected, I think, to err on the optimistic side about Chandler.
	New Open-source PIM	Looking for new services? Look to new software Open-source PIM with flexible licensing for extensions may revive the ASP business.
	Thinking of a Visionary	Yesterday I wrote a viewpoint that concluded with: "There are still so many services we have yet to provide." It always helps to have the current thinking of an industry visionary, so I hopped on a train and went down to Stanford's Computer Systems Laboratory Colloquium to hear Mitch Kapor speak about Chandler.	In the computer business---and many other businesses as well---`second acts' often prove to be hard to accomplish. In all of the years since Lotus passed out of his control, Kapor's `visions' haven't proven to be particularly prescient. Contrast this with Steve Jobs, who---although I am no fan of his either---has been in and out of Apple, Pixar and other situations. Jobs, though I think he is generally wrong, has at least come by the title of visionary honestly. Kapor, though he may well prove to have something interesting, hasn't given us much evidence that he has any special omniscience.
	Platforms and Licensing	Chandler is a new personal information manager, coming this year for Windows, Macintosh and Linux operating systems, based on open-source code but encouraging proprietary add-ons by not requiring a GPL on all software extensions.	Chandler also seems to pre-suppose that the problem of `organization wide' calendaring is a critical one, worth dealing with. So far I regard this as unproven, and subject to question.
	Open Source Projects	Until now, open-source software has been mostly a phenomenon enjoyed by users of the Linux operating system, or occasionally applications such as the Apache Web server running on Windows servers. I say mostly; there are open source projects underway all throughout computing.	This seems true, although I would hasten to add that the success / failure of the open-source movement is still open to question. I think good arguments can be made on both sides of this issue, and that there is so far no conclusive evidence that open-source is particularly effective in dealing with lots of different problem domains.
	Desktop Productivity	I mention Chandler because it is Mitch, the founder of Lotus Development Corp., who will help make open-source a household word. Linux creator Linus Torvalds may be better known among younger computer users, but Mitch's name carries much weight everywhere else. After years as a commercial software developer, Mitch is obviously frustrated with the fragile state of desktop productivity software, as epitomized by the de- facto standard bearer, Microsoft Office.	I'm afraid this tells us more about the author than it does about the subject at hand. `Younger computer users', by the author's definition, now constitute the substantial majority of all computer users. I am reminded of the time I stood in line behind someone buying a record at my local Tower. They were buying a Paul McCartney record. The purchaser asked the check-out clerk `Didn't this guy used to be in some group?'. `Yeh', said the clerk, `Wings.' It was enough to make an old Beatles fan (me) shudder. I wonder how many current day computer users remember Lotus---and of those how many remember 123 as opposed to Notes.
	Unfulfilled Requirement	Mitch put his finger on a key unfulfilled requirement of productivity software users: robust, stable and flexible individual/group calendaring. In fact, this was the subject of the last column I wrote for InfoWorld as a regular staff member in 1997: the need for good shared calendars. Six years later, there hasn't been enough progress.	I am tempted to say: `Been There. Done That. Didn't Work.' Calendaring has been around since at least 1973, and probably earlier. It has never achieved much acceptance. And today there are at least half-a-dozen tries at the problem still in progress, all essentially, at least as far as I can see, to Kapor's try with Chandler. So 1997 is `kid-stuff' in terms of the history of this area.
	Innovation Rates	Mitch thinks Chandler and the open-source model can change that. Open-source communities can fix bugs and innovate at rates that cannot be matched by proprietary software companies. Many components now exist to make assembly of the Chandler code easier to do. Most importantly, users of open-source software become part of a virtuous circle of feedback and shared ownership of something that, for lack of a better phrase, is a public good. Not something owned by a company, or even by a government, but by an entire community of users.	Well, at least there's little reason to argue about this point. Time will tell. And we'll see over the next few months just how fast Chandler code gets `assembled', and whether it really is `easier to do'. My guess is that rather than swimming with the current we'll find that Chandler is swimming upstream. And in molasses at that.
	The OSAF	Kapor established a nonprofit corporation, the Open Source Applications Foundation (OSAF), to build Chandler and encourage a community of support, including everyone from universities and developers and users to foundations to keep OSAF going at a non-profit's traditional break- even balance sheet.
	OSAF and the GPL	But Kapor also aims to extend the virtuous circle to entrepreneurs. Chandler could have been built with a GPL (General Public License) attached to it. Any extensions to a GPLd piece of software must themselves be open-source and GPLd. Kapor says a pure GPL approach is "an obvious disincentive" to entrepreneurial innovation. Instead, OSAF is taking a "dual license" approach, such as MySQL and Sleepycat Software have taken, where a developer can choose to distribute the object code of their extension, not the source code, and pay for this privilege under a commercial license. "Even though some people in open source might be uncomfortable, our rejoinder would be it's helping fund OSAF," Kapor told a Stanford audience.
	US Tax Law	Under U.S. tax law, such license fees would not be tax-deductible, although any outright donations to OSAF would be.
	Service Providers	This arrangement strikes me as an interesting way for service providers to extend their Web hosting business and to reenter the ASP business by playing a role in future dual-license arrangements. Normally, there isn't a nickel to be made by an ISP who would distribute Linux or Apache to a customer. It's actually not allowed under the terms of the licenses for that code. While this is not to say ISPs cannot make money supporting such products via hosting and help desks, the trend is towards extensible, "autonomic" software that doesn't require an army of maintenance engineers.
	ISP as an ASP	But an ISP, acting as an ASP, could take Chandler's calendaring system (fully integrated with the other components of Chandler, such as email, instant messaging, a directory, authentication, managing tasks, and other workflow aspects of PIMs) and extend it. Such extensions could serve focused customers or markets, combining the freedom and flexibility of standards-based open-source solutions at low cost, while at the same time creating a steady revenue stream by licensing solutions to customers that tailor Chandler's capabilities to the customer in question. While Chandler doesn't need to be hosted on a server (it is designed to work in a peer-to-peer fashion), the reality is very few people in small-to- medium size businesses back up their data as often as they should. I could easily see a service provider both developing a customized solution and then hosting the server element as well.
	Open Software Process	Traditional commercial software is not up to this task. It costs too much and it's too hard to modify. Chandler won't be the only alternative. Software based on components built in Java, XML, pieces of Microsoft .Net, and others will also provide ways to do what I've just described. But the key is to open up the software development process in such a way that a whole range of service providers can assemble best-of-breed software components in a just-in-time fashion to solve a problem, whether it's calendaring, workflow or even more sophisticated applications, at lower cost.
	Killer App?	Part of the reason why the first wave of ASPs failed so miserably is that they were dealing with software that was expensive and difficult to customize. Also, there was too much emphasis on the high end of applications. Projects such as Chandler are actually starting small, appealing even to small and medium sized businesses for whom Microsoft Exchange is "overkill and expensive" according to Kapor. Maybe ASPs were just waiting for their killer app. Maybe Chandler is the first.	This seems absurd on the surface to me. There have been several waves of ASPs, and the have ranged all over the map from very low-end to very high-end applications. Everyone is waiting for the `killer app', and Chandler may be it, but it will surely not be `the first' and given the experience with previous PIMs the prospects aren't very good.
	Learn and Support	What can ISPs do? Learn about projects such as Chandler and support them. Look beyond traditional, monolithic software package licenses (certainly, Microsoft, IBM, Oracle, Computer Associates and others have to be). Learn XML and Java and .Net and some tools that support them. If you're too busy, or don't have a passion for software, partner with or hire someone who has the passion.
	New Generation of Software	Certainly, as ISPs defend their position as the highest-quality providers of Internet service around, it behooves them to customize and personalize that service to the greatest degree possible. A new generation of software will help them to do just that.
	Who is Scott Mace?	Scott Mace is Editorial Director of ISPCON. His journalism career spans 21 years including stints at InfoWorld, BYTE Magazine, Stardust.com and Penton Media.
	Chih-Chao Lam	This is a letter from Chih-Chao Lam on 8 Nov 2202 15:21:53 PST. This letter appeared on a Chandler mail-list and thus may be expected to be favorably disposed to Chandler.
	Pre-Summary	The posting is fairly long, so here's a rough summary: Let's focus on 4 or 5 design issues that are both "important" & "urgent" (as Kaitlin Duck Sherwood may put it). An example of an issue is Andy's "auto secure email" proposal. Appoint a moderator and try to channel the community's intelligence and wisdom to solving each issue Each week, moderator poses summary and conclusion of the week's discussions. Moderator also decides if issue is sufficiently closed to move on. In this way, conclusions from each week help drive the next week's discussions. We should think about organizing the discussions in anticipation of the day we will be using Chandler to drive such discussions. I illustrate with a rough category framework example.
	External Discussions	I'll take a stab with thoughts on organizing EXTERNAL discussions. I feel I don't know enough about OSAF internally to be sufficiently brave and offer an opinion about internal discussions yet.
	Detailed Timeline?	But first a few questions to set the context: Apart from the Game Plan posted as part of OSAF's Mission Statement, can you share a more detailed timeline and roadmap for Chandler? what are the key milestones/challenges/obstacles? - what are the different subprojects? how do they all fit together? What are the main reasons to do Chandler as an open source project? How open do you feel OSAF should be to the open source community? What and when would you not share externally? In the game plan, are there/will there be issues that are proprietary to OSAF? What are the goals for each mailing list? what does OSAF want to get out of each list? Longer term, do you see Chandler itself being used as a tool to facilitate such discussions? Is project management within the scope of Chandler? What is the structure, roles & responsibilities within OSAF? How do see that evolving?
	Talented People	I think you have assembled a surprisingly large group of eager and talented people. The challenge is to continually channel this pent-up energy to productive and meaningful causes. I believe one way to keep this energy up is to be as open and communicative as possible. The goal is to lead with a compelling vision (which you've done a great start), communicate and discuss a game plan to achieving this vision by highlighting challenges and obstacles to overcome assign different groups to tackle these challenges iterate over the game plan as we see results and feedback in (2) & (3)	The `you' here refers to the collection of people who have associated themselves with the Chandler project. Whether this group is effective or note remains to be seen. It certainly hasn't shown much so far, but time will tell if this is just `blowing smoke' or a well-deserved compliment.
	Let Chaos Reign	To paraphrase Andy Grove, we should "let chaos reign" by being as open as possible. At the same time, we should "rein in the chaos" by offering structure and organization to focus people's energies on the critical issues and challenges.
	The Vista Prototype	So, as an example: I love Andy Hertzfeld's new posting about the Vista prototype. It obviously shows a lot of quality work has gone into Chandler already. I'm sure it will elicit a lot of feedback and discussions. However, I'm also sure the prototype has uncovered a lot of new questions and challenges so far unanswered by the group. What are these questions (e.g. security issues in jabber communication)? How about explicitly posing these issues to the group? Maybe even with tentative answers? This way you will get the community focused on the issues you yourself are focused on addressing; and most probably you will also get pretty decent answers. Of course, by organizing such issues explicitly, it doesn't mean you won't hear feedback outside of these issues. I don't think people are that shy in this community!
	Discussion Process	DISCUSSION PROCESS So, I'll like to propose that we: Provide a more detailed game plan for achieving Chandler's vision Highlight near-term and crucial/difficult longer-term challenges we need to meet (topics) Organize discussions around topics of (1) & (2)
	The Moderator	Once these topics(ii) are decided, we appoint a moderator for each topic (ideally an OSAF staff or committed volunteer). Each week, the moderator seeds the discussion by starting out with issues surrounding the topic that we need input on. At the end of the week, the moderator summarizes the discussions of that week and conclusions the group has arrived (with moderator discretion but also explicit reasons for chosen conclusions). The summary is then disseminated to entire community and drives the next week's discussions. If there are no more issues surrounding that topic, then the topic can be closed. In many cases, these summaries can then be fed into later product specs as we begin to build Chandler.
	How to Choose	How we choose topics and moderators should also be influenced by structure of OSAF as posed in Q(6) above.
	Design Process	Once we adopt a design process, the process itself should drive a list of criteria for choosing the discussion tools we will use (e.g. Wiki, NNTP, etc.)
	Tools	TOOLS My feeling is that discussion boards are more suited when things are in flux and there is a divergence in opinions and when facts are still being unearthed and discussed. Wikis (and I have little experience here) are more suitable in stating plans, issues and conclusions (i.e. as a central repository of info that is continually updated).
	Wikis	So, Wiki's will be used to document and browse roadmaps, FAQs, status and problem statements (and solutions to date) and perhaps weekly summaries. Mailing lists (structured in a more fine grained manner than today) are used for ongoing discussions and debates. Of course, there will be lots of cross references between the two tools.
	Category Support	CHANDLER/AGENDA-STYLE CATEGORY SUPPORT Finally, I feel we should plan now for the day that we'll be using Chandler to design and build Chandler. Thus, we should attempt a category framework that we will associate to each Chandler message in preparation for the day we will all use Chandler!
	Discussions so far	Looking retroactively at the discussions so far, an example of a framework (not comprehensive) could be: root: chandler discussion framework design UI Usage Scenarios Planned Features Feature Requests e.g. TimeTracker/ProjectMgmt "Philosophy/Guiding principles" "Other PIM Designs pros/cons" ECCO Agenda etc. dev "architecture" "data model" "chosen tech" "other open source projects to consider" "non open source technologies to look at" issues "monolithic app vs. platform of services (daemons)" "automatic categorization" "Spam filtering" "interoperability with other apps" "collaborating with peers" "sharing information" "PDA support" "offline replication support" "internationalization & localization" security & authentication components editor calendar view etc. Organizing the Community (as recommended by Michael Bernstein) Philosophy Process Tools Wiki NNTP Mailing List Chandler
	Balance Categories	The trick is to strike a balance where categories are not too fine grained but enough to focus people on a specific area. I feel [design] and [dev] are too coarse grained today.
	Caegories	Each posting can be associated to one or more categories. This will allow Chandler to create lots of interesting views to slice and dice the discussion threads. Paul Snively's and Bill Seitz's suggestion to peer rate postings ala SlashDot style may also be worth looking into to further increase signal-to-noise ratio.