Hand-forged posts since 2002
We have become dependent on Google as a part of our Web infrastructure (too dependent, some say), in part because Google’s reliability record is so superb. All of which makes the receipt of any sort of error message from any dimension of the Googleverse worthy of note.
Today I tried to access my Google Calendar. Instead I saw this:
A minute later, my calendar returned. But for an instant, I got to thinking about life without Google.
Today’s Journal features a Portals column by Vauhini Vara that represents yet another attempt to gauge how far Web apps have come by attempting to “live on the Web,” forsaking all desktop-based software. (Others — like James Fallows in 2006 in Technology Review, whose effort I wrote about back then — have done this before.)
The trouble with this approach is that it’s a total straw man. No one would ever do this except to provide column fodder. The shifts in our software habits are incremental; we don’t “change state” 100 percent, we just drift in one direction. And the drift today is overwhelmingly towards the Web.
Of course Vara finds the trouble spots exactly where you’d expect: If you’re tied in to a corporate email system, giving up Outlook for a Web interface is still painful. Spreadsheets and PDFs are harder to work with. Web-based writing tools are pretty good but so far they haven’t provided a good replacement for Word’s clumsy but essential “track changes” feature.
OK. In the meantime, those of us who aren’t locked in to Outlook long ago went with Gmail or some other Web-based email system. We keep and share our calendars on the Web, and increasingly we use Web-based tools to coordinate small work groups. No one is holding a gun to our heads, so we happily mix Web apps and desktop apps. Why not?
If you’re starting a small business today, are you going to invest in Outlook or are you just going to piggyback on some Web service? When the business begins to grow, are you going to pay the big Outlook tax or stick with what’s working? As developers devise new useful tools for communication and coordination, are they introduced on the desktop or on the Web — or in both places?
These are the trends that matter. “All or nothing” is beside the point.
My friend and former colleague Chad Dickerson has a great post about Facebook developers reliving the perennial platform-developer’s nightmare: if you build something really wonderful, sooner or later the platform owner incorporates what you invented into the core software.
This line should be savored:
As the old Santayana quote goes, “those who do not learn from history are doomed to repeat it,” but in Silicon Valley, those who rely on their command of history too much often find themselves getting crushed by a 23-year-old who skipped history class in favor of a CS degree.
The platform developer’s dilemma goes back a long way: among other things, to the early days of Dave Winer’s web writing (he’d experienced the phenomenon when he saw his own Macintosh scripting environment eclipsed by Apple’s less versatile in-house effort). But it goes even farther back than that — back before Windows. In the 80s, DOS dominated the world, but you couldn’t really run DOS without a zillion helper utilities. Over time and successive DOS releases many of these helper utilities were incorporated into the OS. Much of the time this was a Good Thing for users, and many of the utilities were freeware anyway, but if you’d tried to build a for-profit business around some essential extension to DOS, you were on shaky ground — and Microsoft was the beast causing the tremors.
Chad locates the difference in today’s software world in the speed of development:
Velocity changes everything. As the developers dance faster in this new environment, so too does the platform elephant. The faster the elephant dances, the more likely “the little people” underneath (as Ariana calls platform developers in the News.com story) could get unwittingly trampled in the process.
Very true. But in the end, I think, developers understandably flock toward any platform on which large numbers of users have pitched their tents — true for DOS decades ago, Facebook today, and who knows what tomorrow.
PS I’m reasonably sure the canonical version of the Santayana quotation is:
Those who cannot remember the past are condemned to repeat it.
But the Web is full of variations. And those who cannot remember their quotes are condemned to wander the Web’s copycat quote pages!
[This is a post describing a technique I’ve found useful for managing my blog. Feel free to skip the geek-out!]
For a long time I’ve wished for a better system to manage my blog post drafts. I know there are client side tools like MarsEdit and Ecto, but I use lots of different machines at home and on the road, and prefer to work with one set of drafts on a server.
Recent tweaks to WordPress have allowed you to filter posts based on published/unpublished/draft status — that means you can have a standling link to a list of drafts. That simple capability got me most of where I wanted to be; when I get an idea for a post, I create a placeholder post with a quick note reminding me of the idea. A bookmark on my browser toolbar points to this list of drafts.
The other tool that has made this really useful is Postalicious — a wordpress plugin that creates blog posts based on Delicious tags. I was less happy with Postalicious the first time I used it because I had it set to automatically publish my links — but Delicious has a tight, Twitter-like limit on the number of characters you can use to annotate the links. And I like to gas on sometimes. I’d find myself going into the post after it was published and adding material — awkward at best.
Now I have Postalicious set to create the new posts as drafts. As I’m wandering the Web, when I see something I want to blog about, I tag it appropriately. Then the next time I have a chance to do some blogging, I’ve got a nice list of the links I want to write about waiting for me in my draft list. The URL is right there so if I want to quote at length I can just click right through to it and cut and paste the longer quote that wouldn’t have fit into Delicious.
Sometimes, it’s these simple things that please us users the most!
That Orwell quote earlier this week that began “Our civilization is founded on coal” had a “pace Chesterton” at the start that puzzled me. A number of you wrote in with suggestions, including a pointer to a fascinating debate between Chesterton and Bernard Shaw about whether to nationalize the coal mines, moderated by Hilaire Belloc.
But I believe Mark Bernstein found the ur-instance of the Chesterton reference:
This is the true and exact account of the Great Cigar Fraud, and the moral of it is this–that civilisation is founded upon abstractions. The idea of debt is one which cannot be conveyed by physical motions at all, because it is an abstract idea.
So, what Orwell was really saying was: sorry, G.K., our civilization is not founded upon abstractions, it’s founded on the hard reality of coal mining. And thus Stroustrup’s reformulation — “our civilization is built on software” — takes us full circle, back to the many layers of abstraction that constitute our program code.
It all connects!
I wrote Dreaming in Code because I believed that, as Bjarne Stroustrup says, “our civilization is built on software.” I noticed that creating software remains stubbornly difficult in certain ways, and, despite its centrality to our civilization, our understanding of that difficulty remains deficient. But I also wanted to create a journalistic record of the day-to-day experience of the software developer at the start of the 21st century — to tell a story about the act of programming itself.
I’m grateful that a good number of the book’s readers who’ve posted their thoughts feel that I achieved that goal. Others don’t think I did, and some days I agree with the criticism. Writing about the act of programming itself is as difficult as writing about any act of writing: the subject is an essentially interior process between the mind and the page (or screen), and it’s highly resistant to illumination.
Consider the difference when the topic of an essay is a rough physical act — like, say, digging coal out of the ground. I read a lot of George Orwell early in my career but I’d forgotten this passage, which Brad DeLong hoisted into the light of blog last year:
Our civilization, pace Chesterton, is founded on coal, more completely than one realizes until one stops to think about it. The machines that keep us alive, and the machines that make machines, are all directly or indirectly dependent upon coal. In the metabolism of the Western world the coal-miner is second in importance only to the man who ploughs the soil. He is a sort of caryatid upon whose shoulders nearly everything that is not grimy is supported. For this reason the actual process by which coal is extracted is well worth watching, if you get the chance and are willing to take the trouble.
When you go down a coal-mine it is important to try and get to the coal face when the ‘fillers’ are at work. This is not easy, because when the mine is working visitors are a nuisance and are not encouraged, but if you go at any other time, it is possible to come away with a totally wrong impression. On a Sunday, for instance, a mine seems almost peaceful. The time to go there is when the machines are roaring and the air is black with coal dust, and when you can actually see what the miners have to do. At those times the place is like hell, or at any rate like my own mental picture of hell. Most of the things one imagines in hell are if there — heat, noise, confusion, darkness, foul air, and, above all, unbearably cramped space. Everything except the fire, for there is no fire down there except the feeble beams of Davy lamps and electric torches which scarcely penetrate the clouds of coal dust.
It should go without saying that a wide gulf separates the strenuous and perilous experience of the “grimy” miners that Orwell depicted and the abstract, cerebral work of programming. The parallels are less obvious — but they jump out at me, too.
Both activities are essential to industry and highly profitable to those at the top of the economic pyramid they support. Both require the exploitation of long hours put in by young workers. In each, the treasures society values are struggled for in dim places and retrieved into the daylight after obscure labors to which their beneficiaries are oblivious.
Writing about a software project couldn’t have been more physically different from descending into a mine. But there were times, during my three years of research, when I felt like I was in an underground labyrinth, hunting for nuggets of insight in the dark.
It was, in any case, striking to find the “Our civilization is founded on…” construction that kicks off Dreaming in Code in Orwell’s penetrating lead. I’ve been trying to trace the Chesterton passage Orwell refers to as his antecedent, but so far no luck. Anyone have a clue?
OOPSLA is the ACM conference that most broadly and widely addresses the sorts of questions I tried to explore in DREAMING IN CODE. I found the two events that I’ve attended, in 2004 and 2006, both highly rewarding. I couldn’t make the 2007 edition in Montreal, but I was delighted to find this page of podcast recordings of many of the conference’s highlights.
I’ve only had time to dip my toes in this stuff so far; there are talks by David Parnas, Fred Brooks, John McCarthy, Patti Maes, Guy Steele, Richard Gabriel, Gregor Kiczales and many others.
I only just caught up with Joel Spolsky’s amusing and insightful Yale talk posted last December — a return-of-the-prodigal-son sort of thing for this Yale graduate. (Here’s parts one, two and three.)
These quotes were worth highlighting:
Time and time again, you’ll see programmers redefining problems so that they can be solved algorithmically. By redefining the problem, it often happens that they’re left with something that can be solved, but which is actually a trivial problem. They don’t solve the real problem, because that’s intractable.
This is a failing, in one sense — it’s why certain Big Problems in the field never seem to get solved. On the other hand, in the face of deadlines or business pressures, we can surely see the value in a programmer’s ability to take some problem that’s impossible to solve (given available resources) and redefine it as a job that can actually be accomplished.
And:
Being able to write clearly on technical topics is the difference between being a grunt individual contributor programmer and being a leader.
The hardest problems facing most programmers don’t involve communicating with the computer; they arise in the course of communicating with people — colleagues, customers, users.
Earlier this week the Open Source Applications Foundation — the organization developing Chandler, whose work I followed for three years and whose story I tell in Dreaming in Code — announced what it called a “restructuring,” which meant laying off roughly 2/3 of its employees. (Infoworld’s story has the basics.)
So does this mean that Mitch Kapor, OSAF’s founder and chief funder, is “pulling the plug” on OSAF, as Techdirt has it, or “bailing on” Chandler, as a CNET blogger put it?
Kapor is indeed leaving the OSAF board and handing the rest of the reins to Katie Capps Parlante, who’s been running the project day-to-day for some time. That’s a big change. From what I can tell, though, this isn’t so much a “plug-pulling” as an amicable parting of the ways.
Kapor’s financial withdrawal is not a big surprise. He had told the Chandler developers several months ago that he intended to fund the project through the end of 2008 but no further; that decision had been discussed on the project’s public mailing list, so the looming changes couldn’t have come as a total shock to anyone who’d been following the story. (I write about these changes in a new epilogue to DREAMING IN CODE that will be included in the forthcoming paperback edition, due out in late February.)
What actually happened at the end of 2007, according to Parlante, who I interviewed today, is that OSAF and Kapor agreed that it would be healthy for the project to move out from under Kapor’s wing faster than they originally envisioned. Over the past year, Kapor has been less involved with Chandler and more focused on new projects (such as Foxmarks), and Parlante says that the project leaders felt that if they were headed towards independence anyway, it made sense to move faster.
“We’ve been joking that we laid off Mitch,” she says.
At that point, Kapor agreed to provide transitional funding for the group — less than he’d originally planned when envisioning paying the entire project’s bills for another year. That triggered the staff cuts.
How much exactly did Kapor commit? Referring to the deal that launched the Mozilla Foundation in 2003, which Kapor brokered when AOL was shutting Netscape down, Parlante says, “He’d told AOL to give Mozilla enough support for it to become viable on its own, and he decided he should follow his own advice with us.” (In 2003, AOL put up $2 million, and Kapor himself put up $300,000, to fund the Mozilla Foundation, which is now a hugely successful enterprise, based on Firefox’s revenue from Google.)
Chandler started in 2002 as a high-profile project that aimed to produce a novel personal-information manager and demonstrate that the open source development methodology could produce innovatively designed desktop software. But the work proceeded at an agonizingly slow pace, and it took about five years for OSAF to ship a usable “Preview” edition last fall.
So there’s no question that the cutbacks represent a come-down for a project that started out with such grand ambitions and golden prospects. But surely there are better metaphors for what’s happening than “pulling the plug”: “leaving the nest,” perhaps. In fact, as of the end of the month, OSAF will move out of its longtime home at Kapor’s offices on Howard Street in San Francisco’s SOMA district and become a virtual team.
From the start of OSAF, Kapor had made clear that he did not envision the project as an open-ended philanthropic obligation, but rather as a test-bed for new ideas in software design and project organization. During the time I spent at OSAF, he would regularly repeat his belief that OSAF ultimately needed to become financially self-sustaining.
Parlante says OSAF will use its transitional funding period to explore lots of different business models — everything from selling advertising or charging for service to community support (donations and fundraising) to business partnerships or deals to bundle the Chandler Hub server with other products. “Open source business models are always a little up in the air, they’re always changing — that’s true even of Mozilla,” Parlante says.
Can Chandler survive on its own? Right now I’d give it good odds for continuing in some form: as long as there are developers interested in continuing work on it, there’s no reason for it not to. It will be harder, but by no means impossible, for the organization to find enough money to support a small full-time staff beyond the transition.
The obituary writers are already chomping at the bit. And of course many of the criticisms of OSAF’s mistakes are accurate. Still, those mistakes are now history. Since shipping the Preview version of Chandler its team has sped up the flow of new releases, new features and bug fixes, suggesting that the pressure of looming independence has already made a difference. The question is, does Chandler today offer enough innovative value to build a thriving community and win support — both volunteer development effort and cash?
Given the history, it would be foolhardy to say “yes” for sure; but I think it’s also a mistake to say “no way.”
I’m a veteran of a company that spent roughly three years disproving premature reports of its demise. Salon is still around and doing good work. It’s certainly going to be challenging for OSAF to continue on its own, and it’s entirely possible that the organization will be gone within a couple of years. But writing it off today seems wrongheaded to me.
Of course, in spending so much time and thought on telling Chandler’s story, I invested something of myself in it, too, so maybe I’m just unwilling to let go. But there are other indicators that the project is unlikely to simply evaporate.
At the very moment that OSAF announced its cutbacks and the obituary writers jumped the gun, geek-hero blogger Cory Doctorow posted an enthusiastic endorsement of Chandler on the extremely popular BoingBoing. Doctorow’s post might be part of an effort to rally support for Chandler among its users now that its future isn’t guaranteed. That’s what happens when an enterprise that people care about is threatened. Or maybe it was a spontaneous coincidence — that happens too!
The big question is whether enough people care enough about Chandler to keep it afloat. In a sense, that is the final experiment in the OSAF lab, and as long as Kapor continued to fund the project out of his own deep pockets, it would never be able to get results.
“I would say I had a lot of ambitions that we wound up, for very good and practical reasons, scaling back on,” Kapor said in an interview Thursday. He described the outcome as “a working subset of a grand vision.”
Kapor said his interest in continuing waned. “We found ourselves in the situation that the team wanted to continue on very much,” he added. “I found myself in a different place. I did not have that same level of commitment and desire, because I had the original dream in mind.”
UPDATE: I did catch up with Mitch Kapor late today. He confirmed the accuracy of this account. “It’s time for me to move on,” he said. See also Kapor’s own blog post on this topic.
I’ve also received a couple of anonymous emails from people involved in the project, suggesting what I’m sure is just the tip of the iceberg of disagreements over Chandler’s direction, its leadership, and the personnel choices involved in the layoffs. Having lived through the difficulty of such events more than once myself, I know that they’re deeply emotional — and that there is often more than one “right” view of the situation. I haven’t been following Chandler closely enough for the last couple of years, since I wrapped up the book, to gauge the accuracy of these perspectives.
I also don’t yet know exactly who’s leaving. I’ll try to link to the participants’ own reports. Here’s Ted Leung’s announcement of his departure. Here’s Matt Eernisse’s. And Mike “Code Bear” Taylor’s. Taylor and Eernisse have both joined Seesmic, Loic LeMeur’s new startup. Brian Moseley, who for a long time was the central developer for the Cosmo Server (later Chandler Server), is also leaving.
Funny footnote: Moseley and I crossed paths a decade before we met at OSAF; he was part of a small development team of Cornell students who wrote the first, somewhat disastrous version of Salon’s Table Talk in 1995. He’s plainly become a very different developer in the interim. His colleagues went on to fame and fortune during the dotcom boom before going bust.
Every year around this time John Brockman poses some Big Question to his Edge discussion group, a salon of scientists and intellectuals. The results are typically all over the map but you can almost always find something of value and/or use. This year’s question was “What have you changed your mind about?” Here are some nuggets I excavated from the sprawling pile:
BoingBoing’s Xeni Jardin writes about how online communities need tending, describing BoingBoing’s experience with managing its comment space (the site hired Making Light‘s Teresa Nielsen Hayden to moderate). Her conclusion is that online discussions are best moderated by human hosts rather than voting systems or algorithms:
Plucking one early weed from a bed of germinating seeds changes everything. Small actions by focused participants change the tone of the whole. It is possible to maintain big healthy gardens online. The solution isn’t cheap, or easy, or hands-free. Few things of value are.
This isn’t exactly news; the gardening metaphor as applied to online conversation has a long history stretching back to the early days of the Well (and probably Usenet as well) and extending more recently into communities like Flickr and Wikipedia. But each new generation of online services needs to learn this lesson through experience; BoingBoing has managed it well.
Linda Stone writes insightfully, as always, about attention — and how we habitually hold our breath as we answer email (I tried observing myself and, yes, it’s true!):
I believe that attention is the most powerful tool of the human spirit and that we can enhance or augment our attention with practices like meditation and exercise, diffuse it with technologies like email and Blackberries, or alter it with pharmaceuticals.
But lately I have observed that the way in which many of us interact with our personal technologies makes it impossible to use this extraordinary tool of attention to our advantage.
In observing others — in their offices, their homes, at cafes — the vast majority of people hold their breath especially when they first begin responding to email. On cell phones, especially when talking and walking, people tend to hyper-ventilate or over-breathe.
The rest is here.
Nick Carr — echoing ideas in his new book, The Big Switch, which I’m reading now — jumps off from a line by Chinese leader Hu Jintao to argue that the Net is becoming more centralized:
It’s not Hu Jintao who is deluded in believing that the net might serve as a powerful tool for central control. It is those who assume otherwise. I used to count myself among them. But I’ve changed my mind.
Kai Krause, who created software tools for designers that were hugely popular a decade or so ago, writes about the frustrating ephemerality of creativity in the software field.
Noting that “hardly any of my software even still runs at all,” he writes:
I used to think “Software Design” is an art form.
I now believe that I was half-right:
it is indeed an art, but it has a rather short half-life:
Software is merely a performance art!A momentary flash of brilliance, doomed to be overtaken by the next wave, or maybe even by its own sequel. Eaten alive by its successors. And time…
Finally, Alison Gopnik, the psychologist and coauthor of The Scientist in the Crib, writes about the purpose of imaginative play:
Learning about the real world has obvious evolutionary advantages and kids do it better than anyone else. But why spend so much time thinking about wildly, flagrantly unreal worlds? The mystery about pretend play is connected to a mystery about adult humans – especially vivid for an English professor’s daughter like me. Why do we love obviously false plays and novels and movies?
…In fact, I think now that the two abilities — finding the truth about the world and creating new worlds — are two sides of the same coins. Theories, in science or childhood, don’t just tell us what’s true — they tell us what’s possible, and they tell us how to get to those possibilities from where we are now. When children learn and when they pretend they use their knowledge of the world to create new possibilities. So do we whether we are doing science or writing novels. I don’t think anymore that Science and Fiction are just both Good Things that complement each other. I think they are, quite literally, the same thing.
A fine insight — one that generations of readers of science fiction and fantasy know in their bones already.
[tags]edge, john brockman, xeni jardin, boingboing, online communities, linda stone, attention, nicholas carr, kai krause, alison gopnik[/tags]