Hi, this is Damien Katz, CEO at CouchOne.

I’ve got some news I’m extremely excited to finally announce: a merger between CouchOne and Membase!

A little background: I met James Phillips, the co-founder of Membase, for the first time in December. I’d heard a little about Membase up to that point, but I was most impressed with some of their high profile users. For example, Membase is a key part of Zynga, where giving millions of users a fast, low latency experience is critical.

Membase has been targeting large scale mission critical apps, being able to scale out quickly and support millions of users, and getting impressive traction. They’d been going after a very specific pain point, a completely different part of the market than what we were targeting. They’ve focused on performance and scalability and exploiting all the power and memory available on modern servers. Simple, Fast, Elastic.

At CouchOne we’ve been focusing on very different problems: mobile, sync and offline use cases. We make it easy to build applications that travel with you, allowing you access to your important data no matter the network conditions. Slow and unreliable connectivity means many businesses can’t rely on the cloud for mission critical apps, all their data is gone when their network is down. But with Couch powered apps on your phone and tablet — putting data directly on the machines at the edge of the network — you have your apps and data with you at all times and safely backed up to the cloud.

Couchbase!

What James had is the vision to see the great fit between the two companies. While independently we were both doing very well, we both have a lot of growing to do yet. And amazingly, the direction Membase needed to grow, we were already doing very well. And in the direction we needed to grow, Membase was already doing very well. Not only were the parts of the stack we were focusing on different and complementary; the way we built out our teams was different and complementary, as well. I’m not sure we could have planned it any better, and we didn’t plan it at all!

And so I’m thrilled to announce Couchbase, a merging of both our companies and our technology!

Technologically, we’ll be joining the products together to create a high volume, low latency, elastic clustered Couchbase server system. A Couch that’s Simple, Fast, Elastic with all the reliability and power of CouchDB. We’ll also continue to support the Membase API, for both backwards compatibility and it’s performance advantages over HTTP.  We will be the only solution out there that can scale to Zynga sized workloads and also scale down to phones and tablets and everything in between, supporting millions of users and keeping everything in sync.

For existing CouchDB users, we will fully support CouchDB’s HTTP API with all its associated benefits: seamless integration with other HTTP based infrastructure, a universally supported, human-readable protocol and direct-browser access just to name a few.

Together as Couchbase, we’ll have the fastest, most scalable (both scale up and scale down) NoSQL solution. We will become the standard storage for mobile devices, and the standard server technology for syncing them all together. Our unified solution will dramatically simplify your technology stack and maintenance for building fast responsive apps that scale to millions of users, and also scale down to phones so people can work and play even when not connected to the network.

My role at Couchbase will be CTO, overseeing the technical direction of the company. Dustin Sallings will be the chief architect. Bob Weiderhold will be CEO and co-founder James Phillips will continue to be product-oriented maniac :) CouchOne co-founders Chris Anderson and Jan Lehnardt will take roles to lead our mobile efforts and to work with our developers and community.

What’s in it for you?

It’s all upside! In the short-term we’ll be able to provide a much better developer and support experience for both for CouchOne and Membase technologies, and move the development speed ahead much faster. The long term benefits are that CouchDB users will acquire the high performance, high scale easy-fast-elastic capabilities of Membase, while Membase users will acquire CouchDB’s indexing features (map/reduce views, lucene, R-Tree GeoCouch), replication, reliability, and an easy path to mobile.

This is hot stuff! 2011 is the year of Couchbase!

Chris Anderson here.

The Web has been synonymous with HTML for too long. But its principles go deeper than arguments over W3C standards or backwards compatible CSS hacks. At the core of the web is the simple concept of linked data. I will argue that the Web, properly understood as linked data, the application that use it, and users that interface with it, can be much richer than just the presentation through HTML, and that extending the reach of the web beyond the confines of the browser is crucial to its long term success.

The surge of smartphone ‘apps’ has pundits and experts alike forecasting the demise of the web. This is the wrong way to think about it. Instead of concentrating on how apps are killing the web, let’s think about how apps can embrace the principles of the Web. Apps could potentially become vibrant participants of the Web, while still retaining their slick user interfaces and proprietary business models.

The web gave us write once run anywhere, a computing holy grail. But apps are platform-specific by design. Putting data on the web (giving it URLs) makes it “linked data”. The huge advantage to such an approach is interoperability at the data layer. Recently, #newtwitter showed us how you can build your web app on top of the same API as your native clients, building almost no new HTML on the server. This wave is only just beginning.

The Web Is Dead?

This recent summer, 2010, Wired Magazine pronounced the web dead.

Here is the tagline that ran along with the article:

Two decades after its birth, the World Wide Web is in decline, as simpler, sleeker services — think apps — are less about the searching and more about the getting. Chris Anderson explains how this new paradigm reflects the inevitable course of capitalism. And Michael Wolff explains why the new breed of media titan is forsaking the Web for more promising (and profitable) pastures.

Of course we’ll take Wired Magazine’s pronouncements in the reverse oracular spirit they’ve earned for a previous obituary, 1997’s “Apple is Dead”:

That year turned out to be a turning point for Apple. Steve came back and everything. By my lights, Wired’s “The Web Is Dead” cover is as ringing an endorsement the Web could hope for.

Apps are threatening the web, with their quick path to revenue (even if they rarely become big hits.) The threat exists because the insides of apps often don’t interact with the web via hyperlinks, or if they do, it’s in an ad-hoc and limited way. This isn’t a bug, it’s just the way apps are — slickness matters in a big way, so developers optimize for user experience, not ‘webiness’.

Is this a turning point for the web, where it will continue as the dominant platform, or will it be replaced by apps? I think the reality is that the Web will win by remaining the backbone, the conduit on which the data is shared and exchanged. Even for the slickest native apps. But before I explain my position, let’s look at the strengths of the Web, and how different the app world is.

Long Live the Web

It is clear that in the possibility space of coding, one goal stood on the horizon for a long time: write once, run anywhere. It’s not always been clear whether it’s attainable, or just a mirage. It’s more of a social question (one of conventions) than a technical one.

Eventually, 21 years ago, the web emerged as the first successful consumer application platform to be independently implemented multiple times, across a wide range of hardware and software environments. This aspect is often overshadowed by the more fundamental changes to our social fabric as the Internet makes us all more connected.

Write once run anywhere has been regarded as a holy-grail since even before Sun’s foray into cross platform application widgets (Java) was unable to take hold as a standard. Similarly Adobe Flash and Microsoft Silverlight have attacked the HTML juggernaut. But in the fullness of time, those efforts look futile when held against the 3D accelerated, mobile, HTML5 web. How does the web do that?

The web is able to subsume the host operating system, as well as invaders (Java and Flash) to become the dominant user interface metaphor of our time, by adhering to a principled stance about openness, one that Tim Berners-Lee can describe better than I can.

The key to Berners-Lee’s argument is that the web enables applications to be brought online, and without any formal coordination, begin to interoperate with other applications on the web, because the constraints of hyperlinking and HTML are defined narrowly enough to allow for consensus. Rather than have a million features, it is better to have one killer feature. For the web, that feature is linking.

Godzilla the App Store

The web was comfortable in its dominance, maybe even starting to stagnate as a platform, when its first new competitor came along — the app store. Such a different way of thinking about software! With the web, anyone can put a new site up, whenever they want. In the app store, plan to wait a week or two before you can show your work to anyone.

But the payoff — literally! With the web your best bet was to put up some ads and hope for massive traffic, or else burden your users with a paywall and suffer the reduced engagement and lack of in-links. In the App Store you can make money from day one, even without massive traffic. It’s no suprise the app ecosystem is growing fast.

The new app sensation, Instagram, is quickly subsuming Facebook’s most powerful feature, photo sharing. And they don’t even have a way to browse your own photos via the web. Don’t get me wrong, I think Instagram is doing everything right, it’s just not very webby — because that’s the way apps are.

What matters in an app first and foremost is that people use it, and encourage their friends to use it. Instagram obviously put a great effort into their onboarding, because setting up my account was seamless and quick. This is development effort well spent, not thinking about linkability. Which is sad, because the message of the Web is so powerful: Build your app into the Web, and it can be linked to and extended beyond the confines of any one system.

Of course, real apps do understand this, and Instagram does share photos by a single-photo url, distributed via other social systems. It pays to be on the web, but Instagram at least has found that the user experience of the Web was no longer the place to invest, when growing the user base.

As a pragmattic matter, it makes sense to focus on slick interfaces and viral adoption, over an interest in broad web-style interoperability. But I think there’s another way.

The Web is more than HTML

Those of us who were aware of the web in the early 90’s knew the web had won when URLs joined the popular parlance. Once everything has a link, people can start to put the web together — by discussing and linking to pages, we build the meaning among the links. The act of linking is more important than the details of HTML. Of course, getting HTML right gives a baseline of interoperability.

Think about #newtwitter again - an (almost) all Ajax application that takes advantage of the same APIs Twitter provides for desktop and mobile clients. The link between the native and the desktop applications is made up of innumerable URLs shared via Web protocols. In Twitter’s case, the URLs are mostly hosted at sites like twitter.com and t.co. Twitter is centralized by design - we’ve seen this mostly-Ajax pattern applied to several prominent websites.

The major criticism that still applies to these Ajax heavy apps, is that because they depend on remote resources, they are inherently slow and unreliable, compared to native apps that don’t require remote servers.

Giving reliable low-latency URLs to native and local web applications

There is a way to have the best of both worlds, by moving the URLs to localhost and asynchronously sharing changes with best-effort as the network connection allows.

My team at CouchOne is putting apps on the web, by building web addressable data into the core of our App Store compatible platform. Our mission is to ensure you have the data you need, no matter the network conditions. We’re happy that developers can make money in the app store, but we know that users will be happier when their data isn’t locked into silos. Everyone should know by now that snappiness is the most important feature any user experience can have.

We’re confident that the benefits you accrue by moving your web server from a high-latency remote server, to the mobile device, will mean a real competitive advantage for early adopters, and eventully a wholesale movement of the web towards client-based eventually consistent applications.

Putting Apps on The Web

The web has traditionally been known as the HTML platform as deployed mostly in browsers. It really has become the #1 way code and functionality gets in front of users. The web won because of its simplicity. But its simplicity is holding it back in the app world.

By giving URLs to data you can have the best of both apps and the web. because the data is shared between the two interfaces so intimately, and presumably with a simple REST interface to support the web client, we can properly say these linked-data apps are on the web. The key to why #newtwitter feels more advanced than other sites with heavy APIs, is that it supports the web client from the public API. This proves that the app API is really Web stuff—we’ll see a lot more of this in the future.

For instance you might have a PhoneGap style cross-platform HTML5 mobile application that suddenly becomes popular among the business crowd, making a native Blackberry UI into a worthwhile investment. The local linked-data layer CouchOne provides a way for distinct implmentations to communicate with a common data substate. With real-time replication, the Blackberry users can collaborate with the web users, on the same app at the same time. The app is on the web, even if it is slick and low latency.

The web won because it allowed linking to anyone, so adding new pages to the web doesn’t require coordination beforhand. In the future, the web will allow sharing of data with the people you choose, using something much like the replication built into Apache CouchDB. Our aim isn’t merely to add to the web developer’s toolkit, it’s to fundamentally rebalance the web in favor of the edge.

As a developer, you’ll be able to take the existing data stored by an existing application, and write you’re own interface for it. Your favorite social network doesn’t have a native UI for your phone’s operating system, but they do offer a Couch feed? Just build your own UI. You’ll still be able to take advantage of real time interaction with users running against the same data on different platforms.

We strive to offer a relaxing new way to share state changes across computing devices, the web, and mobile phones.If you’re interested in combining the web and app worlds, check out Dale’s CouchDB on Android tutorial (coming soon) and the CouchApp community wiki.

Today, one of our CouchDB hosting customers suffered a security issue. During the build up for a product launch, the customer’s developer posted their open source software to the public web. Unfortunately, the source code contained the database administrator credentials. This was an unfortunate error — in this industry the mantra is to hustle and to deliver at all costs. But then a simple oversight anyone could make leads to calamity — we know the feeling and sympathize.

In any event, despite our service’s “beta” status, we are working with our customer to restore their data and reinstate their service. Fortunately, the restoration is greatly simplified by CouchDB’s features.

We value all of our users’ security and as such we strongly suggest that password information never be revealed in publicly accessible source code to avoid this kind of situation in the future. Considering today’s distributed source code systems, the best policy is never to commit authentication credentials at all. We’d like to stress again, that the security incident is not caused by any vulnerability in Apache CouchDB or our hosting infrastructure.

If you have any questions about this or our hosting service in general, do not hesitate to get in touch: hosting@couchone.com

— Jason, VP of Hosting