Ideally, enterprises should be able to take applications and data in or out of a cloud as business requires without having to rewrite the application or transform the data.

As discussed in the article “Don’t Get Stuck in a Cloud ,” cloud portability tends to be a factor related to the type of cloud one uses.

Here is a quick portability analysis of the three big Clouds on the market:

1) Force.com

While it is possible to develop an application on Force.com that does not integrate with SalesForce.com applications, the true value of doing so is the integration of the two. Force.com has a very powerful and highly integrated platform and application cloud. However, Force.com is designed on proprietary technologies. Force.com has a custom language, which looks like Java but is not Java, and its own SQL/ORM layer. The technical tradeoff allows a Force.com application to take full advantage of Force.com scalable architecture and to integrate deeply with SalesForce.com applications.

Consequently, if you are doing an enterprise application that integrates into SalesForce.com, Force.com is definitely the appropriate choice. However, if you are implementing a standalone application with no integration to SalesForce.com applications or ecosystem, you might want to look at more portable platform clouds.

2) Google App Engine

Google went all the way by supporting true Java on its platform cloud. There are still some restrictions, but most of the common Java libraries and frameworks can be used on the Google App Engine.

The only catch, as previously alluded to, is the data layer. Google App Engine uses JDO for its data layer or a subset of JPA. JDO is fine for some types of applications but can be hard and even costly to adopt for enterprise application (e.g., JDO does not support delete-cascade! Extra work is needed to support delete-cascade -needs to implement jdoPreDelete-). And the JPA support is not complete yet. Therefore, moving an application from SQL/Hibernate to AppEngine will require some rewriting but is still manageable for a well-architected application, especially with JPA is used in both environments.

3) Amazon WS

Being an infrastructure cloud, Amazon WS does not provide any platform cloud service and therefore does not restrict application developers to any technology. The downside of this type of cloud is that SaaS developers will have to develop their customized, highly-scalable architecture. This is less of a problem for IT developers, as they will probably want to reuse their application framework, which is already designed to scale to meet their needs.

This has been another look at the cloud market space. Obviously, the market is moving fast, and it is most likely that this map will change over time, but this matrix should give you a relatively accurate view of the current state of the market.

I hope this series of cloud computing articles will be useful for people in the midst of the decision-making process.

If you liked this article a +1 on HN or a re-tweet are greatly appreciated. (see R-Tweets)

To fully analyze this market opportunity, we need to realize that there are two related but different types of enterprise customers for cloud computing.

The first type is internal information technology (IT) organizations within the enterprise that are looking for more agile and cost-effective ways to manage their Internet application and services. The second type is the enterprise SaaS providers who want to leverage proven, highly-scalable architectures and integrate them into some cloud applications to increase functionality and maximize distribution.

IT and SaaS cloud customers have similar requirements but different priorities.

Here is a high-level view of some of the differences.

1) IT Customers

As discussed in the Enterprise vs Consumer Web article, one of the biggest challenges for enterprise IT is to standardize technological architecture and best practices across their application portfolios to minimize application development and maintenance costs.  

Consequently, enterprise IT requires the cloud service to be as standard as possible so that applications, services, and libraries can be easily ported in and out of the cloud without requiring any application rewrite (a.k.a Application Portability). Thus, enterprise clouds must support standard enterprise languages (i.e., Java and/or .Net), a common framework (e.g., Spring, J2EE, Hibernate, and Struts), as well as system and application interfaces (e.g., SOA, XML-RPC, REST, SQL, Monitoring & Management interfaces).

The other important set of requirements from an IT standpoint is service integration. Enterprise software is never about all-or-nothing but rather about mixed environments and perpetual coexistence. Enterprise clouds must, therefore, provide rich service integration capabilities at the data and service layers.

From a cloud platform point of view, Google App Engine comes very close to meeting both of these requirements. Google App Engine data connector apis and fully supports Java. The biggest limitation, at this point, is the lack of support for the SQL interface and, consequently, any object relational mapping libraries, such as Hibernate.

2) SaaS Customers

While Enterprise SaaS customers would welcome the IT cloud features, their primary concerns have to do with scalability and cloud application integration.

The elasticity characteristic of cloud computing is particularly interesting to the SaaS companies since it provides a cost-effective way to scale multi-tenant applications. By choosing a platform cloud solution, SaaS developers do not have to worry about architecting a highly-scalable system as it is a core function of the platform.

The other key advantage of cloud computing for an SaaS business is the cloud application ecosystem. Saas applications can provide greater value-added services by integrating with the cloud applications. And, more importantly, the SaaS business can leverage the cloud applications community as a distribution channel.

So here you have it: one market and two different customer types. If you are an enterprise cloud provider, the trick is to realize the different needs of each customer type and plan a strategy to ultimately satisfy both. If you are a customer, then know what you need and don’t let people tell you what you want.

If you liked this article a +1 on HN or a re-tweet are greatly appreciated. (see R-Tweets)

Jon Davis posted an interesting article discussing whether the Microsoft stack is really more expensive than open source alternatives.

Jon has a point; Microsoft’s restricted (i.e., Express) editions are as free as the open source alternatives. This is undeniably true, since the purpose of many software vendor’s “Express” edition is to compete against open source on price. However, the difference is that with open source you get the full-powered editions. For example, Linux (e.g., CentOs), Xen (for virtualization), PostgreSQL/MySQL, Apache, Java, Tomcat, AspectJ, Lucene, Hibernate, and Eclipse are all robust, full-featured, and powerful technologies available for free to developers. The variety and the quality of product available from the open source community are just astonishing.

On the other hand, Microsoft’s “Express” editions are just limited editions that are understerdanbly designed to lure the users to the full ones. Therefore, in the end, developers should not be duped, if they are using a Microsoft product, they will pay Microsoft.

Furthermore, the biggest benefit of using open source technology is not related to the price. Open source tools are built with the single agenda of making the technology increasingly better for the developer. Technologies produced by software companies have other driving forces, such as business agendas and internal politics. Having worked for big software companies, I can testify that there are many political distractions during the conception and evolution of any product, and often obvious features or integrations do not get done or get delayed because of internal politics. The “from developers for developers” open source model creates a very effective environment in which to produce high-quality technologies for developers.

Nevertheless, for Microsoft shops, the price to move out of the Microsoft stack might be very expensive and discouraging. In my youth, I was an MSDN subscriber (even a proud MCP holder), and I found it emotionally hard to switch. (Kudos to Microsoft for its great developer marketing!) However, for any developer or IT organization that has not invested too heavily in the Microsoft stack or that has already invested in both, I would definitely recommend investing more in the open source stack as it will continue to provide robust, advanced, and full-featured technologies to which you can add even enterprise support (e.g., RedHat). In most cases, these technologies will not have fancy marketing packages and nice dialog boxes, but it is the users who need the nice dialog boxes, not the developers.

Lastly, I find that Linux/Unix is more appropriate for servers than Windows, and once you know how to manage Linux, it is hard to go back to the Windows way of doing things. However, most people do not like change, even though we say we do, so our arguments will always be tainted by our own experience.

Note: This is by no mean a rant against Microsoft or proprietary software in general. I actually have great respect for Microsoft as a software company. I am a dedicated Microsoft Windows and Office user (even if I like to use Google Docs for some of my work) and cannot wait to update my laptop to Windows 7 and the next upgrade of Office and Visio. I like to describe myself as a pragmatically open user who favors open solutions but does not hesitate to use proprietary ones when the open alternatives do not satisfy my needs (i.e., Adobe Photoshop). I use Windows for my PC, Linux for servers, and Android for mobile.

While many see Microsoft Silverlight as an Adobe Flash killer, I actually think Adobe should rejoice that Microsoft is competing with Adobe on its own turf (i.e., media plug-ins) rather than putting all its energy, as it once did, into Web standards and innovation (IE 5.0 was the most robust and compliant Web browser of its time).

If Microsoft were to take a similar approach to the one it embraced in 1995, when it actually took the lead in Web technologies and provided the best Open Web browser implementation, new media functionalities such as video and 2D/3D would become an intrinsic part of the Web, making media plug-ins irrelevant to its future. In other word, if Microsoft were to go full Open Web (with SVG, Canvas, Smil, HTML 5, Video, and CSS3) Adobe Flash would be history in couple of years. However, Microsoft decided to follow Adobe’s plug-in strategy by forking visually rich capabilities into the plug-in world and throwing itself into a completely new market.

Why? Why follow when you can lead?

I think there are three main reasons:

1) Adobe is an easier target.

Between Adobe and Google, Microsoft might think it has a greater chance of winning against Adobe.

Microsoft has probably concluded that Open Web is a much less predictable entity given the complicated relationships among the various open source, standard, and commercial entities (e.g., Mozilla, Google, and Apple). Additionally, given Google and the open source community’s progress on the Open Web front, Microsoft might have feared being able to lead the way this time.

Thus, opting for the plug-in route had the advantage of slowing down Open Web technologies (and consequently Google) and narrowing down the competition to Adobe rather than Google and the open source community.

2) Expanding from the developer market to the designer market is safer.

The desktop software market is comprised of the three main following buckets: office productivity, developer tools, and designer tools. The only place where Microsoft is still not the leader is the designer tools segment, and that is where Adobe excels. Conversely, Adobe is seeing its next tools growth opportunity in the developer market.

Consequently, Microsoft and Adobe have created a new battleground, “designer-developer workflow” where they are both promoting an ultra rich visual experience for Web applications and positioning their respective tools and plug-ins as the ultimate solution for maximizing designer-developer productivity. Microsoft sees it as a way of leveraging its developer base to move into the designer market, and Adobe sees it as extending its designer market to the developer one.

While Microsoft could have focused on providing the best developer and designer tools for Open Web development, it probably felt more comfortable, as Adobe did, controlling the designer and developer experience by owning the language, runtime, and application model. Additionally, from a market standpoint, it is fair to assume that Open Web developers might not be as marketable as developers open to proprietary Web technologies. So from a business standpoint, Microsoft is opting for the safe route and is betting on what it knows best, controlling the developer, and now the designer, experience end-to-end.

3) Microsoft hopes to slow down commoditization.

Last but not least, Microsoft must fear that going full Open Web would backfire, by accelerating its operating system commoditization, and would give good wind to new operating systems, such as the mysterious and aptly named Google Web OS. Microsoft wants neither to fall too far behind on Open Web technologies nor to give them more momentum that they already have.

While I can understand each of these points, I still think that Microsoft’s lukewarm approach to Open Web technologies is the wrong strategy. The Web has always been open in nature, and making pixels fly faster or smoother will not alter that. Given all the passion and strategic interest surrounding it, the Open Web will happen with or without Microsoft. Microsoft would be better off fully embracing and leading Open Web technologies, as it did back in the late 1990s, and redefining the Web design and development market. If a disruption wave is coming your way, surfing it is better than being smashed by it.

I would even go further by saying that Silverlight is helping to maintain the Adobe Flash mainstream. Adobe Flash is an amazing piece of technology, by all accounts, and future versions are poised to be even better. While Silverlight might have some technical advantages here and there, overall, Adobe Flash is still the best media plug-in available as far as functionalities and reach. And given all its antitrust restrictions, Microsoft is even finding itself in a difficult position to aggressively distribute Silverlight. So at the end of the day, the more Microsoft is selling plug-in development to Web developers, the more Adobe will benefit. In fact, Microsoft Silverlight’s marketing department should be commissioned by Adobe.

If you liked this article a +1 on HN or a re-tweet are greatly appreciated. (see R-Tweets)

Anyway, now that this merger is almost done, the big question everybody has is what will happen with Sun software and open-source assets such as Java, MySql, and OpenOffice. There is also the burning question about Oracle’s commitment regarding Linux. Before going one-by-one, it is important to understand few things about Oracle:

1. Oracle does not like GPL. They have been forced to coexist for their Linux strategy against Microsoft, but, they are isolating it as much as possible.
2. Oracle does not care about desktop computing. While Oracle has some desktop applications (e.g., JDeveloper and Beehive Clients), it tends to mostly focus application model research and development on Web frameworks such as JSF and Fusion Middleware. In other word, no AIR will be coming out of Oracle anytime soon.
3. Oracle has a very talented Linux group, headed by Wim Coekaerts, which has made significant Linux (GPL) contributions. However, overall, Oracle is still far behind IBM in terms of Open Source investment. IBM is the organization that gets and does open source better than anyone else.
4. Oracle masters, better than anybody else, the art of selling software to enterprises. It has the most aggressive enterprise sales force on the market, and they know all the tips and tricks to maximize any single software sell.

So, now the burning questions are what Oracle will do with Java, MySql, and OpenOffice, and will it stay committed to Linux?

1) Oracle on Java

Java is probably the biggest topic, at least for developers.

On the language side, I think it will be business as usual. Sun Java linguists will probably stay at Oracle, and Oracle will probably keep them, as they are the core of one of the biggest part of their acquisition. Many developers are already considering the Java language to be in maintenance mode after JCP‘s repeated failures to adopt Java popular requirements such as closures. Therefore, the change in ownership will probably have little effect on the already-not-popular Java language evolutions.

Oracle might have a bigger effect on the server side of Java. EJB3.0/ORM and Portal specs and implementations should get a boost and, hopefully, JSF will get a re-lifting. However, changes in velocity will be hampered by the fact that everything will still have to go through the same JCP process.

Now, the client side is going to be the entertaining one. I think that first, Oracle will get confused and overwhelmed by JavaFX (who has not?). Then, it will be interesting to see what the Oracle people will do about it. My guess is they will let it be for a while (out of confusion), and then quietly deprecate JavaFX as they realize it is the failed compiled client/server model all over again with some flying pixels, a cute, but weird, Java-like-but-not-Java language, with very low client penetration.

On the tool side, the NetBeans vs. JDeveloper fight is going also to be fun to watch. Oracle has been very emotionally tight with its JDeveloper to the point of prioritizing it over BEA Eclipse-based IDE (even after standardizing on WebLogic middleware). The good news is that both NetBeans and JDeveloper are Swing-based, so a happy marriage is not out of the question (except if JavaFx wants to cause trouble).

Personally, I am a little concerned about Tomcat. Tomcat has become a very robust and reliable Servlet container and, with frameworks like Spring and Hibernate, can become the backbone for highly scalable SaaS enterprise applications. The good part is that Tomcat is governed by Apache, which hopefully will maintain a good continuation of the project. But again, if Oracle decides to stop continuing Sun’s investment in Tomcat, the product will untimely surfer.

2) Oracle on MySQL

Let’s get to business. MySQL acquisition is very interesting. It is important to note that Oracle has always tried to understand what it could do with MySQL, without giving it too much attention. This initiative became concrete in 2005, when they bought the innoDB. MySQL’s CEO, Marten Mikos, has also been relatively friendly with Oracle over the years. I actually think he would have rather been bought by Oracle than by Sun. But although this was a topic of discussions, it has never happened, because, as Larry likes to put it:

“I prefer to spend $1 billion and be right than $100 million and be wrong.”

Well, this is Larry’s business genius. He just spent $6 billion and he is probably right.

So, what Oracle will do with MySQL? The new MySql 5.4 has some features that could be considered quite competitive with the Oracle database. And now that MySql has the Oracle brand on it, Oracle will have to be even more careful about it.

My bet is that Oracle will keep the MySQL 5.4 Community going and slow down the development of 6.0 (in very subtle ways). Where Oracle might become aggressive is in regard to the MySQL Enterprise and Cluster editions. While an internal competition is always better than an external one, Oracle is going to want to control it. It has two options for doing this. The first is by price, basically aligning the MySQL Enterprise and Clusters editions to Oracle DB pricing (at least as a lower cost alternative for small to medium enterprises -see comment from Chris Arthur- ). The second is by product, by slowing down MySQL Enterprise product innovation and investment. My guess is that it will be the first one, which might result in a reduction of resources on MySQL community editions as well.

One thing I think won’t happen (at least for the next 5 to 10 years) is a merger between MySQL and Oracle DB. First, it would be a mistake from a business standpoint, as MySQL gives a great new channel to Oracle and, second, Oracle does not want to risk contaminating its crown-jewels database source code with the viral MySQL GPL one.

3) Oracle on OpenOffice

This is probably the sad one. I am a big fan of OpenOffice, and I am not sure of its viability inside Oracle. As mentioned above, Oracle does not really care about desktop computing. While there might be some interesting fit with some Oracle products (e.g., Oracle Beehive), an investment in OpenOffice would require an equal (if not greater) investment in Microsoft Office integration, which Oracle has never done. I am not sure the OpenOffice asset acquisition will trigger a change of heart. I think that in a year or two a spinoff will be inevitable.

4) Linux (vs. OpenSolaris)

Last, but not least, Oracle and Linux. Will this acquisition tamper with Oracle’s commitment to Linux? As far as technical contributions, I do not think it will change much. I think the Oracle Linux group will stay committed and funded to continue the Linux initiatives.

However, on a macro level, we might see some change. I think the real question is, “Will Oracle continue [some of] Sun’s hardware business?” If, yes, then, Oracle will have to push OpenSolaris to the market and that might take some juice out of their Linux marketing initiative. Otherwise, if Larry’s last commitment to Solaris and Sun’s hardware was just a gimmick for Wall Street (or a last favor to Scott McNealy), then, in couple of years, Oracle might be back, full speed, on Linux by acquiring a Novell or Redhat, for example.

Update 2009-05-20: My latest conversations on the subject lead me to believe that Oracle will probably end (i.e. silently put in maintenance mode) the Sun x64 solution (which compete directly with their current HP/x64/Linux/Storage solution), and will keep Sun’s Middleware for higher-end customers. This new hardware and OS division will allow them to effectively push their “DB Appliance” solution to large enterprises (with total control on the Operating System), and push Linux/x64 to the SMB market. So, Oracle might and probably should do both, Solaris and Linux.

So, here is it, my quick take on Oracle acquisitions and some predictions for the future. I really have the greatest respect for the Oracle executive team, Larry, Safra, and many others. I think they are great market strategists, and they are continuously shaping the enterprise software market. Very fun to watch!

Now, the next question is: What will IBM do about it? Buy SAP?

Although there is evidence that the two styles will converge in the future, enterprise and consumer Web architecture and technology are quite different today. If one talks to an enterprise application architect, he or she will probably say that while consumer Web applications are cute, simple, and sometimes useful, their architectures and technologies are merely a bunch of scripts and hacks put together. If one talks to a consumer Web architect, she or he will probably say that enterprise software is overly complex, often unusable, and based on over-priced and under-performing technologies (i.e., JSF or Portal). (See the previous post about Web Developer Spectrum.)

Having lived in both worlds, I can see some truth in both arguments; however, I think that most of the divergence comes from a different set of requirements that leads to separate technical routes.  

I see six main differences between consumer and enterprise Web Applications:

1) Scale (Users vs Applications)

Scale is probably the first and most important requirement that creates a difference between the two types of applications. Consumer Web is all about scaling the number of users for a single application. Successful consumer applications, such as YouTube, Facebook, and Twitter have seen an almost exponential growth in their user base. Consequently, consumer Web architects tend to favor license-free technology and often build a customized technology to exactly fit the high-scale needs of such applications. A good example is Google File System, for which architects built a distributed file system.

On the other hand, enterprises usually have a relatively fixed number of users (which can unfortunately shrink from time to time), but they have ever growing business application needs. The biggest challenge for enterprise IT is to standardize technological architecture and best practices across their application portfolios to minimize application development and maintenance costs. Therefore, enterprise developers tend to favor standard and well-supported technology, even if it carries significant licensing fees. Maintenance is often favored over architectural elegance and performance, and technologies such as JSF, SOA, and Portal often bring the wanted risk/benefits tradeoff.

2) Experience (Simplicity vs Functionality)

The second big difference between an enterprise and consumer Web application is experience. In the consumer world, applications have to be simple and engaging since nothing but the application attracts users. So simplicity is king, and often the less functionality the better. I actually think that the success of Twitter over FriendFeed is mainly due to its simplicity (see FriendFeed vs Twitter). YouTube, Flickr, and many other successful consumer Web applications are great examples showing that simplicity often overcomes completeness.

In an enterprise environment, however, users are employees who depend on an application to perform a specific job. While enterprise applications need to be intuitive and well designed, functionality is king. Limiting application functionality for esthetic is probably not a good enterprise IT strategy.

Interestingly, both camps often make the mistake of putting too much emphasis on Look and Feel aspects and confusing these attributes with usability. As explained in my previous Flying Pixels post, good looking is not necessarily smarter. Most successful Web applications (i.e., Facebook, YouTube, Craigslist, SalesForce.com) have relatively plain but utilitarian user interfaces.

3) Security (One for One vs One to Many)

While both application types need to be secured, the security requirement in the enterprise context is much higher than in the consumer case. In the consumer Web, users usually set one access rule per artifact. For example, when publishing a video on YouTube, you can set it as private, for your friends, or for everybody.

In the enterprise case, you often have many rules for a given set of records that are dependent on complex access rules based on groups, roles, and time. This is one of the reasons that enterprise applications usually use a relatively complex but complete security framework such as Spring Security.

Nevertheless, one common requirement of both enterprise and consumer Web applications is the single sign-on. In the consumer Web, Open Auth and OpenID seem to have gained some momentum while the enterprise is using a mix of proprietary technology such as Oracle Sign On and open source and standard solutions such as JOSSO and Liberty Alliance.

4) Transaction (Decoupled vs Complete)

In a consumer Web application, the most efficient way to scale is to partition and distribute data and logic across many low-cost servers. The pitfall of using such a distributed architecture is that transactions can become quite costly and even practically impossible to implement on a large scale. It’s one thing to have Oracle RAC or Java JTA on a few servers, but it is another story to have it cut across hundreds or even thousands of servers.

Therefore, most consumer Web applications implement what I call a decoupled-transactional model in which a transaction gets split into smaller independent transactions that are executed separately, leaving an opportunity for the system to include some stale data. For example, when an artifact gets deleted, added, or modified, the item modification transaction is often decoupled from the relationship modification ones. The trick is to design the system so that 99% of the time the user will not notice the stale data and that stale data never results in wrong subsequent transactions (for example, preventing an eBay user from buying a deleted item). Most consumer Web applications have their own custom loose-transactional implementations, which are often a mixture of caching, cron-jobs, and fix-transaction tricks.

In the enterprise Web, the requirement is completely different. There is usually no tolerance for stale data, and the system must guarantee complete transactional integrity. Expensive but reliable technology such as Oracle RAC can make a big difference when the enterprise needs to scale a given application.

5) Integration (Loose vs Strict)

Another area in which consumer and enterprise requirements differ is application integration. In the consumer space, application integration happens very organically. Application providers (e.g., Twitter) or application container providers (i.e., Facebook) define interfaces with which everybody can integrate. The result is that thousands if not hundreds of thousands of applications will potentially integrate with some of these interfaces. Consequently, interfaces tend to be simpler, lighter (e.g., REST), and often even client-centric (e.g., OpenSocial and iGoogle). In other words, consumer application integration is about breadth rather than depth.

In the enterprise space, on the other hand, application integration has to be thoughtfully designed and managed and often has an impact in all layers of the application (i.e., presentation, logic, and data). Heavy and expensive technology, such as ETL, SOA, JMS, and Portal, are often an effective way to establish strong integration between applications.

6) Search (Page vs Data)

The last difference is related to search. In the consumer Web, the main search model (e.g., Google and Yahoo!) is page-based. A page is a uniform way to represent content, presentation, and relationships for a given entity. SEO is a well-defined concept that helps Web content and application providers to structure their information to be easily discoverable. One great benefit of this approach is that search is application independent.

In the enterprise Web, search is record-centric, and users do not search pages but records with all their associated attributes (e.g., Access Control). The benefit of this approach is that search is more targeted and secure. However, the biggest caveat about using this approach is that search becomes inherently application-specific, making cross-application search a relatively expensive solution to implement.

So we have looked at the key architectural differences between consumer and enterprise Web applications. The good news is that I think the “software as a service” (SaaS) growth will drive convergence. SalesForce.com is a great example of how a consumer-inspired Web architecture can be tailored to enterprise needs. I also think that Open Source is, and will be, playing a bigger role in the consumer/SaaS Web than it did in the enterprise Web.

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.

Well, while the licensing questions are pertinent and will need to be answered at some point, the real questions are “What? Why? And How much [open]?”

The “What” and “Why” are very dependent on the entity’s business model and should be carefully thought out. Open Source is a useful tool to lower the entry barrier, change product perception, increase adoption, and create awareness. However, it does not come for free, definitely does not reduce engineering cost, and often requires a specific DNA. The key to determining the “What?” is to not only think about what the entity is ready to give to the community, but also, what the community would be interested in taking from the entity. In other words, don’t ask yourself what you can give to the community, but what the community wants to take from you.

The “How much [to open]?” is the main question which will help determine the appropriate license, the challenge being that among your users you will have competitors that you cannot really individualize. To facilitate this thinking process, I made the following matrix which lists the main usage capabilities for the different types of open source licenses.

“Download” and “Evaluate” are often the easiest ones since most technology companies want their “open” or even proprietary technologies to be freely accessible for evaluation. Obviously, all open source licenses allow these two usages.

The “Deploy” is where most misunderstandings come from and where open source differ the most from proprietary software licensing. For server technologies, all open source licenses (1) allow users to freely build and deploy applications on top of the open source [server] asset without any restrictions on their application licensing. Restriction applies only when redistribution of the asset occurs, and typical end-user usage (over the Internet) does not qualify as asset redistribution. For example, Google is using a highly modified version of Linux (GPL) and has not had to give anything back to the community (Note: Google gave some of its customization back, though). Note that for client side open source components, GPL can be a little bit more complicated (not covered in this post).

Redistribution of an application is where GPL differs the most from other open source license types. GPL is very viral by design, and can be a great tool for an entity wishing to control the redistribution of its open source asset by assuming that many potential customers or distributors will not want to play by the GPL rules. Dual-licensing (GPL + Commercial License) is often used for this purpose by allowing users to opt-out of the GPL licensing restriction if they agree to the commercial terms. There are a lot of caveats to this dual-licensing approach (e.g., open contribution, community uptake, and corporate development opportunities), but it has proven to be working (e.g., MySql). MPL and BSD-like licenses (and in some ways LGPL) are designed to allow free redistribution of the open source asset.

Modification of the open source asset is where BSD-like licenses (Apache, BSD, MIT) differ the most from other ones. All other open source licensing forces modifications to their asset to be submitted back with the same original license, whereas BSD/Apache-like licenses do not have such requirements. I personally think that this is one of the principal reasons why Apache products and assets have been broadly adopted by commercial entities such as Oracle in their commercial offerings.

So, in short, for server-side assets, open source licenses cannot really be used to control deployment, but more redistribution and modification. If there is a good OEM business opportunity, then dual-licensing (i.e. GPL + Commercial) might be an option, but if community and adoption are the principal objectives, the Apache/BSD license types are probably the most effective ones. While GPL might give the most control (in some ironic ways), it might also limit market adoption and business opportunities.

My philosophy is that leadership comes from contribution and not control (i.e. licensing).

(1) GPL V3 has an optional clause forcing the deployed applications to be under GPL as well (this clause is not commonly used).

Related Links:

• Some good info about Mozilla Licensing: MPL FAQ, Relicensing FAQ
• GPL vs BSD, a matter of sustainability
• What is CopyLeft (from Gnu.org)

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.

It is very interesting to watch Microsoft waking up, loud and determined as in 1995. The fact they chose Windows and Office brand for their "Live" offerings is significant.

A few interesting points from the Ozzie memo:

• Microsoft did openly recognize having missed some opportunities (e.g., Google, Skype, AJAX).
• They are puzzled about Google’s strategy:
  "[Google's] myriad initiatives … drive scale for their advertising business … or … grow to substantively challenge our offerings"
  (BTW, good job from Google. In less than a decade, they puzzled Microsoft)
• Ozzie did a good assessment regarding today’s Web hurdles:
  "User identity and cross-service interoperability mechanisms are still needlessly fragmented".
  (I hope this means Microsoft will work on standards and interoperability, instead of creating another proprietary Identity Management "a la MS-Passport"!)
• Regarding my previous point about this new advertisement revenue potential, Ozzie did confirm that "… no one yet knows how much of the world’s online advertising revenues should or will flow."
• Ozzie does point out the value of the Internet adoption model and seamless application integration.

Microsoft is certainly doing the right thing by embracing these changes. During the last couple of years, a lot of "underground" work has been done to come to this point. It will be interesting to see Microsoft catching up. Undoubtedly, they can catch-up on the technology side. Their real challenge will be adapting to these new business models.

Some missing points from Ozzie’s memo (just for speculation sake):

• No mention of Open Source. Ozzie could have said that Open Source is part of this new ecosystem. He probably wants to tackle this topic offline.
• Ozzie did explicitly mention the term AJAX couple of times, but not Web 2.0. Arguably, Web 2.0 encompasses AJAX. Free speculation: Microsoft might be starting branding MS Live "against" Web 2.0.

Related links:

• Dave Winer publishes Gates and Ozzie memos.
• On Slashdot -
  Why Microsoft and Google are Cleaning Up With AJAX
• Marc Benioff’s retort