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!

 

 

Comments

[willard]

This is a very interesting thread. I have to say, it is a concern that's been on my mind for years and seem to deal with in all of my professional workplaces. The need for a collaborative environment that can be easily and quickly form-fitted to immediate needs. I've always assumed that the absence of such software was explanable in economic terms --since "long tail" applications have small audiences and limited relevance horizons they tend not to make economic sense. Yet, it always seemed to me that there must be some way of getting around this by lowering the bar relative to the cost of developing such applications. In other words, the need for long tail apps is large, but until a very cheap means of creating such apps becomes available then long tail apps will only exist in places with money to burn. You seem to be suggesting that the wiki is this cheap means of provisioning the long tail. So, if you're right, what you seem to be doing is selling the means instead of the application. This strikes me as an interesting take I had never considered in quite these terms until now. Very interesting.