Alex Barnett blog : enterprise2.0

Join me at Web 2.0 Expo New York - Building in the Clouds: Scaling Web 2.0

alexbarnett — Fri, 08 Aug 2008 13:06:00 GMT

I'll be taking part in one of the Cloud computing panels at Web 2.0 Expo New York this September, details below. If you want to meet up, let me know.

Building in the Clouds: Scaling Web 2.0

Jason Hoffman (Joyent, Inc.), Alistair Croll (Bitcurrent), Alex Barnett, Dwight Merriman (10gen), Jinesh Varia (Amazon Web Services)

10:30am - 11:20am Thursday, 09/18/2008

Performance & Scaling
Location: 1A23 & 24

Cloud computing is self-serve outsourcing for web companies. Clouds give even the smallest startup access to world-class infrastructure that can grow as needed. And developers build apps faster because they start with the building blocks of online applications: authentication, storage, messaging, and the social graph.

But the range of Cloud offerings is daunting. From self-contained development tools to virtual “bare metal,” selecting the right layer of Cloud offerings fundamentally changes how you run your business, what tools you can use, and ultimately how much control you have over your future.

Join this panel of Cloud computing innovators for the silver linings—and dark sides—of the Cloud.

Sync Google Calendar with Outlook and more with WideLens

alexbarnett — Thu, 06 Mar 2008 05:37:00 GMT

Google has just released a very cool utility (.exe download for Windows) providing users with the ability to synchronize their Google Calendar with Outlook.

Some nice features in their 0.9.3.0 release:

schedule the sync frequency: every x minutes
define directional flow: 2-way, and 1-way (either way)

A bit of a buzz going on about this...

Now, what if you could do the same over the web - no download, just use your browser (IE, FF, Safari)...? And not just Google Calendar <> Outlook, but others too...?

Well, it's certainly possible...First, watch this screencast I put together tonight (apologies for sound quality...done from home equipment):

About WideLens

A couple of weeks back Bungee Labs released a reference calendaring application, called WideLens, designed to show off some of the power of the Bungee Connect platform, from the kind of rich AJAX UI experiences delivered through to the high level of functionality developers can create by wiring up and integrating multiple web services and distributed web data sources into a single web app.

Video: WideLens User Experience
Video: Developer Overview

WideLens connects to Microsoft Exchange calendar, Google Calendar, Salesforce.com, Facebook, MySQL and iCalendar feeds, representing a variety of protocols and authentication schemes. MS Exchange is accessed through WebDav, Google Calendar through gData, Salesforce.com via SOAP, Facebook through REST and MySQL connectivity is based on client libraries provided by MySQL (integrated directly inside Bungee Connect).

WideLens is an uber-mashup.

WideLens connects to each of the sources in real-time, presenting the user with live data. With the exception of Facebook and iCalendar, users can create and modify events and those changes are immediately posted back to the source. MySQL pulls double duty, serving as both a WideLens native calendar source and as the persistence layer for all kinds of application data including user preferences and credential information for each service.

Developers: Have At it!

As mentioned above, WideLens has been released as a Bungee Connect reference application where we're encouraging Bungee Connect developers to customize the WideLens application as much as they want, deploy their own version of the app as their own app - to their own domain, at no charge, branded however they want and with whatever features / cuts / modifications / extended they want - the WideLens code is released under a BSD licence (read more here).

To get going with Bungee Connect and develop your own vision of what WideLens could do, sign up for your Bungee Connect account.

Mashup design patterns

alexbarnett — Tue, 22 May 2007 16:27:00 GMT

<warning: the following post meanders, is unstrucutured and doesn't arrive at any conclusion>

In the middle of last year, I invited Dion to meet with me and other members of Microsoft's Data Programmability team to discuss REST in the context of data access over the web. Dion's perspective is one of the reasons our team was able to recognise the potential of a RESTful programming model against relational data, manifested today as Project Astoria.

I've been waiting to read Dion's thoughts on Project Astoria (via John Musser). It's an interesting take, contextualizing Astoria within the overall architectural trends we're seeing take place.

I liked this diagram and got me thinking (dangerous...):

Dion warns that the diagram like this could never be complete representation of the concepts discussed in his post and is work in progress. The mapping done here for the 3 types of applications (Composite Applications, Recombinant Software and Mashups) makes some sense to me. However, it reminds me that I have used the terms "Composite applications" and "Mashups" interchangeably (but never Recombinant Software) depending on who I'm speaking to and without really thinking through what I mean by these terms. To try and clarify my own thinking on this, here's my effort to do so...

Here are the Wikipedia definitions of Composite Applications, Recombinant Software and Mashups.

Composite applications

"the term composite application expresses a perspective of software engineering that defines an application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems)."
Recombinant software
<none>
Mashup
"A mashup is a website or application that combines content from more than one source into an integrated experience."

So nothing in Wikipedia for "Recombinant software", but in searching for a definition I did come another post by Dion written in June 2006 - "Is IBM making enterprise mashups respectable?". Here Dion asserted:

"Accepting that information, visuals, and software can be remixed and combined at multiple levels in an application stack means that there are (at least) five places that mashups can take place."

Dion then went on to define 5 mashup types:

Presentation Mashup: This is the shallowest form of mashup in the sense that underlying data and functionality don’t meet. Information and laout is retrieved and either remix or just placed next to each other. Many of the Ajax desktops today fall into this category and so do portals and other presentation mashup techniques.
Client-Side Data Mashup: A slight deeper form of mashup is the data mashup which takes information from remote Web services, feeds, or even just plain HTML and combines it with data from another source. New information that didn’t exist before can result such as when addresses are geocoded and display on a map to create a visualization that could exist without the underlying combination of data.
Client-Side Software Mashup: This is where code is integrated in the browser to result in a distinct new capability. While a component model for the browser is only now being hashed out as part of Open Ajax, there is considerable potential in being able to easily wire together pieces of browser-based software into brand new functionality.
Server-Side Software Mashup: Recombinant software is probably easier right now on the server since Web services can more easily use other Web services and there are less security restrictions and cross domain issues. As a result, server-side mashups like those that in turn use things like Amazon’s Mechanical Turk or any of the hundreds of open Web APIs currently available, are quite common.
Server-Side Data Mashup: Databases have been linking and connecting data for decades, and as such, they have relatively powerful mechanisms to join or mashup data under the covers, on the server-side. While it’s still harder to mashup up data across databases from different vendors, products like Microsoft SQL Server increasingly make it much easier to do. This points out that many applications we have today are early forms of mashups, despite the term. Of course, the more interesting and newer aspects of mashups happen above this level.

Back to the plot...

When speaking with an "enterprisey" architect I use the term "Composite applications". "Enterprisey" architects think and talk in terms of governance, security, scale and complexity. They also like to hear and use technical sounding terms that confound non-IT folks ;-)

When speaking with a developer, I tend to use the term "Mashups". Developers are smart and lazy - they want to write fewer lines of code, do more with less and love to impress. In my mind at least, the term "mashup" implies a speedy development / test / deploy cycle, design flexibility and simplicity in the sense that its "less hard to do".

Now, if I'm talking to a developer who works in the enterprise context (enterprise as in a large business) the term "enterprise mashup" can connect the "enterprisey" values - governance, security, scale but without the complexity AND with the "mashup" values - speed, flexibility and simplicity.

Reviewing the 5 mashup design patterns above, there is reasonably defined line: Client-side vs. Server-side. Some of the fall into the WOA space - referring to Dion's diagram above:

"Another important item: The bottom of the overlapping circle contains a cryptic acronym near the edge of the circle: WOA. This stands for Web-Oriented Architecture, a concept that I’ve written about several times here and here in this blog. It’s an idea that basically states that software that goes naturally with the “grain” of the Web, extending the core infrastructure of the Web in natural ways, works the best."

Announcing Bungee Connect

alexbarnett — Mon, 16 Apr 2007 07:11:00 GMT

At last, I can tell you more about what Bungee Labs has been up to...

We've just announced details about Bungee Connect, a 100% on-demand web development and deployment environment that will be going into Beta phase in May.

Over the next three days at the Web 2.0 Expo 2007 and on bungeeconnect.com we'll be providing a lot more detail on exactly what Bungee Connect is, how it works and why we think it will be a big deal when we go live.

So before I go on, let me quote a couple of people who have already seen Bungee Connect in action behind closed doors. The following are from tonight's two press releases (1 and 2)

First off, Dion Hinchcliffe:

“Ajax is just the beginning of the RIA story and Bungee Labs provides the rest of the solution with a web-based IDE, on-demand scalable deployment, a well-designed community model and a built-in component ecosystem with real-world licensing options,” said Dion Hinchcliffe, ZDNet blogger; President/CTO, Hinchcliffe & Co.; and editor in chief, AjaxWorld Magazine. “Bungee Connect is a surprisingly complete one-stop shop for the RIA development, deployment and operations lifecycle.”

Next, Dana Gardner:

“Given the current disjointed state of tools, testing and deployment models, most developers find creating rich internet applications (RIAs) to be complex, time-consuming and expensive,” said Dana Gardner, Principal Analyst, Interarbor Solutions. “By combining development, testing and deployment functions into an integrated, low-cost-of-entry service approach, Bungee Connect both broadens the numbers of developers that can produce web applications as well as slashes the barriers of entry for creating innovative ecommerce services and web-based businesses."

The Bungee Labs team has been working very closely with the Amazon team (and others API providers) the last few months to make sure Amazon's web services "just work" with Bungee Connect. Jeff Barr, Senior Evangelist for Amazon's Web Services:

“Bungee Labs’ decision to make their development environment integrate seamlessly with Amazon Web Services is great news for our developer community,” said Jeff Barr, Senior Evangelist for Amazon Web Services. “AWS developers can now use Bungee Connect to directly access our services, which means they can build Web-Scale applications in an easy to use, browser-based development environment.”

Another provider of web APIs, Salesforce.com has also been working closely with the Bungee Labs engineers. This time a quote from Adam Gross, Vice President, Developer Marketing, Salesforce.com:

“Salesforce.com has demonstrated that the innovation and ideas of the consumer Internet are at the core of the next generation of business applications. Bungee Connect together with Salesforce.com’s Apex platform makes it easier for developers to create mashups for their businesses, and in doing so hastens the transition from traditional enterprise software to the new on-demand model of building and deploying applications.”

So, what is Bungee Connect? Well, it's a lot of things:

Bungee Connect is a completely web-based integrated development environment (IDE) for building and deploying rich Ajax web applications, from simple web apps to seriously sophisticated Ajax applications. No install for developers, no installation of delivery infrastructure, and no client install for end users.
Bungee Connect is for developers, not for consumers. Yes, it provides a huge amount of automated support for the integration of SOAP and REST-based web services, Ajax app development and state management. You can develop sophisticated apps that integrate powerful (as well as simple) web services plus develop your own logic without having to write a line of code. It massivley reduces complexity. But, nonetheless, it is for developers, not consumers.
Bungee Connect provides a completely integrated means of deploying apps to the live web. No FTP. No separation between your dev, staging, production and live environment. No local set-up on your machine. No bits to install anywhere. No web servers, no app servers, no stacks, nor libraries to install, patch or manage. No 'Yak shaving'. It's all taken care of for you. You develop your app through the browser, then deploy your app through the browser and map the app to your domain / URL (or embed the app in your site) - It's your app. Oh, and you get IE, Firefox and Safari cross-browser compat taken care of too - you build your app once and it just works in these three browsers. Sweet.
Bungee Connect includes a whole code share and team collaboration concept. You can keep your code proprietary, or you can share it with other Bungee Connect developers in your workgroup or with the wider Bungee Connect developer community. There's a lot more to this than I can cover here and I'll be writing a lot more on this soon, but I like how Mat Asay described the community aspect as a 'Sourceforge for the 21st Century'.
Bungee Connect allows developers to leverage the world of web APIs. We've been working with the API engineering and evangelist teams at Amazon, Ebay, Google, Microsoft Windows Live, PayPal, RealNetworks, Salesforce.com and Yahoo! to ensure Bungee Connect works sweetly with the multitude of their rich APIs (both WS* and RESTful). The aim is to ensure Bungee Connect can work with any web service that you choose and by working with these teams and their APIs in developing Bungee Connect, we've got a great test-bed to make sure we can achieve this goal.
Bungee Connect is No Fee for the developer to use in developing and testing Bungee-powered apps. You only pay once you've deployed your app commercially or unrestricted. We expect this to be US$1 per computer-network-interaction-hour, billed monthly. Again, more on this later.

And there's so much more. Tomorrow, anyone attending Web 2.0 Expo will be able to get hands on with Bungee Connect. We've got a booth with PCs (Windows, Macs and Linux) with the browser open (IE, Firefox and Safari) where you run through some tutorials and judge for yourself if you think we're all smoking crack (see pics below - no crack, just the booths). We'll also be updating the site with screencasts and plenty more details and Martin will be presenting and demo'ing with Brad on Wednesday morning. And by then I'm sure David might have something more to say too...

To underline a couple of points here: we're not live yet. We go into Beta in May and are looking for web developers who ideally already have experience in progamming against the APIs of the companies I mentioned earlier. So sign up if that sounds like you...

---

Update:

Dana Gardner has written up his thoughts on Bungee Connect.
Short but sweet mention on Mashable.com by Pete Cashmore.

Update 2 (4/18/07)

Richard MacManus blogged it over at Read/Write Web
Ryan Stewart blogged us too :-)

7 Thoughts on the Business of API Throttling

alexbarnett — Fri, 06 Apr 2007 12:21:00 GMT

John Musser over at ProgrammableWeb.com has summarized the various ways (he's outlined 12) API providers can control access to their web services. As John says,

"There are good reasons for this ranging from preventing abuse, controlling costs, or other business-driven reasons."

John triggered a few thoughts for me with his post...Thinking out loud now...

7 Thoughts on the Business of API Throttling

1. Web APIs will be a key driver of future of the networked, services-based economy
2. The science of web API throttling is set to become a core business competency - not just a technical competency - for (hundreds of) thousands of businesses
3. Businesses need to learn about the business of API-based business models (an area where there is some experimentation and learning is going on today, but not enough)
4. Business expertise in designing and evolving API-based business models will be a highly valued skill / commodity
5. Standardized business models need to (and will) emerge regarding web APIs, similar to how there are standardized business contracts today
6. API throttling will become exponentially more complex to execute and operate
7. A significant number of small and medium-sized business (the long tail of today's economies) that want to thrive in the networked economy will need to make a decision in the near future: "do we spend large amounts of resources in the technical operation of API service delivery and throttling expertise in-house, or should we outsource this?"

Tagging behind the firewall - a case study

alexbarnett — Sun, 19 Nov 2006 17:32:00 GMT

I've written about 'Enterprise Tagging' or 'tagging behind the firewall' before, but haven't come across any case study material in this area, until yesterday that is. In his latest post, Andrew McAfee has written up a short report on the intranet used at interactive agency Avenue A | Razorfish (AARF):

"What I found most interesting about the company was its own Intranet. To hear David, Ray, and Amy tell it, the company's traditional static Intranet -- the place where an employee would go to look up benefits information or peruse the latest press releases -- still exists, but has been marginalized by a suite of Enterprise 2.0 tools."

What content shows up?

"AARF has built interfaces to the bookmarking site del.icio.us, the photo sharing site Flickr, and Digg, a site where members vote on the importance of news stories. All three use tags, or something close.
AARF employees have learned to add the tag 'AARF' when they come across a web page (using del.icio.us), a photo (Flickr), or a news story (Digg) that they think will be of interest to their colleagues. Shortly after they add this tag, the bookmark (look at the top of the box), thumbnail of the photo (middle) or headline and description of the story (bottom) show up within the AARF E2.0 Intranet. So AARF has found a fast and low-overhead way to let its employees share Internet content with each other. It's also free; these interfaces with del.icio.us, Flickr, and Digg require no fees and no permissions. I find this simply brilliant."

Corporate Attention Data Needs to be Secure

A potential issue to point out here. Since employees are using the AARF tag to share content with other employees and they are doing so on public sites such as del.icio.us, I can also see what AARF employees are bookmarking and sharing with other AARF employees. Is that a good thing? We'll, it's good for me :-). But is that good for AARF? Look, here is a sample. From a cursory look at the AARF tagged bookmarks, I can tell:

Someone is probably lobbying HR for Starbucks coffee machines at the office (I can't blame them...)
Someone is studying Second Life's audience size, probably as an opportunity to either establish their own presence for the agency, or collating info so they can advise clients
Someone is trying to figure out the ROI on blogging (rather you than me...)
Someone is interested in mobile social software apps

Are they giving away company secrets? Lobbying for Starbucks coffee machines, er, probably not. Corporate Second Life plans for AARF? Maybe...

Whoever is responsible for this approach at AARF has probably considered the risks of making this kind of corporate attentional data potentially public (I hope). This level of corporate transparency might be a deliberate decision, but then again, it might not. Either way, companies need to be aware that if they are going to use public tools as a way of sharing content and data in this way, there is the potential to have their corporate attention data tapped into. Today, there is nothing to stop non-AARF employees and competitors subscribing to AARF tag feed and thereby tapping into a thread of AARF's collective thought processes.

(btw, before you point this out, I do realise there is a 'don't share' checkbox in del.icio.us, so it might be the case that what I can see on the AARF tagged content in del.icio.us might only be a subset of content that AARF employees have tagged, and what I'm seeing is what they and feel is OK for the likes of me to see. Even if this is the case and I were the person in change, I'd still be nervous - someone forgets to check a box and well, you get the picture.)

This IP / corporate privacy issue is the precisely the reason why I felt sometime ago that new commercial offerings would emerge to enable corporate tagging be done securely and behind the firewall. That's the 'firewall' bit of 'tagging behind the firewall' idea. (and that's why last year's Mind Camp session was called Del.icio.us Inside). This secure dimension would also allow to internal resources (URIs) to be bookmarked securely...Would you really want competitors to know that you've got a whitepaper written up on the next big thing for your company, with a url: "blah/why_we_will_invest_Xmillion_in_Y_in_2007.html?

Putting this implementation and security issue aside, I believe there is huge potential upside for using social bookmarking and tagging tools inside the firewall, if done right (and that means securely, amongst other things). The pioneering approach by AARF is giving us a glimpse into the future of intranets. I'll give McAfee the final word:

"It gives them 'the latest' about their work environment. And it does so in a bottom-up and egalitarian fashion. This page doesn't contain the latest information that the company's senior managers, or its IT staffers, think employees should know about; it contains the latest information that employees think employees should know about."

P.S. I'm going to bookmark this post 'AARF' on del.icio.us. This should guarantee that it'll appear on the AARF intranet ;-)

P.P.S. If you are at all interested in 'Enteprise 2.0', you really should subscribe to Andrew McAfee's blog. He's associate professor at Harvard who regularly posts on the topic of social software behind the firewall.

Enterprise 2.0 and Culture Change

alexbarnett — Sat, 11 Nov 2006 02:27:00 GMT

Andrew McAfee, an associate professor at the Harvard Business School has identified a user segment within organizations that he describes as the 'Empty Quarter'. The context is within the types of users who become the early adopters of Enterprise 2.0' applications (or social media behind-the-firewall). In McAafee's experience, there are two types of early adopters of these types of technologies: Newbies and Techies:

"'Newbies' here means new entrants to the workforce; as I wrote earlier, recent graduates find it natural to socialize, collaborate, and find what they're looking for via technology platforms (think of MySpace, Facebook, Flickr, Wikipedia, LastFM, del.icio.us, etc.). In addition to point, click, drag, and drop, their baseline computer skills include search, link, tag, and post.
'Techies' are IT staffers, and also those people scattered throughout the rest of the company who are the natural early adopters and advanced users of whatever technologies are available.
...If these observations are accurate, then a graph with technophobia on one axis and years since graduation on the other reveals who's more and less likely to use Enterprise 2.0 tools if they're made available:

The 'empty quarter' of non-adopters is the upper right-hand section of this graph. These are the folk who are relatively unlikely to pick up new tools and run with them."

McAfee goes on to argue that encouraging the Empty Quarter to participate in the production of social media within the Enterprise will benefit the company as a whole, since a great deal of the knowledge produced by this segment is where the institutional knowledge and corporate memory really resides. He goes on to propose ideas around how these users can be encouraged, including focus on the development of the tools themselves (e.g. make it more useable) and policies that might be introduced:

"Maintain a blog for your group / department. Identify who's in charge of it, and update it at least once a week.
Maintain a blog for each project your lab is working on. Post whatever non-confidential information you'd like your colleagues to know about each one.
Keep your personal page up to date. Make sure it lists your areas and industries of expertise.
Use the wiki to make sure your portion of the org chart is up to date."

I agree with McAfee that in order to get the Empty Quarter to adopt the use of social applications it will require both the combination of good technology and efforts around cultural change. Since he's asking for others to share their experience around what has (and presumably hasn't) worked, here are my thoughts and observations on the topic:

the Del.icio.us Lesson

This one is more to do with the technology design, rather than efforts to socially engineer adoption. The idea is called The Del.icio.us Lesson - a key social software design principle. To summarize Joshua Porter's post (who originally coined the term):

"The one major idea behind the Del.icio.us Lesson is that personal value precedes network value. What this means is that if we are to build networks of value, then each person on the network needs to find value for themselves before they can contribute value to the network. In the case of Del.icio.us, people find value saving their personal bookmarks first and foremost. All other usage is secondary."

Creators, Synthesizers, and Consumers

Bradley Horowitz of Yahoo made the observation that social software sites don’t require 100% active participation to generate great value. He used a data point relating to Wikipedia to illustrate the point: half of all edits are made by just 2.5% of all users. Horowitz formalized this idea with the following chart::

"As Yahoo! has been gobbling up many social media sites over the past year (Flickr, upcoming, del.icio.us) I often get asked about how (or whether) we believe these communities will scale.
The question led me to draw the following pyramid on a nearby whiteboard:

The levels in the pyramid represent phases of value creation. As an example take Yahoo! Groups.
1% of the user population might start a group (or a thread within a group)
10% of the user population might participate actively, and actually author content whether starting a thread or responding to a thread-in-progress
100% of the user population benefits from the activities of the above groups (lurkers)
There are a couple of interesting points worth noting. The first is that we don’t need to convert 100% of the audience into “active” participants to have a thriving product that benefits tens of millions of users. In fact, there are many reasons why you wouldn’t want to do this. The hurdles that users cross as they transition from lurkers to synthesizers to creators are also filters that can eliminate noise from signal. Another point is that the levels of the pyramid are containing - the creators are also consumers."

Of course, 'value creation' for a media company such as Yahoo means content that attracts eyeballs, that begets participation, that begets content, that begets further eyeballs and so on. However, I think it would be unwise to then dismiss the general 'natural law' observation around how social media is created, synthesized and consumed as irrelevant in the Enterprise 2.0 context (especially since the observation is provided by someone with a great deal of experimental experience on large scales).

In the context of behind the firewall social media, maybe the key to getting more users to participate is to accept that you can't get everyone to become a content creator. The implication being that one should therefore design efforts to encourage the Empty Quarter with this in mind, and recognize that the role of Synthesizing is just as critical a role in the Enterprise 2.0 space as the the role of creation.

David Winer's view - Don't Bother to Change the Culture

Last year Dave Winer attended a session at Seattle Mind Camp 2.0 that I ran with Michael Blay, Geoff Froh on the topic of behind-the-firewall tagging.

"Dave Winer attended and described the session as a 'intense lightning-fast discussion'. However, he came to the early conclusion as part of that discussion that there was no conclusion - that is a waste of time to try and encourage employees to adopt a tagging culture to share knowledge inside corporate firewall. That users either get it or they don't. You can't force them."

At this post, Dave explained the reasoning behind this view:

"I promised I'd explain once and for all why it's hopeless to "try to get the users" to use social bookmarking software unless they're already using it. Here's why: I don't know. But I do know it never works. It's so bad that when I try to solve the problem (I'm a geek, so I fall into this trap myself, can't help it), I hack at making it easy and painless, figuring it's a user interface problem (if you're a geek you're nodding your head right now, right?) but when I make it so easy anyone would have to do it, not only doesn't anyone else do it, I don't even do it myself! Why? As I said, I don't know! Makes no sense to me at all. But there you are.
I do know that Dan Bricklin posed something like a law to explain the phenomenon, as best as a geek possibly can. Software that rewards you for doing something one percent of the time will get used (email, word processing, SimCity) and software that punishes you for doing it only 99 percent of the time will not get used (calendars, PIMs, categorizing stuff, social bookmarks). The genius of del.icio.us is that it falls into the former category, even though it appears at first to fall into the latter.
Never say Bricklin isn't a smart dude, if you remember his rule, you'll avoid hours of interesting discussions about how important it is to do something that is impossible to do."

I agree and I disagree with Winer.

I agree that if the software is useful for the individual using it, they'll use it (back to the Del.icio.us Lesson). What that says to me then, is that if the software is designed right it can succeed - if not, they won't. I got that.

But then he argues that social bookmarking 'punishes you for doing it only 99 percent of the time': i.e. if you don't always use social bookmarking then 'it' loses it's value. Here I disagree, as that has not been my personal experience. The tagging I do comes and goes in terms of how regularly and how disciplined I am in my tagging stuff. Somedays I just don't tag stuff, somedays I do. When I don't tag stuff for a few days, it doesn't mean that the value of those things I have already tagged diminishes. Those artifacts are still there. Of course, sometimes I wish I had tagged things that I didn't, but that doesn't brake the overall system. It just means it could be better.

So I'm not sure if I fully understand Winer's point here. That said, I do agree with his experience that that some people just will never 'get it'. But I don't think that should mean you shouldn't try.

Culture change can and does work if done right - I know, I've done it within Microsoft. An example is that program managers, software developers and testers are now blogging in our team that weren't before I joined the team: they just needed some encouragement, see the benefits of doing so, receive some training and be provided some support. Not all of our team are blogging of course, but enough to make a significant difference in the way we communicate with customers. And the more bloggers there are, the more that decide to blog. It has also affected the way we communicate inside the firewall too - amongst ourselves within our product team but also with other teams inside of Microsoft. More to do, but the demand for internal blogs and wikis is there. The early adopters will naturally run with these tools but others will require a little more cajoling to see the benefits.

This week, while at DevConnections I attended a session on migrating from Sharepoint 2003 to Sharepoint 2007. Halfway through, the presenter (Bill English) stopped and made the point that all the technical advice he was providing was worth nothing if there wasn't also a culture change effort too: just because the software is there doesn't mean that it'll be used. Effort is required to create awareness of the benefits, training, etc...without these things, you won't succeed.

I'd write more on this but I have to go now. In the meantime, do share your thoughts on this.