software

The infrastructure coop and the web

(In which I take a moment to meander on a topic about which I know very little.)

In Doc Searls' recent writing on "The Ultimate Alignment" he writes on the disconnect between the interests of the companies that are building the web and the people who are using it. To summarize, companies have (or are supposed to have) their investor's best interests in mind rather than the best interests of their customers and users. 

Theoretically, our efficient market system is supposed to align these two groups of interests. Or at least mediate between them. In theory, theory and practice are the same. In practice they tend to differ and one group of interests has a tendency to be subverted. When it comes to situations like the recent Facebook acquisition of Friendfeed or cable and telecom companies colluding with the recording industry to restrict peer-to-peer connections, the disconnect between the interests of users and investors comes into stark relief, and we see that users can be left out in the cold when interests conflict.

Customers have generally been getting the short end of the stick, or the pointy end if they're especially unlucky. This can, and probably should be attributed to a lack of customer organization and a resultant lack of bargaining power; something that is starting to be addressed with varying success by the social web, and which Searls sees culminating in a real capability for direct customer negotiation, which he calls Vendor Relationship Management.

A somewhat alternative approach proposed by Dave Winer, which Searls writes about in the above linked article and to which he appears sympathetic, is the tale in which the customers seize the reins of power and re/self-organize companies into a sane and impeccably moral engine of economic progress, for the good of all. [Ed. Sometimes he has a hard time keeping the lid on the sarcasm, especially in entries written on airplanes. Must be the altitude.]

Despite the sarcasm, I'm incredibly sympathetic to this idea, so after all of that throat clearing, I'd like to think about how it would work. What Searls and Winer are suggesting is a customer-owned coop.

Coops are cooperatives

My understanding of a customer-owned coop is that it is a business which is wholly owned and capitalized by its customers and the purpose of which is to provide a specific service rather than to turn a profit. If additional capital beyond what is required to deliver the service is generated, that capital is returned to the customer/owners. If an existing customer would like to become an owner then they can invest the requisite amount in the coop that is required to receive an equal share. Usually there is some ownership incentive provided, such as the ability to make use of the coop's services, or a discount on those services.

There are lots of kinds of coops, from housing and utility coops with services available only to owners to grocery stores and book stores which operate as commercial entities and often provide only slim discounts to owners. Public companies and governments are arguably coops, though they are not usually acknowledged as such and are usually not strictly customer/user-owned. (Though this is usually fairly close to the truth in the case of democratically elected governments with an electoral process that is relatively uninfluenced by monetary concerns ... and we know there are plenty of those around. [Ed. This sarcasm is getting a tad out of control, isn't it?])

Coops are often formed to establish some vital piece of infrastructure that a community feels is not adequately provided by existing commercial or governmental entities. A community that is lacking a quality grocery store will sometimes establish one as a coop. A university community that feels its access to academic books is restricted or provided at far too high a price by a commercial book store might establish a coop bookstore, effectively buying itself a distribution channel that did not exist before. Same goes for utilities.

In this way of thinking, coops are usually focused on infrastructure, with a special focus on distribution infrastructure during the 20th century. Distribution of food, books, natural gas, or electricity.

Open source is a bit like a coop ... and how

Open source software development is like a coop. The buy-in is contribution, of code, testing, bug-wrangling, documentation, publicity, or community process. The ownership privileges are varied. Contributions of code usually buy the contributor partial ownership of the code-base and the accompanying control, depending on the license - a privilege that cannot be purchased in any other way. Same goes for contributions of documentation vis a vis the body of documentation. All other contributions buy a less well defined voice in the community process.

Open source projects often resemble coops in another manner in that they are usually established to fill a need that a community feels is not adequately met (or is not met at an appropriate price) by existing commercial offerings. Some of the most successful open source projects have been and continue to be focused on infrastructure.

Open source as barter coop and the problem therein

This ground has been pretty heavily tread before, but the above description is of a coop established via barter, rather than exchange of more abstract monetary instruments and the signing of binding legal contracts. Importantly open source projects are only open to ownership by individuals who are prepared to deal in a particular instrument of barter. Open source is a bazaar, but it is a bazaar that is only accessible to those who can pay the entrance fee in a particular currency. It is a bazaar, frequented only by merchants and large distributors, not by individual shoppers. It has the best prices and the best goods, but good luck getting to them.

And therein, of course, is a problem with the open source cooperative model. The strength of many cooperatives is that any interested user can become an owner (and often does), and this is the model that Winer and Searls would like to see, it seems. But in the open source world this is not the case. In meat-space cooperatives, and bazaars for that matter, the answer is money. Anyone with money can buy a share in a coop grocery store. You don't necessarily need to be able to contribute broccoli or organic lamb to participate. 

Coops as cooperatives (and the trouble with staying that way)

Often coops seem to work best when they are providing services to a local community. This may be partially the case because it reduces the interest in joining a coop for reasons other than taking advantage of the primary service that a coop provides. This local focus can be used as a hedge against the possibility of a group of disinterested investors taking over the coop and turning it into a profit-making operation, divorced from a direct interest in providing a service to its customers and instead focused on providing a service to its owners (now two different groups of people). Viola! Modern commercial entity.

For this reason I very much doubt that founding a new company and immediately IPOing as Winer suggests would not accomplish the goal of creating a company that is truly aligned with its users and customers to provide a service they desire or require. Some guard or incentive must exist, as is the case with coops, to keep the coop owned by its users and customers, yet still open to membership from new and interested users and customers.

Open source projects don't have the local angle going for them, but truthfully there is precious little to gain from participating in an open source project if ones goal is not to improve the project. Ego and a bullet on the resume perhaps. Through narrow focus and severely restricted ownership, these projects make sure that all owners are user/customers, even if they cannot guarantee (and in fact do not aspire to a reality) that all users are owners.

And so we come to the point

We have open source projects, which are fairly successful at making sure that they are guided primarily by input from user/customers but which can do a fairly bad job of making sure that all users/customers are well-served. We have commercial entities which do a good job of serving their owners but a bad job of making sure that their owners are also their customers, resulting in divergent interests. We have local coops, which tend to do a pretty good job of both but don't tend to scale well past a local community.

And then we're talking about essentially a distributed infrastructure coop that shares some of the best features of local coops and commercial entities. What structural features could a web-infrastructure cooperative boast that would meet the following necessary requirements?

  • Any user/customer can (and often does) become an owner
  • Only user/customers become owners (with the possible exception of a small minority ownership by other interested parties)

I don't know the answer to this question. In fact, a part of me doubts that there is an answer and that we will be better served attempting to scale community processes. But it seems it is the crux of the problem of the dis-alignment in web infrastructure.

Widgetry

I've been doing a bit of research on widgets for the day job. Hopefully I'll be able to make the results of that work available in some form within the next month. In the meantime, here's a demo showing how web standards are creating a situation in which widgets and dashboards are becoming more self-service. (The movie opens in a pop-up.)


Still shot of movie

The enabling technologies in the video above are

Key functionalities that we are seeing are the ability to create meaningful, dynamic content in a self-service environment as well as easy re-mixing of content into personal dashboards as needed.

In other words, you don't need to be a programmer to do cool and useful stuff, though you do have to have a fair amount of patience on the widget creation side of the house. If history is any guide, the amount of patience required will decrease significantly as the user interfaces to this technology improve.

We're seeing similar trends in the enterprise space. Technologies are pretty much in place but take-up isn't great, probably because of similar pain points in user interface and ongoing work embedding re-mixing and dashboarding services into traditional information workflows.

Fleeting conversations about evil software

Occasionally I'm impressed that the right people are on Twitter at the right time to participate in a conversation, argument, or quip of mutual interest. These little meetings of the mind turn out to be very much in the moment, held together by mutual attention. Afterwards, the individual messages float apart and exist on their own, interspersed with bits of other conversations and status updates, disconnected from the original context. There is, to my knowledge, no place where any given conversation on Twitter can be replayed.

One of those evanescent conversations took place on Twitter today, but I've gone to the trouble to recreate it again after the fact. Hopefully I captured enough relevant bits to convey the gist.

(Read from the bottom up, click for larger version of the image. I'm @esjewett on Twitter.)

I see the sentiments expressed by @mkrigsman pop up quite often, and normally I'm not bothered by it. But I'm impressed by Michael Krigsman's level-headed analysis at his blog, so I felt the need to jump in and make a nuisance of myself.

My concern, as expressed on Twitter, is that we often (especially on the internet) attribute business decisions to some sort of ill-intent. This is especially true for decisions made by Microsoft, and increasingly Apple. Sometimes we go so far as to brand a company evil. This is a bit much in most situations. It's a questionable characterization when companies turn over private information to unjust regimes, but it's a little silly when we're talking about the delivery of iPod firmware updates. (Of course, silliness happens all the time on Twitter, and I suspect @mkrigsman was purposefully being a bit sensationalist to stimulate conversation. Mission accomplished!)

Frankly, on close examination it appears that most untoward behavior on the part of large organizations is the result of ineptitude rather than ill-intent. Most companies just can't get everything (or even most things) right. Even those that excel in a particular area, like Apple in user experience, are bound to miss every once in a while.

As always, we should try to give a charitable interpretation of actions. But where that fails, Hanlon's razor applies:

Never attribute to malice that which can be adequately explained by stupidity.

I usually like where Michael ends up his analyses, and this case was no different. We do indeed live in a complicated world.

Privacy controls - a UI design problem

Privacy controls are an area of continuing concern in social applications. Michael Krigsman has hit on the point in a sensationalist manner on his IT Project Failures blog in a post titled Twitter is Dangerous. I think Michael is off-base because I think Twitter gets it right by keeping it simple: Your stuff is either private or public. It's hard to misunderstand that.

The important thing is that users of a given system clearly understand the privacy implications of entering data into that system. In order for this to happen, the user interface and explanation within the application have to correspond with the terms of service and technical platform. As I said, I think Twitter gets it right, but others may disagree.

We see a more muddled case with the recent addition of social sharing in Google Reader. Google could have done better with the initial launch of this feature, but to the credit of the Reader team, they got the message and fixed the problem. For the interaction design nerds out there, I think that the problem here was actually not with the sharing feature per se, but with a user/developer disconnect around the privacy implications of "Sharing" an item via a publicly indexed feed with an obfuscated URL. Many users thought of the feed as private while I'm pretty sure the Reader developers thought of the Shared items feed as public.

Let's wend our way to the point of this post, which amazingly enough isn't Facebook's Beacon. No, I'm going to talk about the Plaxo Pulse and a conversation I've been having with John McCrea on Twitter. The situation is that I, apparently, had a misconception about how Plaxo shares my Pulse items when I elect to make them "Public".

Specifically, I thought that making a feed "Public" would broadcast it to all of my Plaxo Connections. Connections on Plaxo are like Facebook Friends, both they and I have to agree to being connections. When you make a connection, you categorize the contact as any combination of business, friend, or family. As such, I assumed that I had exact knowledge of who would receive my Plaxo Pulse broadcasts, though I recognize that the material being broadcast is totally public for anyone who actually looks for it.

I was wrong. What actually happens is (apparently) that anyone who uses Plaxo and has me in their address book receives a broadcast in their Pulse feed of entries I set as "Public". In other words, I have no idea who I'm spamming with these entries.

At the risk of sounding self-righteous, I'm going to blame the Plaxo user interface for this one. (Whew, I feel better already.) Here's why:

  1. The copy reading "choose which of your connections ..." clearly indicates that I'm choosing which Connections have permission to see the feed. Plaxo creates a strong division between the Pulse feature and the Address Book feature in their documentation (for example) so when Plaxo says "Connections", I assume they mean it. There is an expectation of consistency in copy across a site.
  2. When "Public" is checked, it automatically checks and grays out the business, friends, and family options, creating the possibility that "Public" corresponds to "All of the above" or "All connections". This interpretation is clearly ambiguous and draws on my (fairly common) experience with HTML check-boxes and multiple choice tests, but any ambiguity is probably a bug in a scenario like this one.

I'll be clear that no damage was done here and all of the Pulse feeds I share are public information, so Michael Krigsman can rest easy. For me this is an academic exercise. But it is conceivable, for example, that a client who has me in his or her address book and uses Plaxo was getting spammed by my tweets and del.icio.us bookmarks 10-15 times per day. I'm a pretty public person, at least online, but I prefer to allow people the choice of whether they want to subscribe to a steady stream of my random thoughts. As such, I've un-Publicized all of my Plaxo Pulse feeds. If you want to see 'em, Connect with me.

I think this is a good example of one thing that can go wrong while designing and changing privacy settings. The complexities are similar to other UI problems, but the ramifications in this area are often invisible to the user and the consequences of misunderstanding could be severe. Combined, these two ingredients put the user at the mercy of the developer and this trust should be respected by taking care in design decisions and testing against real user expectations.

Sexiness in (enterprise) software

Michael Krigsman blogs at his IT Project Failures in response to a Robert Scoble post asking why enterprise software isn't sexy. Vinnie Mirchandani also responds on his Deal Architect blog. Scoble is asking why enterprise software doesn't get more press, and Krigsman and Mirchandani hold that it doesn't get press because it's doing important things. More likely it doesn't get press because your everyday blog reader doesn't really want to know about the software that processes invoices and manages supply chains, nor should they.

But I think this misses the point. It's not just your person on the street that doesn't care. The people that use this software every day don't care about it. A lot of people use software from SAP, Oracle, and Microsoft but very few of these people view the software as anything other than a necessary evil. I don't think it's unreasonable to attribute this lack of interest on the part of actual users to a lack of sexiness, usability, humanization, etc. on the part of the software.

So back to Scoble's question: Why the lack of sexiness?

I believe it comes down to a tendency to discount aspects of software that encourage use because in the case of enterprise software we can require use. This, of course, despite the fact that you can both require and encourage use.

Because of this mentality, and the resulting software (or vice versa), people don't care about the software they use every day. Not caring results in resignation and a cycle develops under which individual employees don't have and don't expect to have control over their software, their business processes (enshrined in the software), or their workflow (also increasingly in the software). This begins to shape up into a recruiting and retention issue because people who care won't want to work with software that they can't control. But it's also a issue because we leave a huge amount of business and user interaction expertise on the table when designing enterprise software for resigned users.

Now, that's money on the table, but I think the amount of money on the table here is dwarfed by the loss of whole areas of enterprise software. Companies are just starting to try to figure out social software and the jury is still out on this area, though there are some positive signs. How about user-controlled business process modeling, even just for analysis processes? Most people are still using Excel for this.

One area of enterprise software that has been an unmitigated failure is the knowledge management arena. A big part of problem is the fact that people have to be able to integrate the KM software into every aspect of their workflow in order to achieve the necessary level of information transfer into a knowledge management environment. Enterprise software traditionally doesn't enable this type of user control, so failure ensues. Sure, documents show up in KM repositories, but a working knowledge management system isn't really about the documents, it's about ideas and knowledge diffusion.

This is all especially concerning when we have Gartner analyst/VP Jeff Mann holding that "social interaction is the way most value is delivered in the modern work environment" and that "by 2012, the primary role of business networks will be to support social interactions, not routine business transactions." (Yes, I really love this quote.) I assume that Mann includes social knowledge creation in his calculus.

I think we can agree that un-sexy software probably doesn't do a very good job of enabling social interaction. And that's a big problem.

Syndicate content