Ross Mayfield's Weblog

Cloud Appliance Comes to the Enterprise

Software Appliances were initially created for high performance network and security infrastructure with lower administration costs. Over time the Appliance model moved up the stack from email appliances to a diverse set of business applications. This trend has continued in parallel to the rise of SaaS and Cloud Computing. SaaS Appliances provide pre-configured, self-contained applications with on-premises deployment that can be automatically updated and upgraded. While the Cloud is the center of attention these days, SaaS Appliances have been quietly evolving up the stack while adapting the best of web-oriented architecture for clouds inside companies.

Whenever there are security or regulatory constraints that demand on-premises deployment, SaaS Appliances can deliver where the Cloud cannot. While several years from now these constraints may change, this is the reality for many enterprises and government agencies. Any SaaS vendor who does deliver both Cloud and SaaS Appliance deployment models from a single image of their software is simply reducing their total addressable market.

Compared to traditional on-premises software, SaaS Appliances provide rapid deployment that shortens technical pilots, fast upgrade cycles without degrading service level and a lower Total Cost of Ownership (TCO).

Combined with subscription business models that let the enterprise right-size the deployment, the ability to deliver or turn on additional applications (e.g. upgrading a Microblogging Appliance to a full Social Software Appliance) provide the flexibility and fit for adoption concurrent with business value.

Traditional enterprise applications such as CRM or ERP will move to the Cloud, but not just because a customer chooses the Cloud over traditional deployment. The Cloud will come to them. For example, I can't wait for a customer to migrate apps and users to the Cloud so we can enable the integrated value proposition of Social Software working across organization and application silos.

Open Source Licensing for Software as a Service

Open Source came before, if not provided a platform for, Software as a Service.  Open Source Licenses have a big loophole for the most common method of software distribution today.  Tim O'Reilly addresses this while making yet another argument for open data.

Linux Magazine's article The GPL Has No (Networked) Future recognizes a point that I've been making for years: that free software license requirements to release source code are all triggered by the act of distribution, and that web applications, which are not actually "distributed," are therefore not bound by these licenses. (See, for example, my 1999 debate with Richard Stallman at the Wizards of OS conference in Berlin.) 

The article describes how during the GPL v3 discussions, there was a move to close the "SaaS loophole" by including some of the provisions of the Affero General Public License or AGPL:

the FSF supported the creation of the Affero GPL and attempted to integrate it into the early drafts of the GPL3. However, that plan backfired and the FSF not only struck the text that would extend the GPL to software delivered as a service but clarified just what "to 'convey' a work" actually means.

Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

In other words, software delivered as service is now officially not covered by the GPL.

...the community forced the provision out as indicated in the FSF's 61-page rationale document [pdf] that accompanies this latest draft.

We have made this decision in the face of irreconcilable views from different parts of our community. While we had known that many commercial users of free software were opposed to the inclusion of a mandatory Affero-like requirement in the body of GPLv3 itself, we were surprised at their opposition to its availability through section 7. Free software vendors allied to these users joined in their objections, as did a number of free software developers arguing on ethical as well as practical grounds.

The article concludes that while this is the right decision, it places real limits on the long-term significance of the GPL: "The future is networked. The GPL isn't."

Bryan Richard's article is a great analysis and the implications of keeping the loophole open for SaaS are significant.  There are both practical and philosophical reasons to close this loophole with a network use clause:

If you're unfamiliar with the SaaS loophole, it's probably best described by a license that actually covers it. Fabrizio Capobianco, who created the Honest Public License describes it as such:

Some people interpret distribution of software as a service not as distribution of software (because GPL v2 was created before web services were on the horizon and therefore did not address them in the license). They believe that they can use open source software to offer services to the public, without returning anything to the community.

As to why you might need it, the creators of the Affero General Public License have this to say:

We believe that certain software can extend the bounderies [sic] of a person, and therefore should not be out of the control of the individual. We believe that people's freedom should be protected. We believe that this includes their digital interface to others.

Affero and the Common Public Attribution License (CPAL)

Many OSI Certified licenses were developed before the web became a common method of distributing an application to users. Making an application available for use over a computer network, such as an email service accessed and used like GMail, should be treated the same as compiling it, burning it on a CD-ROM, and mailed out that CD-ROM. We sought to address this issue when developing the Common Public Attribution License (CPAL). Some licenses use the Affero Network Use clause to this effect, but we chose the External Deployment clause from the Open Source License (OSL) because it is more technology-neutral (OSD #10) and future proof, and is clearer about the philosophy behind the requirement.

The other issue is the Affero license, while widely known and used, is not OSI Certified, whereas OSL is.  My hope is that CPAL, an MPL plus APL plus OSL license, is approved by the OSI at their next board meeting at OSCON at the end of the month and I can write sentences with less acronyms.  But my other hope is that there is a license accepted by the community that provides Attribution like GPLv3, but also closes the SaaS loophole.

Being the Choice Leader

Nick Carr reports on two studies of Enterprise 2.0 adoption by large enterprises:

Some hard data is coming out this week on the adoption of Web 2.0 tools by companies. Yesterday, Forrester released some results from a December 2006 survey of 119 CIOs at mid-size and larger companies. It indicated that Web 2.0 is being broadly and rapidly brought into enterprises. Fully 89% of the CIOs said they had adopted at least one of six prominent Web 2.0 tools - blogs, wikis, podcasts, RSS, social networking, and content tagging - and a remarkable 35% said they were already using all six of the tools. Although Forrester didn't break out adoption rates by tool, it did say that CIOs saw relatively high business value in RSS, wikis, and tagging and relatively low value in social networking and blogging.

McKinsey did a broader survey of 8,300 executives with similar demand and adoption patterns:

It found that social networking was actually the most popular tool, with 19% of companies having invested in it, followed by podcasts (17%), blogs (16%), RSS (14%), wikis (13%), and mashups (4%). When you add in companies planning to invest in the tools, the percentages are as follows: social networking (37%), RSS (35%), podcasts (35%), wikis (33%), blogs (32%), and mashups (21%).

But the highlight of the Forrester study for Nick and Richard MacManus is CIO attitudes towards incumbent vendors vs. startups.

74% of CIOs said they'd be more interested in investing in Web 2.0 if all the tools were offered as a suite, and 71% said they'd prefer the tools to be "offered by a major incumbent vendor like Microsoft or IBM [rather than] smaller specialist firms like Socialtext, NewsGator, MindTouch, and others."

Nick concludes: "You can bypass the CIO on a small scale, but it's difficult to bypass the CIO when it comes time for a company to standardize on a particular product and vendor."  Yup. It has always been the case for enterprise software.

CIOs of large enterprises will largely give preference to the incumbent vendors they have relationships with to realize economies and standardize architecture.  Especially when almost all of their budgets are sunk with maintainence fees of said incumbents.  Part of expressing preference for suites is that suites are now available, beginning with SuiteTwo (Socialtext, Six Apart & Newsgator best of breed core offerings).  I find the results of the survey very encouraging -- that SuiteTwo is a comparable preference to Microsoft or IBM.

Some CIOs will go what what (or whom) they know and stick to existing vendor relationships.  That's why we created SocialPoint for the best-of-breed wiki to work with Sharepoint.  As Lawrence Liu from Microsoft said: "More and more SharePoint customers who want advanced wiki functionality are looking to the specialized wiki ISVs like SocialText to provide it with an integrated user experience in SharePoint by way of 3rd party webparts."

As I've said before, when competing in a market of abundant choices, you have to be the choice leader.  Choice is good.  In some cases, you create choice through channels and partnerships.  But you also have to do so through your core offerings.  Today we have more deployment options than any established or upstart vendor.

• Managed Service Appliance (SaaS behind the firewall)
• Dedicated Hosted Appliance (here is a good introduction to Appliances)
• Custom On-site
• Hosted Professional
• Hosted Personal (free)
• Open Source

Part of why we have choice is not all of our customers are CIOs of large enterprises.  Lee Bryant of explores choice and the convergence of SaaS and Enterprise 2.0 in Bottom-up and inside out - the future of enterprise IT?

Euan's subtle insight on how to do Enterprise 2.0 is that there are powerful grassroots energies to not only tap into, but if you impede them you risk your deployment more than anything.  While there is a certain inevitability of Enterprise 2.0 proliferation thanks not only to SaaS, but namely open source, his message is less about the tools than the demand for them and practices that make it work.

Dion Hinchcliffe explores this and notes "Those that represent to be doing Enterprise 2.0 solely through tool rollout and no infrastructure remediation will almost certainly be among those reporting less encouraging results."

This is all in the context of the alternative to how this post began.  Besides large enterprise CIO preferences, there is the bottom up.  And smaller companies.

Lee discusses the challenges of a completely bottom-up approach:

On the technical level, the integration challenges are non-trivial:

• identity / Single Sign On (SSO);


• internal application integration;


• legislative obligations for data retention, privacy and audit; and,


• availability.

But the integration of people, practise and (dare I say) process is even harder, with challenges such as:

• devolving responsibility and promoting a DIY culture;


• encouraging people to grow their own internal and external networks;


• stimulating conversation and debate by overcoming fear of exposure; and,


• for many people, simply overcoming the idea that any form of online communication beyond email is "not part of their job."

Those challenges become opportunities when you have buy in from the top down and IT supports.  And when you have actual leadership, as Suw Charman noted: you have the best adoption strategy.  Lee specifically explores SaaS and rightly notes that it isn't a fit for many enterprises that have customization needs.  He sees two trends in SaaS that have potential to close this gap:

The first is in the area of specialised appliances or systems that live inside the firewall, where they can happily integrate with internal apps ad data, but which can also be updated and fed by managed connections that extend outside the firewall. The Socialtext managed appliance seems to be a good example of this approach, which is a workable compromise between SaaS and purely internal systems.

The second area is enterprise software that takes advantage of managed connections with web services to add value to internal systems. Movable Type was a pioneer of this approach with its blog ping service to feed a public list of recently updated MT blogs. Their impressive roadmap for the enterprise version of this market-leading blog platform suggests they will take this a lot further in MT v4.

You really should go read his post, at least for the Star Wars metaphor.  He concludes that SaaS still has a way to go:

...But the emphasis will shift from software, which is just a mechanism, to services, which is the actual product. Some of these will be new and imaginative forms of what we might recognise as applications, but many will be pure data or data transformation or sharing services. But whilst we will see adoption among SMEs for cost reasons, enterprises will not embrace SaaS for their mission critical systems or data until such a time as we find robust solutions for the key integration and data management challenges.

I see promise on resolving some of these challenges for the enterprise from innovations borne on the web.  OpenID is a good start for identity and authentication, and will find its way into the bowels of enterprise directory authorization.  RESTian APIs are shaking up pre-conceived notions of SOA.  Open Source provides more options for not only these challenges, but is the dark horse for Enterprise 2.0 the adoption race.

SaaS Appliance

Last week we quietly launched the Socialtext Managed Service Appliance.  Initially we thought this infrastructure innovation would simply give us some operational efficiencies.  But as we ran it by customers, passing their security audits and discussing how it changes IT Operations -- we discovered it was something greater, the delivery of Software-as-a-Service behind the firewall.

When we first created the Appliance deployment option, we worked hard to streamline administration, from setup in 10 minutes to simplifying upgrades.  Fedex a CD, have someone stick it in and type go for an upgrade.  Admittedly, we had one notable failure.  One customer put the CD on top of the server, got some coffee or something, came back and couldn't get it to go.  Turns out CDs melt.  So we started shipping USBs (download has always been an option too).

Practically, the Appliance model is halfway between the latency of SaaS (near zero) and Onsite deployment (near infinity).  Even if you make tasks like a routine upgrade fast and simple, it doesn't mean they will actually happen.  In some IT departments, particularly those who have outsourced IT with firm SLAs, an upgrade is considered a degradation of service level!

This means that even if the upgrade includes an important patch or desired feature, the vendor gets a scheduled window of opportunity, measured in months or quarters, which can be a lifetime.  On our SaaS version we do upgrades measured in hours or days.  Given the constraint to get our best stuff behind the firewalls of customers we developed the operational discipline and QA processes to really give them our best stuff.  We will serve no wine before its time.

As is common practice for startups, eating our own dogfood (or drinking our own champaign) means our company runs on staging versions.  Not the highly experimental branches you might find in our open source repository, but we bang on it before you do and sometimes it bangs on us.

With a SaaS Appliance, our general release process remains relatively the same, but accelerated.  Turns out IT departments not only love how they don't have to touch it, it simply works, but they can realize a lower TCO -- and shift the SLA burden to the vendor.

Among Phil Wainewright's roundup of 2007 SaaS Predictons was this from Saugatuck Technology on SaaS 2.0:

"SOA's impact on SaaS has lead to development of the Extended-Enterprise Service Bus (X-ESB) as a managed-service appliance … We expect to see an increasing number of SaaS Appliances emerge over the next few years as SaaS becomes fully integrated into the enterprise."

One forward looking enterprise we worked with has the strategic version to move all applications off of their network and rely on SaaS across the public internet.  Not everyone has this vision.  And regulations dictate that some never will.  But nobody is in a better position to take the pulse and manage the health of software than the vendor.  A Managed Service Appliance is a model that meets security and regulatory needs, enables the service of SaaS while offering SOA integration within the enterprises' security framework.  Not all enterprise software will be delivered this way, but it is an option on the rise for good reason.

SEE ALSO: Why Appliances Are Good