Category: Open source

Scott Kveton is My Hero

Scott KvetonAnd I’m not kidding either. This guy is solid. He’s a gentleman scholar and an open source kick-ass-takin’-names do gooder mofo with an impeccable track record. And he’s so friggin’ on the ball… and yeah, nice.

I first encountered Scott when I was at Spread Firefox and he’s proven to be one of my best allies in my work to promote open source ever since. We’ve met up at a couple conferences and have built up a fantastic rapport in the short year and half that we’ve known each other. And so it just tickles me orange to see him profiled in InformationWeek’s Innovators & Influences: Change Agents for his work at OSUOSL in securing $350,000 from the search engine of search engines for the continued advancement and development of open source initiatives like Mozilla, Gnome, Gentoo, Debian and others.

The best thing about Scott? He shares my vision for the future of open source and where it’s going — in fact, our conversations have formed a great deal of my thinking about and approach towards our mutual goals. But then Scott’s got a headstart on me, having already delivered all kinds of results. Sigh.

Let me put it this way. He’s kind of like the Babe Ruth of open source. He’s taken aim straight at center field of the status quo and I have absolutely no doubt in my mind that he’s not going to absolutely smash every opportunity that comes down the pipe on his way to advancing the open source movement onward and everforward. 

Congrats, Scott. And to think, we’re just gettin’ warmed up.

Architecting the Flock Content Platform

The Future of *.flock.com

I had a meeting with Daryl, Vera and a sleepy Lloyd the other day to figure out how to bring the Flock.com website properties forward, in terms of both design and utility as well as towards an architecture for participation (thanks Tim!).

So what’s gong to happen to *.flock.com? Simple: massive syndication, resyndication and the collapse of web development as we know it.

Using Drupal as our core platform enables us to move content back and forth between all the different platforms that we use (and trust me, there’s quite a few (password: flock). It also means that the content building blocks that we’re using to build our site will be available to our community to mashup pretty much however it wants (sticking within some liberal licensing scheme, of course (thanks Larry et al!)).

The implications of moving to such an architecture are significant.

To begin with, it means that besides producing content ourselves, we’ll be able to consume feeds seamlessly that our community produces. Yeah, so we can pull in other people’s blog feeds, Flickr feeds, forum feeds and on and on (thanks for adding RSS to Basecamp, Jason!). If it’s got an API or feed output (password: flock) (or is marked up with microformats) figure that at some point we could use it somewhere on our site. It’s like one big disgusting paste-board exercise. Glorious, glorious!

Roadkill ElmoSo get this: this is where web development is going; this is also where Flock is going. Static websites are a relic of a foregone era. It’s no surprise that when you come upon a prone animal on the side of the road, it’s a good bet that it’s dead. Roadkill or natural causes or radiation sickness. Same thing is true on the web.

Yeah, if this direction sounds like chaos, it’s not. It’s ordered madness, which, you’ll note, has massive amounts of potential energy in its structure. Go ask a physicist what that means coz I have no idea. Fortunately, we’ve got some tricks up our sleeves to tame this beast. Check it out.

One thing that’s important here is being able to 1) navigate your way around the site and 2) get back to where you were many days or weeks ago (in an event stream, how do you hit pause?). Well, for one, tagging. Duh. And rich, full-text search (thanks Google!). And a social network thingamabobber. And favorites. And outgoing feeds. With permalinks.

Gee, a website that mirrors Flock’s featureset? Eeeenteresting.

No but seriously, back in the days of Round Two we were building both a browser and a web service. Why? Well, it’s actually pretty interesting when you’re designing both the content source and the user agent. It’s like choosing both the bread and the cheese for your fondue. Or chocolate and fruits. Um yeah ok, but why? Because intimate knowledge of both sides of the equation helps you fill in other variables that much faster!

Consider: 1 + x = 3.

Easy right?

So try this one on: APIs + Feeds + Drupal + Microformats + Flock + mojo, baby = you figure it out.

But I’ll tell you one thing, it’s going to kick ass.

The Out of Towner Meetup

Net2 Logo So tomorrow night is only the second ever Net Tuesday event, being put on by CompuMentor slash TechSoup. Reposting the details:

On December 13th, join Bay Area web innovators and social change agents for demos, discussions and drinks at Net Tuesday!

Ed Batista, Executive Director of Attention Trust, will show you how to stand up for your attention rights, while Seth Sternberg will demo web-based IM app Meebo.

Doors open at 6pm at Balazo Gallery at 2183 Mission St. (Mission & 18th)

Net Tuesdays are held on the second Tuesday of every month, and are part of TechSoup’s NetSquared project. Email net2@techsoup.org or visit the NetSquared site for more details on how to join the movement to remix the web for social change.

So that’s great and all, but the interesting thing (well, besides the event itself) will be the post-Net Tuesday Out of Towner meetup, being organized by yours truly for a few out of town friends. I’m thinking that once the Net2 event is over, we’ll mosey on over to Medjool for drinks, food and general tomfoolery. San Fransocializing will likely occur, but that’s up to the individual attendees.

Anyway, go sign up and bring your friends!

Offline Extension Development for Flock

Proposed Round Two Offline Action Syncing UII had an interesting discussion with Freeman Murray at SHDH last night about offline apps for use in remote areas where network latency can sometimes stretch from days into weeks for access to a “network”.

In such circumstances, you’ll have folks driving around on mopeds or busses with wifi antennae, USB drives or CD-ROMs delivering email and providing a means to getting “online”, admittedly asynchronously. Thought 28.8 was slow? Try email by bike messenger. It’s only one step above message delivery a la Paul Revere.

But in some cases, this is the best they’ve got and you can’t expect Google to trot around the world setting up mesh wifi networks for these folks (not in the near future anyway). And while some folks are working on this project and it is getting better, nevertheless, we must constantly be aware of and design for a rich offline experience.

This is especially close to me, considering I’m writing this on BART without connectivity as I head to the airport. Yes, even in industrialized areas connectivity is still not guaranteed (let alone free).

So an idea I’ve been playing with for some time is how Flock can support offline browsing and interaction, beyond pulling simple content from your cache or downloaded feeds. In the old model of the static web, the permalink model made sense and was perfectly useful — indeed, it’s still nice to be able to pull up that bar’s website when you’re wandering around Paris at 9pm, an hour late for the meetup that you helped coordinate and you’ve got no idea where it is except for the micromap saved in your browser’s cache.

But the problem is that we’ve divorced the data from the interaction layer. It’s like having your Halo saved games without having the game engine to play them. Boy, that’s a whole truckload of fun.

So anyway, Freeman and I were discussing how Flock could help with this problem. One idea that has some legs, I think, combines data delivery in microformatted XHTML pages (you’re caching it already, might as well make the data semantic and thus useful) and then allow basic interactivity with that data through extensions that are designed for both online and offline use. Thus, in the event that you’re offline, well, instead of pulling unsuccessfully from the server, it would pull from your local cache and allow you to do certain basic things, queueing your actions to be performed when you have connectivity again.

Indeed you could even use a P2P architecture for this, sharing encrypted offline action-scripts across a mesh network. When any one of those nodes reconnects, it could upload those instructions to the final destination where they’d be executed in batch. This would have the added benefit of spreading the need for connectivity across many nodes, instead of just one (like a USB drive which could get lost, stolen, confiscated or otherwise compromised). Should the actions have already been performed when the “message in a bottle” arrives, the commands would be simply ignored. There are technical details in here that are beyond my comprehension, but be that as it may, the idea is promising.

So back to offline extensions development… Freeman proposed an architecture in which Flock would ask the web app for a locally-run “servlet” that would provide similar offline interactivity when not connected. Autodiscovery would happen in the way that sites provide favicons or perhaps through a rel=”offline” link. The question though, is whether the user would need to take explicit action to install the servlet extension outright, or if, by visiting a web app (like Gmail or Basecamp), you’re implicitly expressing your interest in using the functionality of the app, whether on or offline.

I think the latter reflects a reality that I want. Installing apps on the desktop doesn’t make sense anymore, what with all my data being hosted in the cloud. So being to access and manipulate my data when I’m offline is going to become a requirement that the browser can tackle. I mean, this is the problem with solar power. You need to use your car whether it’s sunny or not, and so we’ve got rechargeable batteries, right?

Well, I think you get the point. Here’s the high-level description of the proposed solution (which I may or may not have communicated effectively):

  • microformatted XHTML cached as your local datastore
  • locally-run servlets that offer data interactivity simulating the remote data store
  • offline actions supported in extensions
  • queueing mechanism in the browser to synchronize via XML-RPC or p2p encrypted action file when connectivity is available

I probably got a bunch of the technical details wrong, but whaddya think of the general concept? Does this already exist in some other form somewhere?