Calling Things By Their Names

So I heard that sanity has returned to these parts. ^[1]

Our marketing folks are now going to call Lotus QuickPlace, QuickPlace instead of whatever bland and insipid name that had been previously mandated. IBM Lotus Team-Workplace-something or-the-other?

Similarly Sametime will now be called Sametime instead of "IBM Lotus Instant Messaging and Web Conferencing". For a while the Lotus in that designation had been deprecated.

This probably portends that our marketing teams now better understand how to sell the Lotus portfolio. A few years ago, the perception from the trenches where I live was that there was a rush away from the land of Lotus simply because (in my estimation) it wasn't understood or didn't mesh well with the compensation structure of our sales teams. Presumably we've adjusted and now understand what these products are capable of instead of dismissing them out of hand.

Now when belts tighten in the IT industry (and right now, it is a deep retrenchment), people fall back on things that work, whether it is the glue, spackle or wrenches that I keep referencing. And much in the Lotus portfolio works even if it isn't pretty sometimes. And it works especially in the SMB space that is in the Long Tail of software. See our recent acquisitions of more Glue Layer People or even my recent hand-waving thoughts on Lotus Notes:

"For those unfamiliar with Notes/Domino, my handwaving elevator pitch is that it is a platform essentially based on the fundamental insight that a huge class of applications can be built based on just a few compositional building blocks: Forms, Views and a standard file format, the note in Notes terms. The brouhahas made about messaging, security, directory services, and all that paraphernalia that marketing people throw about when they pitch the platform to you are all syntactic sugar around the core competency of Forms and Views and the client and server processes that can manage them. A whole cottage industry of business partners are doing very fine thank you building custom and evolvable applications for businesses, small and large, everywhere. The fact that email can be construed as a forms application is just a side benefit and detracts from the real focus of the platform. This is much misunderstood by people whose only encounter with Notes is as a Mail client. It's really just a forms and view app for people and processes. Incidentally this same platform is most likely what is funding my current work and much of the IBM Software Group, even as resources are spent on other "sanctioned" and more "strategic" approaches. C'est la vie."

So that's the good news.

The not so good news:

Coincidentally the [redacted] domain was removed from the internal dns without notice sometime in the last 2 weeks. I was wondering for a few days why I coudn't couldn't post to [redacted product] or vnc into my development servers from home. I thought it was a temporary flaw and added temporary entries to my hosts file. Of course I eventually realized that nothing in the internal [redacted] hierarchy would ever resolve again that this was part of the reason why [redacted product] moved away from [redacted domain]to its current location at [redacted new location]

Some of us who had to jump through hoops to get static ip addresses like [redacted] were a little disgruntled for a good 15 minutes. Mr Feinberg even brought Godwin's law into the mix albeit with a smiley at the end of that invocation.

I guess it was approriate that the hard drive for that twilight zone machine died 2 days later. Cosmic justice or Sign of the times. These are strange days...

Now this was probably just a case of run-of-the-mill miscommunication, but let's remember that simple things like naming bring out the tribal instinct in people with sometimes shocking reactions... A lot of goodwill could well be lost.

Take for example the time 5 years ago when it was not announced that Lotus Development Corporation had been deincorporated and a good 7,000 people suddenly received payslips from the IBM corporation saying that they had received only their thousand or so dollars year-to-date (and it was mid-year). Indeed it was only months later, after prompting by an atypically tough question in an Lotus all hands meeting and seeing the quite hurt and vociferous articulation of pent-up feeling that the question belied that this was acknowledged in a subsequent prickly corporate message. Perhaps we were being babies (after all we were still getting paid), why should we care about trivial things like the name on our paycheck? I didn't attend said meeting but I caught the fallout since I just became "reverse-mentor" to [redacted executive] and had to explain why such things would matter to us "[redacted] folks"...

The identity of a community is to be found in the most unlikely of things. The things that draw people together to form a cohesive whole are not the explicit things that one thinks, it's not a kind of warlike territoriality or dedication to some mission statement or other, it is rather in small insignificant items that the tribal instinct is articulated.

People will rally round the most surprising items (Elian Gonzalez, OJ Simpson, Teri Schiavo) and they quickly become litmus tests. Think of some of the most intractable political conflicts (say Serbia/Croatia/Bosnia or and here I hesitate, I wonder who else will have an Israel/Palestine category on Blogcentral) and wonder whether the political, religious or economic arguments were really the cause of the conflict or if there weren't instead some more mundane hurt feelings that then blossomed into what we have seen and subsequently rationalized by opportunist political or religious hacks.

Or take this example form my part of the woods: for the past 9 years, Northern Ghana has been in turmoil because of an argument at a market stall over a chicken or guinea fowl (the historians will have to figure this out at some point). Two ethnic groups, the Dagbons and the Kokonbas who have lived peacefully together for centuries are now in open dispute. Many, many lives have been lost, and a huge amount of money, goodwill, diplomacy, cajoling and outright bribing has had to to done to try to cool things down and to get that part of the country to begin to contribute again to the rest of the community. This in a place that can ill afford such distractions. Now in my analogy, the guinea fowl is the stand-in for the name or for a dns entry.

All this to say that when nurturing communities, it is best to keep such sensitivities in mind and call things by their names. If not all those Sensational Fruity Delights might come home to roost.

Editors note: I posted this piece on May 18 on my internal blog but now that the information is no longer a rumour but has received confirmation, I decided to remove the embargo since it speaks to the tribal instinct in communities, something that interests me as an anthropologist of social software

File under: language, naming, communities, tribes, patterns, best practices, software, history, strategy, Lotus, quickplace, sametime, notes, IBM, web, conflict, israel, palestine, Ghana, Dagbon, Kokonba, africa, chicken, Guinea fowl, anthropology, sociology, social software, technology, toli

On The Significance of Social Software

danah boyd posts the abstract of a paper she's writing on The Significance of Social Software for public criticism.

In this paper, I will explore the contributions of social software. I will argue that there have been notable technological advancements, but that their significance stems from the rapid iteration of development in ongoing tango with massive user participation. In other words, the advances of social software are neither cleanly social nor technological, but a product of both.

Social software represents a new generation of social technology development - a generation that is dependent on moving beyond the laboratory and into mass culture. Its manifestations are already staggering - ABC declared 2004 the Year of the Blog as blogging challenged everything from political discourse to identity production. Social networking services in the hundreds have motivated millions of people worldwide to construct and negotiate profiles and grapple directly with the social awkwardness of being more public than one thought. By allowing people to easily stumble upon the work of others, media sharing services have prompted new ways of organizing information and playing with the intention of producing media. These advancements complicate critical theoretical ideas about the nature of the public(s), the role of relationships in sharing, and the collective desire to organize information.

Flash in the pan or novel?

This certainly sounds like a paper that should generate much discussion and I can't wait to weigh in with my keyboard in dissecting it. I was reflecting on much the same question a couple of months ago in People, Processes and Things

The terms that have been used about software that aids collaboration have all been unsatisfactory. They have been mostly opaque terms (groupware, knowledge management etc) overloaded and hyped by marketing teams. Correspondingly also, lots of software in this area has been unsatisfactory even if very useful for some groups whether it's mailing lists, usenet. The flight to a quality term like "social software" that people like Clay Shirky have spurred in recent years is an exercise to escape the stigma of the reigning software. I heartily endorse that effort but when I pass the hungry salesmen in the corridor that are trying to sell software for my company, I know that that effort will be in vain. If it's between their year-end bonuses and calling something "social software", you know what's going to win. Thus I predict that our vocabulary for software that supports groups, organizations and communities will continue to be contaminated.

There is more than mere terminology here as danah points out; there is also the question of whether the newer sofware applications and the insight gained in developing them are significant.

From my standpoint, the only difference in the emergent software is that much of it is web-native and can leverage the delightful surprises and scale of the web platform (which thankfully has remained relatively open). Previously this type of software was typically on vertically-integrated platforms (e.g. Lotus Notes, Groove etc). Now if you lived in the ecosystems of those platforms, you would know that you can (in some cases) get much of the immediacy of the web. As an example, Notes has always had hyperlinks of a sort, there are database links, view links and doc links. Ray Ozzie even invoked Lotus Notes' hyperlinking fundamentals in a bid to save the browser from the Eolas lawsuit. The problem with Notes hyperlinks was that they weren't simple URIs - even if you could indeed copy and paste them in Notes; they were only useful in Notes clients. The ubiquity of the web could not be leveraged in other tools. I couldn't jot down the URI to a particular teamroom on a napkin or paste it in an instant messaging window to share. On the whole nobody cares what kinds of clients you use with web-native software.

Sociological Insight

When considering social software, you have to bring in the sociologists and hence I'd point to some older case studies to consider in this arena regarding the nature of the communities that the software in question is supposed to serve.

• Wellman, Boase and Chen: The Networked Nature of Community Online and Offline

  Communities started changing from groups to networks well before the advent of the Internet. Initially, people believed that industrialization and bureaucratization would dissolve community groups and leave only isolated, alienated individuals. Then scholars discovered that communities continued, but more as sparsely-knit, spatially dispersed social networks rather than as densely-knit, village-like local groups....
  
  Given the movement from the local and densely knit to the far flung and sparsely knit ... it is useful to define community as networks of interpersonal ties that provide sociability, support, information, a sense of belonging and social identity.

• Koku and Wellman: Scholarly Networks as Learning Communities: The case of TechNet

  "There's a shift from small groups to diffuse, variegated social networks. Boundaries are permeable, interactions are with diverse others, linkages switch between multiple networks, hierarchies are flatter and more recursive.... transient, virtual organizations.. work relations spill over nominal work group boundaries... even connecting to outside organizations"

The insight of such quotes is about the fluidity of the communities in this modern life of ours. They presage a notion of social networks with sometimes implicit rather than explicit webs of relationships. The kind of thinking required for networks needs to be flexible in order to deal with the diffuseness of our evolving patterns of discovery and social interaction. Handwaving a little, it is like the kind of shift in thinking that we have gone through in the move from desktop productivity applications (like the traditional office suites) to web applications that need to keep the network abstraction and usage patterns in mind.

On Metrics

I'd also throw in some Usage Statistics from Groove Networks but the details from that report seems to have vanished into the cyber ether although the summary is important in what it displays about how people actually use the software (as opposed to how the people who wrote the software thought it would be used). With appropriate metrics, those in the community can get measures of health (since as we know sometimes a group is it's own worst enemy - e.g. the kind of collaborative moderation on Slashdot). The metrics can also help those who are developing the community software.

Right now the server logs at del.icio.us, Flickr and Furl are among the most valuable pieces of property in the internet. Certainly for anyone interested in social software, the kind of insight that Joshua Schachter is gaining from his logs would be invaluable.

But this goes beyond research, potentially this is something that can be translated into features of genuine use by glue layer people or perhaps that can be monetized in some fashion (e.g. through advertising supported services). If you want to be intelligent in your design of social software, sometimes you need to go straight to the source and simply ask the users (e.g. the proliferation of "Report Spam" buttons in web mail clients). Enlist the users and get them to feed you their usage patterns (e.g. the Alexa toolbar). It's no wonder that Google is trying to do the same with the launch of its web accelerator.

Cross-posted at the Inside Lotus weblog.

File under: communities, social-software, social, networks, groups, software, technology, sociology, Lotus, IBM, language, metrics, web, internet, toli

People, Processes and Things

A product I worked on a few years ago had as its mantra: "people, processes and things". As a marketing message, the slogan's usefulness left a lot to be desired; the catch-all "things" seemed an imprecise cop-out at best. The product dutifully died a quiet death even if it is being reinvented these days. As a rough taxonomy of software applications however, the slogan was a serviceable description of the different areas we focused on. Software architecture is difficult to articulate in any case so fuzzy handwaving of this sort is the norm.

Two recent posts gave me cause to revisit these notions. The earlier one, from Barry Briggs, was a speech wherein he anointed this era the Decade of Process. The second was Jamie Zawinski's takedown of "groupware". Both are interesting takes on these different approaches to software.

On People

Writing in his ever quotable and blunt way, jwz packs a lot of insight into why it's a case of "Groupware BAD... Users Good".

On why people want to write software:

Our focus in the client group had always been to build products and features that people wanted to use. That we wanted to use. That our moms wanted to use.

Adam Bosworth similarly talked about the Mom factor in the design of applications.

More generally, he comes around to one of the pithiest definitions of social software.

So I said, narrow the focus. Your "use case" should be, there's a 22 year old college student living in the dorms. How will this software get him laid?...

"Social software" is about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.

There's lots more in this vein: why words like workflow or enterprise make his eyes glaze over, why groupware is an albatross, how that kind of software is not sexy etc.

The wider insight however is that Zawinski's argument is about focusing on people. It's a recognition that human beings are simply very social beasts and that we place a premium on communications. That's why phone, email and instant-messaging are the big applications of the day. When designing applications in this space, it's mostly a matter of getting out of the way and letting exchanges and interactions occur. Browsers and the web servers are some of the best software incarnations of this principle.

This focus on people, on connectivity and on simple communications is all part of longstanding historical trends in transportation and communications systems. This has been covered most fully by Andrew Odlyzko you can read him on read on why Content is not King, or more exhaustively on the history of communications and its implications for the Internet (pdf).

Among the core architectural principles of the internet are things like the "end-to-end" principle and internet transparency. I like to think of these as engineering tradeoffs in network design that are premised upon the virtue of connectivity. The network "laws" that apparently grow out of these design principles are things like Metcalfe's law on network utility or Reed's law on group-forming. These ideas embody more than mere connectivity however, and the software that builds on top of them is similarly diverse.

Once you move beyond simple person-to-person communications and information sharing, you get into what is the daily bread of those folks at CUE and Many-to-Many and begin to consider the ways in which humans organize themselves. You very quickly start talking about interaction trends in families, clans, tribes, groups and more generally about communities. This "stuff", the cement of society, if you like, is something that sociologists or anthropologists have greater facility in describing and something that software developers have, on the whole, done a poor job of translating.

When you consider how organizations operate there's lots that is implicit and most software has been a blunt tool where a light touch has been required. Just as an example, in most software, things have to be explicitly stated: I'm a member of this group, so-and-so is my friend etc. And even when software can infer or recommend things, oftentimes it is inexact and requires much fine-tuning and/or constant training.

If you take a wider view, you move from the realm of sociology and begin to talk about economics, about commerce, about capital and about ultimately about power. Once business and money comes into it, you understand that are vast quantities of software that address the needs of these other entities. It's obvious that not everyone will be able to write software like Zawinski has (Netscape) that has indeed changed the world and can be strictly focused on users, connectivity and communications. What makes users happy often doesn't coincide with what makes businesses happy - and as for the matter of motivation of software developers, the most salient fact is that businesses tend to pay large and regular amounts.

On processes

I'd argue then that the picture is wider one than simply "people" and that's where I'd return to Briggs' piece on processes. I didn't know Briggs when he was at Lotus but it's clear that we've drunk from the same Kool-Aid: I've used similar examples as he in presentations in the past year, working as I am on forms technology, namely:

Five thousand years ago on Crete people wrote documents in a script we later termed Linear B. When Sir Arthur Evans at the turn of the last century unearthed the tablets at Knossos, the world wondered at them, but for decades could not read them. Then, in 1940, a British scholar named Michael Ventris announced to the world that he had, in fact, deciphered the tablets and that they were in a form of archaic Greek

The world held its breath. Were they previously unknown epic poems, like the Iliad or the Odyssey? Were they great plays by some long-forgotten ancestor of Sophocles or Aristophanes? Were they philosophical discourses by a forebear of Socrates or Plato?

No. They were lists. Lists of sheep. Cows. Horses. Slaves. What we would call today inventories, bills of lading, invoices. To our chagrin, we realized that then, at the dawn of history, these citizens of archaic Greece -- like those of Sumer in the Fertile Crescent of Mesopotamia, like those in Egypt -- lived in a rigidly bureaucratized dictatorship.

They were empires of accountants.

Why do I recount all this? Because our little tale highlights something important, which is that commerce, trade, and the documents that record them lie at the core of the human essence. We are creatures of commerce; it is innate to the very notion of humanity.

Brigg's point is that even though we have wonderful things like literature, it is likely that the invention of writing systems was prompted by mundane bureacratic concerns. He goes on from there to sketch a vision of the type of software that can be created in this area. As befits a speech, there's a little hyperbole in what he says but also an essential truth: process isn't the sexiest of things - but it's an integral and necessary component of society.

As we translate increasing amounts of processes into software, one hopes that we can learn the lessons of the most satisfying aspects of software. At its best, process should be frictionless and unobtrusive like most infrastructure. Why spend an afternoon at the registry of motor vehicles going from queue to queue, filling one form after the other when much of that you can be automated in software? What I fear is lost as we create this software are things like institutional memory and the people-component (the man who explains what that checkbox really means, being able to scribble in the margins of a form, what happens when the next person in a "workflow" is out of the office, or his mail quota has been exceeded etc). There's lots of room for innovation and improvement here.

The terms that have been used about software that aids collaboration have all been unsatisfactory. They have been mostly opaque terms (groupware, knowledge management etc) overloaded and hyped by marketing teams. Correspondingly also, lots of software in this area has been unsatisfactory even if very useful for some groups whether it's mailing lists, usenet. The flight to a quality term like "social software" that people like Clay Shirky have spurred in recent years is an exercise to escape the stigma of the reigning software. I heartily endorse that effort but when I pass the hungry salesmen in the corridor that are trying to sell software for my company, I know that that effort will be in vain. If it's between their year-end bonuses and calling something "social software", you know what's going to win. Thus I predict that our vocabulary for software that supports groups, organizations and communities will continue to be contaminated.

But what about the reality of social software? What collaboration software will be likely to be successful? For me it is clear that one has to start with the platform consideration and from that standpoint we are dealing with the internet and the web and browser clients. Web-native applications, things like wikis for example are going to be part of the picture, not necessarily because they are better but because being based on the most dominant and scaleable platform that we have is virtue enough. More generally, it is going to be applications that take into account the architecture of the web and the internet that will succeed. These will be applications that understand the proposition of identifying resources, the virtue of URIs etc. Those who ignore the lessons of Roy Fielding do so at their peril.

Software that is targeting people will live and die by usability. Those who design software that underlies processes tend to think that they are immune from this but I believe that the same basic principles of interaction design will ultimately apply. No one particularly likes the bureaucracy of process but there's a trait of subversion and resistance in human beings that will undermine any poor tools foisted on them. Paying attention to this will be an important part of success.

On Things

I'll be delphic and try to weasel out of defining what those elusive "things" are. For me, they are a convenient proxy for everything that doesn't fit within the people and process views of things. For businesses, it's relatively mundane things like "documents" that need to be "managed" or keeping track of assets or items we manufacture. Another way to think about 'things' is to consider that people are creative and exist in a culture; software can be applied to the creative process and to establish a sense of place and shared context in society. Some term it "content", more generally it's entertainment, it's the music, the movies, the books that people are interested in and want to participate in and discuss. There's also that whole segment of the software industry, games, that is highly profitable and which seems to be driving things of late - the virtue of idlenesss I suppose.

I'll end by reiterating: people need to communicate so get out of their way and let them collaborate and exchange. Groups, communities and organizations often embody processes, and when using software in support of them, aim for unobtrusiveness and, most crucially, leverage this great network architecture that we have. As for the rest, well that will sort itself out, Darwin and Adam Smith have a lot to say here.

File under: technology, software, design, architecture, social software, people, processes, process, groups, sociology, collaboration, lotus, IBM, social, toli