Collaboration SIG Kicks-Off Nicely

Thanks to everyone who came out Monday night to the  kickoff get together of the new SDForum Collaboration SIG.  I forgot to count but judging from the pictures, about 50 folks come out to meet, mingle, and hear our panel’s perspective on founding, funding, and growing a successful collaboration-focused company.

David Glazer posted a comprehensive transcript of the event, and there’s also a podcast available.  Four days later, three things stand out from the panel’s discussion:

• The SMB market remains huge and untapped for collaboration tools and services.  Search engine marketing and software as a service are two promising approaches to profitably marketing and selling into this collection of niches. 


• Keep It Simple Smarty.  Described variously as the “grandma test” or the “mom test” (what’s with picking on the ladies?), if people can’t start using your product or service and get some value out of it without being trained or reading a manual, don’t bother.  This is the obvious one that most everyone ignores to their peril.  If this isn’t keeping you up at night, you’re priorities are wrong.


• A great way to explore opportunity in the collaboration space is to solve a problem handled so poorly by email that people would switch to a new solution to ease their frustration.

Cheers to our 5–member panel, who did a marvelous job.  It was one of the more interesting panels I’ve attended (not biased of course ;), but in contrast to the other “ad-hoc” events (e.g. Barcamp, 106Miles, BrainJams, SFWIN) I've been attending lately, it felt a bit strange and restricted. 

The bottom line is there’s not enough interaction amongst the attendees and also amongst attendees and guest speakers, which I think is crucial for the SIG to grow strong and make a meaningful difference long term.    Chris Messina and I car pooled back to SF after the event and had a chance to rap about the balance between structure and audience-driven organization being explored by the various *camp events. 

It’s a hard one to navigate — to create something where people who want to lurk and learn can do so while people who want to get more involved can jump in and shape and steer the event, even if they’re not part of the "official” group of organizers. The SIG wiki will help a bit here.

Ultimately I agree with Chris’ sentiment that once you go ad-hoc, you can never go back.  We’re looking forward to experimenting and mixing it up in the future.  Next event in January — details TBA.

Tags: collaborationsig

New SDForum Collaboration SIG

The new SDForum Collaboration SIG kicks off next Monday night (14th) with a panel discussion called Show Me the Money. 

It’s a pretty stellar panel with Joe Kraus of Jotspot,  Dave Hornik of August Capital, William Glazier of Redwood Ventures, David Coleman of Collaborative Strategies, and Sam Pullara of Gauntlet Systems 

“Where is the business and investor focus in Business Collaboration today? Join our panel of representatives from current Business Collaboration ventures as they explore and discuss "Where is the money?" From platforms to ASP services and free collaborative services, a wide spread of business collaboration ventures are currently in the market. And they are getting funding ranging from seed money to name brand VC investment stakeholders.”

It’s next Monday November 14th at Silicon Valley Bank in Santa Clara.  I’m looking forward co-chairing the SIG along with Patti Wilson and Charles Welsh. 

Check out the SIG blog and wiki for more info and to get involved.  Hope to see you Monday night!

Tags: collaboration, sdforum, sig, collaborationsig

First JotSpot Meetup Thurs Oct 27th

JotSpot’s having its first meet and greet tomorrow night (10/27) and you’re invited.  Come on by the Blue Chalk Cafe (630 Ramona St.) in Palo Alto around 7p.  We’ll be upstairs by the BAR hanging out.

RSVP on my post on developer.jot.com or on Upcoming.org, Eventful.com, or Zvents.com.

The Craftsman Approach to Web Design

We're in the process of becoming homeowners again, this time in San Francisco.  It's a 1911 Edwardian, a style related in era to the Arts and Crafts (or Craftsman) arts and architecture movement.  Edwardians are much less ornate than Victorians, but not to the level of organic simplicity of Craftsman homes, which are all about organic simplicity.

Escrow is a stressful period, but it's also filled with anticipation of new beginnings.  To get some ideas and have fun looking at old pictures, Rebecca and I busted out our old home books the other night, including a reproduction of Gustav Stickley's 1912 More Craftsman Homes.

While reading Stickley's preface, I was struck by language that sounded like it could have been written in 2005 about web application design:

"The Craftsman type of building is largely the result not of elaboration, but of elimination.  The more I design, the more sure I am that elimination is the secret of beauty in architecture.  By this I do not mean that I want to think scantily and work meagerly.  Rather, I feel that one should plan richly and fully, and then begin to prune, to weed, to shear away everything that seems superfluous and superficial."

-Gustav Stickley, 1912

Like they say, good design never goes out of style.  That said, it's definitely easier said than done, whether in a home or on the web.

 

DIY Publishing at Webzine 2005 This Weekend

Webzine 2005 is happening this Sat and Sunday in San Francisco, and if you're into blogging, *casting, web design, or any kind of DIY webby stuff, you should check it out. Oh, and parties too.

It's $20ish bucks but don't let that scare you away -- there's going to be some amazing sessions, including:

• Making Media With Open Source Publishing Tools



• Podcasting: The Democratization of Broadcast?



• Using the Internet to Kick the Man's Ass



• Around the Corner: Neighborhood Blogging



• Blog Warez Dance Off!

There's also a conference wiki (thanks JotSpot) and IRC channel to connect with folks before, during, and after the event.

tags: webzine2005

Antony and the Johnsons

I saw Antony and the Johnsons last night at the Palace of Fine Arts.  It was so so soooooo good I just have to gush a little. 

If you don't know Antony, he's british-born, NYC based, a recent surprise winner of the Mercury prize, and has a voice that truly defies categorization.  Close your eyes and imagine Nina Simone meets Sigur Ros meets Boy George.  The music is sparsely arranged piano, violin, cello, and electric bass, but really -- it's all about his voice.  He's got an amazing ability to manipulate silence and emotion with his crazy voice.  Not since seeing Sigur Ros in 2001 have I been so blown away by a live performance.

The guy's got a pretty unique sense of showmanship as well.  Half way through he enticed the audience to whistle a certain low-tone in harmony, and then used it as a background for his solo.  He also engaged in a self-deprecating improvised story-song about a couple of crabs on an island and their relationship with a coconut.  Don't ask.  It worked.  To hear him speak a phrase in a normal voice, and then sing that same phrase in his singing voice, is mind-bending. 

Listen and then buy.

On The Living Dead of Blogs and Startups

Ran across Will Hsu's Dead Blogs Walking post and it resonated with me on a both the startup and blog level.  Will relates the, "fail fast" philosophy to blogs by pointing to a few blogs experiencing blog-post-atrophy.  Applied to blogs, the theory says these blogs deserve a dignified bullet in the head death rather than live on with infrequentlyupdateditis.

"So I say this to these bloggers, treat your blog like a startup - dont
let your labor of love become labor of lame. Update more frequently or
shut it down completely. Other options include join something like
AlwaysOn where you can contribute to a community instead or opening up
your blogs to more contributors to keep it fresh. In the end, no one
likes the living dead."

RE: blogs, I completely disagree.  First off, what does "shut it down" mean?  Wipe it clean from the web?  Hope not.  Kill it with a "here's my bullet" post and then never return?  Maybe, but what's the point of that if a month... or three later you've got something to say?

Besides losing your once-frequent readers, we've got Google and tags and PubSub and Technorati to keep people connected, so I say keep it up -- keep it going.  If the point of blogging is to participate in conversation, I don't think fail fast applies.  Conversation isn't a contest, and you haven't failed if you don't find yourself posting as frequently as you once did.

RE: startups, I wholeheartedly agree with fail fast.  When I founded Inovie Software and launched TeamCenter in 1997, I didn't think 4 years later we would only have 15 employees and a couple million in revenue.  Heck we were supposed to grow wildly like seemingly everyone else.  But that didn't happen -- bootstrapping can be a slow process. 

Yes I was constantly reminded and fearful we were becoming the "living dead."  I guess you could say we were given our numbers.  In the end we were acquired in a relatively small deal and thus not forced to experience limb loss of the "truly" living dead.

So did Inovie fail fast?  4 years ain't fast.  And despite not experiencing wild success, I don't consider it a failure at all.  But yes, I would have liked to done the same in 2 years and gotten back on the horse for a second go during that period of my life.  Didn't happen, but I learned.

So fail fast is indeed a great mode for startups, but as Fred Wilson points out, it's "rarely that simple."

OpenEvents and Microformats

Seems like all my blogging-love has been going to the JotSpot Developer Blog lately...  *Sigh*.  Don't get me wrong, I love writing there because I can combine my passion for collaboration software with my admiration for Jot's amazing capabilities and a growing Jot developer community.   

But there's something about writing here on ehick that I've missed -- a place to write out loud more wholistically and randomly about stuff.  Niall Kennedy of Technorati and I were talking about this last week at Gnomedex -- even when your personal and professional interests overlap hugely, there's satisfaction in making and maintaining a distinction.  So I think I'm back!

Speaking of Gnomedex, after a week's rumination on my initial thoughts and listening to the conversation about "How do you design a remixable Web application?", my long-term takeaway is a renewed interest and sense of importance of Microformats (explained). 

Funny because there wasn't an explicit talk about them, but the moment the Microsoft dudes started demoing Outlook subscribed to a custom RSS "calendar feed" using iCal files in enclosures, I thought of Microformats and hCalendar.  Others did too.  Kevin Marks wrote to this effect soon thereafter, as have many folks since.  Adding additional semantic mark up to XHTML makes too much sense for these types of use cases.

Ever since my Google/Internet Arcive meet Mr. Event post last year I remain personally fascinated with "OpenEvents" and the event space in general, even thought I've lagged in keeping up with what's being said and done.  EVDB is supporting hCalendar and just launched their new API. Upcoming.org seems to be cranking and has an API.  Trumba's all shiny and new, but not sure they're going the Microformat way...?

All cool stuff, happening quickly.  At the very least I'm going to consume more of this myself to get the user's perspective.

Rojo 2.0 Rocks

Rojo just launched a totally new rev of their RSS feed reading service with a totally redesigned UI based around tags.  Tag love continues, and for good reason.  I've only spent 5 minutes with the new offering, but initial impressions say I'm finally motivated to move off my Caltrain-commuter-friendly Newsgator to an online service.  (Can we get syncing with some offline reader at some point pretty please?  Until then, I'll just use Slogger.)

I test-drove Rojo 1.0 right after it was launched in October, but didn't have the same reaction back then.  It was good but not there.  The new UI is much improved, and tags just plain work for me.  Nice!  (See Jeff Clavier's post for more depth look.)

ETECH: Remixing Wikis with Rendezvous, Web Services and SchoolTool

Just heard an excellent ETECH presentation titled, "From the Classroom: Remixing Wikis with Rendezvous, Web Services and SchoolTool". Lewis Elementary School in Portland, Oregon are using wikis (Instiki) and some basic web services to provide an interactive, low-budget teaching "intranet."

Basically they have teachers run Instiki on their laptop, then students in a lab use Mac's Rendezvous to connect to the teacher's laptop & create and submit their schoolwork on the teacher's wiki.  The teach can then take home and read/grade/comment on schoolwork.

Teachers and kids love it.  They love it because it's easy and it works.

Then the needed to integrate w/other systems, e.g. the class rosters or student profiles are located on a different system.  They're using SchoolTool, an open source school management program, and then using web services to hook up the wiki so it syncs with the other IT systems used by teachers.  (SchoolTool reminds me a bit of CivicSpace.)

Then they needed a calendar, so the turned to "SchoolBell" -- a calendar server that is part of SchoolTool, and again use web services to tie the calendar to the wiki.

This is awesome stuff.  It's great to see an elementary school principal talk about how they're mixing technologies to self-serve a better way to teach students.  And this is bottom up -- they bypassed the school district's grand plans for infrastructure that will be purchased "some day soon" and put something together today.

At O'Reilly ETECH Next Week

I'm heading down to my old hood next week for the O'Reilly ETECH conference.  I'll be there with fellow JotSpotters Abe and Joe.

ps. up for grilling a steak while sipping a cocktail and lounging in a red naugahyde booth?

OpenXource Helps Open up Closed Source Software

I had the pleasure of coffee Bob McWhirter (blog) yesterday.  Bob is the guy behind codehause.org, home to open source projects such as Groovy, Jaxen, and ActiveMQ among many others.  Bob recently founded OpenXource, a consulting and product company focused on helping companies move closed source software to open source. 

Helping with the strategy and execution of moving closed source to open source is an undeserved market according to Bob, and I agree with him.  Folks like Sourcelabs and Spikesource are going the other direction, helping companies bring open source in.  I don't know of anyone else specializing in the other way around. 

And while perhaps a smaller market, it's a much harder problem IMHO.  I had a taste of this helping Orbeon transition their presentation server product to open source, and of course their biz model too.  Oh yeah, that thing.  They've since joined ObjectWeb and their community and biz is on the rise, but going it alone, without the benefit of experience, is difficult.

Behind raw adoption numbers, the next most important metric of an open source project's success is the size and health of its dev community.  OpenXource is addressing this with a hosted community service called Xircles.  Its Open source community in a box, leveraging the insights gained starting, growing, and managing codehaus.org.  They've got to differentiate from the Collabnet's, sourceforge's, and GForge of the world, but there seems to be room to innovate there for sure.  This is a needed service, and I wish Bob and OpenXource success!

Developer Relations Conference, San Jose

I'm headed down to the Developer Relations Conference next Mon/Tues in San Jose.  Looking forward to meeting some new folks, learning, and sharing some ideas.  If you're going, drop me a line (scott at jot dot com), or leave a comment here.

(Too bad the conference isn't walking distance from CalTrain.  Here's my 44 mile commute.  Google is calling this a 39 minute drive...  When are they going to incorporate a realistic driving time algorithm to compliment their fancy-pants maps?)

Lessons from DEMO@15

Reuben, Joe and I returned yesterday from the DEMO@15 conference in Scottsdale, where we presented JotSpot.  There was a ton of energy there (enhanced by my over-caffeinated state), and a really wide array of really super exciting presenting companies (eg. check out bloggingdemo.com).  This was my first time at DEMO, and I definitely want to go back.  Reflecting a bit, once again I can't help but feel lucky to have experienced the true satisfaction of working hard as a team to pull something off.  It ranks among the simple pleasures in life in my book.

Among the swirl of thoughts still in my head, a couple of thoughts have been whizzing into the mental spotlight repeatedly, and the feel like "lessons learned".  Actually, they're lessons re-learned.  I feel like I continually re-learn these lessons, brought to me in slightly different package each time.  In this case, the form of a conference.  These ain't new, but why do I feel like they're so new upon each re-discovery?  I won't worry about that -- just happy to continue to move them to the front brain.

1. It's about people.  In this case, it's the folks you meet in the hallway and  have a 5 minute conversation with.  It's a new connection and perspective, even if you don't see that person again for another year, or ever.



2. It's about people.  In this case, it's getting the chance to give rapid-fire demos to people every 5-10 minutes, and get their rapid-fire reaction and feedback.  Can't be done over a web demo, can't be done by getting an email from a customer or a forum posting.  There's no substitute for looking at someones face or body language.  Watch where the brow starts to scrunch up... what's missing?  what's getting confusing?  where is the demo, and thus the product, going wrong in their mind?  What's their world view RE: what's being shown on the screen.  I love to ask what people don't like (I use the "hate" word) about what they just saw after a demo.



3. KISAP.  Keep It Simple And Pretty.  (or KISP?)  Slight variant on KISS, but I think they go together like two peas in a pod.  I don't like to use software that I can't figure out in say 2 minutes.  Maybe I'm ADD but I put that kind of bar up for new software that comes into my normal work flow.  If it's simple and pretty, I'll get going.  If it's simple and pretty and then has a bunch of advanced features that don't get in the way of simple and pretty, I'm all the more motivated.



4. Don't try to change people's habits.  Enough said there.

At DEMO Conference Next Week

As Joe mentioned on the JotBlog, we're (JotSpot) heading to DEMO in Scottsdale this weekend.  I've never been and am really looking forward to it.  Get in touch before hand or just come by our table and say hello if you're going to be there.

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.

Situated Software and The Long Tail of Software

I want to carry along and dig deeper into the discussion of how the Long Tail supports and interacts with Clay Shirky's concept of situated software (morphed into "situational software" by some).  A briefest-possible summary of these two memes are that the Long Tail is an economic-centric concept that, "the myriad of niche products whose collective market share can rival the blockbusters" (from Chris Anderson), and situated software is a social-centric concept of, "software designed in and for a particular social situation or context...where scalability, generality, and completeness are not the key virtues," (my paraphrase).

Elevator summaries aside, I want to highlight a longer quote from Clay's essay to ground and reinforce my particular emphasis here.  Again from Situated Software:

"The biggest difference this creates relative to classic web
applications is that it becomes easy to build applications to be used
by dozens of users, an absurd target population in current design
practice. Making form-fit software for a small group of users has
typically been the province of banks and research labs -- because of
the costs involved, Web School applications have concentrated on
getting large-scale audiences. And by privileging the value that comes
with scale, Web School applications put other kinds of value,
particularly social value, out of reach.
...
This in turn gives software form-fit to a particular group a number of
desirable characteristics -- it's cheaper and faster to build, has
fewer issues of scalability, and likelier uptake by its target users.
It also has several obvious downsides, including less likelihood of use
outside its original environment, greater brittleness if it is later
called on to handle larger groups, and a potentially shorter lifespan."

With that as context, there's definitely a set of ongoing conversations about the subtleties and implications that arise from this approach to software.  These are the things I'd like to begin to explore here: implications and opportunities down at the nook and cranny level of detail.  We can start by looking at situational software through the lens of topics we already discuss in software, i.e. what's the impact on: development practices? support and training? business models? integration? etc.  Looking back at that last sentence, those topics certainly provide starting points for discussion, but they feel a bit out of place here, like they're last year's problems in this "newly discovered moon" of situated software.  (Or maybe I'm drinking too much kool-aid? ;)

Let's kick off with a micro-survey of previous perspectives. Ben Hyde addresses documentation and support:

"That reminded me of how often I’ve encountered in-house one of a kind
systems with no training materials what so ever. You do occasionally
hear complaints about the lack of training materials (or doc); but
generally the social networks of the organization are entirely
sufficient to make up for the lack of doc."

Meg Hourihan talks generally about requirements:

"One reason the situated software approach works so well is the clear
definition of the end users of the system. It enables developers to
build for a very specific set of users and features, which is a
wonderful foundation for success. When you don't have business people
requesting new features for some hypothetical user or situation, your
software tends to do what it's designed to do better."

as does City Noise:

"But the exciting possibilities are for more informal even temporary
applications built by people in a neighbourhood to be used by people in
that neighbourhood."

Mike at Techdirt hints at relationships with SOA:

"The idea of more open "service oriented" systems is clearly the way where enterprise systems need to move. However, beneath that level, the idea of more niche, focused applications (perhaps designed by non-programmers) for specific needs still has a very large (and rapidly growing) place."

Carlos Perez addresses business models (as well as this post's subject from 40k feet):

"Micro-ISVs have an interesting strategy. The strategy is to as quickly
and as cheaply as possible introduce products into the marketplace.
That immediately implies that there are absolutley no real barriers of
entry. The only barrier of entry is a psychological one, that is, the
monetary gains that one can reap in such a venture is so small that
it's not worth any company's effort."  (see also Carlos' Gold... post and Eric Sink's Exploring Micro-ISVs article)

And rounding it all out, Matthew the Silent Penguin points to a particularly relevant  situational software use case relating to Tsunami relief:

"So we designed a simple requirements system for them and are building
it right now. The system will basically allow everyone to record the
requests they get from various sources and then check out requests to
say they took care of it. The (of course Web based) system will at
least help eliminate duplication of effort. This is going to be demo'ed
to them at tomorrow's (well today's now really .. its nearly 3am) 8am
meeting and if they accept it'll will go live by noon. Not a bad
turnaround time eh?"

Okay!  Clearly there are many angles and interested parties talking.  As I said above, my point in this post is just lay some groundwork for collecting situational software's "issues" from say a 5k foot perspective, both yesterday's and tomorrow's.  What's the comprehensive list?  I look forward to discussing and dissecting these one by one in the future to get a better picture of what the real-world details look like on the ground. 

ps. My personal interest in this subject traces back to my GroupWare to TeamWare to SituatedWare: Wikis Get the Platform Right post a few months ago.  I feel lucky to have connected that personal interest with my day job as JotSpot's new Director of developer relations!

 

 

Information Overload Makes Better Specialists

Mary Hodder has posted on Information Overload -- a problem dear to many people's hearts.  Mary talks about the tangible benefit and relief she experienced after allowing herself to operate in "skim" mode vs. "fully understand" mode when facing firehose, as well as differing comfort levels with skimming based on age.  Somehow skim mode allows her a subtle but powerful release of the pressure to read thoroughly and follow all threads to understanding, which in turn puts a friendlier face on info overload and makes her more effective:

"So a while ago, when I first started seeing this difference, I decided to skim, like a skipping rock, certain kinds of information and data, because I found that living with less anxiety actually allowed me to take in more and understand it more deeply. I am not sure if this is all real, or just something on the way to understanding better what really is happening as I take in this flood of data and watch people interacting with it. But I do know that I'm much happier filtering more information I want to understand by type, as I take things in, and doing surveys in the flood of digital information, instead of feeling obligated to consume every bit before I can understand something." 

I can definitely relate to this sense of liberation.  I summarize my version of this tension by tracing it back to my "jack of all trades master of none" phobia.  Not sure where I got it, but it's a little voice that I can remember hearing going way way back.  While I think there are obvious and universal benefits to "specializing", you can go too far.  It's ultimately why I dropped out of a CS PhD program, and I've been whittling away at this phobia slowly but surely ever since, accelerating as time passes.

Don't get me wrong, I'm a focus maniac, and think most people, myself included, are well served by hanging their hat on one or maybe two "specializations."  But while specializing, it's equally important to cross-pollinate.  Without it, it's much harder to be an effective specialist, and particularly hard to innovate.  In growing your ecosystem, information overload can be a blessing and not a curse.  From your sturdy oak perch, throw a bunch of seeds in the surrounding field and see what grows.  Most will be small and easily crushed under pressure (i.e.. shallow knowledge acquired while skimming), but some will thrive in unexpected ways to ultimately make a more beautiful landscape. 

As an example downside of over-specialization I point to Evelyn Rodriguez's recent, "This is what can happen whey you think narrowly post:

Reading this article has me seething - and it's an unfortunate reminder that over-specialization is dangerous not just in business:

"The earthquake centre had been inundated with calls since 8.05am when tremors were felt in Bangkok and the northern capital of Chiang Mai.... Burin Vejbanterng, the duty officer [for the government-run Earthquake Bureau in Thailand] at the time [of the Sumatra earthquake] said: 'To be honest I did not think of the waves because my speciality is earthquakes.'"

That's pretty extreme.  I don't think Burin skims much.

Another take comes from Chris Anderson.  In discussing the importance of metadata in the context of ecommerce and the Long Tail, Chris supports the notion that skimming is a nice compliment to "going deep", and by extension is an effective info overload strategy:

"As Amazon's Jeff Bezos explains it, for a product that a potential purchaser has a great deal of interest in, no amount of information is too much: from reader and trade reviews to service records, the more they can learn about a product the more comfortable they are buying it. But for products that they just don't care much about, even something as simple as knowing what most other people bought can make the difference between being frozen by overwhelming choice and purchasing with confidence."

Squint a bit and this pretty much summarizes my strategy.  Go deep and devour when I'm presented with something important and meaningful, but strive to leave time to skim a diverse set of specialist, as wide and as deep as I can handle in a given day.  With this in mind, I face info overload a bit more peacefully.

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.

Accounting for Lunch with JiffyBill.com

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: JiffyBill.com. (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.
      

JiffyBill.com 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.
      

      
      
      
      

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 LinkedIn.com
  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) http://dream.berkeley.edu/EventCalendar/Events.xsd



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

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.

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.

 

Last.fm -- 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 Last.fm fits in. Last.fm 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 Last.fm 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 Last.fm's own words,

"Last.fm 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 Last.fm 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, Last.fm 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:

So while Last.fm 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!

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.

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... ;)

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.

Build vs. use Open Source? Koders.com can Help.

Google for open source projects has appeared: Koders.com.  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.

ehick Migrating to TypePad.com

I've decided to migrate my blog to TypePad.com. From now on, I'll be hanging out at http://scottmcmullan.typepad.com/blog

For syndication purposes, my Feedburner RSS/Atom XML feed is still the same: http://feeds.feedburner.com/scottmcmullan.

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!

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.