However, by design, tagging requires users to have some sort of writing privilege, which greatly limits its reach potential. Practically speaking, it means that if a user wants to tag an item on a system (e.g, Youtube, Flickr, or delicious) he or she must have an account on that system and be logged in at the time of the operation.

While this is probably not an issue for major Internet services, it can be a chicken-and-egg issue for new, upcoming services that do not yet have a large enough community to build a meaningful tag cloud. How can a new service maximize its community tag cloud if it doesn’t yet have a community?

Here is where the concept of Search Oriented Tagging comes in. The concept is that users do not tag anymore but just search. The service will extract keywords from the search query and track the user’s interaction with the results. The system will then apply statistical logic to automatically tag the interacted entities.

Although this approach is not intended to be a substitute for traditional tagging, it can also complement tagging mechanisms for large community sites.

Search-oriented tagging offers these benefits:

• Maximizes tagging participation: By transforming tagging into a registration-free functionality, search-oriented tagging maximizes its reach to the service’s full audience (i.e., registered users and visitors)
• Scales with the community: Search-oriented tagging’s statistical nature scales well with site content and community growth.
• Search synergy: Since the function is search-centric, this form of tagging can refine the search relevance logic.
• Time-sensitive: Since search-oriented tagging is more transparent and pervasive, it can better capture time-sensitive tags such as "harmony," "Google Chrome," or "lipstick on a Pig."

I am sure that this concept is not entirely new, and that search engines have similar logic to improve their results relevance. However, by applying this concept to tagging, new services can more effectively build a relevant tag cloud while developing their communities. The concept can also be applied to large community services to make their tagging systems more agile and time-sensitive.

If you aware of any services that are using this mechanism, feel free to submit a comment.

1. Social Networking is the method of connecting and communicating with the purpose of increasing knowledge (of people and of domain).
2. Collaboration is the method of organizing knowledge and expertise to efficiently accomplish a particular task.

So, Social Networking is about sharing and discovering, and collaboration is about organizing and creating. Although informal, the point of these definitions is to demonstrate the similar but inherently distinctive meanings of collaboration and social networking.

The latest challenge for an enterprise is that social networking has undergone significant innovation cycles, mostly on the consumer side, and collaboration has not kept pace. As a consequence, an enterprise is often tempted to substitute collaboration by social networking, which could lead to an oversized enterprise social network with very little productivity gain, or even a loss, due to the over-communication side effect.

In my opinion, enterprise collaboration is still too unstructured, fragmented, and, I would even say, immature. Most users became accustomed to unnatural and inefficient ways to partner for the most basic task, such as document collaboration. Some collaborative solution providers tend to offers partial results for fear of empowering or promoting their competition. For example, Google has an interest in luring users away from the Microsoft Office application suite, so the company consequently orients its technology and innovation toward this business goal to the detriment of the overall user’s value. Interesting solutions such as SocialText, Confluence, Jive, Yammer, and 37Signals are trying to tackle this opportunity, and while they are indisputably useful and innovative, significant untapped opportunities remain.

The key to designing the next generation of collaboration solutions is to reconsider the ways that software and services can help people who are collaborating from the bottom up. Often times, collaboration software attempts to accomplish too much, and often finds itself obstructing user workflow. I developed the following seven design principles, based on my experience with building collaboration software:

1) With, Not Against, Email.

Although we might first think “email is broken” when we want to build a new collaboration system, this is a bad thought to consider. Instead, remember that email is a popular, easy-to-use type of program. In fact, email is often the first and last application people use every day. In short, do not build a system to bypass email, but rather a system that enhances email.

2) With, Not Against, Office.

For a long time, there has been an emotional (or business) trend among professionals to terminate the office desktop software era. Although some of the rationale behind these wishful thoughts is understandable, the collaborative solution would fare better if it would learn to work seamlessly with desktop office files and software instead of trying to circumvent them.

Users do not want to import or export files, but rather, they want to create, save, share, and comment on documents from any location, such as desktop, Web, or mobile, whether they are on or offline.

In other words, office desktop software, including word-processing, spreadsheet, and presentation programs, are just as pervasive to be considered a part of the operating system, as is the Web browser, but in a much less controversial way.

3) Individual Productivity as the End, Group Collaboration as the Means.

Ultimately, we live in an individualistic and competitive society, and the best way to build an effective organization is to align individual and organizational interests. To this end, from the beginning of time, organizations have hierarchically organized themselves with clear accountabilities and a clear chain of command.

Thus, organizations require the tools and processes to optimize their entire structures by empowering each element of their organization, from the individual worker up to the top manager. With different roles come different needs, but if the tools exist to make each role more efficient, the entire organization will maximize its execution potential. Maximizing group productivity might be the right path to make a specific role more efficient, but it is just the means and not the end.

4) Extensibility Over Completeness.

When developing a collaboration system, it is a natural inclination to try to build a full set of shared applications. Some might try to build email, content management, calendar, web conferencing, and instant messaging, while others might focus on a more sophisticated set of applications, such as project management, people-friendly wikis, issue-tracking, and collaborative workspaces.

While some of these modules are necessary, system extensibility is as important, if not more. Effective collaboration systems must be customized and enhanced by the people who are collaborating, and consequently, the applications must be extensible. The trick is to strike the right balance of pre-built application and extensibility capabilities. Because this is where most collaboration systems have failed, it is where the biggest opportunity resides. Hopefully the PaaS movement will result in useful concepts that can be applied to collaboration systems.

5) Software as a Service (Saas) AND Software.

Another current market tendency is to try to oppose enterprise software (i.e., “on-premise software”) versus SaaS solutions (or “applications in the clouds”). I was recently a Red Herring panelist in San Jose, where some CEOs predicted the slow death of enterprise software and the pending victory of the SaaS way.

While I am big believer in the SaaS business opportunities and the first one to advocate beginning enterprise solutions from a SaaS angle, I believe that a complete collaboration offering ultimately needs to support all the deployment modes possible, including the hybrid ones.

I agree that today’s “enterprise software” is broken and has become increasingly (even ridiculously!) expensive to extend and to maintain. However, the solution is not to remove choice from the users, but rather to fix the problem at its source: the enterprise software architecture. (see good post from Neil Robertson on Why enterprise software is Not dead)

6) Asynchronous Over Real-Time.

Software vendors occasionally think that they have an embryo of a collaboration system because they have some real-time technologies (e.g., web push technologies for co-browsing). However, I disagree. Real-time technologies are good tools to build a collaboration system, but they are no more collaborative than any other low-level technology. In fact, Facebook, and before that, email, has shown that most collaboration happens in an asynchronous fashion rather than in real-time. Facebook CEO Mark Zuckerberg articulated this fact in one of his keynote addresses, where he discussed the increasing number of opportunities for two people to communicate if they do not have to be at the same place at the same time. Although obvious, we technologists often get overexcited by our own technology.

7) Social Networking Inside.

Last on my list is social networking, because at this time, it is overhyped. It is also last, because a system that follows the first six points would already be relatively unique. Last, because in the end, it will be put first anyway. Nevertheless, a better-connected organization is a more effective one, so social networking practices and technologies are great ways to improve an organization’s internal connectivity.

So, here it is, a first take at seven design principles for the next generation of collaboration solution. In collaboration, we have assumed for too long that users will learn new ways of doing things that enable them to accomplish the task at hand more quickly. This, unfortunately, is not true. Rather than assuming that users will adapt to the software, it is the software that should adapt to the users. In short, do not ask a user to spend time in order to save time.

Having worked for many technology provider companies (e.g., Netscape, Oracle, and Adobe) and being a developer myself (mostly on weekends), I have always been fascinated by the dynamics and trends in the developer industry. I think that, coupled with the open source and software as a service dynamics, this industry is experiencing an auspicious time for interesting technological and business opportunities.

If you happen to build a [Web] developer strategy for a company or a project, you will often need to have some sort of representation of this market. To this end, I have been developing a simple—but useful—representation of the Web developer community in the form of a spectrum which I have called the “Web Developer Spectrum.”

The Web Developer Spectrum consists of four main contiguous sections, from Enterprise Technology Developers up to Hackers/Hobbyists. It is important to note that an individual developer may belong to multiple sections, depending on the nature of his or her projects at a given time.

Here is the representation and description of this spectrum.

Enterprise Technology Developers

The Enterprise Technology Developers category consists of developers who work for big technology companies, such as Oracle, IBM, and Sun, and create technologies and standards that will be packaged in complete product offers targeting large enterprise IT departments.

These developers tend to be focused on architecture, completeness, and standardization, sometimes at the cost of simplicity and accessibility. Compared to other developer segments, these developers usually have an adequate amount of time and resources to get their job done.

Some good examples of technologies coming out of this segment are: J2EE, JSF, EJB2.x, and SOAP. As previously mentioned, some of these technologies, especially EJB 2.x, could be considered by some enterprise developers a little bit over-designed. EJB 3.x has addressed some of these issues by adopting the persistence model from alternative open source frameworks, such as Hibernate.

Business Application Developers

This segment includes developers from system integrators, such as Cab Gemini, Infosys, IBM-Services, and developers from various enterprise IT departments. The main priority of this segment of developers is to build and deploy enterprise applications in order to maximize the overall business productivity.

These developers are usually application-centric, meaning that they focus mostly on bringing the right functionalities to the right users in a timely manner. They tend to favor technologies with high returns on investment (i.e. with the highest “application-out/time-in” ratio), and they usually like to mitigate risk by contractual relationships with technology “vendors” (i.e. product licensing and support agreements).

JSP, ColdFusion, asp.net, Spring, Hibernate, and XML-RPC are the types of Web technologies used by the business application developers. Many of these developers are coming from the 3GL/4GL client/server development world, and often require quite extensive training to learn these new Web development paradigms and tools.

Web 2.0 Developers

By Web 2.0 developers I mean developers who build Web application for consumers, such as Digg, Delicious, Facebook, Bebo, Twitter, Craigslist, and many other Web companies. The successful one tends to start small and scale fast, while the others tend to move from project to project until they find the one that can attract a good user community.

Web 2.0 developers tend to be user-centric, prioritizing application simplicity and design over completeness. Web 2.0 developers tend to like dynamic, simple, and scalable technologies, such as Ruby/Rails, REST, and MemCache, Java (minus J2EE), to name a few. This is a relatively difficult business for technology and tool vendors since this community is very self-serving and usually pushes technologies in the opposite direction from what a typical enterprise would require (scalability vs. transactional).

Hacker & Hobbyist Developers

Last, but not least, there are the hacker (in the open source sense) and hobbyist developers. While many of these developers are actually paid to work on their projects, some of them (the hobbyists) code mostly for fun and self-satisfaction. This segment could be another spectrum in itself, but I combined it for simplicity.

Great quality products, such as PHP Gallery 2.x, Wordpress, and PHP BB are coming from this community, as well as some smaller projects, such as greasemonkey, and other application plugins. This community tends to be self-serving as well and extremely proficient at fulfilling its own needs.

Hobbyists tend to use more scripting language, such as Python, PHP, Javascript, and other accessible technologies, while hackers tend to go relatively deep in the software development stack to accomplish the required tasks.

A few weeks back, I showed this spectrum to Rich Levandov from Master Head Venture Partners, and he raised a very interesting point. Prior to the open source development, technology vendors, such as Oracle, Sun, and IBM, represented the largest developer community on the market, and, consequently, were the main technology sources for the industry. With the popularization and maturation of the open source development and distribution model, community-created technologies have become more and more relevant, to the point where they even eclipse vendors’ technologies. AJAX and Hibernate are probably the most recent examples of such a trend. I still see major technology vendors making most of the technology distributions (given the enterprises’ need to mitigate risk); however, I think they will have to adopt more and more community technologies and standards if they want to stay relevant in the marketplace.

Obviously, this representation in not perfect, but, many times, it has helped me to visualize “developer” business opportunities. I hope this will be useful to others, and I definitely welcome any and all feedback.

SOP services can range from application aggregation, presentation, linking (e.g, Mashup), provisioning, componentization, and context augmentation (e.g., Social Graph and common application data). As SOPs mature, it would not be surprising to see these platforms offer most, if not all, of the traditional application platform services in a service-oriented manner, such as application testing, versioning, data migration, and much more.

In the consumer space, the best SOP examples would be Facebook, OpenSocial, and Ning. In the enterprise, a good example would be SalesForce.com (including their latest Force.com addition) and some of the newer smaller players such as Coghead, DabbleDB, and BungeeConnect. Note that SOP solutions can be offered as a hosted service (Platform as a Service, aka PaaS), or can be packaged as a product (not as common yet). In many ways, enterprise portal architecture can be considered the SOP ancestor.

We can identify four distinct but complementary main SOP access modes. Most SOP providers (such as Facebook and SalesForce.com) offer more than one access mode. Others, like OpenSocial, have thus far focused only on one.

Below is a simplified visualization of these modes and their corresponding descriptions.

A) Proxy Mode:

In this mode, the SOP is in between the user-browser and the application, and proxies all browser requests to the applications. The best known example of this model is the Facebook FBML application model.

Here is the simplified application lifecycle for the SOP Proxy mode:

1. Each page request goes through the SOP server, which forwards the request to the application with some additional SOP context (e.g., Identification and Social Graph information).
2. The application then returns the requested page to the SOP server in a specific presentation format (e.g., FBML for Facebook). The SOP server then translates the “SOP-formatted page” into a standard HTML/AJAX format for the browser to read.

This mode allows developers to focus on the content of the application while reusing pre-built SOP components and delegating presentation to the SOP server.

The main caveat of this approach is performance, since each page request [usually] requires an additional http-request to get the result back to the user. Another caveat is the SOP dependence. Usually, this model also requires applications to output a proprietary XML (e.g., FBML and SNML), which limits application portability.

B) iFrame Mode:

In this mode, the SOP server is between the browser and the application only at initialization time, and all subsequent application users’ interactions are forwarded directly to the application (usually using the browser’s iFrame client-sandboxing mechanism). This is commonly known as the Facebook “iFrame mode,” or the not-yet-released Google OpenSocial “type=URL.” This mode also requires the SOP server to have a strong set of REST/SOAP APIs, since this will be the only way for the application to access SOP context information (e.g., Social Graph).

Here is the simplified application lifecycle for the iFrame mode:

1. When a user clicks on the application page, the SOP server initializes the application and returns an HTML page to the browser with an iFrame pointing directly to the application.
2. Every subsequent user’s interaction with the application will be in the context of the applications, as if the application had its own browser window.

This mode enables full user interface control and maximum application portability. However, developers will not be able to use the SOP presentation and component services, and will have to re-implement common components and look & feel.

Note: To my knowledge, most Facebook applications are using the Proxy mode mainly for to avoid these two caveats.

C) Client-Mashup Mode:

Another mode similar to the iFrame mode is the Mashup mode, which executes the application on the client side (in JavaScript) by providing AJAX APIs to get data from the SOP server (i.e., SOP Context) and the application server.

Here is the simplified application lifecycle for the Client-Mashup mode:

1.  When a user clicks on the application page or component, the SOP server initializes the application and returns the HTML and JavaScript content for the browser to execute.
2. The application (JavaScript) code can make AJAX calls to the applicationaccess content and methods.
3. A JavaScript API is also provided to the application to access SOP data and methods.

For heavy JavaScript developers, this approach can be very attractive. It also forces the application to take maximum advantage of the AJAX model and offer a consistent way to access SOP and application data and methods. It is a common and convenient means for developing widgets (note: OpenSocial is based on the Google Gadgets application model).

However, for full applications, this approach can be a little too JavaScript-heavy and limits portability. It also requires the developer to re-implement some basic browser functionalities, such as page navigation, since each user click will need to be handled in JavaScript.

D) Server-Embedded Mode

The Server-Embedded SOP mode is probably the most involved from an SOP implementation standpoint. In this mode, the SOP server stores, manages, and executes the application codes and data. This approach usually requires the SOP server to provide a browser interface to develop, test, and manage the application. In the consumer market, Ning, Coghead, DabbleDB, and BungeeConnect are good examples of such a model, as well as Force.com on the enterprise side.

This mode works very similarly to the Proxy mode, except that now the application runs in the process (theoretically speaking) of the SOP server.

So, here is a first pass at the Service Oriented Platform concepts. SOP has already made a significant impact on the software industry, as we have seen with Facebook and SalesForce.com. It is probably safe to assume that SOP will become even more relevant to the consumer and enterprise software market as time goes on. From a theoretical architecture point of view, it is interesting to see the lines between online, hosted, distributed, and centralized being blurred.

Note to self: Probably a good time to update my Buzzpad.

Related Links:

• Facebook v. OpenSocial from Widget Box
• OpenSocial and Facebook Platform side by side comparison from Iosart blog
• Bungee Labs opens developer platform-as-a-service from Larry Dignan

Current Web application model limitations:

For technology providers, although the cost of development of a internet service might be relatively low, operational costs, mostly related to bandwidth and storage, severely limit what can be offered to users. For example, providing an entirely free mainstream photo, audio, and video sharing Internet application would require continuous investment that would be hard to justify outside of an monopolistic business strategy.

From the user’s point of view, while the "zero install" feature of the Web application model is advantageous, it also has the drawback of a "zero memory" limitation (at least as it relates to Internet requests). This means that an interrupted transaction (i.e., Internet request) is a lost transaction. While this is not really an issue for small requests (e.g., eBay bid, craigslist post), it could be quite frustrating for users performing more involved tasks, such as sharing videos.

Also, although today’s new Web trend (Web 2.0) encourages the social aspect of these services, I think that most of the current Web 2.0 applications are still primarily focused on the "tech-savvy" population and have not yet reached the "mainstream." One of my current explanations for this assumption is that "mainstream" users tend to prefer participating with their adjacent network first (friends and family) first, which has been cumbersome given the current proliferation of user identity silos.

Web 2.0 Limitations

P2P Opportunities:

While P2P is definitely not the magic pixie dust to solve all of these problems, combining the P2P paradigm with the traditional Web application model could open the door to many interesting innovations and offer the following advantages:

• Reduced operational cost: By the very nature of P2P architecture, P2P technology providers can offload most of the service processing to their end-users, allowing providers to just centralize what matters to them most (usually the directory service), while offering more attractive services to their users. For example, Skype’s P2P approach was probably a big factor in their exponential growth despite their relatively modest financial investment.
• Illusion of continuity : While this is not really a P2P attribute, most of the P2P clients, such as Skype, instant messengers, and file sharing applications, usually support some sort of "transaction recoverability." This means that the client application is usually able to remember an interrupted request and restart it where it left it.
• Network of proximity: One great feature of all IM clients is the "buddy list", which allows users to easily communicate and share with their close network, such as friends and family. I personally think it would be a great step forward if this paradigm could be carried into the user’s Web experience.

As with all technologies, there are many different ways these types of functionalities can be delivered to users. It could come from a better and deeper integration between existing P2P clients, such as Skype or BitTorrent, with existing Internet browsers. Third party browser extensions, such as the promising AllPeers Firefox extension (profiled by Techcrunch), seem also to be headed towards this goal. Or, lastly, it could come from a revolutionary all-in-one client, similar to Groove, but geared for the consumer market.

Related links:

• Great Allpeers article (from Allpeers’ blog) about extension vs standalone.
• Some Skype P2P pitfalls on Om Malik’s blog.
• An interesting take from Muli Koppel about Skype and Web 2.0.

Most of these criticisms seem to be based on the fact that Flock tries to provide an alternative "Web browser" application rather than providing extensions to existing browsers (e.g., a Firefox extension). Lately, the launch of a great Firefox extension Performancing (see Steve Rubel and O.M. Malik quick profile), which offers one of the core Flock’s functionalities by allowing users to blog "in the context" of their browsing experience, has revived the discussion. In a response to these last complaints, Chris from Flock, supported by Bart (Flock’s CEO), issued a good post giving a little more context behind Flock’s vision and direction.

As mentioned by Michael Arrington of TechCrunch, Flock’s Buzz might have come a little bit too early for the Bits, which is always a very dangerous position to be in. Also, Flock’s first audience, the Mozilla tech savvy crowd, was probably not especially receptive to the idea of another browser. I personally am a big fan of Mozilla Firefox, and while I have tested Flock developer preview release, I went back to Firefox since I have all my extensions set up.

However, I deeply believe in Flock’s idea. As Chris mentioned, Flock might or might not be the answer, but the point is that users need much more than a traditional Web browser to make the "Everybody-to-Everybody" Internet vision a reality. This new "Internet Companion" could come from the evolution of an existing Web browser, from a set of extensions, or from another application altogether: the way it gets here is less important than the things it will allow people to do. Obviously, this assumes the goal is to allow the "rest of us" to participate on the Internet.

So, the question is not "to Flock or not to Flock", but rather to believe that the way we will interact with the Internet in couple years will be substantially different from what we do today.

Also, I have had the privilege of meeting the Flock team on many occasions, and it is always refreshing to see a passionate and dedicated team so focused on accomplishing its vision. I would not be surprised if future versions of Flock will surprise us. And I definitely need this new "Internet Companion" for my grandmother and sisters.