CivicSpace Rocks

Last week I had the pleasure of meeting Zack Rosen, founder and director of CivicSpace Labs.  CivicSpace is a Drupal-based platform that is being billed as a, "grassroots organizing platform that empowers collective action inside
communities and cohesively connects remote groups of supporters."  Translated that means open source collaboration software to help people connect so they cann campaign and press for change.  "The" public sector platform.  Or if that's not clear, I guess knowing it's the 2nd generation of software written originally for the Howard Dean for President campaign, and you get the vibe.

This is one of the coolest projects I've ever run across!  Collaboration software for all the people trying to change the world for the better.  Of course "the better" depends on your notion of what needs fixing, and over coffee we also discussed people on "the other side" (my words) using CivicSpace to do fun stuff like organize to squash women's rights or keep "those people" from threatening our communities with "their lifestyles." etc.  But that's fine too -- let the best organized pushing the soundest principles win!  Enough of that -- not my typical blogging topic...

People are using this stuff too.  Currently the live sites page lists 147 sites.  The model is to create the software as open source, and then sign up ISPs and consultants to host at costs low enough for cash-strapped grassroots orgs to afford. Zack's recent CivicSpace as a Platform post discusses some of the issues they face going after such a broad customer base, but I agree that this is doable because there are many passionate and capable people to tap.  It helps at this stage to have funding, which they do (some foundations and a Bay Area VC), and conviction, which I can say that Zack has in spades.

CivicSpace is looking to grow the community so if you need this service or want to get involved, check it out.

JotSpot Company Blog

It's official: JotSpot just started a company blog.  In addition to my personal posts here, I'll be contributing more JotSpot-specific stuff there.

JotSpot in 2005!

I love driving at night.  With the kids lulled to sleep by the harmony of rain and freeway drone, we decided late last night to skip our planned LA layover and power all the way to San Francisco, downpour and all.  It was a great way to cap a 2-week retreat to San Diego.  With the exception of 10 minutes of SNOW on the grapevine, it was easy sailing all the way to our 5am arrival, and my wife and I used the time to reflect as well as look ahead to 2005.

Jon Udell is calling 2005 the Year of the enterprise Wiki, and I couldn't agree more!  In addition to hanging out with friends and family over the holiday, I accepted an offer to join JotSpot, the Application Wiki company.  Since first blogging optimistically about JotSpot following their October beta launch, I've gotten to know their service and spent some time noodling, and have been both very impressed and very inspired.  So I'm incredibly excited to be joining Joe and Graham and the rest of the JotSpot team.  I start tomorrow -- more details after I get going.  Right now I couldn't agree more with Jon's sentiment:

"As the Wiki phenomenon enters its second decade, it’s hard to predict just how the technology will evolve. Two things seem
certain: Wiki culture will continue to thrive, and enterprise users will continue to seek lighter, easier collaboration tools.
Sounds like a winning combination."

So is this OpenEvents?

Greetings from sunny San Diego.  Morning after posting Google/Internet Archive, Meet Mr. Event we threw the kids in the WRX and headed south for some R&R with friends and family.  So now that I've snuck into the local wifi cafe I'm very gratified to discover more people, projects, and conversations about this events vision.   For sake of clarity, from now on I think I'll start using Marc Canter's OpenEvents moniker -- seems like the same/right philosophy, and appears to still be a green-field project.

Here are just a few additional links I've found related to OpenEvents vision, although I haven't had time to fully dig through all this yet:

• EventsML, an IPTC effort for an XML vocab standard for, "event publishing, event planning, and event coverage."



• ESS  the "Event Share Specification" for, "assisting in the publishing and distribution of event (e.g. meetings,
  conferences, holidays) information."



• WhizSpark's broader thoughts on social networking and events



• CivicSpace are some veterans of the Dean campaign building a, "...platform that empowers collective action inside
  communities and cohesively connects remote groups of supporters."



• Who What When Where XML is headed up by Hanan Cohen, who believes, "people should be able to publish where and when they will be, and
  others should be able do discover those facts and arrange to meet them."

Among many others!  I haven't yet digested the comments/trackbacks/new info, but clearly people are looking and addressing events from many different angles and biz models. And it's all "just software," so it's doable.  Hard part is herding cats, aligning interests so collaboration, real work, and follow-through happen.

Still getting my mind around all this, but I'm looking forward to continuing to connect with interested and engaged parties.  But my main event right now is quality time with family until the new year, so I think I'll idle my mind and keyboard until '05.  Have a great holiday if you're still reading this!

Google/Internet Archive, Meet Mr. Event

In the spirit of "tags are the new black," here's a vision for how event and calendar management should be handled by 2006:  Wouldn't it be grand if all events in the world, from a garage sale in Lexington to a tech conference in SF, could be automatically discovered (Google), stored in one central, public domain, web services accessible database (Internet Archive), where the events could then be categorized (Topix), community rated and recommended (Amazon/Netflix/Last.FM), personally tagged (Flickr/del.icio.us), and ultimately custom-fed (PubSub) directly to your calendar device of choice (Calconnect)?

Cool, where do I sign up? I Could have used this to promote our now defunct SF Web Services SIG, which was done "by hand," one site/email list at a time.  Not to mention the relative difficulty when you go searching for a good event in your area...(not to knock workit.com or craigslist.org -- thanks guys!)  But I want this uber event service now!

So past and current pains combined with threads followed, dots connected, and small wheels turned since last week's Berkeley Calendar Project post create this mashup event service vision.  Actually, people are talking about this vision in so many words.  Dr. Bob Glushko and Allison Bloodworth et al are leading part of the effort by trying to bring sanity and sharing to the 80+ event calendars of UC Berkeley.  Tantek Çelik and other folks working on hCalendar talk about using your web site as your API,

"...bloggers can discuss events in their blog(s) in such a way that spiders
and other aggregators can retrieve such events, automatically convert
them to iCalendar, and use them in any iCalendar application or service.",

Kevin Hughs at zLab writes,

"The potential for applications that make use of networked, time-driven information is
huge. Today's portals have no concept of event personalization or collaboration.
Today's applications have only the most basic concept of integrating with or subscribing
to time-driven data. And there are no providers of horizontal event-based services. ... Software and
the Internet has freed online music from its proprietary data and application jails, why
not do the same with events? The traditional calendar interface deserves a overhaul.",

Marc Canter chimes in,

"I wonder if they wanna help put up shared XML servers of Events - scraped from throughout the web?",

the Calconnect.org folks proclaim,

"Our members’ intent is to enable calendaring and scheduling tools and applications to enter the mainstream of computing," said Dave Thewlis. "After email, the World Wide Web, and instant messaging, calendaring and scheduling capabilities are what business people and consumers will really care about.",

and many many others I have yet to discover [add more in comments].  Yes, A few people are already doing similar stuff, like upcoming.org, rsscalendar.com, openeventscom, whizspark.com, evdb.com(?), and most likely Google Labs (?) [any more?].  But for starters, from what I can glean these efforts rely on people coming and manually submitting events, rather than auto-discovery and aggregation via spidering --> problem of db critical mass.

So let's make one!  Let's combine something practical and "standards-based" (ie., iCalendar/XHTML) like hCalendar, but extend it with the rich UBL-inspired semantics of a Berkeley Event Model.  Now that everyone agrees, let's move one.  We need open source tools so event producers (even for my yard sale) can list their events on their blogs/web sites, like they already do, but also be sure to use valid markup.  (Note: people are motiviated to promote their events -- no prodding necessary)  Then we need an open source spider, a bunch of disks and some linux boxes, a REST API, open source recommendation and reputation/rating/tagging engines (eg., tweaked openscrobbler + ??/??/??), and some pub-sub and feed generators.  And to top it off, let's make the database and service usable by all (eg., some kind of creative commons), so we can unleash the creativity of the world to build custom interfaces via our web services API.  Easy stuff in these days of inspiration from  Amazon/Google/PayPal/eBay/SForce, open source, wikis, bugzilla, and PayPal donate buttons.  Right?

The law of ideas says that at least 6 (or is it 8?) people are either building or have already built this exact event service -- and I haven't found it yet.  Any pointers?  If not, anyone want to build this monster?

CalConnect.org Consortium Tackles Calendar Sharing

[Update to Calendar Federation and Syndication at UC Berkeley post]  From Brian Dear comes word of Calconnect.org, a new consortium to promote IETF's calendar sharing standards.  From the press release:

"This isn’t simply about calendar programs," noted Patricia Egen, Interop manager and member of the Board of Directors, who originated the idea of the Consortium. "This is about seamlessly connecting your calendar with others so that your professional and personal life runs more smoothly."

Infoworld notes, "members of the consortium include Duke
University, MIT, Stanford University, the University of Washington, the
University of Wisconsin-Madison and the University of California,
Berkeley. The group also includes NASA's Jet Propulsion Laboratory, the
Mozilla Foundation, the Open Source Application Foundation and IT
vendors Oracle Corp., Novell Inc., Meeting Maker Inc., Symbian Ltd. and
Yahoo Inc."  No Microsoft or IBM...

I applaud this effort and know the consortium has comprehensive and important goals, but there's still a burning question in my mind: given their stated 3-5 year time frame, what kind of ad-hoc, bottom-up, microformat (eg., hCalendar) type "standard" might emerge?  I guess we'll just wait and see... (eg., EVDB)

Video Blogging for Grandmas and the Workplace

From Stuart Henshall I discovered Userplane's free AV Blogger service:

"Userplane's Audio & Video Blogger service is an easy-to-use
system allowing the creation of audio and video recorded messages for
use in blogs, websites and email.

The Userplane AV Recorder
application will automatically detect your camera and microphone, and
allow you to record up to a 10 minute recording. Each recording is
streamed from the Userplane servers, and can be copy-and-pasted into
your web media."

AV Blogger (and apparently others like videoaddon.com) seem to have lowered the bar to capture, store, and broadcast video using common tools and copy/paste code snippets for websites (and their wiki and blog nephews!).  This is a serious boon for distributed teams, grandparents (see Belen's picture blog), eBay sellers, and everyone in between.  (Uh oh, I'm envisioning a thousand talking heads bobbing through the blogosphere...  Maybe we ought to stick to text! ;)

[UPDATE:] Marc Canter points to me-tv (blog), a browser-based feed reader for video in the spirit of podcasting.  This appears targeted for those creating/hosting their own video files, unlike the AV Recorder service, which takes care of everything for you (you just need a webcam).

   

blogazul, a Twist on the Semantic Wiki

I had the pleasure of meeting Jean Sini yesterday.  He's behind a new project called blogazul, which in its current state is an integrated weblog/wiki system similar to SocialText and SnipSnap.  The interesting twist is what Jean is calling a "semantic wiki," but with a different interpretation of Semantic from Platypus Wiki or discussions elsewhere.  Blogazul is leveraging XML Schema instead of RDF.  From blogazul.com:

"The idea is quite simple: while we maintained the “edit-in-place”
principle that makes wiki so easy to use, we added a whole new
dimension: a wiki page can now be structured in XML. And instead of
typing that XML directly, or viewing it in raw form, it is presented,
both for reading and editing, through style-sheets. The goal: you focus
on the content only, and you get the structure, the rich layout, and
the automated functionality derived from the fact that the data types
of the content are known. Just like smart tags, the semantic wiki style
sheets, based on the fact that there is an address in your page,
exposes automated features like yellow pages, driving directions, maps,
etc."

This is an interesting architecture that follows a more formal model-based approach to programming a wiki, which I talked about previously in my Big Red Button post.  Definitely similar in spirit to what JotSpot, Twiki, and XWiki are doing RE: creating application platforms on a wiki base, but instead of user-friendly scripting or programming wiki objects, XML Schemas and XSLT drive the action.

Intellectual Agility Powers Collaboration

Read two interesting and very different articles recently on the behavioral side of collaboration: CIO's A Travel Guild to Collaboration, and Dave Pollard's How We Can Improve Collaboration.  Both try to address why collaboration works, why it's hard, and why employing a collaborative approach to get stuff done eludes many teams and organizations.

CIO Magazine's straightforward A Travel Guild to Collaboration mainly addresses B2B collaboration, as opposed to ad hoc collaboration in the trenches.  It's a good, basic summary of challenges to collaboration:

• win-lose mentality and mistrust



• negotiating ownership of resulting IP



• security & springing leaks in the data fortress



• integration issues faced when systems need to talk.

As well as common tips like:

• clarify mutual value



• build trust



• provide the right tools



• value of independent 3rd party tool hosting. 

Not a ton new here, but good quotes and case study references always reinforce what we ought to be remembering.  In particular these two quotes from MIT Medial Lab's Michael Schrage added some spice,

"Having lawyers drive collaborative initiatives is like having drunk drivers drive Pintos on New Year's Eve in Boston," and

"It takes a shared space to create shared understanding.  If there's no shared space, there's no collaboration.  Period."

A more passionate presentation was given by Dave Pollard in his How We Can Improve Collaboration.  He covers with a number of general points, some of which echo the CIO article:

• competitiveness can obfuscate collaboration



• we're really good at collaborating in emergencies --> it's instinctive



• when collaboration is working, it's fun



• collaboration must be practiced and requires course-correction



• recognition people contribute at different levels and with different styles

He also rips into some anti-collaborative realities that everyone loves to hate, like,  "Hierarchy, our cult of leadership, and the inflated egos of
managers." He actually goes overboard in vilifying leaders as being inherently anti-collaborative when he says, "I would hazard a guess that excellent collaboration skill is almost
entirely absent in those we call 'leaders' in all aspects of human
endeavor."  (Not sure why he used such a broad brush to paint leaders?)

But most interesting is his discussion of "intellectual agility" as a core driver and prerequisite for successful collaboration. He defines intellectual agility by contrasting a failed collaborative experience with a successful one:

"What was different in this earlier, failed attempt at collaboration? In my opinion, John and I exhibit what I would call intellectual agility,
while our colleagues in the earlier session do not. .... Intellectual agility is the
ability to allow yourself to fully understand, appreciate, adapt to and
integrate others' ideas and ways of thinking with your own, and, on
occasion, to abandon your own preconceptions quickly and entirely when
presented with compelling evidence of a better answer."

He's spot on.  Intellectual agility is what makes a collaboration valuable, and moves it beyond a coordination or info sharing.  And it is hard to come by --> collaboration can be difficult!  But here's were we need intellectually agile leaders.  They're out there, and they'll multiply quickly from network effects if they and their organizations following Dave's advice to practice, value and reward intellectual agility and a collaborative approach to getting stuff done.

GroupWare to TeamWare to SituatedWare: Wikis Get the Platform Right

Wikis for Content

I've been writing quite a bit about Wikis lately. The first time I used a Wiki, I knew I had come across the most practical tool for ad-hoc teams to date. You know, the bread and butter of meeting agendas, minutes, capturing brainstorms, team research, team to-dos, etc. I collaborated on content, engaged in simple processes, and maybe even used a form or three, but never got too fancy.

Indispensable, addictive tools for sure, but for some reason I didn't put wikis within a larger functional or historical context. I noticed and followed the commercial offerings from startups like SocialText and Atlassian, but despite plugins and forms, I continued to keep them politely tucked on the aisle and shelf of "collaborative web sites for team content." (Maybe it was their continued association with blogs, or focus on wiki markup?)

Wikis for Applications

So when I caught wind of JotSpot's "application wiki" positioning and vision, I was intrigued. It's a vision shared with forward-thinking open source wikis like XWiki and TWiki, but I'd never seen it articulated so clearly. After beta testing Jot a bit, I started to get it. In my last post I even dotted a line between an application wiki and a platform for model-based/model-driven application development -- they seem like a promising match.

Wikis for Core Infrastructure

So now after digging in to Jot even more, and also letting Clay Shirky's idea of Situated Software (software purpose-built for a very small group of users) sink in (with help from techdirt and Jon Udell), my mental curtains have opened still further.

GroupWare, as pioneered by Lotus Notes, was a big and difficult email-centric enterprise collaboration product. But unless you were an IT programmer, you and your team were out of luck as far as carving out a little custom corner of Notes for secure, private collaboration. This gap was targeted by the first generation of "Internet team" products that came on the scene in 1997 to help pioneer the TeamWare market. Products like Inovie's TeamCenter (my company), Netmosphere's ActionPlan, and Instinctive's eRoom had missions to serve ad-hoc, browser-empowered project teams, who would come together, collaborate and share project plans and documents, and then disband. Some were more focused on collaboration, some more on project management, but they all pre-integrated a set tools for working with tasks, documents, reports, tabular data, chats, etc. Many more have come since, including OnProject, Basecamp, Groove, and Lotus Team Workplace to name a few.

The limitation with these TeamWare products is their strength: they nicely pre-integrate sets of tools that certain teams find very helpful, but if your team can't or doesn't care to work within the processes best-served by those tools, you're out of luck! There's never been a TeamWare platform that gave most teams immediate value out of the box, but could then be easily programmed to enable self-service, tightly integrated mini-apps for specialized needs (ie., Situated Software). From what I've seen of JotSpot, it's got the juice to be this platform (looking forward to understanding capabilities of SocialText, TWiki, etc., as well) :

• Pre-built apps and templates to provide TeamWare's hit-the-ground-running with familiar processes and best practices


• Well thought out, easy to use, easy to copy, tweak, and evolve data and programming model in JotScript, to foster a development community and capture the long tail of Situated Software


• Blank-canvas approach of classic content wikis for content collaboration, web linking, and document sharing


• XML-centric core to avoid creating a big island of information, and perhaps even acting as a "good-enough" platform for integration a la composite applications


• Everything gets revision controlled (even the apps and documents), so everyone can sleep at night.

Sure there are always hurdles around culture, application management, directory integration, etc., but these strike me as solvable over time given the ingredients that go into application wikis. So whether application wikis grow up to become the platform for the diverse needs of model-based apps and/or TeamWare and/or Situated Software, their future looks bright.

Application Wikis: Powering the 'Big Red Button'?

Bob Glushko, director of UC Berkeley's Center for Document Engineering, has a saying that goes something like, "Just take your application's XML schema, give it to the Platform, and press the big red button. Done, application created." That was the vision behind the Center's "XML Application Platform" project I led last year. It's model-based application nirvana, where the data model is explicit in the Schema, and through annotations and maybe some additional metadata, an entire web-based application is created automatically. And it's hard to do. We built a prototype on Orbeon's Presentation Server, which can be thought of as a next-generation Cocoon, but alas a 2 semester research project can only get so far...

I've finally starting digging deeper into JotSpot, the new-wiki-kid-on-the-block. They're positioning as an "application wiki", and I'm now seeing what that actually means. From what I see so far they've done a nice job of making it very easy to have 2-way integration with enterprise data and applications, whether through web services or RSS (e.g., see Jon Udell demo that includes integrating with SalesForce.com). David Mattison writes:

The problem, though, is that the wiki, by itself, has limited programmability. You can enter text and make links, but that’s not quite the same as building an actual application. While both SocialText and JotSpot appear to offer additional components that they’ve built, the next stage may be for them to start promoting easy integration with additional outside apps and components developed by others. If you start thinking of the wiki as less an open whiteboard for text, and more an open workbench for integrating web services-based applications however you’d like, things start to get much more interesting.

So if JotSpot and other "application wikis" like SocialTextand XWikican come up with rich enough scripting languages, the wiki becomes the natural platform to power the Big Red Button Platform. The real work comes in creating the XML models that capture the semantics of access control, workflow, and some of the other aspects that real apps require. But much of that stuff is presumably already in the Wiki! So with some thinking and work, I can picture these aspects as little JotSpot applications/services that get stitched together with some XML configuration and viola, we've got XML schema-driven applications -- and a Big Red Button!

Middlespace: Context for Discussing Collaborative Software

Ross Mayfield presents a few case-studies to help explain what he calls Middlespace

Bottom-up phenomena has accelerated in recent years because of social software. A relatively simple decentralized pattern of enabling more connections and groups to form has complex results. These results (for example: open source, the long tail, heterarchical organization, emergent democracy, wikipedia and participatory media) hold great promise. Bottom-up production is driven by social incentives, comes at a lower cost, realizes economies of speed and enhances quality through diverse and greater participation. Despite these benefits, Bottom-up phenomena is perceived as a significant risk because the dynamic of control is uncertain. But every risk has its rewards and can be managed if known.

Where the bottom-up and top-down meet -- middlespace -- is the realm of policy, metrics, incentives, cooperation and sharing control. The practice and politics of this realm are best explored through new case studies. [full post]

Acknowledging and defining this 'middlespace' provides context and frames the discussions that must take place when collaborative software spreads beyond early adopters into an organization's mainstream.