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.

Team Hosted combines the enterprise features of Confluence with the convenience and affordability of SaaS. It lets users:

• Edit pages using Microsoft Word
• Utilize free third-party plugins like EditGrid spreadsheets and Gliffy diagrams
• Attach and share documents, photos and video (up to 10GB)
• Start immediately. No installation or payment is required

You can get a free 30 day trial of Atlassian Confluence, which might be a good way to test drive it before you decide to buy into a monthly Enterprise hosted or on-site license for Confluence.

There’s no question that Wikipedia is widely used across the Internet.  Wikipedia’s comScore rank was number 7 in March 2008, with over 58 million unique visitors.

And given their traffic, there’s no question that the cost of running their infrastructure is going to be high, and growing annually.  Cloud computing guru James Hamilton, who recently left Microsoft to take a post at Amazon’s Web Services division, wrote about Wikipedia’s architecture.  Among the interesting points: Wikipedia gets 50,000 http requests per second, and has over 18 million objects (pages and attachments) in the English version alone.  The infrastructure powering includes a total of somewhere around 300 servers.

One alternative that has been discussed is the idea of adding advertisements on the site.  But that may not ultimately provide enough revenue for Wikipedia to pay off its operating expenses, and it could open the door for alternative services to pop up that don’t include advertising.

So where would that leave Wikipedia?  If they go the advertising route, and that ultimately doesn’t pan out, could they switch to a pay-for-access premium service?  And would customers pay?  It might be an alternative to save themselves, but I’m not sure how many people would ultimately pay for access to Wikipedia.

I suppose one other possibility for Wikipedia is that they get acquired by some other entity that wants to leverage them only for the brand name recognition.  A larger player, perhaps Amazon or Microsoft for example, could easily afford to take the annual loss, and treat it as a method of extending good will amongst their customers and potential future customers.

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.

A technical preview of these web-based tools was expected to be out and accessible to the general public by now, but apparently those plans have changed.

Ina Fried over at CNET posted an article about Microsoft’s web-base office tech-preview:

It’s currently being used by fewer than 1,000 Microsoft employees, as part of a test that started last month and is slated to go through February. Consumers won’t be able to try a test version of the products until sometime next year. Microsoft isn’t saying when, but I’d say you’ll have plenty of time to try the Windows 7 beta before you have to worry about testing the Office Web apps.

I’d previously written about Microsoft’s strategy with SharePoint being flawed in that they weren’t focusing enough on emerging web-based editing tools such as Google Docs and other Wiki-style solutions and instead focusing on integration with the desktop version of Microsoft Office.  After personally seeing a preview of Microsoft’s plans for Office 14, I can say that they’re heading in the right direction.  The big question will be: can they execute on the vision?  Plus, with lots of companies tightening their belts, perhaps for an extended period of time, will more companies give alternative desktop publishing tools, including OpenOffice, another shot at replacing Office?

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.

Fedora Core

Link: http://fedoraproject.org/

What it does: Fedora Core is a free linux distribution. As with most free linux distributions, it usually contains the “bleeding edge” code from the OpenSource projects that comprise the distribution. Generally, this is desirable for people looking to take advantage of new features, but for enterprise servers, or for applications requiring a more stable and tested codebase, distributions such as RedHat Enterprise Linux or SuSE Enterprise Linux are more appropriate. Fedora is my particular favorite, but Debian and Ubuntu are also very solid.

PHP5

Link: http://www.php.net/

What it does: It’s PHP! Duh! … Fedora Core features this in an RPM package, and you can install it during the installation process.

Apache2

Link: http://httpd.apache.org/

What it does: Apache is the front-end webserver required by all of the other OpenSource projects on this list. As with PHP, it is included in the Fedora Core distribution as the HTTP server, and you can install it during the initial installation process.

mySQL

Link: http://www.mysql.com/

What it does: mySQL is the database back-end required to store data for all of the OpenSource projects on this list. As with PHP and Apache, it is a part of the Fedora Core distribution, and can be installed during the installation process.

MediaWiki

Link: http://www.mediawiki.org

What it does: MediaWiki is a fantastic OpenSource wiki platform. It’s fairly straightforward to set up and deploy, and you’ll be up and running in no time. MediaWiki is the platform that supports Wikipedia.

Drupal

Link: http://drupal.org/

What it does: Drupal is a web content management system. Drupal includes templates, making it easy for departments to start building their own web pages quickly and easily.

phpBB

Link: http://www.phpbb.com/

What it does: phpBB is a web-based discussion platform (aka a bulletin board system, or forums). Having a web-based platform for discussion allows you to capture tacit information that might otherwise be inaccessible in email discussions and make it readily available to anyone searching for it on your Intranet.

Horde

Link: http://www.horde.org/

What it does: Horde is a web-based email, calendaring and task management system that is quick to set up and deploy.

WordPress

Link: http://www.wordpress.org

What it does: WordPress is simply the best PHP-based blogging application available.

Coppermine

Link: http://coppermine-gallery.net/

What it does: Coppermine is an easy-to-use and powerful image gallery application.

Know of anything I missed that should be on the list?  Let me know!