I started thinking about this more today, and I came up with what I believe is a more or less accurate picture of the high-level areas of social computing, or for lack of a better term, the community platform:

So, what’s in a community platform?  Let’s take a look…

Knowledge Management

• Sharing: the ability for users to upload, tag and rate content, the ability to broadcast what you are working on (activity feeds)
• Discover: the ability for users to browse content that others have submitted or rated highly, or the ability to search content

Social Computing

• Discuss: user-driven blogging, and SMS-integrated micro-blogging, along with email-integrated threaded discussion boards
• Collaborate: the ability to check-in and check-out shared documents (usually the common office formats: DOC, XLS, PDF), and keep a revision history, as well as simple and fast rich text editing (wikis)

Social Networking

• Profile (Reputation): a representation of who you are, what you know, and what you have contributed to the community
• Network: the ability to connect with other users in the system, create private working groups, and maintain different scopes of visibility into the activities of others

The funny thing about this picture is that these high-level concepts are the same ones that have been around for many years.  For example, a typical bulletin board system from the early 1990s would’ve offered these same kinds of features.  Sharing?  Sure – you could upload and download files.  Remember the ZModem protocol, anyone?  How about Discover?  Yep, search was a part of the best file sharing parts of a BBS.  How about Discussions or Collaboration?  Well of course, and there was even FIDOnet.  You could check-in documents into the file repo and keep track of versions.  Sure, it was all over a terminal window, but it was still a community platform.  What about profile (reputation) and networking?  Well, those pieces weren’t quite as solid.  Bulletin board systems had some notion of a profile, but you really couldn’t add people that you were "friends" with, and there was no notion that your profile was hidden to everyone except your friends.

As I’ve written before, the downturn in the economy is a prime time for companies who are looking to invest in new ERP, CRM and productivity systems to consider SaaS instead of a on-site hosted solution.  The pay-as-you-go and pay-as-you-grow model of SaaS means that companies would have an easier time forecasting exactly how much they’ll need to spend on software, although it ultimately shifts the burden of capital expenditures (CapEx) to the SaaS provider.  It’s true, though, that companies will likely become skittish about making any large investments in SaaS in a rocky economy.

As Dignan points out:

… the SaaS sector is likely to look like the rest of the software industry–the big companies will benefit in a downturn. Simply put, you’ll buy from a company you know can take a punch. In SaaS, that means Salesforce.com can take more share. Smaller fish may have to show their bank accounts to skittish CIOs.

Meanwhile, Matt Asay over at CNET News suggests that the best way to calm customer’s fears is to open source the original code, rather than offering to put it in escrow at all, the same way that SugarCRM does.

I’m not so sure about the latter approach of offering the source code up as open source, especially because as Matt points out, it diminishes the value of the assets the vendor.  It could also inadvertently give leverage to competitors that figure out how to provide hosting services and infrastructure at costs underneath the vendor’s.  Not to mention, as Dignan points out in his post: who really asks for code that was in escrow, anyways?

Ultimately I think the right approach is the one that Vinnie Mirchandani suggested: data portability first and foremost.  But I think data portability matters for a few other reasons, too:

1.) It prevents companies who invest in SaaS from feeling like they are locked into one particular suite or service provider.

2.) It creates value-add opportunities for other SaaS players to re-mix company data.  Imagine, for example, being able to explore my company’s financial data hosted in one provider with a business intelligence tool provided by another, without having to do any complex wiring or custom coding between the two.  Or being able to wire specific triggers inside of business applications to external workflow services.

3.) Companies should be able to own sensitive data internally if they decide they want to, and this could make many folks who are sensitive about where data lives today less anxious in general.

4.) One of the big problems today with existing business software is already the silos it tends to create by not offering enough entry points to business data.  If anything, SaaS providers’ motto when it comes to data is: the more ways to slice and dice it, the better.  Isn’t that what SOA (service oriented architecture) was all about?

I’m currently working with a group of wickedly smart people to build a new hosted (yes, SaaS-based) collaborative decision making platform: DecisionSpaces.

What does DecisionSpaces do?  There are lots of collaborative tools available today to help groups of people share documents and collaboratively edit pages (like Microsoft SharePoint or Wikis), but most of them offer up only a blank slate.  The space is generic, facilitating any kind of collaborative effort: working on a spreadsheet, writing copy for a new marketing campaign, developing product design documentation, etc.  But these tools are merely general purpose collaboration containers, and they don’t necessarily help in the decision making process itself.

In fact, many people revert to email when it comes to making a collective decision.  For example: imagine a group of folks trying to determine where to hold their next convention.  Should they use the old reliable location that they’ve used the last four years, or should they try something new?  Typically this kind of exercise would start over email, and quickly spiral out of control: people would be added or dropped from CC, documents would be circulated, and a decision might be made without everyone knowing exactly what had been decided.  DecisionSpaces provides a place for that kind of decision making, and will allow the group’s work to be captured and easily reviewed so that everyone in the project stays in the loop, all without clogging up your email inbox.

So why SaaS-based?  Well, first: it’s nice to be able to invite others to your decision, akin to being able to invite anyone to an instant web conference.  Having an internally hosted solution often means getting the right ports open on the firewall, having the right bandwidth, etc.  By offering it through SaaS, we’re making it easier to bring in anyone from anywhere.  Secondly, SaaS offers customers greater flexibility with pricing, allowing people to effectively pay for what they are using instead of buying software that ultimately never gets installed (known as "shelfware").  Finally, we personally believe in SaaS as the best way to deliver software to our customers.  It’s not just a business model; it’s a way to keep our software on the cutting edge without having our customers go through any kind of painful patching or update process to stay current.

Why register for the beta? The Private Beta program will begin in the first half of 2009, and participants will be chosen from the folks that register between now and the end of February 2009.  The benefits of registering include:

• Being able to use the DecisionSpaces Beta for free
• Being able to help drive the development of the product to fit your real-world decision making needs
• Getting access to special pricing once we exit beta
• Being able to sit on conference calls and web demonstrations with me and other talented and interesting individuals from the DecisionSpaces team

If any of that sounds interesting to you, please visit DecisionSpaces and register for the private beta today.

I’ve previously outlined the switch from IT capital expenditures to operational expenditures, and certainly that will be one area that a lot of CIOs and IT Directors will look at when considering their alternatives.  But that’s only the financial motivation, which doesn’t really address the real-world concerns that corporations as a whole will legitimately have about porting some services over from internally hosted services (which are, for better or worse, considered “secured”), to SaaS delivery.

So what services are easier SaaS targets, and why?  Here are a few of the common IT services that I hope to see provided through SaaS at more companies by the end of 2009:

Email: it’s ubiquitous, it goes out across the web unencrypted for the most part (although there are many ways to encrypt emails), and we always want it to be available everywhere.  Email’s close cousins are also good targets: calendaring, address books, and shared discussion folders would all be easy targets for SaaS vendors.  It would be great, for example, to see Microsoft host Exchange Server on-demand.  I’m sure lots of folks would like to have 7gb+ email inboxes that are automatically search indexed by a remote system for speedy searching.  And for IT, there would be numerous benefits, but perhaps the two most important: no longer having to manage the infrastructure necessary to support a globally accessible email server, and being able to readily keep track of the storage costs per each user and department.

Wikis: wikis have become more widely used as a collaboration tool for teams to work together on planning, documentation, and research in the last few years.  The best wikis are accessible anywhere, anytime to all team members at high speed.  All too often Wikis are hosted underneath someone’s desk in the office.  And when they are on a corporate infrastructure, they usually suffer from slower network links between offices.  Some wikis deal with more sensitive content that may provide pause for IT departments before jumping to a SaaS offering, but many are very simple alternatives to emailing documents around. And obviously, if email is already delivered as a service, there’s no reason Wikis shouldn’t be far behind.

Blogs: especially outward-facing company blogs, are easily delivered through SaaS.  There’s no reason they shouldn’t be delivered through SaaS: the whole point of the company blog is to share content, ideas and thoughts with your customers.  You want maximum accessibility and minimum delays for customers to be able to reach your blog. 

Support Sites: customer support sites, whether they be for software products or physical goods like shoes, bicycles, or hammers, are generally structured the same: self-service help, discussion forums, troubleshooting guides, product documentation, and technical assistance (although one would hope that a hammer is pretty self explanatory).  These sites also need to be available to a broad audience through a fast connection (as an aside: ideally customer support sites today should be looking at supporting OpenID or alternate forms of identification, with potentially hooks into social networks, to prevent people from having to create additional usernames and identities.).

General Purpose Web Hosting: company web hosting is another no-brainer when it comes to SaaS.  With perhaps only the exception of very large businesses that only sell goods online, most company websites can easily be hosted through a 3rd party company instead of on-site.

While writing this, I thought of one final point that’s worth mentioning: as data moves onto SaaS providers, indexing it through search engines to provide a single point of search entry for organizations will become much more challenging.  Perhaps a service in itself that will soon come about: enterprise search indexation (and content tagging) as a service.

I agree that it takes very little time to get started with a new Wiki.  The site is very fast, and generally very easy to use.  It only took me about 30 seconds to get a Wiki up and running.  Editing pages is smooth and pretty reliable.  Their rich text editor is pretty solid and speedy.  As with most Wikis, it’s very easy to keep tabs on who’s been updating pages through a Recent Updates page.

Security is pretty straightforward.  It’s easy to add a bulk list of users just by specifying their email addresses, and it’s easy to lock down pages to various levels of editing and viewing by guests and authenticated users.  Premium accounts can also whitelist and blacklist IP addresses.  It would be nice if PBWiki supported LDAP connectivity.  It doesn’t appear to be available as of yet, at least none that I could find in the documentation. Updated: Thanks to Chris Yeh from PBWiki who pointed me to the API documentation for LDAP integration with PBWiki. http://pbwiki.com/api_v2/#Delegated_Auth

PBWiki is really designed to be a true SaaS offering.  It supports multi-tenancy very well.  Premium accounts can even add have their own custom domain name to support wiki.[your domain].com.

A few things that could be better: there’s no Wiki syntax.  For anyone accustomed to using Wiki syntax with other Wikis like Atlassian Confluence or MediaWiki, Wiki syntax is shorthand for formatting (like *bold* or /italics/) that gets converted to HTML when the page is rendered in the Wiki.  The result of that is that when you have edits which only pertain to formatting, PBWiki can’t tell you what the difference was.  The folder structure isn’t very complex — you can only have one level of depth to a folder, and it’s not possible to build navigation around parent/child topics as with other Wiki solutions.  It’s a bit amusing to see the FamFamFam Silk icon set used so heavily, although many Wikis have adopted it as their icon set.

Overall, though, PBWiki is certainly a fantastic out-of-the-box on-demand SaaS-style Wiki.  I definitely found it more useful than Google Sites, a similar offering from Google.

PBWiki is now supporting over 500,000 wiki pages.

As an open question to my friends over at Atlassian: when are you going to make your on-demand version of Confluence as easy to deploy as PBWiki?  I suppose it’s a question of: does it make sense for Atlassian to compete in the SaaS Wiki market given that the majority of usage for Atlassian is software development Wikis.  That’s perhaps one SaaS sore-spot.  I could imagine that some software companies might feel a little nervous about the idea of putting their software development notes up on the web where anyone might attempt to spy on them. 

But I have to imagine there are also a lot of other research organizations that would like to use Atlassian in a SaaS mode to cut down on the cost of hosting it themselves, and obtain more flexible pricing.

Here’s a quick round-up of 5 things that can kill a web project, and how to avoid them…

#1 No documented governance

When building any web application primarily driven by user-generated content, it is essential to document the governance process by which content will be updated and added, who will have access to update the content, and who will decide when content needs to be removed or refreshed.  Without this documentation vetted and signed-off by all interested parties, you may find yourself in a negative situation where the true content owners within your organization don’t have sufficient control over the process to update content within your web application.  The end result: content may be inappropriate to the audience, or may not be updated frequently enough.

#2 Lack of required content

Every good extranet or intranet lives and dies by its content.  Without useful content either being created by entitled owners or consumed by a target audience, there is simply no way that your web project will succeed.  It is important to regularly survey your audience to insure the content you have in your extranet or intranet meets the needs of your audience.  It’s also ideal, if possible, to find a select screening group of users or audience members that can give you initial and early feedback about the content that you plan to make available on your extranet or intranet.  That can also help you determine how to properly document the governance process.

Make sure that as a part of your planning process and governance documentation that you’ve identified the correct people within your organization to own content and keep it up-to-date.  It may also be useful to plan how you will identify unused content and weed it from the system.

#3 Poor usability

It cannot be stressed enough: poor usability will absolutely kill an extranet or intranet.  Poor usability can arise from a number of problems: missing or inaccurate search, confusing navigation, poorly placed links to important information, or confusing methods of getting content updated.

As with insuring that you have the correct content, making sure to bring on a group of your target audience early on in the process will help get early feedback that could allow you to make corrections where needed.

Don’t be afraid to invest time early on in prototyping your site with any kind of visual prototyping tool.  And don’t forget that in a pinch, pen and paper prototypes can still lead to a good deal of feedback from your users.

#4 Incomplete or poorly documented use cases

Whether you’re building a commercial web application or an extranet or intranet, not documenting the types of things that you expect your users to do will certainly lead to problems.

Before venturing out on your next project, make sure that a part of the project documentation includes use cases.  As with #2, having this documentation ahead of time will make documenting the governance for your extranet or intranet much easier.

To build a good use case, start with a good user persona, or a composite of the type of user you expect to browse your site.  List out the common tasks you expect this perosona to complete, such as: searching for a Knowledge Base article, adding a new service request, downloading a whitepaper, or collaborating with team members.  Describe in detail how you expect them to complete these tasks.  This also forces you to think more about your information architecture, as described in #5.

#5 Poorly planned information architecture

Information architecture — how you arrange your navigation, your document taxonomy, your application screen flows — is commonly overlooked when building a new extranet or intranet.  This is an area where a little investment in time can pay off big in the end.

Often times, when information architecture is overlooked or ignored during a project, you may end up with a site that gets a few hits directly to important content, but the rest of the site remains untouched.  This is usually caused by a poor organization of the information available in the site.

Having your extranet or intranet have consistent and understandable terminology, intuitive navigation, and a proper taxonomy for your documents will increase your site’s usability, and allow more users to feel comfortable browsing your site.

Planning out your site’s information architecture is very similar to building a corporate taxonomy, which is explored in more detail in the post Building a Corporate Taxonomy.

There’s a common but frequently overlooked aspect to much of the current web technology under the branding “web 2.0″: transparency. Everyday interactions that used to be opaque are now increasingly visible to everyone, from everything to how you’re feeling about the weather, to what music you’re listening to, and more. Bees have been doing something like this for millions of years: locating sources of pollen and returning to the hive to broadcast the flight pattern to recruit other bees.

Sites like twitter and facebook make it extremely easy to share random thoughts and updates on what you’re doing, what you’re thinking, etc. But do these types of applications have any real function in a business environment? Is it all just a bunch of buzzing, or can real work be accomplished? And, perhaps most importantly: does social transparency have any real place in a business environment?

The Business Value in Social Computing

Much of what goes into consumer-based social applications like twitter and facebook are simple updates, such as “just ate a burrito.” At first glance to someone who’s not yet involved in any of these sites, their reaction might be: what’s so useful about all this chatter?

Tacit Knowledge Sharing

While it may not be immediately obvious: regular updates about even the most mundane tasks are an important form of tacit knowledge sharing. Ultimately, having an easy platform for each individual user to share their status, ideas or just random thoughts is a perfect way to allow others to capture and harness information that may not have otherwise been known to them.

A business example: I’ve just finished a new whitepaper relevant to the auto industry. If I had a platform internally where I could broadcast that as my status, anyone who was searching for an auto industry expert could identify me as someone with experience in that area. Knowing that whitepaper was available might also lead sales reps who follow my status to increased sales, or having the right materials to close their deals in a timely manner. It’s a simple but powerful example of how social transparency in business can lead to increased efficiency in information sharing.

Avoiding Duplication of Effort

A common problem in organizations of all size is the duplication of effort, or simply: two people working on the same task at any given time. By sharing information about what I am working on and when I am working on it, I can effectively provide a way for my co-workers to avoid repeating the same effort.

The savings here are twofold: my co-workers will invest their time where it’s appropriate, and my work will be recognized and valued by my organization.

Teamwork and Team Building

The great thing about applications that help increase social transparency is that it helps facilitate a kind of personal sharing communication that might not otherwise exist within an organization. As a person working within an organization, sharing little bits about myself gives the people I work with a broader vision into the types of things I do on a daily basis, and can lead to opportunities for them to share in the work that I am doing.

Communication is the key to successful teamwork, and any platform that helps facilitate frequent and relevant communication will necessarily lead to more successful and rewarding teamwork.

Fostering Social Transparency in the Enterprise

Once the benefits of increased social transparency are clear and applicable to your organization, what are some ways to begin to foster that type of communication?

Encourage and Enable Team Communication

Before beginning to invest in any kind of social computing platform, it’s important to insure that the right team environment exists where teams across your organization will feel empowered to communicate information freely. This may simply not be possible for all organizations, many may be structured intentionally to prevent the free-flow of information for privacy, security or safety reasons.

But if team communication is feasible, it should be highly encouraged before beginning on any social computing pilot, simply because if teams aren’t communicating today, they won’t be likely to change their behaviors just because of a new application available to them.

Pilot and Prototype

Pick a target group of people who you believe will be the “lead users” for your pilot program, and begin working on an ideal prototype application. This prototype application should revolve around a particular use case or set of use cases where you intend to increase the amount of transparency.

For example: if you are working in an environment where one team frequently produces and updates content that another team uses, select key users from the team producing content and the team consuming content. Another example might be for teams where members are frequently traveling and need to post their whereabouts easily so that other team members can locate them.

Once you have a strong set of users and use cases, you can select the platform for building your prototype application.

Fun is a Part of the Equation

A final key point in applying social transparency and social computing concepts in your business or organization is to understand what it is that everyone is talking about, and why sites like twitter and facebook are so popular. Simplicity, usability, and “fun to use” are important aspects of social applications.

If you haven’t already done so, take a moment to sign up for sites like twitter, facebook, linkedin, del.icio.us or pownce. It’s important to get a feel for what works and doesn’t work. Once you begin using these applications, you’ll notice very quickly that the “fun” factor is not just about the fact that applications like facebook have games. The fun factor is in using the application, and being productive in it without wanting to smash your head into your monitor.

Have something to share that I may have missed? Let me know in the comments!

While his assertion may be a slight bit of exaggeration aimed at stirring up debate, I do believe he is correct in one regard: email has hit the extent of its usefulness as a platform for collaborating amongst a group of people.

But will we see an end to email? And why do people keep using it if its an inefficient method of collaborating?

The problems with email

I don’t think that we’ll ultimately see a complete end to email, but certainly we all need better tools to collaborate.

• When you’re on an email thread, your email inbox will quickly get flooded with multiple replies. In those cases, an issue may resolve itself before you’ve even finished catching up with the entire thread.
• Key people are often left out of the discussion by mistake on email chains, and attempts to get them back in the loop don’t always work. How many times have you seen “Adding [person] to the thread” and then watched someone reply to a message earlier in the thread, once again losing the person that was supposed to be on the thread?
• Documents that get attached to email threads get updated out of sequence, losing changes.

Why do people still use email to collaborate?

All of those problems were supposed to be solved with products like SharePoint and Documentum, but for some reason, most people in organizations that have these systems still don’t use them as a primary method of collaboration. Often times an issue will be initiated and closed entirely over email without any of the supporting documents ever being captured in an enterprise document management or collaboration system. Why is that?

• Email is still the most widely available application in a mobile setting. An average business user is more likely to have access to email from a mobile device, such as a BlackBerry or smartphone, and in a time-sensitive situation, people revert to emails to insure a quick turnaround.
• Most current enterprise collaboration systems lack a good email bridge. It would be useful, for example, to be able to upload a new document to SharePoint or Documentum by simply attaching it to an email and sending it to the server to be processed.
• Most enterprise collaboration systems feel clunky. In the arms race to build it bigger, badder, and looking more like a desktop application, the major players end up adding too much functionality into the product, neglecting key usability points that have long been solved by consumer web applications.
• Most enterprise collaboration systems lack a solid mobile interface. In part this is because their customers have traditionally not opted to purchase monthly data plans for their employees, but with mobile devices providing richer Internet browsing capabilities, this is rapidly changing.

Wikis: a modern collaborative environment

As a person with a software development background, my preference for a collaborative environment is a wiki system. But to the average business user, a wiki is still a “geek thing” that they don’t quite understand or feel comfortable using. That’s largely the reason that they’ll revert to writing an email or sending a Word document. Over time I’m sure that more business users will expand their comfort level with wikis, but there is also room for improvments in the features of wikis to make the average business user more confident using them. Certainly they have evolved: most opensource and nearly all commercial wikis include both a plain text and rich text editor, something that was completely absent from the first incarnation of wikis.

Conclusion

Email as a collaboration platform has certainly reached the extent of its usefulness in that arena. But email certainly has uses beyond collaboration, and it will certainly live on as bridge to future collaborative systems. As wikis and other types of emerging collaborative environments mature, these tools will be considered as necessary as email to the daily life of every business user or knowledge worker.

UPDATE 6/14/2008: The New York Times featured an article about “email overload” and how companies like IBM, Microsoft, Intel and Google are fighting against it.

Emphatically: no.  Every organization that generates or manages volumes of information should have and maintain a commonly shared taxonomy for organizing, storing and accessing that information.  Just so we’re clear: when I say “taxonomy”, I’m not talking about stuffing dead animals.  That’s taxidermy, and I’ll save that for another post… Maybe.

A taxonomy is simply a set of commonly used terms to classify a piece of information.  In practical terms: a corporate taxonomy is a hierarchy of related terms used to organize documents and information used across the entire company.  An example of a single branch within a corporate taxonomy would be something like: Product Line X > Product Y > Product Y Feature Z

So what are the benefits of a corporate taxonomy, and where do you start?  Let’s take a look.

The Benefits of a Corporate Taxonomy

Before I go into some suggestions on how to build a corporate taxonomy, let’s examine why.

• Spend less time looking and more time discovering documents and information. Arm your sales force with the right information to close more deals. Bring projects in on-time and under budget because you’re able to locate the how-to when you need it.  Make cross-selling a reality instead of a pipe dream.
• Spend less time publishing and more time discovering documents and information. Having a common hierarchy and a process for determining where documents get published makes it easier for your knowledge workers to know where to publish their documents and information.  Some of this can be automated as well, but having a broadly understood classification of information prevents confusion and lowers the likelihood of documents and content being published incorrectly.
• Unify the vocabulary of your company or organization. Often times if a company or organization lacks a company taxonomy, they may also not even agree on a common vocabulary.  This can especially lead to confusion and inefficiencies when disparate groups from throughout the organization attempt to communicate with each other.
• End-user tagging still generates random terms at best. In a company setting, it may not even be possible to engage all users to tag information, but worse than that, critical information can end up being categorized incorrectly.

Building a Corporate Taxonomy

Starting a taxonomy from scratch can be challenging, especially if you don’t already have a commonly used set of terms across the enterprise.  This is by no means a comprehensive list of the steps involved, but rather more of a pointer to get you started in the right direction.

• Get corporate sponsorship before you begin. Effectively building a corporate taxonomy requires that you have people at the right level of the organization who can support your final decisions.
• Identify the key stakeholders and keep them constantly informed. This is pretty much a generic requirement for any major project.  Are there people throughout your organization that will be significantly affected by your decisions?  Keep them informed, and set expectations as to how you will communicate the final outcome.
• Poll your consumers for the terms they know and use today. It’s likely that large groups of users already use common terms for the various classes of information they generate today.
• Try to keep the taxonomy topical and avoid document classifications in the structure. The types of information available typically can be understood by looking at the individual content item itself rather than navigating to it through the taxonomy.
• Try to avoid having more than three layers of depth. When information is over-classified, browsing for it and finding related information can become difficult, if not impossible.  People lose faith in the taxonomy and may be unwilling to use it.
• Present a taxonomy skeleton to key members of your organization. Ultimately it’s up to the business stakeholders and your sponsors to sign-off on the final version, but don’t be afraid to assert a clear recommendation where it will clearly benefit the structure of the taxonomy.
• Make sure there are no empty branches. Once you ultimately define your taxonomy, make sure that there are no empty branches, or branches that only have one or two pieces of information.  It may be impossible to avoid this, but having a lot of empty folders may ultimately lead to a lack of confidence in the overall organization, or it could be a sign that there are too many layers of classification.

Tagging in the Enterprise

If you’ve read this far, you may believe that I’m underestimating or even dismissing the power of tagging.  Indeed, I do believe that tagging is essential to adding a further layer of classification over content and information, and that it can add additional value.  However, imagine for a moment a public library that decided not to conform to the library of congress standards for cataloging their books.  Could we expect them to locate the books we need if they didn’t agree on a common classification system?  It would seem unlikely.

In fact, products available on the market today, such as librarything.com, offer services for libraries to extend their catalog systems with user-defined tags.  Amazon.com follows a similar structure, in that they allow users to tag products, but ultimately they maintain the overall structure. This is the right hybrid model: a common, reliable scheme for classifying books and products, with user-extensible metadata that can supplement the taxonomy.

Think I forgot to mention something?  Care to disagree?  Let me know in the comments!