Wednesday, December 22, 2004

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!

Friday, December 17, 2004

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/, 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 or -- 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 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,, openeventscom,,, 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?

Wednesday, December 15, 2004 Consortium Tackles Calendar Sharing

[Update to Calendar Federation and Syndication at UC Berkeley post]  From Brian Dear comes word of, 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 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).


Tuesday, December 14, 2004

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

"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,

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.

Friday, December 10, 2004

Accounting for Lunch with

It's the age old "problem" amongst frequent mealtime friends: splittin' the bill.  The folks at Orbeon used PayPal standalone, but talked about a better way all the time over lunch.  It's finally here: (by way of Judith Meskill)  They layer a nice bill splitting/presentment layer on top of PayPal.  From their Why JiffyBill? section:

Have you ever gone to lunch with a group of friends or co-workers but did not have the correct change to settle the bill?  Often in such situations one person will offer to pay the entire bill, and the others can pay them back later.  Sometimes a person will "forget" to pay and it is easy to lose track of the debts the longer they go unpaid.

Or perhaps you are a professional looking for a simple, low-cost way to bill your clients. Billing software can be expensive and difficult to setup and maintain.  And such packages  typically do not facilitate communication with the client.
 is here to help!  We make it easy to record a bill, including all of the items or services and who should pay for each.  We even auto divide tip and taxes for you, if applicable.  The bill is then sent via email to each of the responsible parties, who may view it, add comments, and record payments.


Thursday, December 09, 2004

Tool Tips for Entrepreneurs (or "that's soooo 2004...")

By way of Steve Shu I found Paul Allen's (of Infobase Ventures) nice little cheat sheet for entrepreneurs.  These are really Paul's proxies to ensure entrepreneurs seeking his ear have put some basics in place before contacting him.  But yes in general, they're excellent tips, and he encourages the use of some great new(ish) services.  I excerpt my favorite 4 here:

  • You must be using
    and have at least 10 connections and 2 endorsements. That way there
    is a good chance that I will know someone who knows you. It will be
    easier for us to gain mutual trust this way.

  • You must have an advisory board of 3 or more successful
    business people (preferably 6-10) who believe in you and are willing
    to meet with you monthly or bi-monthly to dispense advice and help you
    with your challenges.

  • If your company is at revenue stage, you must be using Quickbooks Online Edition
    so that I can review your financials with you as needed. This costs
    only $19.95 per month and gives 3 users access to your data. I need to
    see the real picture and not just hear about the big ideas.

  • If you do have publicly traded competitors, you must have a My Yahoo portfolio listing all their stock symbols, so you can stay current with their news and financial status.

Read them all!

Calendar Federation and Syndication at UC Berkeley

Jon Udell and others are having a discussion about the sorry state of calendar sharing, both standards activities and clients/platforms (see also Ted Leung and previously Lisa Williams).  The particular discussion is centering around Mozilla and Chandler and how to use WebDAV/CalDAV as a transport for calendar sharing.  But at the end of his first post, Jon writes:

"I wish there were a middle ground between this model and the dedicated
calendar server. Imagine a WebDAV implementation that could map
collections not just to whole-file resources, but to XML elements
within files. Given an XML flavor of the iCalendar format, you could
achieve more finely-granular control over calendar data. But the same
model would work for other applications using other XML formats. And
you'd have the option of searching with XPath or XQuery, again
leveraging infrastructure not bound to any application domain.

He summarizes nicely some of the goals of the Berkeley Campus-Wide Event Calendaring Project, headed up by Allison Bloodworth and others from Berkeley and the CDE.  The project was motivated by the fact that there are something like 75 different calendars at Berkeley, and there's no way to easily share events or create user-friendly views or feeds.  (BTW their work just won the best presentation/paper award at XML 2004 -- kudos!) 

So their focus is to apply Document Engineering techniques to create the XML data model that accomplishes Jon's wishes, and then apply model-based app techniques using XML/XSLT/XSD to create software and glueware to manipulate those events (eg., create calendars).  Borrowing from their XML 2004 presentation, they summarize their solution:

  • A standard XML data model of an Event (Scott says: think UBL for events)

  • A centralized repository of Event information

  • A calendar management tool

    • Manage events in the repository

    • Customize a visually compelling, dynamic web-based calendar

  • A design for a system architecture allowing XML feeds to and from the repository for calendars who choose to maintain their own website & repository

They have the XSD schemas and have some software built.  This is important related work if you're interested in calendar sharing and syndication -- check it out.

[UPDATE:] From Adam Rifkin's excellent Microformats post I found hCalendar:

"hCalendar is a 1:1 mapping of iCalendar to semantic XHTML. ...bloggers often discuss events on their blogs -- upcoming events, writeups of past events, etc. With just a tad bit of structure, 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."

This Microformat philosphy is pragmatic == I like!.

Tuesday, December 07, 2004

BzzAgent and Word of Mouth Marketing: Ripe for Open Source?

Fascinating recent NY Times article "The Hidden (In Plain Sight) Persuaders". Read this one with awe and a hint of unplaced fear.  BzzAgent and a few other firms "hire" small armies of every day folks to stealthily promote products to their friends in casual conversation. Fascinating because while these people are hired (or more correctly "admitted") to become BzzAgents, they don't do it for $$. Instead the program taps in to people's inner needs to "belong to something bigger," be the "first kid on the block to know about XYZ," and maybe even as a form of therapy:

"In essence, they told Balter that there was nothing wrong with the
rewards; it was just that the rewards weren't really the point. Even
now, only about a quarter of the agents collect rewards, and hardly any
take all they have earned." and,

"What, I asked her, if not the potential to get some free prizes for
effort, made her bother to volunteer with BzzAgent? First, she told me,
she gets the chance to sample new products shortly before they hit the
stores, so she gets to feel a bit like an insider. Second, she has
always liked to give people her opinion about what she's reading or
what products she's using, and BzzAgent gives her more to talk about.
Third, if she does like something, then telling other people is helpful
to them. So participating is both a chance to weigh in and be heard,
and also something close to an act of altruism."

and a woman speaking about her husband's involvement as a BzzAgent,

"She said she thought it had made him more open to other people. He used
to be the kind of guy who just hated to call a mechanic about a noise
the car was making; he would wait until the car actually broke down and
he had no choice but to bother someone about it. He was in a shell. But
that has changed..."

Nothing wrong with those motivations. Sounds like much of what drives open source software. And apparently the program works like gangbusters for BzzAgent's clients. But for how long?  It's probably just another immunity people will erect to deal with marketing overload (see also Marqui's use of paid bloggers), but this one could prove a hard strain to resist.  Lots of good discussion and commentary going on at Hugh Macleod's post around these issues.

So what's the problem, other than worrying about being duped by a BzzAgent, and adjusting to yet another marketing channel?  From the same post, Hugh offers one opinion,

"Jack, I'm not dissing BzzAgents because I think it's "wrong" or
"immoral". If people want to squander their social capital on pimping
supermarket-level products, fine. It's their life. I think BzzAgents is a "crap" idea simply because it doesn't solve
the client's fundamental problem i.e. nobody sincerely wants to talk
about their product."

But it apparently does solve this fundamental problem of kick starting chatter for BzzAgent clients, even if we're uncomfortable with it. So until we're immune or 60 Minutes outs the program, after which BzzAgents run the risk of becoming social pariah's when discovered, it will continue to be a viable sink for marketing dollars.

But there is a kernel of a wholesome, everyone-can-get-behind idea here. An "Open Source BzzAgent" approach comes to mind, where people honestly excited about products can get hooked up with other such folks for laughs and rewards (eg., I'd sign up to somehow formalize or benefit from my tireless Flickr invitation habit). This would have to be very grass roots and bottom up/decentralized, but sounds doable with enough free time and experimentation. This idea and/or project has to be out there already -- I'll hunt around and report back.

Monday, December 06, 2004

Browser-Based Application Architectures

Oliver Steele of Laszlo Systems recently posted a good history of various browser-based application architectures.  Most interesting is his definition of "client-side web applications" in contrast with Model 2 (or Model 2X) and other evolutions he calls Model3 and 4:

"In a client-side web application, a single web page (or its application equivalent) is downloaded.  This application can generate a sequence of views on the client.  Sometimes the client application requests a new dataset — typically in XML, or a protocol (RPC, SOAP) that is serialized to XML — but this dataset is read into the client application; it doesn’t replace it."

While a good definition and fine architecture, Oliver is making client-side web applications sound newer than they are.  Wasn't this the whole idea behind Java Applets?  Granted the first applets didn't have all the architectural pieces right (eg., port 80 issues and server architecture needed to be home grown), but many people who committed to applets in the late 90's ended up exactly as Oliver mentions.  At Inovie our entire TeamCenter product was a judicious mix of java applets (Swing -- gag!) and HTML, all done as HTTP over port 80.  For portions of the app that really benefited from a rich interface, a single applet was loaded, and as new views were requested, the applet communicated with the server to get new data. Great post, just adding some additional context.


Friday, November 26, 2004 -- Long Live New Music!

Among the many joys of becoming parents, my wife and I were recently discussing some of the sacrifices of parenting 2 children under 2, including giving up live music for the time being.  From the many of fun things we used to do out-on-a-thursday-or-friday-night, we singled out seeing live bands as our most missed.

For music fanatics, live music is a package deal. it's part of a ritual of too-frequent trips to the record store, sitting through (and often loving) lots of opening bands, catching up with friends between acts, and shooting the breeze about ever newer music and upcoming shows. But by moving to a new city, away from family, while simultaneously starting our own little family, we've effectively taken that package deal off the table for now.

But beyond the joy of live performance, the pleasure of discovering new music isn't something we ought to have to give up. However without the exposure and exchange part of the package, we're missing out on the discovery part as well.

That's where fits in. is a service that lets you build your own radio station by adding albums you like or think you like, and then lets you stream them as your own "personal radio." But while you're listening, they're taking notes, both from your station and from your existing music library via an optional media player plugin.  From these stats, they start recommending neighboring stations, introducing you to other people with complimentary taste. You can then listen to your neighbors' stations as well!  In's own words,

" is a personalised online radio station that plays the right music to the right people. Songs spread from listener to listener.
You get your own online radio station that you can fill up with the music you like. This information is used to find users who are similar to you. With this information can play you new artists and songs you might like."

I have used music info/recommendation sites like epitonic and allmusic in the past and found them very helpful, but they always seemed incomplete.  I never integrated them into my music routine, more just for exploring or dabbling.  But by 1) giving you access to tons of free (nearly) streaming music and 2) letting you connect with and listen to the collections of people with similar tastes, has found a magic formula. The magic, as Suw Charman points out, is how they've skillfully integrated a social network to stand out from the crowd,

"I consider both of these sites to be social networking sites, even
though it would be possible to characterise Last.FM as a music site and
Flickr as a photography site. But both sites have at their heart not
the music or the photos but social networking and the sharing of
personal information. Without their social networks, both sites would
be pointless."

So now with my station I'm enjoying music I already know or know to check out, and from my neighbors' stations I'm discovering new music that's been more often a fit than not. Plus now that I'm donating a small amount via PayPal (I chose the amount), I can share my personal radio with the world, which completes the sharing cycle both inside and outside the network.  Check out my personal radio button to the right, or click: ehick radio

So while isn't babysitting for us until 2am, it's helping us enjoy, discover, and share new music in a natural and familiar way, which is worth a lot!

Tuesday, November 23, 2004

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.

Saturday, November 06, 2004

Arielle Maria McMullan

I'm proud to announce the newest member of our family, Arielle Maria McMullan!  "Little" Arielle arrived at 9lb 13oz, 21.5" long, and everyone is doing great. 

My already sporadic postings might take a bit of a hit over the next week or two... ;)

Wednesday, November 03, 2004

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.

Thursday, October 28, 2004

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 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!

Wednesday, October 27, 2004

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.

Friday, October 22, 2004

Build vs. use Open Source? can Help.

Google for open source projects has appeared:  Looks like they scoure open source repositories and let you search for code by keyword, language, or license. 

But even more interesting is their "Build vs. Integrate Open Source" tool, which allows you to ballpark the cost to develop a given component yourself using some of your own cost metrics.  For example, here's their assessment of the cost to duplicate the popular Hibernate project's functionality. Good stuff.

Wednesday, October 20, 2004

ehick Migrating to

I've decided to migrate my blog to From now on, I'll be hanging out at

For syndication purposes, my Feedburner RSS/Atom XML feed is still the same:

Open Source Inside?

I had the pleasure of meeting Palamida founder Ray Waldin recently. Palamida is addressing a growing problem for ISV's: "what sort of open source might we be using, and are we adhering to the licenses?"

With a smorgasbord of ready-to-integrate code and a the proliferation of licensing terms, it's getting harder to ensure a complex, long-lived software product doesn't mistakenly run afoul of any licenses. Both Palamida and their competitor Black Duck Software are bringing a welcome service to market -- best of luck Ray!

Monday, October 11, 2004

The Dells of Open Source, Part 2

A little over a week ago I blogged SourceLabs, a newly minted Open Source aggregator aiming to sell support and services around productized open source components that have affinity. I expected to see a flood of these (it's a good idea after all), and last week we were indeed treated to another: SpikeSource. Turns out Kim Polese is CEO and the company was incubated and funded Ray Lane and Kleiner Perkins. Nice start!

Digging deeper, an interview with founder Murugan Pal (former Asera CTO) at TheServerSide quotes him as saying,
Almost all the other companies in this space talk about the same thing--but what are the objectives metrics that they are measuring? Is it integration? Standards compliance? Regression? Negative tests, boundary tests. How can you integrate these tests in multiple dimension? How about IP rights classification? Security threat assessment?

But thinking about this for a few seconds longer, I see some cracks in this foundation. For starters protecting the investment Murugan mentions above. Once SpikeSource's LAMPJ stack becomes known as versions a, b, c, ... j of open source components 1, 2, 3, ... 10, and this info is widely disseminated, why pay the subscription? Certainly some will, but how many, and how much can you charge? And then there's the low or no cost competitors, who "knock off" your package with their own free distribution the day after each new release. I can picture tiny me-too companies shadowing SpikeSource's "products" and getting a free ride off their rigorous processes.

I'm obviously glossing over a whole host other value-add they have in mind. However in general, the basic value proposition of selling access and support to a, "vetted and test set of open source software as a product" seems better suited to software higher either higher up the stack, like Gluecode's portal server, or to a "sell the services" model, like JBoss or Orbeon.

Wednesday, October 06, 2004

Excite co-founders launch JotSpot -- getting INTERESTING!

I've been reading Joe Kraus' blog Bnoopy on entrepreneurship since he started it last month. His posts recounting lessons learned as Excite's co-founder have been entertaining gems for entrepreneurs. Inovie Software, the San Diego-based business collaboration company I founded in 1997 and later sold (now at UGS), was a minnow compared to Excite. Even so, we faced most of the challenges Joe describes.

So given my background and interest in business collaboration and entrepreneurship, I was very excited to read that Joe's new company, JotSpot, is joining SocialText to bring the power of wikis to a broader audience. Nice!! Ever since I first used a wiki I've been hooked. The first thing I do now when getting involved in a new project is ensure a wiki is in place -- I don't want to work without one! A Wiki provides a type of ad-hoc, free-form collaboration we never achieved with TeamCenter. If I knew then what I know now, I... Nevermind! ;)

Dan Farber writes:
JotSpot is based on wiki technology, which lowers the barriers to creating Web-based collaborative applications. JotSpot extends the concept. "Wikis run out of steam in that they don't allow you to add structure or build apps," Kraus said. "On the surface, JotSpot looks like Wiki and you can use as a wiki, but it allows you to start with unstructured data and add structure incrementally."

That's the stuff right there. I'm really looking forward to seeing where SocialText, JotSpot, and some in open source (e.g., XWiki) take this "Application Wiki" concept.

ps. Jon Udell has blogged a Flash Demo for anyone interested in seeing JotSpot in action.

Web 2.0

I'm enjoying reading some of the coverage of the Web 2.0 conference going on this week. Coverage, pontifications, thought provoking soundbites, and new company and product launches are flying out fast and furious! Many ideas great to silly for sure -- I should have gone :(

One particular new company/product announcement (blogged by Jeremy Zawodny) that caught my eye was Rojo, a new web-based "feed" aggregator. I'm overwhelmed by my current 82.6 (and growing daily) sources of news, blogs, commentary, etc., and Rojo sounds like a promising solution. Not exactly sure yet how it compares to other similar products like Bloglines, but i'm currently evaluating both and will post some comments soon.

Wednesday, September 29, 2004

The Dells of Open Source

One common way to innovate is to combine two or more different things and create something new that is more than a sum of parts. This happens in music all the time. Musicians take what they like -- their influences -- and combine them in their own way. Sometimes you get literal combinations that create little genres like "trip-hop," "ambient dub," our "sadcore," but most often you just get bands that, "sound like a faster mix of band X and band Y."

Sooo... what do you get when you combine Dell and Open Source? As covered by CNET in Industry veterans bet on open-source model, you get a startup called SourceLabs. SourceLabs looks to make money by efficiently sourcing, pre-integrating, and selling solutions made from low-cost ($0) open source software packages. I like the analogy, and certainly being the "Dell" of anything has a nice ring to it.

Now this is nothing that Redhat and others haven't done for the likes of Linux and other now established open source products. So in a way, it's just more of the same good stuff -- giving corporate adopters of open source "one throat to choke." But still, I like thinking about this in terms of Dell, rather than just purely in terms of selling support and peace of mind. Dell makes money combining commodity hardware and offering computing solutions, Redhat does the same for operating system, and SourceLabs will pre-integrate and sell open source "stacks." No word yet on which or how many stacks.

My big question is how does this scale? Can SourceLabs, or someone like them, go big and become the Amazon of open source? Or just focus on a core set of applications, like Linux (or Dell)? I expect to see many more companies like this in the near future.

Wednesday, September 22, 2004

Open Source and the Transistor Radio?

I recently listened to Clayton Christensen's presentation from the 2004 Open Source Business Conference called "Capturing the upside." (Actually I streamed it from Doug Kaye's wonderful IT Conversations site).

Clayton compared the adoption and success of open source to Sony and their first transistor radios and the first Japanese autos exported to the US. Basically the early transistor radios were feature-wise pitiful when compared to the existing products on the market. However, they succeeded because they addressed a new market: young people who would put up with the static and poor reception because they could actually afford them, combined with the fact that they relished the ability to listen privately to there rock music, away from parental earshot. Existing radios, while high-quality, were big and expensive, and thus out of reach of most teenagers. So while the existing market supposedly clamored for ever-more features, the "good enough" transistor product proved that features and functionality had gotten ahead themselves, and the new "poor quality" upstart came in to open a open a new market. And then of course the transistor radio slowly improved, and the rest is history...

Clayton points out that open source is doing the same thing today. Beyond the now established open source infrastructure standouts like Linux, MySQL, Apache, etc., there's a newer crop of applications like SugarCRM, Gluecode, and Firefox that have also started out humbly as "good enough." Many people just aren't served by feature-saturated, high-priced commercial offerings. Instead they're finding relatively immature open source alternatives to be good enough, and also lower TCO or be more customizable or... I'm now looking at innovation and market evolution with respect to open source with a new twist -- thanks Clayton!

Wednesday, September 15, 2004

Angel funding coming back?

I went to SDForum's VC SIG tonight to hear an angel investor panel discussion on the climate for angel investment. The general consensus was that the angel community is slowly but surely moving out of the "fear" mode it has been in since the bubble burst and earlier angel rounds were getting "crammed down" when VC's came in on down rounds. Interestingly, the angel deals that have been getting done during the downturn have consisted of larger groups investing smaller amounts ($5-25k each).

But the bottom line is deal flow is supposedly picking up, and investments are getting done, mostly in the $1M-$3M pre-money valuation for prototype to nascent revenue companies (the panel admitted it's hard to generalize valuation). And the key to determining whether to fund the company: whether a VC will follow after new milestones are hit. The event was standing-room only and well run -- I look forward to going back again next month.

Tuesday, September 14, 2004

Minor Confusion over Open Source BPEL

Paul Brown sent me a heads up about the recent Infoworld article on open source BPEL (ObjectWeb plans open source BPEL server). The article also mentioned the recently announced Open Integration Suite, and mentioned that Orbeon had also recently contributed a BPEL Server to open source:
"It won't be the only open source BPEL server available. Orbeon Inc., a systems integrator in Mountain View, California, released the source code for its BPEL server a few weeks ago, along with several other components that comprise the Orbeon Integration Suite."
Unfortunately that's not quite the case... Orbeon did found and seed the Open Integration Suite project with a contribution of it's OXF product line, but it will be sourcing other complimentary components, including a BPEL Server, from other open source projects. The good news is that eMaxx's is now a candidate for inclusion in the suite! (Disclaimer: I am currently on Orbeon's board of advisors.)