Socialtext's New Microblogging Appliance

Written by Steven Walling / July 14, 2009 10:45 AM / 4 Comments

Disclosure: Socialtext is sponsor of the ReadWriteEnterprise channel.

Hot new trends are hard to resist, especially when they open up lucrative new markets. For proof positive, look no further than Socialtext, which today released a Microblogging Appliance independent of the rest of their enterprise collaboration offering.

Long an advocate of the integrated approach to social software, this is the first time Socialtext has unbundled any part of their software. In addition to competing with startups like Yammer and Socialcast, the company aims to use the appliance as a teaser for their complete platform.

Why Now?

In a phone conversation with us, Socialtext co-founder Ross Mayfield outlined two compelling reasons for the shift in strategy when it comes to enterprise microblogging:

Competition with standalone apps: Startups like Yammer and Socialcast has garnered a lot of attention from customers and analysts alike. In the process of due diligence when considering such apps, Mayfield says that companies often have come to Socialtext to make some comparative assessments. But until today, no amount of money could buy you access to Socialtext Signals by itself.

Pilot project: While analysts have decried self-contained microblogging as an unproven sector not easily integrated in to daily workflows, Socialtext sees the appliance as a first step in introducing its software to businesses exploring enterprise 2.0 for the first time.

Unlike the Socialtext freemium option unveiled last month, there is an upfront charge for either a hosted version or an on-site appliance. (Note that when they say Microblogging Appliance, they do not mean on-premise only.) But for $5 per user more a month, businesses have the option to upgrade to Socialtext's wiki/blog Workspaces and Dashboard.

More to Come?

Technically, the Socialtext platform is a series of different apps connected by REST APIs. So in theory at least, there's no reason why they could not break down the entire platform in to its parts, either to be sold separately or in whole according to the customers needs.

Even if it wouldn't be particularly difficult, Socialtext co-founder Ross Mayfield says he doesn't see further fragmentation happening anytime soon. "While further unbundling is an option, what really drives this is which integrated user experiences make sense together.", he told ReadWriteWeb.

Comments

Subscribe to comments for this post OR Subscribe to comments for all ReadWriteEnterprise posts

Somehow my previous post has duplicated content. I somehow manage to consistently fumble my commenting at RWW. :-( The post should read:

Monolithic applications with a few doorknobs for data is a far cry from RESTful (WOA more specifically) and/or distributed architecture and the ability to decompose or federate services and applications. I've been seeing more and more marketing people message RESTFul. They are confused. What they mean is there is XML/JSON accessible over HTTP. Or what is more commonly referred to as REST interfaces. This is NOT a decoupled composition of web-services. This is NOT a platform that is stateless and resource oriented. The former (doorknobs) is nice for pulling or pushing data and is relatively simple to implement. The latter web oriented architecture (WOA--RESTful design applied to 'www' tech) is difficult to implement, but yields scalable and easily integrated applications that are inherently standards compliant. Applications with a WOA can be broken down into their individual services because it is, by its very nature, a composition of decoupled web-services that are stateless. There are many advantages to this: extensibility, scalability, integration. Indeed, these can even be used as as an app server for developing new applications atop. Because WOA applications require a service orchestration engine (and access control layers) these also can be used to federate other applications (services, data sources, etc). I write about this, albeit at a much higher level, here: http://cli.gs/cn

In theory you could break down a monolithic app into it's parts. In reality the shit would be completely broken.

Feel free to delete my previous post if you have the time and inclination. Thanks :-)

Posted by: Aaron Roe Fulkerson | July 14, 2009 3:05 PM

I dont understand why companies would pay such a price when they can get this done thru many other microblogging services

Posted by: Web Hosting | July 15, 2009 3:35 PM

Disclaimer: I work for Socialtext, but below is only my personal opinion and isn't representative for other Socialtext folks.

Aaron, the "The Future of Collaborative Networks" is well-thought-out overview -- many thanks for the link! :-)

When designing Socialtext Desktop, we had an explicit goal of only communicate with ST servers using stateless ReST API calls, which makes the presentation layer entirely independent of the particular ST instance it's interacting with.

With that in mind, I do agree that offering a ReST API -- even a comprehensive one that makes Social Desktop possible -- merely makes decoupled composition easier, but does not equate the two.

However, we've been consciously "breaking down a monolithic app into it's parts" when coding for new components in the ST system, such as Desktop, Signals or SocialCalc, in order to improve connection with third-party services (e.g. via twitter bridge, webhooks, etc.).

Designed this way, these product-parts do communicate with each other via a public stateless ReST API, instead of relying on server-side shared storage.

So while ST is not at a point where I'd call it "completely federated" -- for example, the API authorization layer is not yet completely abstracted out -- we've also come a long way from the "monolithic app with ReST API" phase.

I'd say we're 80% there, but it only means there's still 80% to go. :-)

Posted by: 鳳 | July 26, 2009 6:51 AM