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!
