Monday, January 31, 2005

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.

Wednesday, January 19, 2005

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!



Monday, January 10, 2005

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.

Friday, January 07, 2005

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.

Monday, January 03, 2005

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