Probably it is very hard to create a company around an open source project without disrupting part of the open source ecosystem around it... on the other hand it is important to create some kind of structure to pay the developers to continue working on the project. I'm not sure what I would do without VMware helping Redis... but I guess that some decent compromise should exist, like creating a support company for the software but leaving the project itself as an open source effort with it's own separated site, mailing list, and so forth.
There is also an ethical problem IMHO. For instance is Redis mine? I guess it is not: VMware is funding the development so I can write code thanks to Vmware. Pieter is contributing a lot of code. The community is helping a lot the project: with talks spreading the word, helping on the mailing list, helping to fix bugs, and so forth.
My guess is that the developers really conceptually "own" a very small piece of the pie, and when they create business around an open source software, they should take this in mind otherwise it is simple to involuntarily use work/efforts that other people did in the past and turn it into your business.
It's not easy however... as: the end users should be happy and well served, and the software should not just be "open source" but an open process, with an open community, and so forth. At the same time the developers should pay their bills without issues and earn enough to avoid being tempted to joined company XYZ instead of working to their project. It's not trivial to have all this together I guess, and I feel very lucky that there is VMware making this simple for me, but not all the open source developers are equally fortunate so I guess it is crucial that the open source community keeps working on different ideas to find viable solutions.
Salvatore, it is great that VMWare supports you and Redis: representative of the best open source model (open source developers paid to concentrate on writing code). Especially great for Redis users since the source code is still open source, can be read, modified, etc.
This is NOT second system syndrome. This is business, pure and simple. I had a long, LONG series of emails and calls with CouchBase about commercial support for Couch. We have some big production apps on it.
When it got down to time to pay for support, they told me (this is 2 months ago) in a rare and unusual bit of candor, that they were going to drop Couch in less than six months, so did I want to buy commercial support for just six months?
I told them not only do I not want commercial support, but I just got so freaked out I would not recommend couch for future projects to clients, because it was obvious that internally the team had moved on.
They asked me not to tell anyone so I didn't, but now that this is out there I can say what I deducted from our discussions: Couch doesn't make any money; MemBase does. Period.
Kevin Smith at Opscode said they're moving away from Couch (and to MySQL) as Couch just doesn't scale. No finely grained reader/writer locks, one reader/writer thread/db, huge and random delays due to checkpointing that can make the server inoperable, difficulty ever finishing a view checkpoint under load, etc. I think he's right - it's been abandoned as a platform.
It's absolutely their prerogative to move on and it seems like the right decision, but it's not a technical decision. The reality is that CouchDB is largely a product running small, toy apps, written by people who won't PAY anything for support. MemBase is being used by big companies with a lot of money to spend on commercial support and enterprise features.
Actually there is still one case where I recommend Couch and it's when you need the mobile sync features. I doubt that they'll make those a priority anytime soon on the MemBase product (at least I haven't seen or heard anything).
This is not news, and should not reflect poorly on Apache CouchDB. AFAICT, Damien's last commit on the project was 18 months ago, and he is by no means the most active commiter, even on a historical basis.[1]
Apache CouchDB's data model is sublime for the domain I often work in, and I think the same goes for a lot of people. It's not just mobile; personally, I don't do anything mobile- or sync-related.
I have no plans on moving on.[2] Apache CouchDB is as active and healthy a project as ever AFAICT, and having hosting providers like Cloudant makes the entire model all that more attractive.
If it's all about business, then slagging on the project that gave your company its name is perhaps not the greatest approach. Moving on is fine, a fact of life. Making things more difficult for those you leave behind isn't cool, especially when your moving on happened a long time ago.
Interesting. I agree with you when you say what makes Couch interesting is its sync (mobile or not) features. There are lots of DBs out there that focus on scale and not enough on sync.
If they want to win the mobile market though, they will have to re-implement the DB in C. Erlang was a good choice on the server but in the current mobile ecosystem it's clearly a drawback.
re: "...Couch just doesn't scale...": I am curious, did you try using the BigCouch project, open source released from Cloudant? I have never used BigCouch on a customer project, but have experimented with it and it is easy to setup and is the scaling architecture that Cloudant uses for their data store as a service business.
It is interesting, when they dropped Couchbase Single Server I jumped on #couchdb irc channel and said how there will be a developer drain from CouchDB since quite a few of them work for Couchbase and will be working on Couchbase Server only (instead of supporting and sending patches back to CouchDB as well).
I got a lot of disagreements and nasty responses back, suggesting that it would not happen and CouchDB is doing awesome, and how this basically doesn't affect CouchDB at all. However here is its creator, urging everyone in so many words to drop CouchDB and switch to Couchbase.
If CouchDB works for you today, there is no reason to drop it. However, I'm working hard to make sure Couchbase works even better for you. That's what I'm saying.
The ideas in CouchDB were really great, but I was very disappointed with what was termed a 1.0 release of CouchDB, as it did not feel ready for prime time, and it ended up torpedoing a project I was working on. I'm also disappointed that it did not quickly improve, and that it appears to be abandoned by it's creator. I am therefore going to avoid Couchbase or anything by it's creator, as I do not trust that it's a foundation that I can build upon.
That sucks and I'm sorry. I made lots of mistakes, the biggest was trying to run a business instead of the technology. I'm again back where I should be. Whether you choose our technology or not, I wish you success.
As a guy who was lurking around for basically whole duration of CouchDB development. I would argue that Damien did not fall prey to the second system syndrome. He's just too much of a pragmatic for something like that. The soundness of Damiens engineering views and approaches is hugely similar to those of Linus Torvalds.
The truth in my eyes is that CouchDB is misunderstood, the same way Lotus Domino is misunderstood. And if majority of users misunderstand what it is good about then it is not going to be used in an optimal fashion.
What I guess that Damien is going to do is build a database that does shit people expected CouchDB to do. And I believe that Damien is a hedge that ensures that goods are going to be delivered.
This post is pretty vague. Having heard of Couch a few times over the years but not used it, it would been more helpful if he said something like: "I started a company and forked the open source CouchDB project that I founded. The company and new commercial product is CouchBase and it will be better for these reasons..." And I would be curious about some examples of where the open governance limited the CouchDB project as he's implying.
Those seem to be orthogonal things -- he could have just created a non-Apache open source project rather than making it commercial.
He is beating around the bush so much and using such vague wording that I wonder if he is hiding something, or just ashamed that he's cashing in on his creation. There's no shame in making money and no shame in making a commercial fork of your own project. But the CouchBase website looks awfully "enterprisey" now and I think there is some shame in that...
I don't use couchdb either but I do follow the nosql space a little and what I read was that he's creating an all-new project.
Couchdb is an Apache foundation-led project and will continue on its own path. Couchbase is an all-new project that will solve some of the same use-cases but be better at scaling. It's not a fork at all.
True, the website is full of bs. But since it actually talks about the products and technoloies (kind of) it only rates 6 of 10 on my enterprisey-bullsht scale. Others are far worse
This is really bad news. Not exactly out of the blue, but there's no ambiguity now.
http://docs.couchbase.org/couchbase-manual-2.0/couchbase-int...
There's such a wide functional gap between CouchDB and CouchBase that it feels like the heart has been ripped out and placed into an entirely different beast. Of course the Apache project is still there, but I have grave doubt over whether it will continue to be actively developed.
To ease anxieties, it would be great to see a roadmap or some statement of commitment from those remaining in the CouchDB community. Including Iris and Cloudant.
I've spent the past year building an app on CouchDB and I've really enjoyed using it. The couch.io to CouchBase transition was poorly communicated, so I'm glad Damien's made such a clear statement of intent. Clearly I'm going to have to stick with Apache CouchDB for now. I was interested in moving to CouchBase, but that's surprisingly difficult:
1. There's no easy transition for my data. I thought I could just install CouchBase and replicate from my existing CouchDB -- nope, can't be done. Huh? But why...
2. It's partly because CouchBase drops the CouchDB REST API. Which also means, none of my existing code works with it. So I guess it's no big deal that my data won't move over, because my app won't be able to retrieve it anyway.
Because there's no easy transition, they've created a situation where anyone considering a move to CouchBase is just as likely to re-evaluate all of the other document (or k/v) stores.
"We are moving more and more of the core database in C/C++, while still using many of the concurrency and reliability design principles we've proven with the Erlang codebase. And Erlang is still going to be part of the product as well, particularly with cluster management, but most of the performance sensitive portions will be moving to over C code. Erlang is still a great language, but when you need top performance and low level control, C is hard to beat."
This is interesting. If I remember correctly, CouchDB was first written in C++ and then moved to Erlang. Now the project has come full circle (which is fine of course).
I don't think it's coming full circle. They're just properly separating the project code, so that the time critical code is in C/C++ while the scale/fault-tolerant code will be in Erlang.
Oof, seems like a lot of inefficiency in retraining, redocumentation, converting, etc. Not to mention the debugging issues between two different technologies.
This feels like bad news for CouchDB users, since they will need to re-write code and re-learn a new system if they choose to migrate to Couchbase Server.
It's better to promote Couchbase server for it's own merits rather than promoting it as the future of CouchDB.
It would have been a bold move, if Damien had left the "Couch" name with Apache CouchDB, and released his CouchBase product under another name. Also, this would have liberated him from having to distance himself from CouchDB, Erlang and Apache, when promoting his new product.
I agree with what I think that you and other people here are saying: the Apache CouchDB project will continue to be supported by a good community so there is very little technical risk for using CouchDB. BTW, I think that datastore as a service companies like Cloudant, MongoHQ (and many other good companies) are a great convenience, but for self hosting, I wonder why anyone really needs support for CouchDB, MongoDB, etc. unless they have very large deployments.
I looked at couchbase and it seems somewhat user-friendly. The way to preview your created views by using only a subset of data is nice. Another nice thing is the split into ?16? different databases that allow compaction to occur on a smaller level rather than having to compact the whole 60 gb file at once
The downside for me so far:
- I couldn't find any way to import my current couchbase single server data over to couchbase.
- The old couchdb webinterface (futon) made browsing through data easy, the couchbase interface seems to make this a bit more complicated. (Maybe I didn't look in the right places?)
- I couldn't figure out if I can still hook up the _changes feed to elasticsearch
We have something higher-performance than _changes and have had elasticsearch support as a third-party plugin for a while. We don't have firm plans to bring it in first-class, but we do think it would be beneficial to many of our users.
Shame. I really like CouchApp. It felt like CouchDB was one rails moment away from being a whole new way to develop web apps, where the DB, the client, and the application were all part of the same glorious union rather than being a bunch of ugly parts bolted together.
The FAQ [1] tells me that Couchasebase Server 2.0 is open source. But, the link to source tarballs and git repos is conspicuously absent from all the pages i've looked through on couchbase.com/org.
The sources all seem to be sitting in https://github.com/membase/ -- they are componentized, so may be... interesting to work out how to get a running server, but it seems to be there :-) ep_engine looks like the heart of it.
I found it surprising that Damien comes off so completely unapologetic about his decision to abandon Apache and the CouchDB community. As a long time CouchDB user and open source believer the whole tone of his post leaves a dirty taste in my mouth.
"And I'm dead serious about making it the easiest, fastest and most reliable NoSQL database. Easy for developers to use, easy to deploy, reliable on single machines or large clusters, and fast as hell. We are building something you can put your mission critical, customer facing business data on, and not feel like you're running a dirty hack."
That sounds like something I very much want, I hope Damien and the team can deliver.
A big part of this will be getting solid, up to date documentation in place. Even though CouchDB is fantastic to work with, when the official docs are out of line with how it actually works, you immediately feel like you're walking on eggshells.
That said, I really do like the idea of Everything Restful, and wish them the best!
The features I got exited most about (and am relying on today) are: databases per user, continuous replication and the _changes.
From my understanding, these are not part of the CouchBase server, right?
What are the future plans for these features?
Telling from the 2 CouchConfs I've been to, Couchbase is focused on huge one-db setups, distributed and fast ... but what about the "database per user" setup? Is this going to die?
[+] [-] antirez|14 years ago|reply
There is also an ethical problem IMHO. For instance is Redis mine? I guess it is not: VMware is funding the development so I can write code thanks to Vmware. Pieter is contributing a lot of code. The community is helping a lot the project: with talks spreading the word, helping on the mailing list, helping to fix bugs, and so forth.
My guess is that the developers really conceptually "own" a very small piece of the pie, and when they create business around an open source software, they should take this in mind otherwise it is simple to involuntarily use work/efforts that other people did in the past and turn it into your business.
It's not easy however... as: the end users should be happy and well served, and the software should not just be "open source" but an open process, with an open community, and so forth. At the same time the developers should pay their bills without issues and earn enough to avoid being tempted to joined company XYZ instead of working to their project. It's not trivial to have all this together I guess, and I feel very lucky that there is VMware making this simple for me, but not all the open source developers are equally fortunate so I guess it is crucial that the open source community keeps working on different ideas to find viable solutions.
[+] [-] catwell|14 years ago|reply
On a side note: who owns the Redis brand (and logo)?
[+] [-] mark_l_watson|14 years ago|reply
[+] [-] rubyrescue|14 years ago|reply
When it got down to time to pay for support, they told me (this is 2 months ago) in a rare and unusual bit of candor, that they were going to drop Couch in less than six months, so did I want to buy commercial support for just six months?
I told them not only do I not want commercial support, but I just got so freaked out I would not recommend couch for future projects to clients, because it was obvious that internally the team had moved on.
They asked me not to tell anyone so I didn't, but now that this is out there I can say what I deducted from our discussions: Couch doesn't make any money; MemBase does. Period.
Kevin Smith at Opscode said they're moving away from Couch (and to MySQL) as Couch just doesn't scale. No finely grained reader/writer locks, one reader/writer thread/db, huge and random delays due to checkpointing that can make the server inoperable, difficulty ever finishing a view checkpoint under load, etc. I think he's right - it's been abandoned as a platform.
It's absolutely their prerogative to move on and it seems like the right decision, but it's not a technical decision. The reality is that CouchDB is largely a product running small, toy apps, written by people who won't PAY anything for support. MemBase is being used by big companies with a lot of money to spend on commercial support and enterprise features.
Actually there is still one case where I recommend Couch and it's when you need the mobile sync features. I doubt that they'll make those a priority anytime soon on the MemBase product (at least I haven't seen or heard anything).
[+] [-] cemerick|14 years ago|reply
Apache CouchDB's data model is sublime for the domain I often work in, and I think the same goes for a lot of people. It's not just mobile; personally, I don't do anything mobile- or sync-related.
I have no plans on moving on.[2] Apache CouchDB is as active and healthy a project as ever AFAICT, and having hosting providers like Cloudant makes the entire model all that more attractive.
If it's all about business, then slagging on the project that gave your company its name is perhaps not the greatest approach. Moving on is fine, a fact of life. Making things more difficult for those you leave behind isn't cool, especially when your moving on happened a long time ago.
[1] 8/24/2010, according to https://github.com/apache/couchdb [2] http://groups.google.com/group/clojure-clutch/browse_frm/thr...
[+] [-] catwell|14 years ago|reply
If they want to win the mobile market though, they will have to re-implement the DB in C. Erlang was a good choice on the server but in the current mobile ecosystem it's clearly a drawback.
[+] [-] mark_l_watson|14 years ago|reply
[+] [-] rdtsc|14 years ago|reply
I got a lot of disagreements and nasty responses back, suggesting that it would not happen and CouchDB is doing awesome, and how this basically doesn't affect CouchDB at all. However here is its creator, urging everyone in so many words to drop CouchDB and switch to Couchbase.
[+] [-] damienkatz|14 years ago|reply
[+] [-] epistasis|14 years ago|reply
[+] [-] damienkatz|14 years ago|reply
[+] [-] smacktoward|14 years ago|reply
> now, as it turns out, I have a chance to do it all again
> throwing out what didn't work, and strengthening what does
> not feel like you're running a dirty hack
Second-system syndrome [1] ahoy!
[1] See http://www.the-wabe.com/notebook/second-system.html, http://c2.com/cgi/wiki?SecondSystemEffect, http://en.wikipedia.org/wiki/Second-system_effect, http://www.joelonsoftware.com/articles/fog0000000069.html, et al
[+] [-] JanezStupar|14 years ago|reply
The truth in my eyes is that CouchDB is misunderstood, the same way Lotus Domino is misunderstood. And if majority of users misunderstand what it is good about then it is not going to be used in an optimal fashion.
What I guess that Damien is going to do is build a database that does shit people expected CouchDB to do. And I believe that Damien is a hedge that ensures that goods are going to be delivered.
[+] [-] zerothehero|14 years ago|reply
Those seem to be orthogonal things -- he could have just created a non-Apache open source project rather than making it commercial.
He is beating around the bush so much and using such vague wording that I wonder if he is hiding something, or just ashamed that he's cashing in on his creation. There's no shame in making money and no shame in making a commercial fork of your own project. But the CouchBase website looks awfully "enterprisey" now and I think there is some shame in that...
[+] [-] smokinn|14 years ago|reply
I don't use couchdb either but I do follow the nosql space a little and what I read was that he's creating an all-new project.
Couchdb is an Apache foundation-led project and will continue on its own path. Couchbase is an all-new project that will solve some of the same use-cases but be better at scaling. It's not a fork at all.
[+] [-] gizzlon|14 years ago|reply
[+] [-] henchan|14 years ago|reply
http://docs.couchbase.org/couchbase-manual-2.0/couchbase-int... There's such a wide functional gap between CouchDB and CouchBase that it feels like the heart has been ripped out and placed into an entirely different beast. Of course the Apache project is still there, but I have grave doubt over whether it will continue to be actively developed. To ease anxieties, it would be great to see a roadmap or some statement of commitment from those remaining in the CouchDB community. Including Iris and Cloudant.
[+] [-] robterrell|14 years ago|reply
1. There's no easy transition for my data. I thought I could just install CouchBase and replicate from my existing CouchDB -- nope, can't be done. Huh? But why...
2. It's partly because CouchBase drops the CouchDB REST API. Which also means, none of my existing code works with it. So I guess it's no big deal that my data won't move over, because my app won't be able to retrieve it anyway.
Because there's no easy transition, they've created a situation where anyone considering a move to CouchBase is just as likely to re-evaluate all of the other document (or k/v) stores.
[+] [-] plinkplonk|14 years ago|reply
This is interesting. If I remember correctly, CouchDB was first written in C++ and then moved to Erlang. Now the project has come full circle (which is fine of course).
[+] [-] TheRevoltingX|14 years ago|reply
[+] [-] Joakal|14 years ago|reply
Why would it be fine?
[+] [-] clark-kent|14 years ago|reply
It's better to promote Couchbase server for it's own merits rather than promoting it as the future of CouchDB.
[+] [-] nephics|14 years ago|reply
CouchDB is dead, long live Apache CouchDB.
[+] [-] mark_l_watson|14 years ago|reply
[+] [-] rb2k_|14 years ago|reply
The downside for me so far:
- I couldn't find any way to import my current couchbase single server data over to couchbase.
- The old couchdb webinterface (futon) made browsing through data easy, the couchbase interface seems to make this a bit more complicated. (Maybe I didn't look in the right places?)
- I couldn't figure out if I can still hook up the _changes feed to elasticsearch
[+] [-] dlsspy|14 years ago|reply
[+] [-] gr2m|14 years ago|reply
[+] [-] sgentle|14 years ago|reply
[+] [-] minikomi|14 years ago|reply
[+] [-] sausagefeet|14 years ago|reply
[+] [-] FraaJad|14 years ago|reply
[1]http://blog.couchbase.com/couchbase-server-20-most-common-qu...
[+] [-] brianm|14 years ago|reply
[+] [-] nknight|14 years ago|reply
https://github.com/couchbase/couchdb
[+] [-] czue|14 years ago|reply
[+] [-] crabasa|14 years ago|reply
That sounds like something I very much want, I hope Damien and the team can deliver.
[+] [-] alecthomas|14 years ago|reply
[+] [-] minikomi|14 years ago|reply
That said, I really do like the idea of Everything Restful, and wish them the best!
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] perfunctory|14 years ago|reply
[+] [-] grout|14 years ago|reply
Clue: Dealmaking is not codemaking.
[+] [-] gr2m|14 years ago|reply
From my understanding, these are not part of the CouchBase server, right? What are the future plans for these features?
Telling from the 2 CouchConfs I've been to, Couchbase is focused on huge one-db setups, distributed and fast ... but what about the "database per user" setup? Is this going to die?
[+] [-] thesorrow|14 years ago|reply