You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2013/07/24 13:24:06 UTC
What's our Why?
Hi devs,
I came across this video recently:
Simon Sinek: How great leaders inspire action
http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
In it he sets out what he calls the Golden Circle:
Why
- What's your purpose?
- What's your cause?
- What's your belief?
How
- How do we do it?
- How does our product differentiate?
- How are we different?
- How are we better?
What
- What do we do?
- What do we make?
He points out that the difference between companies like Apple and
companies like Dell.
Dell tells you what they do, and how. "We make great computers. They're
well designed and work well. Wanna buy a computer?" Most companies do it
like this. But they often miss out the "why".
But then you look at Apple, and they do it the other way around. Apple tell
you what their purpose is. The rest is almost an afterthought. "We believe
in challenging the status quo. We believe in thinking different. We do that
with great design and a focus on the user experience. We just happen to
make computers." He then joking quips: "Ready to buy one yet?"
(His talk gives several other examples, with his thesis being that telling
your story from the outside in is what separates all the great companies
and leaders. One of his main examples is the Wright brothers.)
He comments that if you talk about what you believe, you will attract those
that believe what you believe. That when you talk about what you believe,
people will join you for their own reasons, for their own purpose. And that
what you do simply serves as proof of what you believe. Or as he quips:
"Martin Luther King gave his 'I have a dream' speech, not his 'i have a
plan' speech."
Why am I bringing this to the dev list?
Because our message stinks. "Apache CouchDB™ is a database that uses JSON
for documents, JavaScript for MapReduce queries, and regular HTTP for an
API" is a terrible way to introduce who we are, what we stand for, and why
we build this thing. (And I'm allowed to say all that, because I'm the one
who wrote it, with lots of help from Jan.)
So what am I proposing? I'm proposing that we figure out our why. That we
figure out what we stand for, what we believe in. And then we figure out
how we're gonna do that (pro tip: replication is more important than the
data format we use). Not only will this define a consistent internal vision
for the project (what *are* we working towards anyway?) but it will help us
to attract people who believe in what we believe.
So, if you have any thoughts about this, speak up!
Thanks,
--
NS
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
(P.S. The video is defo recommended watching! This guy covers it better
than I have.)
On 24 July 2013 12:42, Noah Slater <ns...@apache.org> wrote:
> Agreed. Those are important! I think replication is basically our #1
> technical selling point.
>
> However... These are still "how" and not "why".
>
> "Of the web" is more approaching the why, but it's still mostly "how".
>
> For the why, I am thinking something more akin to the sorts of stuff that
> CouchDB can enable. The peer-to-peer replication of apps and datasets. Of
> being able to have your data everywhere. Why? Why are these things
> important to us? Replication is great (super great) but what purpose is it
> serving? What ultimate goal is it helping us to edge closer to?
>
>
> On 24 July 2013 12:33, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>
>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
>> > So, if you have any thoughts about this, speak up!
>>
>> For me, CouchDB is about:
>>
>> - Schema-less/document-oriented
>> - Replication
>>
>> I also like that it's built "of the web", as Jacob KM wrote, but for
>> my usage, that's mostly extra convenience and elegance, not one of the
>> core reasons why I end up using CouchDB.
>>
>> Cheers,
>>
>> Dirkjan
>>
>
>
>
> --
> NS
>
--
NS
Re: What's our Why?
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Jul 24, 2013 at 1:42 PM, Noah Slater <ns...@apache.org> wrote:
> For the why, I am thinking something more akin to the sorts of stuff that
> CouchDB can enable. The peer-to-peer replication of apps and datasets. Of
> being able to have your data everywhere. Why? Why are these things
> important to us? Replication is great (super great) but what purpose is it
> serving? What ultimate goal is it helping us to edge closer to?
Painless distributed systems?
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
Agreed. Those are important! I think replication is basically our #1
technical selling point.
However... These are still "how" and not "why".
"Of the web" is more approaching the why, but it's still mostly "how".
For the why, I am thinking something more akin to the sorts of stuff that
CouchDB can enable. The peer-to-peer replication of apps and datasets. Of
being able to have your data everywhere. Why? Why are these things
important to us? Replication is great (super great) but what purpose is it
serving? What ultimate goal is it helping us to edge closer to?
On 24 July 2013 12:33, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
> > So, if you have any thoughts about this, speak up!
>
> For me, CouchDB is about:
>
> - Schema-less/document-oriented
> - Replication
>
> I also like that it's built "of the web", as Jacob KM wrote, but for
> my usage, that's mostly extra convenience and elegance, not one of the
> core reasons why I end up using CouchDB.
>
> Cheers,
>
> Dirkjan
>
--
NS
Re: What's our Why?
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
> So, if you have any thoughts about this, speak up!
For me, CouchDB is about:
- Schema-less/document-oriented
- Replication
I also like that it's built "of the web", as Jacob KM wrote, but for
my usage, that's mostly extra convenience and elegance, not one of the
core reasons why I end up using CouchDB.
Cheers,
Dirkjan
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
Thanks guys! I am slowly plodding away at this. Will update the list when I
have something to share.
On 9 August 2013 13:03, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 24 July 2013 14:06, Noah Slater <ns...@apache.org> wrote:
> > Benoit,
> > "Painless distributed systems" is also a step in the right direction for
> > answering the question "why?"
>
> +1 I like this.
>
> > So far we have:
> >
> > * Relax
> > * Decentralised web
> > * Peer-to-peer replication of apps and datasets
> > * Your data, everywhere
> > * Put the data where you need it
> > * We handle your data / you handle display
> > * Painless distributed systems
> >
> > Somewhere in here ^ (and perhaps in a follow up reply) is a single shared
> > value system. Something we all hold dear.
> >
> >
> >
> >
> > On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
> >
> >> Anyway, CouchDB is not like apple or dell. This isn't a company. And we
> >> don't have to share all the same vision, but only common values, a core.
> >> I'm not sure it enter in the what you describe. What kind of vision are
> you
> >> speaking about?
> >>
> >> Also I would remove any pro-tip from your mail if we want to start from
> a
> >> neutral base.
> >>
> >> Couchdb is known for the replication but not only. Couchapps and the way
> >> people hack around is another (hoodie, kanso, erica/ couchapp all
> >> differents visions of what is a couchapp but all are using couchdb the
> >> same_.. Message hub is another (nodejistsu, hoodie are using couchdb as
> a
> >> message hub somehow, not only but a lot of their arch is based on
> changes).
> >> And now we we can add some kind of big data handling. Not forgetting
> people
> >> that are using apache couchdb on their mobile, they exists and the
> patches
> >> will be release.
> >>
> >> All have different visions. But they share some common features. I don't
> >> want to forget someone because of a vision of some. I only know that
> >> couchdb has some strong features that could be improved.
> >>
> >> All that to say that rather than thinking to a vision, maybe we could
> >> collect all the usages around and see what emerges from it. What are the
> >> core features, What couchdb should focus on and itterrate depending on
> the
> >> new usage. I guess it's some kind of philosophy: "relax we take care
> about
> >> your data and the way you exchange and render them wherever they are".
> >>
> >> - benoit
> >>
> >>
> >> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org>
> wrote:
> >>
> >> > Hi devs,
> >> >
> >> > I came across this video recently:
> >> >
> >> > Simon Sinek: How great leaders inspire action
> >> >
> >>
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
> >> >
> >> > In it he sets out what he calls the Golden Circle:
> >> >
> >> > Why
> >> >
> >> > - What's your purpose?
> >> > - What's your cause?
> >> > - What's your belief?
> >> >
> >> > How
> >> >
> >> > - How do we do it?
> >> > - How does our product differentiate?
> >> > - How are we different?
> >> > - How are we better?
> >> >
> >> > What
> >> >
> >> > - What do we do?
> >> > - What do we make?
> >> >
> >> > He points out that the difference between companies like Apple and
> >> > companies like Dell.
> >> >
> >> > Dell tells you what they do, and how. "We make great computers.
> They're
> >> > well designed and work well. Wanna buy a computer?" Most companies do
> it
> >> > like this. But they often miss out the "why".
> >> >
> >> > But then you look at Apple, and they do it the other way around. Apple
> >> tell
> >> > you what their purpose is. The rest is almost an afterthought. "We
> >> believe
> >> > in challenging the status quo. We believe in thinking different. We do
> >> that
> >> > with great design and a focus on the user experience. We just happen
> to
> >> > make computers." He then joking quips: "Ready to buy one yet?"
> >> >
> >> > (His talk gives several other examples, with his thesis being that
> >> telling
> >> > your story from the outside in is what separates all the great
> companies
> >> > and leaders. One of his main examples is the Wright brothers.)
> >> >
> >> > He comments that if you talk about what you believe, you will attract
> >> those
> >> > that believe what you believe. That when you talk about what you
> believe,
> >> > people will join you for their own reasons, for their own purpose. And
> >> that
> >> > what you do simply serves as proof of what you believe. Or as he
> quips:
> >> > "Martin Luther King gave his 'I have a dream' speech, not his 'i have
> a
> >> > plan' speech."
> >> >
> >> > Why am I bringing this to the dev list?
> >> >
> >> > Because our message stinks. "Apache CouchDB™ is a database that uses
> JSON
> >> > for documents, JavaScript for MapReduce queries, and regular HTTP for
> an
> >> > API" is a terrible way to introduce who we are, what we stand for, and
> >> why
> >> > we build this thing. (And I'm allowed to say all that, because I'm the
> >> one
> >> > who wrote it, with lots of help from Jan.)
> >> >
> >> > So what am I proposing? I'm proposing that we figure out our why.
> That we
> >> > figure out what we stand for, what we believe in. And then we figure
> out
> >> > how we're gonna do that (pro tip: replication is more important than
> the
> >> > data format we use). Not only will this define a consistent internal
> >> vision
> >> > for the project (what *are* we working towards anyway?) but it will
> help
> >> us
> >> > to attract people who believe in what we believe.
> >> >
> >> > So, if you have any thoughts about this, speak up!
> >> >
> >> > Thanks,
> >> >
> >> > --
> >> > NS
>
> Somewhat belated but here's my 2c.
>
> I got started with couchdb because the thing I wanted to do *did* need
> simple & reliable web/html access, didn't need middleware, didn't need
> a complex sql setup. It fit a document style db very well and in the
> end the company I worked for decided to use sharepoint (go figure) so
> I left them and stayed with couchdb of course.
>
> TL;DR replication + JSON + HTML makes some things *very* easy. And the
> API behind it means that scaling up/out/down is trivial, compared to
> other solutions.
>
--
Noah Slater
https://twitter.com/nslater
Re: What's our Why?
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 24 July 2013 14:06, Noah Slater <ns...@apache.org> wrote:
> Benoit,
> "Painless distributed systems" is also a step in the right direction for
> answering the question "why?"
+1 I like this.
> So far we have:
>
> * Relax
> * Decentralised web
> * Peer-to-peer replication of apps and datasets
> * Your data, everywhere
> * Put the data where you need it
> * We handle your data / you handle display
> * Painless distributed systems
>
> Somewhere in here ^ (and perhaps in a follow up reply) is a single shared
> value system. Something we all hold dear.
>
>
>
>
> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> Anyway, CouchDB is not like apple or dell. This isn't a company. And we
>> don't have to share all the same vision, but only common values, a core.
>> I'm not sure it enter in the what you describe. What kind of vision are you
>> speaking about?
>>
>> Also I would remove any pro-tip from your mail if we want to start from a
>> neutral base.
>>
>> Couchdb is known for the replication but not only. Couchapps and the way
>> people hack around is another (hoodie, kanso, erica/ couchapp all
>> differents visions of what is a couchapp but all are using couchdb the
>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb as a
>> message hub somehow, not only but a lot of their arch is based on changes).
>> And now we we can add some kind of big data handling. Not forgetting people
>> that are using apache couchdb on their mobile, they exists and the patches
>> will be release.
>>
>> All have different visions. But they share some common features. I don't
>> want to forget someone because of a vision of some. I only know that
>> couchdb has some strong features that could be improved.
>>
>> All that to say that rather than thinking to a vision, maybe we could
>> collect all the usages around and see what emerges from it. What are the
>> core features, What couchdb should focus on and itterrate depending on the
>> new usage. I guess it's some kind of philosophy: "relax we take care about
>> your data and the way you exchange and render them wherever they are".
>>
>> - benoit
>>
>>
>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> > Hi devs,
>> >
>> > I came across this video recently:
>> >
>> > Simon Sinek: How great leaders inspire action
>> >
>> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>> >
>> > In it he sets out what he calls the Golden Circle:
>> >
>> > Why
>> >
>> > - What's your purpose?
>> > - What's your cause?
>> > - What's your belief?
>> >
>> > How
>> >
>> > - How do we do it?
>> > - How does our product differentiate?
>> > - How are we different?
>> > - How are we better?
>> >
>> > What
>> >
>> > - What do we do?
>> > - What do we make?
>> >
>> > He points out that the difference between companies like Apple and
>> > companies like Dell.
>> >
>> > Dell tells you what they do, and how. "We make great computers. They're
>> > well designed and work well. Wanna buy a computer?" Most companies do it
>> > like this. But they often miss out the "why".
>> >
>> > But then you look at Apple, and they do it the other way around. Apple
>> tell
>> > you what their purpose is. The rest is almost an afterthought. "We
>> believe
>> > in challenging the status quo. We believe in thinking different. We do
>> that
>> > with great design and a focus on the user experience. We just happen to
>> > make computers." He then joking quips: "Ready to buy one yet?"
>> >
>> > (His talk gives several other examples, with his thesis being that
>> telling
>> > your story from the outside in is what separates all the great companies
>> > and leaders. One of his main examples is the Wright brothers.)
>> >
>> > He comments that if you talk about what you believe, you will attract
>> those
>> > that believe what you believe. That when you talk about what you believe,
>> > people will join you for their own reasons, for their own purpose. And
>> that
>> > what you do simply serves as proof of what you believe. Or as he quips:
>> > "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
>> > plan' speech."
>> >
>> > Why am I bringing this to the dev list?
>> >
>> > Because our message stinks. "Apache CouchDB™ is a database that uses JSON
>> > for documents, JavaScript for MapReduce queries, and regular HTTP for an
>> > API" is a terrible way to introduce who we are, what we stand for, and
>> why
>> > we build this thing. (And I'm allowed to say all that, because I'm the
>> one
>> > who wrote it, with lots of help from Jan.)
>> >
>> > So what am I proposing? I'm proposing that we figure out our why. That we
>> > figure out what we stand for, what we believe in. And then we figure out
>> > how we're gonna do that (pro tip: replication is more important than the
>> > data format we use). Not only will this define a consistent internal
>> vision
>> > for the project (what *are* we working towards anyway?) but it will help
>> us
>> > to attract people who believe in what we believe.
>> >
>> > So, if you have any thoughts about this, speak up!
>> >
>> > Thanks,
>> >
>> > --
>> > NS
Somewhat belated but here's my 2c.
I got started with couchdb because the thing I wanted to do *did* need
simple & reliable web/html access, didn't need middleware, didn't need
a complex sql setup. It fit a document style db very well and in the
end the company I worked for decided to use sharepoint (go figure) so
I left them and stayed with couchdb of course.
TL;DR replication + JSON + HTML makes some things *very* easy. And the
API behind it means that scaling up/out/down is trivial, compared to
other solutions.
Re: What's our Why?
Posted by Dale Harvey <da...@arandomurl.com>.
+1000, thanks for this Jan
It very much models both I how I think about CouchDB and how I think +
architect PouchDB (much of that is echoed on http://pouchdb.com/)
I have quite a lot of thoughts on this, most of them technical so I will do
them in seperate threads, but wanted to voice my agreement in the overall
thoughts of this.
On 24 July 2013 22:36, Jan Lehnardt <ja...@apache.org> wrote:
> I have a dream…
>
> (pardon the plagiarism)
>
> I want to live in a world where people are empowered to understand
> and are capable to decide where their data lives. I want to live in
> a world where developers build apps that support that, not because
> they went out of their way to implement it, but because it is a
> feature of the software platform they are using.
>
> I want to be able to help people improve their lives in regions of
> the world where ubiquitous network access isn’t — and sometimes that
> is just a major western capital’s subway — but more likely is it a
> lesser developed location, or a rural area that will never see mobile
> broadband, let alone wired broadband because there is no financial
> incentive.
>
> I want to live in a world where technology solves more problems than
> it creates. One of those ways is allow people to use software wherever
> they are in whatever context they need it in. More often than not,
> that means far away from fast network access (Despite what @dhh is
> trying to tell you).
>
> My primary motivation for working on Apache CouchDB is to help build
> the world I want to live in. The same motivation drives my motivation
> behind Hoodie (http://hood.ie), which builds on top of CouchDB and
> wouldn’t be possible without it.
>
>
> * * *
>
> In the past year I have interviewed a fair number of people, let’s
> say 50, from those who have heard about CouchDB to users to core devs.
>
> The ONE feature that makes CouchDB relevant is multi-master replication.
> There is no exception, this is the ONE thing that makes CouchDB
> exceptional. NOBODY else has that, and even the decent proprietary
> solutions that are just coming to market suck where we KICK ASS.
>
> There are many other things that people like about CouchDB: reliability,
> no schema, HTTP interface, the view system, etc. But NONE of these people
> would care if CouchDB didn’t have multi-master replication.
>
>
> * * *
>
> The number one thing that people did NOT like about CouchDB is that it
> is confused. CouchDB has a torn identity, half database, half
> application server. It wasn’t clear (and I am part responsible for this)
> what CouchDB is and wants to be. In everybody’s defence, I think, it
> just took a while to figure it out. Now is a good time to put our
> findings in writing and fix this.
>
> The number one request from people was to clear up CouchDB’s story,
> to have a clear, bold vision that captures people and that they can
> easily understand and share and support and move forward.
>
>
> * * *
>
> Here is a narrative about what CouchDB has, that has formed in my head
> in the past year. I have shared this with some people privately for some
> feedback and they all liked it, so it has that going for it. I also tried
> out bringing some of these issues up in presentations I have given, to
> again great feedback.
>
> E.g.:
>
> http://www.youtube.com/watch?v=7mdG-iAizVc or
> http://www.youtube.com/watch?v=edbi9jJZkpg
>
> Before I lay it out, I understand that I will be ruffling some feathers.
> I think that is both necessary and healthy. I think the picture I am
> going to paint will make a lot of people in the CouchDB community happy,
> some with concessions, but I utterly and strongly believe that this
> vision of what CouchDB is has the power to set the course for the next
> five years of the project and attract a whole lot of new people both
> as users and contributors.
>
>
>
> * * *
>
> CouchDB is a database that replicates.
>
> Think of it as git for your data-layer. Not in a sense where you manage
> text files and diff and merge, but in the sense that you have a local
> version of your data and one or multiple remote ones and you can
> seamlessly move your data between them, back and forth and crossover.
>
> Imagine a local checkout of your data that you can work on, and then
> share it with Lucie across the table, she finds some issues and fixes
> up the data, and shares it with Tim across the room. Tim fixes two
> more issues and you pull both their changes into your copy. We conclude
> the whole thing is golden and we push it to staging, where our continuous
> integration runs and decides that the data is good to go into production,
> so it pushes it to production. There the data is picked up from various
> clients, some mobile over there, some web over here, a backup system
> in the Tokyo office…
>
> Or you have hospitals in remote regions in Africa that collect local
> health data, like how many malaria infections a region has and they all
> share their results over unreliable mobile connections and the data
> still makes it eventually maybe with a few hours delay and the malaria
> expert in the capital city sees an increased outbreak of some illness
> and is able to send out medicine in time to arrive for the patients
> to help. Where today the expert takes months to travel between the
> hospitals to collect that data manually and find out that there was
> a lethal outbreak two months ago and everybody died.
>
> (Somebody built this, CouchDB does save lives, I get teary every time
> I tell this story (like now). Our work doesn’t get more noble than
> this.)
>
> Or imagine millions of mobile users with access to terabytes of
> data in the cloud, replicating the bits they need to their phones
> and tablets, allowing super-fast low-latency access for a stellar
> user experience, while giving access to sheer amounts of data and
> allowing full write access on the mobile device to be replicated
> back to the cloud when connections exist.
>
> (Our friends at Cloudant have a couple of those customers.)
>
>
> That is the power of CouchDB.
>
>
> * * *
>
> Replication is the PRIMARY feature of CouchDB. “is a database” means
> “stores your data, safely and securely”, “that replicates” highlights
> the primary feature.
>
> There are many more very cool features of CouchDB, even the details
> on how we achieve reliability and data safety or how replication
> works are mindblowingly cool. The simple HTTP interface, the JSON
> store, the app-server features, map reduce views, all very excellent
> things that make CouchDB unique, but it is very important to understand
> that they are SECONDARY features.
>
>
> * * *
>
> I want to learn from understanding what the PRIMARY and SECONDARY
> features for CouchDB are. I already feel a bit bad about that the
> PRIMARY ones are two (“a database” *and* “that replicates”), but I
> think that is as little as it gets.
>
> I want CouchDB’s new identity to be a database that replicates. I want
> to provide a slide deck for a “CouchDB in 25 minutes” presentation* that
> everybody can take and give and customise, but I want that one of the
> first things you say “CouchDB is a database that replicates”. I want
> that if you ask anyone inside the CouchDB developer community (you!)
> about what CouchDB is to answer “CouchDB is a database that replicates”
> and then follow up explaining what we mean, and *then* add a few more
> of the SECONDARY features that you particularly like.
>
> * https://dl.dropboxusercontent.com/u/82149/CouchDB-in-25-Minutes.pdf
> Full talk at: http://vimeo.com/62599420 (sorry this one is German,
> still trying to find an English version of this)
>
> I want that people who barely look at CouchDB comment on an unrelated
> Hacker News thread write “…CouchDB is a database that replicates, maybe
> that is a better fit for your problem”.
>
> I want that the CTO of the newly funded startup thinks “I seem to have
> a replication problem to solve, maybe CouchDB can help.”
>
> I want to move CouchDB’s development forward, and when we ask ourselves
> whether to add a feature, we run it by our PRIMARY feature set and ask
> “does it support ‘CouchDB is a database that replicates’” and if it does
> we go ahead and build it, and if it doesn’t we may consider it as a
> SECONDARY feature, or we discard it altogether.
>
> (I don’t actually care what the final slogan will be, and please bike-shed
> this to no avail, but it should capture what I mean with “CouchDB is a
> database that replicates”, a phrase that we can burn into everybody’s
> head that captures CouchDB’s PRIMARY feature, its PRIMARY value
> proposition, the ONE thing that explains WHY we are excited about
> CouchDB.)
>
>
> * * *
>
> Now, you might be miffed that your pet feature didn’t make the PRIMARY
> list.
> Do not worry, I believe I have a solution for that.
>
> I have brought this up before, but I really do think the holy grail to all
> this is a very well done plugin system that allows us to follow the “small
> core, massive plugin repository” paradigm that other’s ever so successfully
> pioneered.
>
> This allows us to focus on what CouchDB is for internal and external
> communication, for roadmap discussions and attraction of developer talent.
>
> More importantly, it allows us to keep all the fringe things that makes
> CouchDB so very appealing to a lot of different people. It also allows us
> to open up development to people who feel intimidated working on core
> CouchDB, but can easily write a little plugin or three (this is basically
> me, I have like 20 branches on GitHub that are useful to maybe 5% of our
> users and they don’t get used any).
>
> A wise person once said “Core is where features go to rot.”, and if you
> look at a number of CouchDB features, you can see that we suffer from that.
>
> We need a kick-ass plugin system that allows us to easily create, publish,
> maintain and update little pieces of code that allow our users to make
> their CouchDB their own. (I am signing up to build that, but I will need
> your help, there is a shit ton of work to do :)
>
>
> * * *
>
> ALERT: OPINION (your opinion may differ and we need to hear it)
>
> There is a discussion we need to have what the “small core” means for
> CouchDB. There is a discrepancy between the absolute minimum to fulfil
> the “CouchDB is a database that replicates“ mantra and what would be
> a useful-out-of-the-box product that our users could set up and be
> productive with.
>
> My minimum set looks roughly like this:
>
> - core database management (crud dbs & json/mime-docs, clustering)
> - remote & local replication
> - MR-views & GeoCouch enabled by default (ideally abstracted
> away with nice “query dsl”)
> - HTTP interface
> - Fu/Fauxton
> - configuration
> - stats
> - docs
> - plugin system with Erlang (and in the future JavaScript support
> via Node.js)
>
> This makes for a useful CouchDB default setup.
>
> Everything else should be a plugin. A piece of code that can be installed
> with a quick search and a click of a button in Futon (or a `curl`-call on
> the HTTP interface). Not far away, definitely not “siberia” (if you get
> the PHP reference), but close to the core and encouraged to be used.
>
> And yes, this explicitly includes things like shows and lists and update
> functions and rewrites and vhosts. We should make it super simple to add
> these, but for a default experience, they are very, very confusing. We
> should have a single plugin “CouchApp Engine” which includes Benoit’s
> vision of CouchApps done right that is just a click away to install.
>
> In terms of highlighting the strengths of the core CouchDB “product”, this
> is what I’d put on the website:
>
> - Apache CouchDB implements the CouchDB vision:
> It is a database that replicates.
>
> - Document Database:
> - Data records are standard JSON.
> - Unlimited Binary data storage with attachments.
> - (alternatively arbitrary mime docs with special rules for JSON docs)
>
> - Fault-tolerant:
> - Data is always safe. Tail-append storage ensures no messing with
> already committed data.
> - Errors are isolated, recovery is local and doesn’t affect other
> parallel requests.
> - Recovery of fatal errors is immediate. There is no “fixup phase”
> after a restart.
> - Software updates and bugfix deployment without downtime.
>
> - Highly Concurrent:
> - Erlang makes good use of massively parallel network server
> installations.
> - Garbage collection happens roughly on a per-request basis.
> GC in one request doesn’t affect other requests.
>
> - Cluster / BigCouch / Big Data:
> - Includes a Dynamo-style clustering and cluster-management
> feature that allows to spread data and load over multiple
> physical machines.
> - Scales up to Petabytes of data.
>
> - Secondary 2D and 3D indexing
> - Using incremental and asynchronous index updates for
> high-performance queries.
>
> - Makes good use of hardware:
> - Tail-append storage allows for serial write access to
> storage media, which is a best-case-scenario for spinning
> disks and SSDs.
>
> - Small Core & Flexible Plugin System:
> - Some features are only useful for a small group of people, these
> can be installed with a super simple plugin management system that
> is built into the admin interface.
> - Get new features with a click or tap.
> - Plugins can be written in Erlang (and in JavaScript in the future).
>
> - Cross Platform Support
> - Runs on any POSIX UNIX as well as Windows.
> - Support for some embedded devices like Android and RaspberryPi.
>
>
> I think this would make for a compelling list of technical features.
>
> (I’d probably also add a blip about the ASF and the Apache 2.0 License
> for good measure)
>
> ALERT END
>
>
> * * *
>
> And then, CouchDB is one more thing. CouchDB isn’t just the Erlang
> implementation of this whole replicating database idea. CouchDB is also
> the wire protocol, the specification that makes all the magic work.
> Apache CouchDB is the focal point for The Replicating Society*.
>
> (* cue your Blade Runner jokes)
>
> Apache CouchDB is THE standard for data freedom and exchange and is
> the clearing house, the centre for an ecosystem that includes fantastic
> projects like PouchDB and the TouchDBs, MAx Ogden’s `dat` and whichever
> else follow these. Not saying we merge those projects in, they can stand
> on their own, but we should embrace everything that makes the
> interoperable replication world a reality.
>
> http://couchdb.apache.org is going to be the centre of the data
> replication universe.
>
>
> * * *
>
> Now all of this is my vision and I bringing it to this table now.
> I have to admit that I am very nervous about this. A lot of things
> aren’t very well thought out and at the same time, I care very
> deeply about this project and it’s community and their future, so
> there is a little anxiety doing this little emotional striptease
> in front of all of you.
>
> What we will end up with, is not what I dream up and that’s that,
> but I hope I can inform and set the direction of where we are going,
> and then we can all together figure out the hard parts, and question
> my assumptions and change little thing or lots.
>
> I don’t want to make this mine, but ours. To keep and to be proud of.
>
> The last thing I want is to stifle diversity, in thought and code,
> and I am very sure that some of you will find a lot to disagree with
> what I am saying, and that’s great, because this should, again, be
> ours, not mine.
>
> But the one thing I am convinced of is the little pivot that this
> project hinges on* between relative obscurity and blasting success
> is that we need to find our version of a simplified, streamlined
> and aligned way of defining, building and communicating what Apache
> CouchDB is.
>
> (* I suck at metaphors)
>
> And yes that means that some thing that *YOU* think are important
> are getting a second row seat instead of the front row. Heck even
> some of my pet features get a second row seat, but that is fine
> because they aren’t gone, there is still room for all the crazy
> and not-so-crazy-but-not-essential stuff that people love in the
> plugin system, one click away. All this so we can benefit from
> being able to focus on building a modern, compelling, fun, humble
> and clever database that we can build the future, our future, on.
>
>
> * * *
>
> I want to live in a world where people are empowered to understand
> and are capable to decide where their data lives.
>
>
> I want to live in a world where technology solves more problems than
> it creates.
>
>
> My primary motivation for working on Apache CouchDB is to help build
> the world I want to live in.
>
>
> The ONE feature that makes CouchDB relevant is multi-master replication.
>
>
> I want to learn from understanding what the PRIMARY and SECONDARY
> features for CouchDB are.
>
>
> Apache CouchDB is the focal point for The Replicating Society.
>
>
> I don’t want to make this mine, but ours. To keep and to be proud of.
>
>
> * * *
>
>
> CouchDB is a database that replicates.
>
> I’m excited about your feedback! <3
>
> Sincerely,
> Jan
> --
>
>
>
>
>
>
> Thanks to Noah for kicking off this way overdue discussion.
>
>
> On Jul 24, 2013, at 15:28 , Noah Slater <ns...@apache.org> wrote:
>
> > Okay, here are some rough thoughts.
> >
> > Why?
> >
> > - We believe that distributed data should be easy
> >
> > How?
> >
> > - Painless multi-master replication
> > - Effortless clustering and sharding
> > - Co-location of data, queries, and views
> > - Deep browser and platform integration
> > - Built of the Web
> >
> > What?
> >
> > - Erlang
> > - HTTP
> > - JSON
> > - JavaScript
> > - MapReduce
> >
> > (That last list could go on, and on, and on...)
> >
> > Anyway. This is just a rough sketch of the sort of hierarchy I am
> thinking
> > about.
> >
> > Whatever this ends up looking like, I think this is how we should talk
> > about CouchDB. This structure could be a template for anything. A talk, a
> > sales pitch, the homepage itself. The important thing is that we start
> from
> > "why?" and we build up from foundations.
> >
> >
> > On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
> >
> >> I'm trying to imagine what our "I have a dream" speech would be like for
> >> CouchDB. If we were the Wright brothers, we might stand up and say "I
> have
> >> a dream that one day man will fly." We might say, "I have a dream that
> >> distributed data will be easy." (I mean, that about covers it, right?
> >> Doesn't have to be complex. The hard part is making sure we actually
> focus
> >> in on the root dream we all have.)
> >>
> >> Jan mentioned a few months ago that CouchDB almost wants to be the Git,
> >> for databases. What is Git? What would Git's "dream" be? I can imagine
> >> Linus saying "I have a dream that distributed version control will be
> >> easy." Same sorta thing, right?
> >>
> >>
> >> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
> >>
> >>> Benoit,
> >>>
> >>> You should defo watch that video and see what you think. Note that it
> >>> does not matter if we are a company. This insight applies to companies,
> >>> products, loose groups of people working towards one thing (like the
> Wright
> >>> brothers) and even individuals. (i.e. What is your personal "why" and
> how
> >>> are the things you are doing working towards that.)
> >>>
> >>> I also want to put you at ease by saying that having a single shared
> >>> "why" doesn't mean that anybody's vision, or personal goals have to be
> left
> >>> by the wayside. People can still come to the project with their own
> goals,
> >>> and their own perspective. But the project itself should have a clear
> sense
> >>> of what we are trying to accomplish.
> >>>
> >>> I think the "why" we come up with can easily be something that inspires
> >>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp
> peeps,
> >>> the "big data" peeps, the mobile platform peeps. Think about a why that
> >>> might evolve out of "your data, everywhere". Who (in our existing
> >>> communities) wouldn't love that and want to rally behind that? (But
> this is
> >>> just one idea.)
> >>>
> >>> Asking "what are the core features" misses the point. Why are these
> core
> >>> features? Why did we add them in the first place? What are we working
> >>> towards? See, you hit on it in your final sentence: "relax we take care
> >>> about your data and the way you exchange and render them wherever they
> >>> are". This! This is the kind of thing that I think we should hone, and
> >>> figure out, and document.
> >>>
> >>> Once we have that, it can inform our "how". When we're talking about
> >>> features, about product direction (i.e. what we add, what we subtract)
> we
> >>> can say "well, how is this related to what we're trying to do here?"
> Do you
> >>> see what I mean? :)
> >>>
> >>> "Painless distributed systems" is also a step in the right direction
> for
> >>> answering the question "why?"
> >>>
> >>> So far we have:
> >>>
> >>> * Relax
> >>> * Decentralised web
> >>> * Peer-to-peer replication of apps and datasets
> >>> * Your data, everywhere
> >>> * Put the data where you need it
> >>> * We handle your data / you handle display
> >>> * Painless distributed systems
> >>>
> >>> Somewhere in here ^ (and perhaps in a follow up reply) is a single
> shared
> >>> value system. Something we all hold dear.
> >>>
> >>>
> >>>
> >>>
> >>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
> >>>
> >>>> Anyway, CouchDB is not like apple or dell. This isn't a company. And
> we
> >>>> don't have to share all the same vision, but only common values, a
> core.
> >>>> I'm not sure it enter in the what you describe. What kind of vision
> are
> >>>> you
> >>>> speaking about?
> >>>>
> >>>> Also I would remove any pro-tip from your mail if we want to start
> from a
> >>>> neutral base.
> >>>>
> >>>> Couchdb is known for the replication but not only. Couchapps and the
> way
> >>>> people hack around is another (hoodie, kanso, erica/ couchapp all
> >>>> differents visions of what is a couchapp but all are using couchdb the
> >>>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb
> as a
> >>>> message hub somehow, not only but a lot of their arch is based on
> >>>> changes).
> >>>> And now we we can add some kind of big data handling. Not forgetting
> >>>> people
> >>>> that are using apache couchdb on their mobile, they exists and the
> >>>> patches
> >>>> will be release.
> >>>>
> >>>> All have different visions. But they share some common features. I
> don't
> >>>> want to forget someone because of a vision of some. I only know that
> >>>> couchdb has some strong features that could be improved.
> >>>>
> >>>> All that to say that rather than thinking to a vision, maybe we could
> >>>> collect all the usages around and see what emerges from it. What are
> the
> >>>> core features, What couchdb should focus on and itterrate depending on
> >>>> the
> >>>> new usage. I guess it's some kind of philosophy: "relax we take care
> >>>> about
> >>>> your data and the way you exchange and render them wherever they are".
> >>>>
> >>>> - benoit
> >>>>
> >>>>
> >>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org>
> wrote:
> >>>>
> >>>>> Hi devs,
> >>>>>
> >>>>> I came across this video recently:
> >>>>>
> >>>>> Simon Sinek: How great leaders inspire action
> >>>>>
> >>>>
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
> >>>>>
> >>>>> In it he sets out what he calls the Golden Circle:
> >>>>>
> >>>>> Why
> >>>>>
> >>>>> - What's your purpose?
> >>>>> - What's your cause?
> >>>>> - What's your belief?
> >>>>>
> >>>>> How
> >>>>>
> >>>>> - How do we do it?
> >>>>> - How does our product differentiate?
> >>>>> - How are we different?
> >>>>> - How are we better?
> >>>>>
> >>>>> What
> >>>>>
> >>>>> - What do we do?
> >>>>> - What do we make?
> >>>>>
> >>>>> He points out that the difference between companies like Apple and
> >>>>> companies like Dell.
> >>>>>
> >>>>> Dell tells you what they do, and how. "We make great computers.
> They're
> >>>>> well designed and work well. Wanna buy a computer?" Most companies do
> >>>> it
> >>>>> like this. But they often miss out the "why".
> >>>>>
> >>>>> But then you look at Apple, and they do it the other way around.
> Apple
> >>>> tell
> >>>>> you what their purpose is. The rest is almost an afterthought. "We
> >>>> believe
> >>>>> in challenging the status quo. We believe in thinking different. We
> do
> >>>> that
> >>>>> with great design and a focus on the user experience. We just happen
> to
> >>>>> make computers." He then joking quips: "Ready to buy one yet?"
> >>>>>
> >>>>> (His talk gives several other examples, with his thesis being that
> >>>> telling
> >>>>> your story from the outside in is what separates all the great
> >>>> companies
> >>>>> and leaders. One of his main examples is the Wright brothers.)
> >>>>>
> >>>>> He comments that if you talk about what you believe, you will attract
> >>>> those
> >>>>> that believe what you believe. That when you talk about what you
> >>>> believe,
> >>>>> people will join you for their own reasons, for their own purpose.
> And
> >>>> that
> >>>>> what you do simply serves as proof of what you believe. Or as he
> quips:
> >>>>> "Martin Luther King gave his 'I have a dream' speech, not his 'i
> have a
> >>>>> plan' speech."
> >>>>>
> >>>>> Why am I bringing this to the dev list?
> >>>>>
> >>>>> Because our message stinks. "Apache CouchDB™ is a database that uses
> >>>> JSON
> >>>>> for documents, JavaScript for MapReduce queries, and regular HTTP for
> >>>> an
> >>>>> API" is a terrible way to introduce who we are, what we stand for,
> and
> >>>> why
> >>>>> we build this thing. (And I'm allowed to say all that, because I'm
> the
> >>>> one
> >>>>> who wrote it, with lots of help from Jan.)
> >>>>>
> >>>>> So what am I proposing? I'm proposing that we figure out our why.
> That
> >>>> we
> >>>>> figure out what we stand for, what we believe in. And then we figure
> >>>> out
> >>>>> how we're gonna do that (pro tip: replication is more important than
> >>>> the
> >>>>> data format we use). Not only will this define a consistent internal
> >>>> vision
> >>>>> for the project (what *are* we working towards anyway?) but it will
> >>>> help us
> >>>>> to attract people who believe in what we believe.
> >>>>>
> >>>>> So, if you have any thoughts about this, speak up!
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> --
> >>>>> NS
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> NS
> >>>
> >>
> >>
> >>
> >> --
> >> NS
> >>
> >
> >
> >
> > --
> > NS
>
>
Re: What's our Why?
Posted by Jan Lehnardt <ja...@apache.org>.
This is very powerful, thanks Benoit!
I think both our views are very much compatible with a single vision
that I think is so important we find to all stand behind. I am so
very glad to have you on board with this :)
Best
Jan
--
On Jul 25, 2013, at 10:52 , Benoit Chesneau <bc...@gmail.com> wrote:
> So even if Noah didn't noticed I finished my previous mail with this
> kind of philosophy "relax we take care about your data and the way you
> exchange and render them wherever they are". Of course it was without
> the lyricism but it is defining the vision I have since the beginning
> with couchdb modulo the fact that the replication wasn't existing at the
> beginning. I join Jan for some parts. One sure thing is that you can't
> separate the why from the how. Anyway let me share my own experience of
> CouchDB, it will help somehow to explain why I am *using* Couchdb, and
> *how* I envision it.
>
> The first thing that interested me in couchdb was its simplicity of
> usage and customization. An HTTP API, a small code base. The HTTP API is
> more important than some are saying today. Of course we could use a
> binary protocol it would be faster. But it is just a matter of time.
> With HTTP 2.0 coming at the end of the year, the already working
> implementations using SPDY, the HTTP couchdb api will be exchanged in
> binary stream. Using couchdb over and on the web is really one of its
> key features.
>
> Anyway, when I started to use couchdb (long time ago) I created some
> applications. One of the first was Friendpaste. The replication was
> just starting to exist (or on the point to, I can't remember) and the
> first reason I used CouchDB for Friendpaste was because it allowed me
> to view/maps the documents to my application quite in an intuitive and
> natural way. I didn't have to query them across multiple tables, simply
> map them then query them to match some pattern. I didn't have to
> organize them at first in tables or columns. I just had to store my
> document and create views (index) on them. The views can be later edited
> or edited, but the documents, the way I store the data don't change.
> Which was perfectly fit the way I code, iterating over features ans
> sometimes completely change the way I'm using/view the data in the code.
> CouchDB was giving me way to manipulate data I didn't have since a
> while, since I played with hypercard or lotus notes. A documented
> oriented database by itself is a concept, a way to handler your data.
> And couchdb has its own particular way to do it. Even copied like it
> some databases I won't name it it is different. Incremented views and
> the way couchdb is storing the data are designed for the new storages we
> have today (ssds and others). All new databases that are designed today
> are using such system. Of course it should be improved.
>
> When the changes feeds were introduced in couchdb it was
> revolutionnizing the way couchdb can be used and improved a lot the
> replication. CouchDB was one of the first modern database to allow
> anyone to listen on document changes and replicate them in a continuous
> manner. At that time synchronization was not so trendy and there wasn't
> many solutions allowing master-master replication. I created many
> applications based on it since. One of them was the afgwardiary an
> application to view the data leaked by wikileaks about the afghanistan
> war [1], a couchapp entirely hosted in couchdb using geocouch to
> manipulate the in formations This experimentation was really
> interesting in the sense that it allowed people to exchange the leaked
> data in a P2P fashion using the replication but also to render them.
> That without installing anything but a patched couchdb with geocouch
> (later becoming rcouch). I continued my experimentation with the
> diplomatic cables.
>
> Eventually, frustrated by the time it took to put the code in couchdb,
> and the lack of real review (lot of devs were busy to do other things)
> and also the need to have a database that I can easily deploy and
> customize I forked couchdb to create rcouch [3]. Rcouch is part of a
> more global project refuge [4].
>
> In a sense, rcouch share the vision of Jan. To do rcouch I created a
> couch core that can be extended by adding new erlang application and in
> the new revision coming next week load/unload dynamically some plugins.
> The rcouch core is articulated today in different apps: couch,
> couch_changes, couch_stats, couch_replicator, couch_httpd, couch_index
> and couch_mrview (which is based on couch_index). More details on the
> wiki [5]. With rcouch are coming different extensions: refuge_spatial
> (forked geocouch to work with latest couch core), random docs, db
> updates... This core still has the shows and lists included. Not because
> they are efficient, they aren't but because they are a pretty cool way
> to manipulate/transform the data coming from the view index or the
> database before sending them to your application or the user. Back in
> the past, shows and lists was called forms and were created as way to
> transform the data. For me the couchapps are not the shows and list, not
> even these HTML5 apps that are a very limited view of what is possible.
> Couchapps are mostly script to render the data over an index. In my
> view we should ditch shows and lists to a concept of apps getting a
> request object when they are exposed to the web or just an environ when
> they are used as a script to extend the internal API (like redis
> scripts).
>
> In the mean time I continued to maintain and improve the versions of
> couchdb for ios and android, ported rcouch to different arm platforms
> (minicomputer, raspberry, ....) and helped to design some interresting
> systems using Couchdb to replicate a lot of data between mobiles and
> servers on different locations but also using couchdb as a message hub.
>
> If I would like today define couchdb based on my rcouch experience and
> the ports I did, I would say: "Apache Couchdb allows you to handle and
> synchronize your data between different locations and devices in quasi
> realtime over and on the web in a P2P manner without SPOF".
>
> So for me couchdb isn't only a database that replicate, it is also a way
> to ease the usage of your data, the way you can view them in your
> applications or directly on the web and over the web.
>
> - benoit
>
> [1] https://github.com/benoitc/afgwardiary
> [2] https://github.com/benoitc/nymphormation
> [3] https://github.com/refuge/rcouch/wiki
> [4] http://refuge.io
> [5] https://github.com/refuge/rcouch/wiki/refactoring
>
>
> On Wed, Jul 24, 2013 at 11:36 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> I have a dream…
>>
>> (pardon the plagiarism)
>>
>> I want to live in a world where people are empowered to understand
>> and are capable to decide where their data lives. I want to live in
>> a world where developers build apps that support that, not because
>> they went out of their way to implement it, but because it is a
>> feature of the software platform they are using.
>>
>> I want to be able to help people improve their lives in regions of
>> the world where ubiquitous network access isn’t — and sometimes that
>> is just a major western capital’s subway — but more likely is it a
>> lesser developed location, or a rural area that will never see mobile
>> broadband, let alone wired broadband because there is no financial
>> incentive.
>>
>> I want to live in a world where technology solves more problems than
>> it creates. One of those ways is allow people to use software wherever
>> they are in whatever context they need it in. More often than not,
>> that means far away from fast network access (Despite what @dhh is
>> trying to tell you).
>>
>> My primary motivation for working on Apache CouchDB is to help build
>> the world I want to live in. The same motivation drives my motivation
>> behind Hoodie (http://hood.ie), which builds on top of CouchDB and
>> wouldn’t be possible without it.
>>
>>
>> * * *
>>
>> In the past year I have interviewed a fair number of people, let’s
>> say 50, from those who have heard about CouchDB to users to core devs.
>>
>> The ONE feature that makes CouchDB relevant is multi-master replication.
>> There is no exception, this is the ONE thing that makes CouchDB
>> exceptional. NOBODY else has that, and even the decent proprietary
>> solutions that are just coming to market suck where we KICK ASS.
>>
>> There are many other things that people like about CouchDB: reliability,
>> no schema, HTTP interface, the view system, etc. But NONE of these people
>> would care if CouchDB didn’t have multi-master replication.
>>
>>
>> * * *
>>
>> The number one thing that people did NOT like about CouchDB is that it
>> is confused. CouchDB has a torn identity, half database, half
>> application server. It wasn’t clear (and I am part responsible for this)
>> what CouchDB is and wants to be. In everybody’s defence, I think, it
>> just took a while to figure it out. Now is a good time to put our
>> findings in writing and fix this.
>>
>> The number one request from people was to clear up CouchDB’s story,
>> to have a clear, bold vision that captures people and that they can
>> easily understand and share and support and move forward.
>>
>>
>> * * *
>>
>> Here is a narrative about what CouchDB has, that has formed in my head
>> in the past year. I have shared this with some people privately for some
>> feedback and they all liked it, so it has that going for it. I also tried
>> out bringing some of these issues up in presentations I have given, to
>> again great feedback.
>>
>> E.g.:
>>
>> http://www.youtube.com/watch?v=7mdG-iAizVc or
>> http://www.youtube.com/watch?v=edbi9jJZkpg
>>
>> Before I lay it out, I understand that I will be ruffling some feathers.
>> I think that is both necessary and healthy. I think the picture I am
>> going to paint will make a lot of people in the CouchDB community happy,
>> some with concessions, but I utterly and strongly believe that this
>> vision of what CouchDB is has the power to set the course for the next
>> five years of the project and attract a whole lot of new people both
>> as users and contributors.
>>
>>
>>
>> * * *
>>
>> CouchDB is a database that replicates.
>>
>> Think of it as git for your data-layer. Not in a sense where you manage
>> text files and diff and merge, but in the sense that you have a local
>> version of your data and one or multiple remote ones and you can
>> seamlessly move your data between them, back and forth and crossover.
>>
>> Imagine a local checkout of your data that you can work on, and then
>> share it with Lucie across the table, she finds some issues and fixes
>> up the data, and shares it with Tim across the room. Tim fixes two
>> more issues and you pull both their changes into your copy. We conclude
>> the whole thing is golden and we push it to staging, where our continuous
>> integration runs and decides that the data is good to go into production,
>> so it pushes it to production. There the data is picked up from various
>> clients, some mobile over there, some web over here, a backup system
>> in the Tokyo office…
>>
>> Or you have hospitals in remote regions in Africa that collect local
>> health data, like how many malaria infections a region has and they all
>> share their results over unreliable mobile connections and the data
>> still makes it eventually maybe with a few hours delay and the malaria
>> expert in the capital city sees an increased outbreak of some illness
>> and is able to send out medicine in time to arrive for the patients
>> to help. Where today the expert takes months to travel between the
>> hospitals to collect that data manually and find out that there was
>> a lethal outbreak two months ago and everybody died.
>>
>> (Somebody built this, CouchDB does save lives, I get teary every time
>> I tell this story (like now). Our work doesn’t get more noble than
>> this.)
>>
>> Or imagine millions of mobile users with access to terabytes of
>> data in the cloud, replicating the bits they need to their phones
>> and tablets, allowing super-fast low-latency access for a stellar
>> user experience, while giving access to sheer amounts of data and
>> allowing full write access on the mobile device to be replicated
>> back to the cloud when connections exist.
>>
>> (Our friends at Cloudant have a couple of those customers.)
>>
>>
>> That is the power of CouchDB.
>>
>>
>> * * *
>>
>> Replication is the PRIMARY feature of CouchDB. “is a database” means
>> “stores your data, safely and securely”, “that replicates” highlights
>> the primary feature.
>>
>> There are many more very cool features of CouchDB, even the details
>> on how we achieve reliability and data safety or how replication
>> works are mindblowingly cool. The simple HTTP interface, the JSON
>> store, the app-server features, map reduce views, all very excellent
>> things that make CouchDB unique, but it is very important to understand
>> that they are SECONDARY features.
>>
>>
>> * * *
>>
>> I want to learn from understanding what the PRIMARY and SECONDARY
>> features for CouchDB are. I already feel a bit bad about that the
>> PRIMARY ones are two (“a database” *and* “that replicates”), but I
>> think that is as little as it gets.
>>
>> I want CouchDB’s new identity to be a database that replicates. I want
>> to provide a slide deck for a “CouchDB in 25 minutes” presentation* that
>> everybody can take and give and customise, but I want that one of the
>> first things you say “CouchDB is a database that replicates”. I want
>> that if you ask anyone inside the CouchDB developer community (you!)
>> about what CouchDB is to answer “CouchDB is a database that replicates”
>> and then follow up explaining what we mean, and *then* add a few more
>> of the SECONDARY features that you particularly like.
>>
>> * https://dl.dropboxusercontent.com/u/82149/CouchDB-in-25-Minutes.pdf
>> Full talk at: http://vimeo.com/62599420 (sorry this one is German,
>> still trying to find an English version of this)
>>
>> I want that people who barely look at CouchDB comment on an unrelated
>> Hacker News thread write “…CouchDB is a database that replicates, maybe
>> that is a better fit for your problem”.
>>
>> I want that the CTO of the newly funded startup thinks “I seem to have
>> a replication problem to solve, maybe CouchDB can help.”
>>
>> I want to move CouchDB’s development forward, and when we ask ourselves
>> whether to add a feature, we run it by our PRIMARY feature set and ask
>> “does it support ‘CouchDB is a database that replicates’” and if it does
>> we go ahead and build it, and if it doesn’t we may consider it as a
>> SECONDARY feature, or we discard it altogether.
>>
>> (I don’t actually care what the final slogan will be, and please bike-shed
>> this to no avail, but it should capture what I mean with “CouchDB is a
>> database that replicates”, a phrase that we can burn into everybody’s
>> head that captures CouchDB’s PRIMARY feature, its PRIMARY value
>> proposition, the ONE thing that explains WHY we are excited about
>> CouchDB.)
>>
>>
>> * * *
>>
>> Now, you might be miffed that your pet feature didn’t make the PRIMARY
>> list.
>> Do not worry, I believe I have a solution for that.
>>
>> I have brought this up before, but I really do think the holy grail to all
>> this is a very well done plugin system that allows us to follow the “small
>> core, massive plugin repository” paradigm that other’s ever so successfully
>> pioneered.
>>
>> This allows us to focus on what CouchDB is for internal and external
>> communication, for roadmap discussions and attraction of developer talent.
>>
>> More importantly, it allows us to keep all the fringe things that makes
>> CouchDB so very appealing to a lot of different people. It also allows us
>> to open up development to people who feel intimidated working on core
>> CouchDB, but can easily write a little plugin or three (this is basically
>> me, I have like 20 branches on GitHub that are useful to maybe 5% of our
>> users and they don’t get used any).
>>
>> A wise person once said “Core is where features go to rot.”, and if you
>> look at a number of CouchDB features, you can see that we suffer from that.
>>
>> We need a kick-ass plugin system that allows us to easily create, publish,
>> maintain and update little pieces of code that allow our users to make
>> their CouchDB their own. (I am signing up to build that, but I will need
>> your help, there is a shit ton of work to do :)
>>
>>
>> * * *
>>
>> ALERT: OPINION (your opinion may differ and we need to hear it)
>>
>> There is a discussion we need to have what the “small core” means for
>> CouchDB. There is a discrepancy between the absolute minimum to fulfil
>> the “CouchDB is a database that replicates“ mantra and what would be
>> a useful-out-of-the-box product that our users could set up and be
>> productive with.
>>
>> My minimum set looks roughly like this:
>>
>> - core database management (crud dbs & json/mime-docs, clustering)
>> - remote & local replication
>> - MR-views & GeoCouch enabled by default (ideally abstracted
>> away with nice “query dsl”)
>> - HTTP interface
>> - Fu/Fauxton
>> - configuration
>> - stats
>> - docs
>> - plugin system with Erlang (and in the future JavaScript support
>> via Node.js)
>>
>> This makes for a useful CouchDB default setup.
>>
>> Everything else should be a plugin. A piece of code that can be installed
>> with a quick search and a click of a button in Futon (or a `curl`-call on
>> the HTTP interface). Not far away, definitely not “siberia” (if you get
>> the PHP reference), but close to the core and encouraged to be used.
>>
>> And yes, this explicitly includes things like shows and lists and update
>> functions and rewrites and vhosts. We should make it super simple to add
>> these, but for a default experience, they are very, very confusing. We
>> should have a single plugin “CouchApp Engine” which includes Benoit’s
>> vision of CouchApps done right that is just a click away to install.
>>
>> In terms of highlighting the strengths of the core CouchDB “product”, this
>> is what I’d put on the website:
>>
>> - Apache CouchDB implements the CouchDB vision:
>> It is a database that replicates.
>>
>> - Document Database:
>> - Data records are standard JSON.
>> - Unlimited Binary data storage with attachments.
>> - (alternatively arbitrary mime docs with special rules for JSON docs)
>>
>> - Fault-tolerant:
>> - Data is always safe. Tail-append storage ensures no messing with
>> already committed data.
>> - Errors are isolated, recovery is local and doesn’t affect other
>> parallel requests.
>> - Recovery of fatal errors is immediate. There is no “fixup phase”
>> after a restart.
>> - Software updates and bugfix deployment without downtime.
>>
>> - Highly Concurrent:
>> - Erlang makes good use of massively parallel network server
>> installations.
>> - Garbage collection happens roughly on a per-request basis.
>> GC in one request doesn’t affect other requests.
>>
>> - Cluster / BigCouch / Big Data:
>> - Includes a Dynamo-style clustering and cluster-management
>> feature that allows to spread data and load over multiple
>> physical machines.
>> - Scales up to Petabytes of data.
>>
>> - Secondary 2D and 3D indexing
>> - Using incremental and asynchronous index updates for
>> high-performance queries.
>>
>> - Makes good use of hardware:
>> - Tail-append storage allows for serial write access to
>> storage media, which is a best-case-scenario for spinning
>> disks and SSDs.
>>
>> - Small Core & Flexible Plugin System:
>> - Some features are only useful for a small group of people, these
>> can be installed with a super simple plugin management system that
>> is built into the admin interface.
>> - Get new features with a click or tap.
>> - Plugins can be written in Erlang (and in JavaScript in the future).
>>
>> - Cross Platform Support
>> - Runs on any POSIX UNIX as well as Windows.
>> - Support for some embedded devices like Android and RaspberryPi.
>>
>>
>> I think this would make for a compelling list of technical features.
>>
>> (I’d probably also add a blip about the ASF and the Apache 2.0 License
>> for good measure)
>>
>> ALERT END
>>
>>
>> * * *
>>
>> And then, CouchDB is one more thing. CouchDB isn’t just the Erlang
>> implementation of this whole replicating database idea. CouchDB is also
>> the wire protocol, the specification that makes all the magic work.
>> Apache CouchDB is the focal point for The Replicating Society*.
>>
>> (* cue your Blade Runner jokes)
>>
>> Apache CouchDB is THE standard for data freedom and exchange and is
>> the clearing house, the centre for an ecosystem that includes fantastic
>> projects like PouchDB and the TouchDBs, MAx Ogden’s `dat` and whichever
>> else follow these. Not saying we merge those projects in, they can stand
>> on their own, but we should embrace everything that makes the
>> interoperable replication world a reality.
>>
>> http://couchdb.apache.org is going to be the centre of the data
>> replication universe.
>>
>>
>> * * *
>>
>> Now all of this is my vision and I bringing it to this table now.
>> I have to admit that I am very nervous about this. A lot of things
>> aren’t very well thought out and at the same time, I care very
>> deeply about this project and it’s community and their future, so
>> there is a little anxiety doing this little emotional striptease
>> in front of all of you.
>>
>> What we will end up with, is not what I dream up and that’s that,
>> but I hope I can inform and set the direction of where we are going,
>> and then we can all together figure out the hard parts, and question
>> my assumptions and change little thing or lots.
>>
>> I don’t want to make this mine, but ours. To keep and to be proud of.
>>
>> The last thing I want is to stifle diversity, in thought and code,
>> and I am very sure that some of you will find a lot to disagree with
>> what I am saying, and that’s great, because this should, again, be
>> ours, not mine.
>>
>> But the one thing I am convinced of is the little pivot that this
>> project hinges on* between relative obscurity and blasting success
>> is that we need to find our version of a simplified, streamlined
>> and aligned way of defining, building and communicating what Apache
>> CouchDB is.
>>
>> (* I suck at metaphors)
>>
>> And yes that means that some thing that *YOU* think are important
>> are getting a second row seat instead of the front row. Heck even
>> some of my pet features get a second row seat, but that is fine
>> because they aren’t gone, there is still room for all the crazy
>> and not-so-crazy-but-not-essential stuff that people love in the
>> plugin system, one click away. All this so we can benefit from
>> being able to focus on building a modern, compelling, fun, humble
>> and clever database that we can build the future, our future, on.
>>
>>
>> * * *
>>
>> I want to live in a world where people are empowered to understand
>> and are capable to decide where their data lives.
>>
>>
>> I want to live in a world where technology solves more problems than
>> it creates.
>>
>>
>> My primary motivation for working on Apache CouchDB is to help build
>> the world I want to live in.
>>
>>
>> The ONE feature that makes CouchDB relevant is multi-master replication.
>>
>>
>> I want to learn from understanding what the PRIMARY and SECONDARY
>> features for CouchDB are.
>>
>>
>> Apache CouchDB is the focal point for The Replicating Society.
>>
>>
>> I don’t want to make this mine, but ours. To keep and to be proud of.
>>
>>
>> * * *
>>
>>
>> CouchDB is a database that replicates.
>>
>> I’m excited about your feedback! <3
>>
>> Sincerely,
>> Jan
>> --
>>
>>
>>
>>
>>
>>
>> Thanks to Noah for kicking off this way overdue discussion.
>>
>>
>> On Jul 24, 2013, at 15:28 , Noah Slater <ns...@apache.org> wrote:
>>
>>> Okay, here are some rough thoughts.
>>>
>>> Why?
>>>
>>> - We believe that distributed data should be easy
>>>
>>> How?
>>>
>>> - Painless multi-master replication
>>> - Effortless clustering and sharding
>>> - Co-location of data, queries, and views
>>> - Deep browser and platform integration
>>> - Built of the Web
>>>
>>> What?
>>>
>>> - Erlang
>>> - HTTP
>>> - JSON
>>> - JavaScript
>>> - MapReduce
>>>
>>> (That last list could go on, and on, and on...)
>>>
>>> Anyway. This is just a rough sketch of the sort of hierarchy I am
>> thinking
>>> about.
>>>
>>> Whatever this ends up looking like, I think this is how we should talk
>>> about CouchDB. This structure could be a template for anything. A talk, a
>>> sales pitch, the homepage itself. The important thing is that we start
>> from
>>> "why?" and we build up from foundations.
>>>
>>>
>>> On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
>>>
>>>> I'm trying to imagine what our "I have a dream" speech would be like for
>>>> CouchDB. If we were the Wright brothers, we might stand up and say "I
>> have
>>>> a dream that one day man will fly." We might say, "I have a dream that
>>>> distributed data will be easy." (I mean, that about covers it, right?
>>>> Doesn't have to be complex. The hard part is making sure we actually
>> focus
>>>> in on the root dream we all have.)
>>>>
>>>> Jan mentioned a few months ago that CouchDB almost wants to be the Git,
>>>> for databases. What is Git? What would Git's "dream" be? I can imagine
>>>> Linus saying "I have a dream that distributed version control will be
>>>> easy." Same sorta thing, right?
>>>>
>>>>
>>>> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
>>>>
>>>>> Benoit,
>>>>>
>>>>> You should defo watch that video and see what you think. Note that it
>>>>> does not matter if we are a company. This insight applies to companies,
>>>>> products, loose groups of people working towards one thing (like the
>> Wright
>>>>> brothers) and even individuals. (i.e. What is your personal "why" and
>> how
>>>>> are the things you are doing working towards that.)
>>>>>
>>>>> I also want to put you at ease by saying that having a single shared
>>>>> "why" doesn't mean that anybody's vision, or personal goals have to be
>> left
>>>>> by the wayside. People can still come to the project with their own
>> goals,
>>>>> and their own perspective. But the project itself should have a clear
>> sense
>>>>> of what we are trying to accomplish.
>>>>>
>>>>> I think the "why" we come up with can easily be something that inspires
>>>>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp
>> peeps,
>>>>> the "big data" peeps, the mobile platform peeps. Think about a why that
>>>>> might evolve out of "your data, everywhere". Who (in our existing
>>>>> communities) wouldn't love that and want to rally behind that? (But
>> this is
>>>>> just one idea.)
>>>>>
>>>>> Asking "what are the core features" misses the point. Why are these
>> core
>>>>> features? Why did we add them in the first place? What are we working
>>>>> towards? See, you hit on it in your final sentence: "relax we take care
>>>>> about your data and the way you exchange and render them wherever they
>>>>> are". This! This is the kind of thing that I think we should hone, and
>>>>> figure out, and document.
>>>>>
>>>>> Once we have that, it can inform our "how". When we're talking about
>>>>> features, about product direction (i.e. what we add, what we subtract)
>> we
>>>>> can say "well, how is this related to what we're trying to do here?"
>> Do you
>>>>> see what I mean? :)
>>>>>
>>>>> "Painless distributed systems" is also a step in the right direction
>> for
>>>>> answering the question "why?"
>>>>>
>>>>> So far we have:
>>>>>
>>>>> * Relax
>>>>> * Decentralised web
>>>>> * Peer-to-peer replication of apps and datasets
>>>>> * Your data, everywhere
>>>>> * Put the data where you need it
>>>>> * We handle your data / you handle display
>>>>> * Painless distributed systems
>>>>>
>>>>> Somewhere in here ^ (and perhaps in a follow up reply) is a single
>> shared
>>>>> value system. Something we all hold dear.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>
>>>>>> Anyway, CouchDB is not like apple or dell. This isn't a company. And
>> we
>>>>>> don't have to share all the same vision, but only common values, a
>> core.
>>>>>> I'm not sure it enter in the what you describe. What kind of vision
>> are
>>>>>> you
>>>>>> speaking about?
>>>>>>
>>>>>> Also I would remove any pro-tip from your mail if we want to start
>> from a
>>>>>> neutral base.
>>>>>>
>>>>>> Couchdb is known for the replication but not only. Couchapps and the
>> way
>>>>>> people hack around is another (hoodie, kanso, erica/ couchapp all
>>>>>> differents visions of what is a couchapp but all are using couchdb the
>>>>>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb
>> as a
>>>>>> message hub somehow, not only but a lot of their arch is based on
>>>>>> changes).
>>>>>> And now we we can add some kind of big data handling. Not forgetting
>>>>>> people
>>>>>> that are using apache couchdb on their mobile, they exists and the
>>>>>> patches
>>>>>> will be release.
>>>>>>
>>>>>> All have different visions. But they share some common features. I
>> don't
>>>>>> want to forget someone because of a vision of some. I only know that
>>>>>> couchdb has some strong features that could be improved.
>>>>>>
>>>>>> All that to say that rather than thinking to a vision, maybe we could
>>>>>> collect all the usages around and see what emerges from it. What are
>> the
>>>>>> core features, What couchdb should focus on and itterrate depending on
>>>>>> the
>>>>>> new usage. I guess it's some kind of philosophy: "relax we take care
>>>>>> about
>>>>>> your data and the way you exchange and render them wherever they are".
>>>>>>
>>>>>> - benoit
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org>
>> wrote:
>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> I came across this video recently:
>>>>>>>
>>>>>>> Simon Sinek: How great leaders inspire action
>>>>>>>
>>>>>>
>> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>>>>>>>
>>>>>>> In it he sets out what he calls the Golden Circle:
>>>>>>>
>>>>>>> Why
>>>>>>>
>>>>>>> - What's your purpose?
>>>>>>> - What's your cause?
>>>>>>> - What's your belief?
>>>>>>>
>>>>>>> How
>>>>>>>
>>>>>>> - How do we do it?
>>>>>>> - How does our product differentiate?
>>>>>>> - How are we different?
>>>>>>> - How are we better?
>>>>>>>
>>>>>>> What
>>>>>>>
>>>>>>> - What do we do?
>>>>>>> - What do we make?
>>>>>>>
>>>>>>> He points out that the difference between companies like Apple and
>>>>>>> companies like Dell.
>>>>>>>
>>>>>>> Dell tells you what they do, and how. "We make great computers.
>> They're
>>>>>>> well designed and work well. Wanna buy a computer?" Most companies do
>>>>>> it
>>>>>>> like this. But they often miss out the "why".
>>>>>>>
>>>>>>> But then you look at Apple, and they do it the other way around.
>> Apple
>>>>>> tell
>>>>>>> you what their purpose is. The rest is almost an afterthought. "We
>>>>>> believe
>>>>>>> in challenging the status quo. We believe in thinking different. We
>> do
>>>>>> that
>>>>>>> with great design and a focus on the user experience. We just happen
>> to
>>>>>>> make computers." He then joking quips: "Ready to buy one yet?"
>>>>>>>
>>>>>>> (His talk gives several other examples, with his thesis being that
>>>>>> telling
>>>>>>> your story from the outside in is what separates all the great
>>>>>> companies
>>>>>>> and leaders. One of his main examples is the Wright brothers.)
>>>>>>>
>>>>>>> He comments that if you talk about what you believe, you will attract
>>>>>> those
>>>>>>> that believe what you believe. That when you talk about what you
>>>>>> believe,
>>>>>>> people will join you for their own reasons, for their own purpose.
>> And
>>>>>> that
>>>>>>> what you do simply serves as proof of what you believe. Or as he
>> quips:
>>>>>>> "Martin Luther King gave his 'I have a dream' speech, not his 'i
>> have a
>>>>>>> plan' speech."
>>>>>>>
>>>>>>> Why am I bringing this to the dev list?
>>>>>>>
>>>>>>> Because our message stinks. "Apache CouchDB™ is a database that uses
>>>>>> JSON
>>>>>>> for documents, JavaScript for MapReduce queries, and regular HTTP for
>>>>>> an
>>>>>>> API" is a terrible way to introduce who we are, what we stand for,
>> and
>>>>>> why
>>>>>>> we build this thing. (And I'm allowed to say all that, because I'm
>> the
>>>>>> one
>>>>>>> who wrote it, with lots of help from Jan.)
>>>>>>>
>>>>>>> So what am I proposing? I'm proposing that we figure out our why.
>> That
>>>>>> we
>>>>>>> figure out what we stand for, what we believe in. And then we figure
>>>>>> out
>>>>>>> how we're gonna do that (pro tip: replication is more important than
>>>>>> the
>>>>>>> data format we use). Not only will this define a consistent internal
>>>>>> vision
>>>>>>> for the project (what *are* we working towards anyway?) but it will
>>>>>> help us
>>>>>>> to attract people who believe in what we believe.
>>>>>>>
>>>>>>> So, if you have any thoughts about this, speak up!
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --
>>>>>>> NS
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> NS
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> NS
>>>>
>>>
>>>
>>>
>>> --
>>> NS
>>
>>
Re: What's our Why?
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Aug 4, 2013 at 9:45 PM, Noah Slater <ns...@apache.org> wrote:
> Benoit,
>
> Been clicking around http://refuge.io/ — really like the "why" that you
> communicate here. ("Data should be yours!") Was wondering if you have any
> pointers to more on this. Like, do you have any other vision / why / long
> term goals? Any essays or emails you've written on it?
>
> I am currently synthesising a "CouchDB Vision" document. Moved it to Google
> Docs because it's easier to draft things. Once I've got something that
> isn't embarrassing to look at, I'll share with the list and solicit
> comments.
>
>
>
Hi Noah,
I've done some presentations that you can find on refuge-media, video of
some them exist on the wen:
http://github.com/refuge/refuge-media .
Last presentation given at the EUC 2013 presents the full vision though a
little too technical yet.
There are also some mails on the mailing list and G+ but nothing more
structured right now. This lack of structure is quite deliberate right now
since things were still in the flux. During the last 2 moths, Nicolas and
me have worked hard on the project and a prototype should be available next
week. At this point i will elaborate more. Note that the vision is proper
to Refuge and not really related to Apache Couchdb.
About the way we are working on the why, like I said I really wish we could
find the time to list the selling points raised here without lyricism and
start a QA over the community with these points. It can help to figure the
community vision and take it in consideration in the project vision. Just a
suggestion. I thought I had time to collect these points last week but it
will need require more time from myself.. I will try to do that before
Thursday. Maybe someone can be faster than me on that. Also it shouldn't
(and I didn't intent to) stop your own effort, the more materials we have,
the best it is.
- benoit
> On 25 July 2013 16:43, david martin <da...@lymegreen.co.uk> wrote:
>
> > On 25/07/13 09:52, Benoit Chesneau wrote:
> >
> >> So even if Noah didn't noticed I finished my previous mail with this
> >> kind of philosophy "relax we take care about your data and the way you
> >> exchange and render them wherever they are". Of course it was without
> >> the lyricism but it is defining the vision I have since the beginning
> >> with couchdb modulo the fact that the replication wasn't existing at the
> >> beginning. I join Jan for some parts. One sure thing is that you can't
> >> separate the why from the how. Anyway let me share my own experience of
> >> CouchDB, it will help somehow to explain why I am *using* Couchdb, and
> >> *how* I envision it.
> >>
> >> The first thing that interested me in couchdb was its simplicity of
> >> usage and customization. An HTTP API, a small code base. The HTTP API is
> >> more important than some are saying today. Of course we could use a
> >> binary protocol it would be faster. But it is just a matter of time.
> >> With HTTP 2.0 coming at the end of the year, the already working
> >> implementations using SPDY, the HTTP couchdb api will be exchanged in
> >> binary stream. Using couchdb over and on the web is really one of its
> >> key features.
> >>
> >> Anyway, when I started to use couchdb (long time ago) I created some
> >> applications. One of the first was Friendpaste. The replication was
> >> just starting to exist (or on the point to, I can't remember) and the
> >> first reason I used CouchDB for Friendpaste was because it allowed me
> >> to view/maps the documents to my application quite in an intuitive and
> >> natural way. I didn't have to query them across multiple tables, simply
> >> map them then query them to match some pattern. I didn't have to
> >> organize them at first in tables or columns. I just had to store my
> >> document and create views (index) on them. The views can be later edited
> >> or edited, but the documents, the way I store the data don't change.
> >> Which was perfectly fit the way I code, iterating over features ans
> >> sometimes completely change the way I'm using/view the data in the code.
> >> CouchDB was giving me way to manipulate data I didn't have since a
> >> while, since I played with hypercard or lotus notes. A documented
> >> oriented database by itself is a concept, a way to handler your data.
> >> And couchdb has its own particular way to do it. Even copied like it
> >> some databases I won't name it it is different. Incremented views and
> >> the way couchdb is storing the data are designed for the new storages we
> >> have today (ssds and others). All new databases that are designed today
> >> are using such system. Of course it should be improved.
> >>
> >> When the changes feeds were introduced in couchdb it was
> >> revolutionnizing the way couchdb can be used and improved a lot the
> >> replication. CouchDB was one of the first modern database to allow
> >> anyone to listen on document changes and replicate them in a continuous
> >> manner. At that time synchronization was not so trendy and there wasn't
> >> many solutions allowing master-master replication. I created many
> >> applications based on it since. One of them was the afgwardiary an
> >> application to view the data leaked by wikileaks about the afghanistan
> >> war [1], a couchapp entirely hosted in couchdb using geocouch to
> >> manipulate the in formations This experimentation was really
> >> interesting in the sense that it allowed people to exchange the leaked
> >> data in a P2P fashion using the replication but also to render them.
> >> That without installing anything but a patched couchdb with geocouch
> >> (later becoming rcouch). I continued my experimentation with the
> >> diplomatic cables.
> >>
> >> Eventually, frustrated by the time it took to put the code in couchdb,
> >> and the lack of real review (lot of devs were busy to do other things)
> >> and also the need to have a database that I can easily deploy and
> >> customize I forked couchdb to create rcouch [3]. Rcouch is part of a
> >> more global project refuge [4].
> >>
> >> In a sense, rcouch share the vision of Jan. To do rcouch I created a
> >> couch core that can be extended by adding new erlang application and in
> >> the new revision coming next week load/unload dynamically some plugins.
> >> The rcouch core is articulated today in different apps: couch,
> >> couch_changes, couch_stats, couch_replicator, couch_httpd, couch_index
> >> and couch_mrview (which is based on couch_index). More details on the
> >> wiki [5]. With rcouch are coming different extensions: refuge_spatial
> >> (forked geocouch to work with latest couch core), random docs, db
> >> updates... This core still has the shows and lists included. Not because
> >> they are efficient, they aren't but because they are a pretty cool way
> >> to manipulate/transform the data coming from the view index or the
> >> database before sending them to your application or the user. Back in
> >> the past, shows and lists was called forms and were created as way to
> >> transform the data. For me the couchapps are not the shows and list, not
> >> even these HTML5 apps that are a very limited view of what is possible.
> >> Couchapps are mostly script to render the data over an index. In my
> >> view we should ditch shows and lists to a concept of apps getting a
> >> request object when they are exposed to the web or just an environ when
> >> they are used as a script to extend the internal API (like redis
> >> scripts).
> >>
> >> In the mean time I continued to maintain and improve the versions of
> >> couchdb for ios and android, ported rcouch to different arm platforms
> >> (minicomputer, raspberry, ....) and helped to design some interresting
> >> systems using Couchdb to replicate a lot of data between mobiles and
> >> servers on different locations but also using couchdb as a message hub.
> >>
> >> If I would like today define couchdb based on my rcouch experience and
> >> the ports I did, I would say: "Apache Couchdb allows you to handle and
> >> synchronize your data between different locations and devices in quasi
> >> realtime over and on the web in a P2P manner without SPOF".
> >>
> >> So for me couchdb isn't only a database that replicate, it is also a way
> >> to ease the usage of your data, the way you can view them in your
> >> applications or directly on the web and over the web.
> >>
> >> - benoit
> >>
> >> [1] https://github.com/benoitc/**afgwardiary<
> https://github.com/benoitc/afgwardiary>
> >> [2] https://github.com/benoitc/**nymphormation<
> https://github.com/benoitc/nymphormation>
> >> [3] https://github.com/refuge/**rcouch/wiki<
> https://github.com/refuge/rcouch/wiki>
> >> [4] http://refuge.io
> >> [5] https://github.com/refuge/**rcouch/wiki/refactoring<
> https://github.com/refuge/rcouch/wiki/refactoring>
> >>
> >>
> >> On Wed, Jul 24, 2013 at 11:36 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>
> >> I have a dream…
> >>>
> >>> (pardon the plagiarism)
> >>>
> >>> I want to live in a world where people are empowered to understand
> >>> and are capable to decide where their data lives. I want to live in
> >>> a world where developers build apps that support that, not because
> >>> they went out of their way to implement it, but because it is a
> >>> feature of the software platform they are using.
> >>>
> >>> I want to be able to help people improve their lives in regions of
> >>> the world where ubiquitous network access isn’t — and sometimes that
> >>> is just a major western capital’s subway — but more likely is it a
> >>> lesser developed location, or a rural area that will never see mobile
> >>> broadband, let alone wired broadband because there is no financial
> >>> incentive.
> >>>
> >>> I want to live in a world where technology solves more problems than
> >>> it creates. One of those ways is allow people to use software wherever
> >>> they are in whatever context they need it in. More often than not,
> >>> that means far away from fast network access (Despite what @dhh is
> >>> trying to tell you).
> >>>
> >>> My primary motivation for working on Apache CouchDB is to help build
> >>> the world I want to live in. The same motivation drives my motivation
> >>> behind Hoodie (http://hood.ie), which builds on top of CouchDB and
> >>> wouldn’t be possible without it.
> >>>
> >>>
> >>> * * *
> >>>
> >>> In the past year I have interviewed a fair number of people, let’s
> >>> say 50, from those who have heard about CouchDB to users to core devs.
> >>>
> >>> The ONE feature that makes CouchDB relevant is multi-master
> replication.
> >>> There is no exception, this is the ONE thing that makes CouchDB
> >>> exceptional. NOBODY else has that, and even the decent proprietary
> >>> solutions that are just coming to market suck where we KICK ASS.
> >>>
> >>> There are many other things that people like about CouchDB:
> reliability,
> >>> no schema, HTTP interface, the view system, etc. But NONE of these
> people
> >>> would care if CouchDB didn’t have multi-master replication.
> >>>
> >>>
> >>> * * *
> >>>
> >>> The number one thing that people did NOT like about CouchDB is that it
> >>> is confused. CouchDB has a torn identity, half database, half
> >>> application server. It wasn’t clear (and I am part responsible for
> this)
> >>> what CouchDB is and wants to be. In everybody’s defence, I think, it
> >>> just took a while to figure it out. Now is a good time to put our
> >>> findings in writing and fix this.
> >>>
> >>> The number one request from people was to clear up CouchDB’s story,
> >>> to have a clear, bold vision that captures people and that they can
> >>> easily understand and share and support and move forward.
> >>>
> >>>
> >>> * * *
> >>>
> >>> Here is a narrative about what CouchDB has, that has formed in my head
> >>> in the past year. I have shared this with some people privately for
> some
> >>> feedback and they all liked it, so it has that going for it. I also
> tried
> >>> out bringing some of these issues up in presentations I have given, to
> >>> again great feedback.
> >>>
> >>> E.g.:
> >>>
> >>> http://www.youtube.com/watch?**v=7mdG-iAizVc<
> http://www.youtube.com/watch?v=7mdG-iAizVc>or
> >>> http://www.youtube.com/watch?**v=edbi9jJZkpg<
> http://www.youtube.com/watch?v=edbi9jJZkpg>
> >>>
> >>> Before I lay it out, I understand that I will be ruffling some
> feathers.
> >>> I think that is both necessary and healthy. I think the picture I am
> >>> going to paint will make a lot of people in the CouchDB community
> happy,
> >>> some with concessions, but I utterly and strongly believe that this
> >>> vision of what CouchDB is has the power to set the course for the next
> >>> five years of the project and attract a whole lot of new people both
> >>> as users and contributors.
> >>>
> >>>
> >>>
> >>> * * *
> >>>
> >>> CouchDB is a database that replicates.
> >>>
> >>> Think of it as git for your data-layer. Not in a sense where you manage
> >>> text files and diff and merge, but in the sense that you have a local
> >>> version of your data and one or multiple remote ones and you can
> >>> seamlessly move your data between them, back and forth and crossover.
> >>>
> >>> Imagine a local checkout of your data that you can work on, and then
> >>> share it with Lucie across the table, she finds some issues and fixes
> >>> up the data, and shares it with Tim across the room. Tim fixes two
> >>> more issues and you pull both their changes into your copy. We conclude
> >>> the whole thing is golden and we push it to staging, where our
> continuous
> >>> integration runs and decides that the data is good to go into
> production,
> >>> so it pushes it to production. There the data is picked up from various
> >>> clients, some mobile over there, some web over here, a backup system
> >>> in the Tokyo office…
> >>>
> >>> Or you have hospitals in remote regions in Africa that collect local
> >>> health data, like how many malaria infections a region has and they all
> >>> share their results over unreliable mobile connections and the data
> >>> still makes it eventually maybe with a few hours delay and the malaria
> >>> expert in the capital city sees an increased outbreak of some illness
> >>> and is able to send out medicine in time to arrive for the patients
> >>> to help. Where today the expert takes months to travel between the
> >>> hospitals to collect that data manually and find out that there was
> >>> a lethal outbreak two months ago and everybody died.
> >>>
> >>> (Somebody built this, CouchDB does save lives, I get teary every time
> >>> I tell this story (like now). Our work doesn’t get more noble than
> >>> this.)
> >>>
> >>> Or imagine millions of mobile users with access to terabytes of
> >>> data in the cloud, replicating the bits they need to their phones
> >>> and tablets, allowing super-fast low-latency access for a stellar
> >>> user experience, while giving access to sheer amounts of data and
> >>> allowing full write access on the mobile device to be replicated
> >>> back to the cloud when connections exist.
> >>>
> >>> (Our friends at Cloudant have a couple of those customers.)
> >>>
> >>>
> >>> That is the power of CouchDB.
> >>>
> >>>
> >>> * * *
> >>>
> >>> Replication is the PRIMARY feature of CouchDB. “is a database” means
> >>> “stores your data, safely and securely”, “that replicates” highlights
> >>> the primary feature.
> >>>
> >>> There are many more very cool features of CouchDB, even the details
> >>> on how we achieve reliability and data safety or how replication
> >>> works are mindblowingly cool. The simple HTTP interface, the JSON
> >>> store, the app-server features, map reduce views, all very excellent
> >>> things that make CouchDB unique, but it is very important to understand
> >>> that they are SECONDARY features.
> >>>
> >>>
> >>> * * *
> >>>
> >>> I want to learn from understanding what the PRIMARY and SECONDARY
> >>> features for CouchDB are. I already feel a bit bad about that the
> >>> PRIMARY ones are two (“a database” *and* “that replicates”), but I
> >>> think that is as little as it gets.
> >>>
> >>> I want CouchDB’s new identity to be a database that replicates. I want
> >>> to provide a slide deck for a “CouchDB in 25 minutes” presentation*
> that
> >>> everybody can take and give and customise, but I want that one of the
> >>> first things you say “CouchDB is a database that replicates”. I want
> >>> that if you ask anyone inside the CouchDB developer community (you!)
> >>> about what CouchDB is to answer “CouchDB is a database that replicates”
> >>> and then follow up explaining what we mean, and *then* add a few more
> >>> of the SECONDARY features that you particularly like.
> >>>
> >>> * https://dl.dropboxusercontent.**com/u/82149/CouchDB-in-25-**
> >>> Minutes.pdf<
> https://dl.dropboxusercontent.com/u/82149/CouchDB-in-25-Minutes.pdf>
> >>> Full talk at: http://vimeo.com/62599420 (sorry this one is German,
> >>> still trying to find an English version of this)
> >>>
> >>> I want that people who barely look at CouchDB comment on an unrelated
> >>> Hacker News thread write “…CouchDB is a database that replicates, maybe
> >>> that is a better fit for your problem”.
> >>>
> >>> I want that the CTO of the newly funded startup thinks “I seem to have
> >>> a replication problem to solve, maybe CouchDB can help.”
> >>>
> >>> I want to move CouchDB’s development forward, and when we ask ourselves
> >>> whether to add a feature, we run it by our PRIMARY feature set and ask
> >>> “does it support ‘CouchDB is a database that replicates’” and if it
> does
> >>> we go ahead and build it, and if it doesn’t we may consider it as a
> >>> SECONDARY feature, or we discard it altogether.
> >>>
> >>> (I don’t actually care what the final slogan will be, and please
> >>> bike-shed
> >>> this to no avail, but it should capture what I mean with “CouchDB is
> a
> >>> database that replicates”, a phrase that we can burn into everybody’s
> >>> head that captures CouchDB’s PRIMARY feature, its PRIMARY value
> >>> proposition, the ONE thing that explains WHY we are excited about
> >>> CouchDB.)
> >>>
> >>>
> >>> * * *
> >>>
> >>> Now, you might be miffed that your pet feature didn’t make the PRIMARY
> >>> list.
> >>> Do not worry, I believe I have a solution for that.
> >>>
> >>> I have brought this up before, but I really do think the holy grail to
> >>> all
> >>> this is a very well done plugin system that allows us to follow the
> >>> “small
> >>> core, massive plugin repository” paradigm that other’s ever so
> >>> successfully
> >>> pioneered.
> >>>
> >>> This allows us to focus on what CouchDB is for internal and external
> >>> communication, for roadmap discussions and attraction of developer
> >>> talent.
> >>>
> >>> More importantly, it allows us to keep all the fringe things that makes
> >>> CouchDB so very appealing to a lot of different people. It also allows
> us
> >>> to open up development to people who feel intimidated working on core
> >>> CouchDB, but can easily write a little plugin or three (this is
> basically
> >>> me, I have like 20 branches on GitHub that are useful to maybe 5% of
> our
> >>> users and they don’t get used any).
> >>>
> >>> A wise person once said “Core is where features go to rot.”, and if you
> >>> look at a number of CouchDB features, you can see that we suffer from
> >>> that.
> >>>
> >>> We need a kick-ass plugin system that allows us to easily create,
> >>> publish,
> >>> maintain and update little pieces of code that allow our users to make
> >>> their CouchDB their own. (I am signing up to build that, but I will
> need
> >>> your help, there is a shit ton of work to do :)
> >>>
> >>>
> >>> * * *
> >>>
> >>> ALERT: OPINION (your opinion may differ and we need to hear it)
> >>>
> >>> There is a discussion we need to have what the “small core” means for
> >>> CouchDB. There is a discrepancy between the absolute minimum to fulfil
> >>> the “CouchDB is a database that replicates“ mantra and what would be
> >>> a useful-out-of-the-box product that our users could set up and be
> >>> productive with.
> >>>
> >>> My minimum set looks roughly like this:
> >>>
> >>> - core database management (crud dbs & json/mime-docs, clustering)
> >>> - remote & local replication
> >>> - MR-views & GeoCouch enabled by default (ideally abstracted
> >>> away with nice “query dsl”)
> >>> - HTTP interface
> >>> - Fu/Fauxton
> >>> - configuration
> >>> - stats
> >>> - docs
> >>> - plugin system with Erlang (and in the future JavaScript support
> >>> via Node.js)
> >>>
> >>> This makes for a useful CouchDB default setup.
> >>>
> >>> Everything else should be a plugin. A piece of code that can be
> installed
> >>> with a quick search and a click of a button in Futon (or a `curl`-call
> on
> >>> the HTTP interface). Not far away, definitely not “siberia” (if you get
> >>> the PHP reference), but close to the core and encouraged to be used.
> >>>
> >>> And yes, this explicitly includes things like shows and lists and
> update
> >>> functions and rewrites and vhosts. We should make it super simple to
> add
> >>> these, but for a default experience, they are very, very confusing. We
> >>> should have a single plugin “CouchApp Engine” which includes Benoit’s
> >>> vision of CouchApps done right that is just a click away to install.
> >>>
> >>> In terms of highlighting the strengths of the core CouchDB “product”,
> >>> this
> >>> is what I’d put on the website:
> >>>
> >>> - Apache CouchDB implements the CouchDB vision:
> >>> It is a database that replicates.
> >>>
> >>> - Document Database:
> >>> - Data records are standard JSON.
> >>> - Unlimited Binary data storage with attachments.
> >>> - (alternatively arbitrary mime docs with special rules for JSON
> >>> docs)
> >>>
> >>> - Fault-tolerant:
> >>> - Data is always safe. Tail-append storage ensures no messing with
> >>> already committed data.
> >>> - Errors are isolated, recovery is local and doesn’t affect other
> >>> parallel requests.
> >>> - Recovery of fatal errors is immediate. There is no “fixup phase”
> >>> after a restart.
> >>> - Software updates and bugfix deployment without downtime.
> >>>
> >>> - Highly Concurrent:
> >>> - Erlang makes good use of massively parallel network server
> >>> installations.
> >>> - Garbage collection happens roughly on a per-request basis.
> >>> GC in one request doesn’t affect other requests.
> >>>
> >>> - Cluster / BigCouch / Big Data:
> >>> - Includes a Dynamo-style clustering and cluster-management
> >>> feature that allows to spread data and load over multiple
> >>> physical machines.
> >>> - Scales up to Petabytes of data.
> >>>
> >>> - Secondary 2D and 3D indexing
> >>> - Using incremental and asynchronous index updates for
> >>> high-performance queries.
> >>>
> >>> - Makes good use of hardware:
> >>> - Tail-append storage allows for serial write access to
> >>> storage media, which is a best-case-scenario for spinning
> >>> disks and SSDs.
> >>>
> >>> - Small Core & Flexible Plugin System:
> >>> - Some features are only useful for a small group of people, these
> >>> can be installed with a super simple plugin management system
> that
> >>> is built into the admin interface.
> >>> - Get new features with a click or tap.
> >>> - Plugins can be written in Erlang (and in JavaScript in the
> >>> future).
> >>>
> >>> - Cross Platform Support
> >>> - Runs on any POSIX UNIX as well as Windows.
> >>> - Support for some embedded devices like Android and RaspberryPi.
> >>>
> >>>
> >>> I think this would make for a compelling list of technical features.
> >>>
> >>> (I’d probably also add a blip about the ASF and the Apache 2.0 License
> >>> for good measure)
> >>>
> >>> ALERT END
> >>>
> >>>
> >>> * * *
> >>>
> >>> And then, CouchDB is one more thing. CouchDB isn’t just the Erlang
> >>> implementation of this whole replicating database idea. CouchDB is also
> >>> the wire protocol, the specification that makes all the magic work.
> >>> Apache CouchDB is the focal point for The Replicating Society*.
> >>>
> >>> (* cue your Blade Runner jokes)
> >>>
> >>> Apache CouchDB is THE standard for data freedom and exchange and is
> >>> the clearing house, the centre for an ecosystem that includes fantastic
> >>> projects like PouchDB and the TouchDBs, MAx Ogden’s `dat` and whichever
> >>> else follow these. Not saying we merge those projects in, they can
> stand
> >>> on their own, but we should embrace everything that makes the
> >>> interoperable replication world a reality.
> >>>
> >>> http://couchdb.apache.org is going to be the centre of the data
> >>> replication universe.
> >>>
> >>>
> >>> * * *
> >>>
> >>> Now all of this is my vision and I bringing it to this table now.
> >>> I have to admit that I am very nervous about this. A lot of things
> >>> aren’t very well thought out and at the same time, I care very
> >>> deeply about this project and it’s community and their future, so
> >>> there is a little anxiety doing this little emotional striptease
> >>> in front of all of you.
> >>>
> >>> What we will end up with, is not what I dream up and that’s that,
> >>> but I hope I can inform and set the direction of where we are going,
> >>> and then we can all together figure out the hard parts, and question
> >>> my assumptions and change little thing or lots.
> >>>
> >>> I don’t want to make this mine, but ours. To keep and to be proud of.
> >>>
> >>> The last thing I want is to stifle diversity, in thought and code,
> >>> and I am very sure that some of you will find a lot to disagree with
> >>> what I am saying, and that’s great, because this should, again, be
> >>> ours, not mine.
> >>>
> >>> But the one thing I am convinced of is the little pivot that this
> >>> project hinges on* between relative obscurity and blasting success
> >>> is that we need to find our version of a simplified, streamlined
> >>> and aligned way of defining, building and communicating what Apache
> >>> CouchDB is.
> >>>
> >>> (* I suck at metaphors)
> >>>
> >>> And yes that means that some thing that *YOU* think are important
> >>> are getting a second row seat instead of the front row. Heck even
> >>> some of my pet features get a second row seat, but that is fine
> >>> because they aren’t gone, there is still room for all the crazy
> >>> and not-so-crazy-but-not-essential stuff that people love in the
> >>> plugin system, one click away. All this so we can benefit from
> >>> being able to focus on building a modern, compelling, fun, humble
> >>> and clever database that we can build the future, our future, on.
> >>>
> >>>
> >>> * * *
> >>>
> >>> I want to live in a world where people are empowered to understand
> >>> and are capable to decide where their data lives.
> >>>
> >>>
> >>> I want to live in a world where technology solves more problems than
> >>> it creates.
> >>>
> >>>
> >>> My primary motivation for working on Apache CouchDB is to help build
> >>> the world I want to live in.
> >>>
> >>>
> >>> The ONE feature that makes CouchDB relevant is multi-master
> replication.
> >>>
> >>>
> >>> I want to learn from understanding what the PRIMARY and SECONDARY
> >>> features for CouchDB are.
> >>>
> >>>
> >>> Apache CouchDB is the focal point for The Replicating Society.
> >>>
> >>>
> >>> I don’t want to make this mine, but ours. To keep and to be proud of.
> >>>
> >>>
> >>> * * *
> >>>
> >>>
> >>> CouchDB is a database that replicates.
> >>>
> >>> I’m excited about your feedback! <3
> >>>
> >>> Sincerely,
> >>> Jan
> >>> --
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Thanks to Noah for kicking off this way overdue discussion.
> >>>
> >>>
> >>> On Jul 24, 2013, at 15:28 , Noah Slater <ns...@apache.org> wrote:
> >>>
> >>> Okay, here are some rough thoughts.
> >>>>
> >>>> Why?
> >>>>
> >>>> - We believe that distributed data should be easy
> >>>>
> >>>> How?
> >>>>
> >>>> - Painless multi-master replication
> >>>> - Effortless clustering and sharding
> >>>> - Co-location of data, queries, and views
> >>>> - Deep browser and platform integration
> >>>> - Built of the Web
> >>>>
> >>>> What?
> >>>>
> >>>> - Erlang
> >>>> - HTTP
> >>>> - JSON
> >>>> - JavaScript
> >>>> - MapReduce
> >>>>
> >>>> (That last list could go on, and on, and on...)
> >>>>
> >>>> Anyway. This is just a rough sketch of the sort of hierarchy I am
> >>>>
> >>> thinking
> >>>
> >>>> about.
> >>>>
> >>>> Whatever this ends up looking like, I think this is how we should talk
> >>>> about CouchDB. This structure could be a template for anything. A
> talk,
> >>>> a
> >>>> sales pitch, the homepage itself. The important thing is that we start
> >>>>
> >>> from
> >>>
> >>>> "why?" and we build up from foundations.
> >>>>
> >>>>
> >>>> On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
> >>>>
> >>>> I'm trying to imagine what our "I have a dream" speech would be like
> >>>>> for
> >>>>> CouchDB. If we were the Wright brothers, we might stand up and say "I
> >>>>>
> >>>> have
> >>>
> >>>> a dream that one day man will fly." We might say, "I have a dream that
> >>>>> distributed data will be easy." (I mean, that about covers it, right?
> >>>>> Doesn't have to be complex. The hard part is making sure we actually
> >>>>>
> >>>> focus
> >>>
> >>>> in on the root dream we all have.)
> >>>>>
> >>>>> Jan mentioned a few months ago that CouchDB almost wants to be the
> Git,
> >>>>> for databases. What is Git? What would Git's "dream" be? I can
> imagine
> >>>>> Linus saying "I have a dream that distributed version control will be
> >>>>> easy." Same sorta thing, right?
> >>>>>
> >>>>>
> >>>>> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
> >>>>>
> >>>>> Benoit,
> >>>>>>
> >>>>>> You should defo watch that video and see what you think. Note that
> it
> >>>>>> does not matter if we are a company. This insight applies to
> >>>>>> companies,
> >>>>>> products, loose groups of people working towards one thing (like the
> >>>>>>
> >>>>> Wright
> >>>
> >>>> brothers) and even individuals. (i.e. What is your personal "why" and
> >>>>>>
> >>>>> how
> >>>
> >>>> are the things you are doing working towards that.)
> >>>>>>
> >>>>>> I also want to put you at ease by saying that having a single shared
> >>>>>> "why" doesn't mean that anybody's vision, or personal goals have to
> be
> >>>>>>
> >>>>> left
> >>>
> >>>> by the wayside. People can still come to the project with their own
> >>>>>>
> >>>>> goals,
> >>>
> >>>> and their own perspective. But the project itself should have a clear
> >>>>>>
> >>>>> sense
> >>>
> >>>> of what we are trying to accomplish.
> >>>>>>
> >>>>>> I think the "why" we come up with can easily be something that
> >>>>>> inspires
> >>>>>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp
> >>>>>>
> >>>>> peeps,
> >>>
> >>>> the "big data" peeps, the mobile platform peeps. Think about a why
> that
> >>>>>> might evolve out of "your data, everywhere". Who (in our existing
> >>>>>> communities) wouldn't love that and want to rally behind that? (But
> >>>>>>
> >>>>> this is
> >>>
> >>>> just one idea.)
> >>>>>>
> >>>>>> Asking "what are the core features" misses the point. Why are these
> >>>>>>
> >>>>> core
> >>>
> >>>> features? Why did we add them in the first place? What are we working
> >>>>>> towards? See, you hit on it in your final sentence: "relax we take
> >>>>>> care
> >>>>>> about your data and the way you exchange and render them wherever
> they
> >>>>>> are". This! This is the kind of thing that I think we should hone,
> and
> >>>>>> figure out, and document.
> >>>>>>
> >>>>>> Once we have that, it can inform our "how". When we're talking about
> >>>>>> features, about product direction (i.e. what we add, what we
> subtract)
> >>>>>>
> >>>>> we
> >>>
> >>>> can say "well, how is this related to what we're trying to do here?"
> >>>>>>
> >>>>> Do you
> >>>
> >>>> see what I mean? :)
> >>>>>>
> >>>>>> "Painless distributed systems" is also a step in the right direction
> >>>>>>
> >>>>> for
> >>>
> >>>> answering the question "why?"
> >>>>>>
> >>>>>> So far we have:
> >>>>>>
> >>>>>> * Relax
> >>>>>> * Decentralised web
> >>>>>> * Peer-to-peer replication of apps and datasets
> >>>>>> * Your data, everywhere
> >>>>>> * Put the data where you need it
> >>>>>> * We handle your data / you handle display
> >>>>>> * Painless distributed systems
> >>>>>>
> >>>>>> Somewhere in here ^ (and perhaps in a follow up reply) is a single
> >>>>>>
> >>>>> shared
> >>>
> >>>> value system. Something we all hold dear.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
> >>>>>>
> >>>>>> Anyway, CouchDB is not like apple or dell. This isn't a company.
> And
> >>>>>>>
> >>>>>> we
> >>>
> >>>> don't have to share all the same vision, but only common values, a
> >>>>>>>
> >>>>>> core.
> >>>
> >>>> I'm not sure it enter in the what you describe. What kind of vision
> >>>>>>>
> >>>>>> are
> >>>
> >>>> you
> >>>>>>> speaking about?
> >>>>>>>
> >>>>>>> Also I would remove any pro-tip from your mail if we want to start
> >>>>>>>
> >>>>>> from a
> >>>
> >>>> neutral base.
> >>>>>>>
> >>>>>>> Couchdb is known for the replication but not only. Couchapps and
> the
> >>>>>>>
> >>>>>> way
> >>>
> >>>> people hack around is another (hoodie, kanso, erica/ couchapp all
> >>>>>>> differents visions of what is a couchapp but all are using couchdb
> >>>>>>> the
> >>>>>>> same_.. Message hub is another (nodejistsu, hoodie are using
> couchdb
> >>>>>>>
> >>>>>> as a
> >>>
> >>>> message hub somehow, not only but a lot of their arch is based on
> >>>>>>> changes).
> >>>>>>> And now we we can add some kind of big data handling. Not
> forgetting
> >>>>>>> people
> >>>>>>> that are using apache couchdb on their mobile, they exists and the
> >>>>>>> patches
> >>>>>>> will be release.
> >>>>>>>
> >>>>>>> All have different visions. But they share some common features. I
> >>>>>>>
> >>>>>> don't
> >>>
> >>>> want to forget someone because of a vision of some. I only know that
> >>>>>>> couchdb has some strong features that could be improved.
> >>>>>>>
> >>>>>>> All that to say that rather than thinking to a vision, maybe we
> could
> >>>>>>> collect all the usages around and see what emerges from it. What
> are
> >>>>>>>
> >>>>>> the
> >>>
> >>>> core features, What couchdb should focus on and itterrate depending on
> >>>>>>> the
> >>>>>>> new usage. I guess it's some kind of philosophy: "relax we take
> care
> >>>>>>> about
> >>>>>>> your data and the way you exchange and render them wherever they
> >>>>>>> are".
> >>>>>>>
> >>>>>>> - benoit
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org>
> >>>>>>>
> >>>>>> wrote:
> >>>
> >>>> Hi devs,
> >>>>>>>>
> >>>>>>>> I came across this video recently:
> >>>>>>>>
> >>>>>>>> Simon Sinek: How great leaders inspire action
> >>>>>>>>
> >>>>>>>> http://www.ted.com/talks/**simon_sinek_how_great_leaders_**
> >>> inspire_action.html<
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
> >
> >>>
> >>>> In it he sets out what he calls the Golden Circle:
> >>>>>>>>
> >>>>>>>> Why
> >>>>>>>>
> >>>>>>>> - What's your purpose?
> >>>>>>>> - What's your cause?
> >>>>>>>> - What's your belief?
> >>>>>>>>
> >>>>>>>> How
> >>>>>>>>
> >>>>>>>> - How do we do it?
> >>>>>>>> - How does our product differentiate?
> >>>>>>>> - How are we different?
> >>>>>>>> - How are we better?
> >>>>>>>>
> >>>>>>>> What
> >>>>>>>>
> >>>>>>>> - What do we do?
> >>>>>>>> - What do we make?
> >>>>>>>>
> >>>>>>>> He points out that the difference between companies like Apple and
> >>>>>>>> companies like Dell.
> >>>>>>>>
> >>>>>>>> Dell tells you what they do, and how. "We make great computers.
> >>>>>>>>
> >>>>>>> They're
> >>>
> >>>> well designed and work well. Wanna buy a computer?" Most companies do
> >>>>>>>>
> >>>>>>> it
> >>>>>>>
> >>>>>>>> like this. But they often miss out the "why".
> >>>>>>>>
> >>>>>>>> But then you look at Apple, and they do it the other way around.
> >>>>>>>>
> >>>>>>> Apple
> >>>
> >>>> tell
> >>>>>>>
> >>>>>>>> you what their purpose is. The rest is almost an afterthought. "We
> >>>>>>>>
> >>>>>>> believe
> >>>>>>>
> >>>>>>>> in challenging the status quo. We believe in thinking different.
> We
> >>>>>>>>
> >>>>>>> do
> >>>
> >>>> that
> >>>>>>>
> >>>>>>>> with great design and a focus on the user experience. We just
> happen
> >>>>>>>>
> >>>>>>> to
> >>>
> >>>> make computers." He then joking quips: "Ready to buy one yet?"
> >>>>>>>>
> >>>>>>>> (His talk gives several other examples, with his thesis being that
> >>>>>>>>
> >>>>>>> telling
> >>>>>>>
> >>>>>>>> your story from the outside in is what separates all the great
> >>>>>>>>
> >>>>>>> companies
> >>>>>>>
> >>>>>>>> and leaders. One of his main examples is the Wright brothers.)
> >>>>>>>>
> >>>>>>>> He comments that if you talk about what you believe, you will
> >>>>>>>> attract
> >>>>>>>>
> >>>>>>> those
> >>>>>>>
> >>>>>>>> that believe what you believe. That when you talk about what you
> >>>>>>>>
> >>>>>>> believe,
> >>>>>>>
> >>>>>>>> people will join you for their own reasons, for their own purpose.
> >>>>>>>>
> >>>>>>> And
> >>>
> >>>> that
> >>>>>>>
> >>>>>>>> what you do simply serves as proof of what you believe. Or as he
> >>>>>>>>
> >>>>>>> quips:
> >>>
> >>>> "Martin Luther King gave his 'I have a dream' speech, not his 'i
> >>>>>>>>
> >>>>>>> have a
> >>>
> >>>> plan' speech."
> >>>>>>>>
> >>>>>>>> Why am I bringing this to the dev list?
> >>>>>>>>
> >>>>>>>> Because our message stinks. "Apache CouchDB™ is a database that
> uses
> >>>>>>>>
> >>>>>>> JSON
> >>>>>>>
> >>>>>>>> for documents, JavaScript for MapReduce queries, and regular HTTP
> >>>>>>>> for
> >>>>>>>>
> >>>>>>> an
> >>>>>>>
> >>>>>>>> API" is a terrible way to introduce who we are, what we stand for,
> >>>>>>>>
> >>>>>>> and
> >>>
> >>>> why
> >>>>>>>
> >>>>>>>> we build this thing. (And I'm allowed to say all that, because I'm
> >>>>>>>>
> >>>>>>> the
> >>>
> >>>> one
> >>>>>>>
> >>>>>>>> who wrote it, with lots of help from Jan.)
> >>>>>>>>
> >>>>>>>> So what am I proposing? I'm proposing that we figure out our why.
> >>>>>>>>
> >>>>>>> That
> >>>
> >>>> we
> >>>>>>>
> >>>>>>>> figure out what we stand for, what we believe in. And then we
> figure
> >>>>>>>>
> >>>>>>> out
> >>>>>>>
> >>>>>>>> how we're gonna do that (pro tip: replication is more important
> than
> >>>>>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>> data format we use). Not only will this define a consistent
> internal
> >>>>>>>>
> >>>>>>> vision
> >>>>>>>
> >>>>>>>> for the project (what *are* we working towards anyway?) but it
> will
> >>>>>>>>
> >>>>>>> help us
> >>>>>>>
> >>>>>>>> to attract people who believe in what we believe.
> >>>>>>>>
> >>>>>>>> So, if you have any thoughts about this, speak up!
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> NS
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> NS
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> NS
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> NS
> >>>>
> >>>
> >>>
> > The needs and benefits and USP of Couchdb/rcouch/Bigcouch/**spatial
> > hybrid are different
> > and also the motivations for inclusion or exclusion and extension of any
> > need or want is
> > different for SaaS and distributed or mobile application.
> >
> > This makes it difficult to answer the superficially easy "why" question.
> >
> > It is only the possibilities of the "how" and "what" questions that will
> > answer the "why" in devastating unanswerable logic.
> >
> > Refuge.io and Rcouch have the best "how", why?
> >
> > --
> > David Martin
> >
> >
>
>
> --
> Noah Slater
> https://twitter.com/nslater
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
Benoit,
Been clicking around http://refuge.io/ — really like the "why" that you
communicate here. ("Data should be yours!") Was wondering if you have any
pointers to more on this. Like, do you have any other vision / why / long
term goals? Any essays or emails you've written on it?
I am currently synthesising a "CouchDB Vision" document. Moved it to Google
Docs because it's easier to draft things. Once I've got something that
isn't embarrassing to look at, I'll share with the list and solicit
comments.
On 25 July 2013 16:43, david martin <da...@lymegreen.co.uk> wrote:
> On 25/07/13 09:52, Benoit Chesneau wrote:
>
>> So even if Noah didn't noticed I finished my previous mail with this
>> kind of philosophy "relax we take care about your data and the way you
>> exchange and render them wherever they are". Of course it was without
>> the lyricism but it is defining the vision I have since the beginning
>> with couchdb modulo the fact that the replication wasn't existing at the
>> beginning. I join Jan for some parts. One sure thing is that you can't
>> separate the why from the how. Anyway let me share my own experience of
>> CouchDB, it will help somehow to explain why I am *using* Couchdb, and
>> *how* I envision it.
>>
>> The first thing that interested me in couchdb was its simplicity of
>> usage and customization. An HTTP API, a small code base. The HTTP API is
>> more important than some are saying today. Of course we could use a
>> binary protocol it would be faster. But it is just a matter of time.
>> With HTTP 2.0 coming at the end of the year, the already working
>> implementations using SPDY, the HTTP couchdb api will be exchanged in
>> binary stream. Using couchdb over and on the web is really one of its
>> key features.
>>
>> Anyway, when I started to use couchdb (long time ago) I created some
>> applications. One of the first was Friendpaste. The replication was
>> just starting to exist (or on the point to, I can't remember) and the
>> first reason I used CouchDB for Friendpaste was because it allowed me
>> to view/maps the documents to my application quite in an intuitive and
>> natural way. I didn't have to query them across multiple tables, simply
>> map them then query them to match some pattern. I didn't have to
>> organize them at first in tables or columns. I just had to store my
>> document and create views (index) on them. The views can be later edited
>> or edited, but the documents, the way I store the data don't change.
>> Which was perfectly fit the way I code, iterating over features ans
>> sometimes completely change the way I'm using/view the data in the code.
>> CouchDB was giving me way to manipulate data I didn't have since a
>> while, since I played with hypercard or lotus notes. A documented
>> oriented database by itself is a concept, a way to handler your data.
>> And couchdb has its own particular way to do it. Even copied like it
>> some databases I won't name it it is different. Incremented views and
>> the way couchdb is storing the data are designed for the new storages we
>> have today (ssds and others). All new databases that are designed today
>> are using such system. Of course it should be improved.
>>
>> When the changes feeds were introduced in couchdb it was
>> revolutionnizing the way couchdb can be used and improved a lot the
>> replication. CouchDB was one of the first modern database to allow
>> anyone to listen on document changes and replicate them in a continuous
>> manner. At that time synchronization was not so trendy and there wasn't
>> many solutions allowing master-master replication. I created many
>> applications based on it since. One of them was the afgwardiary an
>> application to view the data leaked by wikileaks about the afghanistan
>> war [1], a couchapp entirely hosted in couchdb using geocouch to
>> manipulate the in formations This experimentation was really
>> interesting in the sense that it allowed people to exchange the leaked
>> data in a P2P fashion using the replication but also to render them.
>> That without installing anything but a patched couchdb with geocouch
>> (later becoming rcouch). I continued my experimentation with the
>> diplomatic cables.
>>
>> Eventually, frustrated by the time it took to put the code in couchdb,
>> and the lack of real review (lot of devs were busy to do other things)
>> and also the need to have a database that I can easily deploy and
>> customize I forked couchdb to create rcouch [3]. Rcouch is part of a
>> more global project refuge [4].
>>
>> In a sense, rcouch share the vision of Jan. To do rcouch I created a
>> couch core that can be extended by adding new erlang application and in
>> the new revision coming next week load/unload dynamically some plugins.
>> The rcouch core is articulated today in different apps: couch,
>> couch_changes, couch_stats, couch_replicator, couch_httpd, couch_index
>> and couch_mrview (which is based on couch_index). More details on the
>> wiki [5]. With rcouch are coming different extensions: refuge_spatial
>> (forked geocouch to work with latest couch core), random docs, db
>> updates... This core still has the shows and lists included. Not because
>> they are efficient, they aren't but because they are a pretty cool way
>> to manipulate/transform the data coming from the view index or the
>> database before sending them to your application or the user. Back in
>> the past, shows and lists was called forms and were created as way to
>> transform the data. For me the couchapps are not the shows and list, not
>> even these HTML5 apps that are a very limited view of what is possible.
>> Couchapps are mostly script to render the data over an index. In my
>> view we should ditch shows and lists to a concept of apps getting a
>> request object when they are exposed to the web or just an environ when
>> they are used as a script to extend the internal API (like redis
>> scripts).
>>
>> In the mean time I continued to maintain and improve the versions of
>> couchdb for ios and android, ported rcouch to different arm platforms
>> (minicomputer, raspberry, ....) and helped to design some interresting
>> systems using Couchdb to replicate a lot of data between mobiles and
>> servers on different locations but also using couchdb as a message hub.
>>
>> If I would like today define couchdb based on my rcouch experience and
>> the ports I did, I would say: "Apache Couchdb allows you to handle and
>> synchronize your data between different locations and devices in quasi
>> realtime over and on the web in a P2P manner without SPOF".
>>
>> So for me couchdb isn't only a database that replicate, it is also a way
>> to ease the usage of your data, the way you can view them in your
>> applications or directly on the web and over the web.
>>
>> - benoit
>>
>> [1] https://github.com/benoitc/**afgwardiary<https://github.com/benoitc/afgwardiary>
>> [2] https://github.com/benoitc/**nymphormation<https://github.com/benoitc/nymphormation>
>> [3] https://github.com/refuge/**rcouch/wiki<https://github.com/refuge/rcouch/wiki>
>> [4] http://refuge.io
>> [5] https://github.com/refuge/**rcouch/wiki/refactoring<https://github.com/refuge/rcouch/wiki/refactoring>
>>
>>
>> On Wed, Jul 24, 2013 at 11:36 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>> I have a dream…
>>>
>>> (pardon the plagiarism)
>>>
>>> I want to live in a world where people are empowered to understand
>>> and are capable to decide where their data lives. I want to live in
>>> a world where developers build apps that support that, not because
>>> they went out of their way to implement it, but because it is a
>>> feature of the software platform they are using.
>>>
>>> I want to be able to help people improve their lives in regions of
>>> the world where ubiquitous network access isn’t — and sometimes that
>>> is just a major western capital’s subway — but more likely is it a
>>> lesser developed location, or a rural area that will never see mobile
>>> broadband, let alone wired broadband because there is no financial
>>> incentive.
>>>
>>> I want to live in a world where technology solves more problems than
>>> it creates. One of those ways is allow people to use software wherever
>>> they are in whatever context they need it in. More often than not,
>>> that means far away from fast network access (Despite what @dhh is
>>> trying to tell you).
>>>
>>> My primary motivation for working on Apache CouchDB is to help build
>>> the world I want to live in. The same motivation drives my motivation
>>> behind Hoodie (http://hood.ie), which builds on top of CouchDB and
>>> wouldn’t be possible without it.
>>>
>>>
>>> * * *
>>>
>>> In the past year I have interviewed a fair number of people, let’s
>>> say 50, from those who have heard about CouchDB to users to core devs.
>>>
>>> The ONE feature that makes CouchDB relevant is multi-master replication.
>>> There is no exception, this is the ONE thing that makes CouchDB
>>> exceptional. NOBODY else has that, and even the decent proprietary
>>> solutions that are just coming to market suck where we KICK ASS.
>>>
>>> There are many other things that people like about CouchDB: reliability,
>>> no schema, HTTP interface, the view system, etc. But NONE of these people
>>> would care if CouchDB didn’t have multi-master replication.
>>>
>>>
>>> * * *
>>>
>>> The number one thing that people did NOT like about CouchDB is that it
>>> is confused. CouchDB has a torn identity, half database, half
>>> application server. It wasn’t clear (and I am part responsible for this)
>>> what CouchDB is and wants to be. In everybody’s defence, I think, it
>>> just took a while to figure it out. Now is a good time to put our
>>> findings in writing and fix this.
>>>
>>> The number one request from people was to clear up CouchDB’s story,
>>> to have a clear, bold vision that captures people and that they can
>>> easily understand and share and support and move forward.
>>>
>>>
>>> * * *
>>>
>>> Here is a narrative about what CouchDB has, that has formed in my head
>>> in the past year. I have shared this with some people privately for some
>>> feedback and they all liked it, so it has that going for it. I also tried
>>> out bringing some of these issues up in presentations I have given, to
>>> again great feedback.
>>>
>>> E.g.:
>>>
>>> http://www.youtube.com/watch?**v=7mdG-iAizVc<http://www.youtube.com/watch?v=7mdG-iAizVc>or
>>> http://www.youtube.com/watch?**v=edbi9jJZkpg<http://www.youtube.com/watch?v=edbi9jJZkpg>
>>>
>>> Before I lay it out, I understand that I will be ruffling some feathers.
>>> I think that is both necessary and healthy. I think the picture I am
>>> going to paint will make a lot of people in the CouchDB community happy,
>>> some with concessions, but I utterly and strongly believe that this
>>> vision of what CouchDB is has the power to set the course for the next
>>> five years of the project and attract a whole lot of new people both
>>> as users and contributors.
>>>
>>>
>>>
>>> * * *
>>>
>>> CouchDB is a database that replicates.
>>>
>>> Think of it as git for your data-layer. Not in a sense where you manage
>>> text files and diff and merge, but in the sense that you have a local
>>> version of your data and one or multiple remote ones and you can
>>> seamlessly move your data between them, back and forth and crossover.
>>>
>>> Imagine a local checkout of your data that you can work on, and then
>>> share it with Lucie across the table, she finds some issues and fixes
>>> up the data, and shares it with Tim across the room. Tim fixes two
>>> more issues and you pull both their changes into your copy. We conclude
>>> the whole thing is golden and we push it to staging, where our continuous
>>> integration runs and decides that the data is good to go into production,
>>> so it pushes it to production. There the data is picked up from various
>>> clients, some mobile over there, some web over here, a backup system
>>> in the Tokyo office…
>>>
>>> Or you have hospitals in remote regions in Africa that collect local
>>> health data, like how many malaria infections a region has and they all
>>> share their results over unreliable mobile connections and the data
>>> still makes it eventually maybe with a few hours delay and the malaria
>>> expert in the capital city sees an increased outbreak of some illness
>>> and is able to send out medicine in time to arrive for the patients
>>> to help. Where today the expert takes months to travel between the
>>> hospitals to collect that data manually and find out that there was
>>> a lethal outbreak two months ago and everybody died.
>>>
>>> (Somebody built this, CouchDB does save lives, I get teary every time
>>> I tell this story (like now). Our work doesn’t get more noble than
>>> this.)
>>>
>>> Or imagine millions of mobile users with access to terabytes of
>>> data in the cloud, replicating the bits they need to their phones
>>> and tablets, allowing super-fast low-latency access for a stellar
>>> user experience, while giving access to sheer amounts of data and
>>> allowing full write access on the mobile device to be replicated
>>> back to the cloud when connections exist.
>>>
>>> (Our friends at Cloudant have a couple of those customers.)
>>>
>>>
>>> That is the power of CouchDB.
>>>
>>>
>>> * * *
>>>
>>> Replication is the PRIMARY feature of CouchDB. “is a database” means
>>> “stores your data, safely and securely”, “that replicates” highlights
>>> the primary feature.
>>>
>>> There are many more very cool features of CouchDB, even the details
>>> on how we achieve reliability and data safety or how replication
>>> works are mindblowingly cool. The simple HTTP interface, the JSON
>>> store, the app-server features, map reduce views, all very excellent
>>> things that make CouchDB unique, but it is very important to understand
>>> that they are SECONDARY features.
>>>
>>>
>>> * * *
>>>
>>> I want to learn from understanding what the PRIMARY and SECONDARY
>>> features for CouchDB are. I already feel a bit bad about that the
>>> PRIMARY ones are two (“a database” *and* “that replicates”), but I
>>> think that is as little as it gets.
>>>
>>> I want CouchDB’s new identity to be a database that replicates. I want
>>> to provide a slide deck for a “CouchDB in 25 minutes” presentation* that
>>> everybody can take and give and customise, but I want that one of the
>>> first things you say “CouchDB is a database that replicates”. I want
>>> that if you ask anyone inside the CouchDB developer community (you!)
>>> about what CouchDB is to answer “CouchDB is a database that replicates”
>>> and then follow up explaining what we mean, and *then* add a few more
>>> of the SECONDARY features that you particularly like.
>>>
>>> * https://dl.dropboxusercontent.**com/u/82149/CouchDB-in-25-**
>>> Minutes.pdf<https://dl.dropboxusercontent.com/u/82149/CouchDB-in-25-Minutes.pdf>
>>> Full talk at: http://vimeo.com/62599420 (sorry this one is German,
>>> still trying to find an English version of this)
>>>
>>> I want that people who barely look at CouchDB comment on an unrelated
>>> Hacker News thread write “…CouchDB is a database that replicates, maybe
>>> that is a better fit for your problem”.
>>>
>>> I want that the CTO of the newly funded startup thinks “I seem to have
>>> a replication problem to solve, maybe CouchDB can help.”
>>>
>>> I want to move CouchDB’s development forward, and when we ask ourselves
>>> whether to add a feature, we run it by our PRIMARY feature set and ask
>>> “does it support ‘CouchDB is a database that replicates’” and if it does
>>> we go ahead and build it, and if it doesn’t we may consider it as a
>>> SECONDARY feature, or we discard it altogether.
>>>
>>> (I don’t actually care what the final slogan will be, and please
>>> bike-shed
>>> this to no avail, but it should capture what I mean with “CouchDB is a
>>> database that replicates”, a phrase that we can burn into everybody’s
>>> head that captures CouchDB’s PRIMARY feature, its PRIMARY value
>>> proposition, the ONE thing that explains WHY we are excited about
>>> CouchDB.)
>>>
>>>
>>> * * *
>>>
>>> Now, you might be miffed that your pet feature didn’t make the PRIMARY
>>> list.
>>> Do not worry, I believe I have a solution for that.
>>>
>>> I have brought this up before, but I really do think the holy grail to
>>> all
>>> this is a very well done plugin system that allows us to follow the
>>> “small
>>> core, massive plugin repository” paradigm that other’s ever so
>>> successfully
>>> pioneered.
>>>
>>> This allows us to focus on what CouchDB is for internal and external
>>> communication, for roadmap discussions and attraction of developer
>>> talent.
>>>
>>> More importantly, it allows us to keep all the fringe things that makes
>>> CouchDB so very appealing to a lot of different people. It also allows us
>>> to open up development to people who feel intimidated working on core
>>> CouchDB, but can easily write a little plugin or three (this is basically
>>> me, I have like 20 branches on GitHub that are useful to maybe 5% of our
>>> users and they don’t get used any).
>>>
>>> A wise person once said “Core is where features go to rot.”, and if you
>>> look at a number of CouchDB features, you can see that we suffer from
>>> that.
>>>
>>> We need a kick-ass plugin system that allows us to easily create,
>>> publish,
>>> maintain and update little pieces of code that allow our users to make
>>> their CouchDB their own. (I am signing up to build that, but I will need
>>> your help, there is a shit ton of work to do :)
>>>
>>>
>>> * * *
>>>
>>> ALERT: OPINION (your opinion may differ and we need to hear it)
>>>
>>> There is a discussion we need to have what the “small core” means for
>>> CouchDB. There is a discrepancy between the absolute minimum to fulfil
>>> the “CouchDB is a database that replicates“ mantra and what would be
>>> a useful-out-of-the-box product that our users could set up and be
>>> productive with.
>>>
>>> My minimum set looks roughly like this:
>>>
>>> - core database management (crud dbs & json/mime-docs, clustering)
>>> - remote & local replication
>>> - MR-views & GeoCouch enabled by default (ideally abstracted
>>> away with nice “query dsl”)
>>> - HTTP interface
>>> - Fu/Fauxton
>>> - configuration
>>> - stats
>>> - docs
>>> - plugin system with Erlang (and in the future JavaScript support
>>> via Node.js)
>>>
>>> This makes for a useful CouchDB default setup.
>>>
>>> Everything else should be a plugin. A piece of code that can be installed
>>> with a quick search and a click of a button in Futon (or a `curl`-call on
>>> the HTTP interface). Not far away, definitely not “siberia” (if you get
>>> the PHP reference), but close to the core and encouraged to be used.
>>>
>>> And yes, this explicitly includes things like shows and lists and update
>>> functions and rewrites and vhosts. We should make it super simple to add
>>> these, but for a default experience, they are very, very confusing. We
>>> should have a single plugin “CouchApp Engine” which includes Benoit’s
>>> vision of CouchApps done right that is just a click away to install.
>>>
>>> In terms of highlighting the strengths of the core CouchDB “product”,
>>> this
>>> is what I’d put on the website:
>>>
>>> - Apache CouchDB implements the CouchDB vision:
>>> It is a database that replicates.
>>>
>>> - Document Database:
>>> - Data records are standard JSON.
>>> - Unlimited Binary data storage with attachments.
>>> - (alternatively arbitrary mime docs with special rules for JSON
>>> docs)
>>>
>>> - Fault-tolerant:
>>> - Data is always safe. Tail-append storage ensures no messing with
>>> already committed data.
>>> - Errors are isolated, recovery is local and doesn’t affect other
>>> parallel requests.
>>> - Recovery of fatal errors is immediate. There is no “fixup phase”
>>> after a restart.
>>> - Software updates and bugfix deployment without downtime.
>>>
>>> - Highly Concurrent:
>>> - Erlang makes good use of massively parallel network server
>>> installations.
>>> - Garbage collection happens roughly on a per-request basis.
>>> GC in one request doesn’t affect other requests.
>>>
>>> - Cluster / BigCouch / Big Data:
>>> - Includes a Dynamo-style clustering and cluster-management
>>> feature that allows to spread data and load over multiple
>>> physical machines.
>>> - Scales up to Petabytes of data.
>>>
>>> - Secondary 2D and 3D indexing
>>> - Using incremental and asynchronous index updates for
>>> high-performance queries.
>>>
>>> - Makes good use of hardware:
>>> - Tail-append storage allows for serial write access to
>>> storage media, which is a best-case-scenario for spinning
>>> disks and SSDs.
>>>
>>> - Small Core & Flexible Plugin System:
>>> - Some features are only useful for a small group of people, these
>>> can be installed with a super simple plugin management system that
>>> is built into the admin interface.
>>> - Get new features with a click or tap.
>>> - Plugins can be written in Erlang (and in JavaScript in the
>>> future).
>>>
>>> - Cross Platform Support
>>> - Runs on any POSIX UNIX as well as Windows.
>>> - Support for some embedded devices like Android and RaspberryPi.
>>>
>>>
>>> I think this would make for a compelling list of technical features.
>>>
>>> (I’d probably also add a blip about the ASF and the Apache 2.0 License
>>> for good measure)
>>>
>>> ALERT END
>>>
>>>
>>> * * *
>>>
>>> And then, CouchDB is one more thing. CouchDB isn’t just the Erlang
>>> implementation of this whole replicating database idea. CouchDB is also
>>> the wire protocol, the specification that makes all the magic work.
>>> Apache CouchDB is the focal point for The Replicating Society*.
>>>
>>> (* cue your Blade Runner jokes)
>>>
>>> Apache CouchDB is THE standard for data freedom and exchange and is
>>> the clearing house, the centre for an ecosystem that includes fantastic
>>> projects like PouchDB and the TouchDBs, MAx Ogden’s `dat` and whichever
>>> else follow these. Not saying we merge those projects in, they can stand
>>> on their own, but we should embrace everything that makes the
>>> interoperable replication world a reality.
>>>
>>> http://couchdb.apache.org is going to be the centre of the data
>>> replication universe.
>>>
>>>
>>> * * *
>>>
>>> Now all of this is my vision and I bringing it to this table now.
>>> I have to admit that I am very nervous about this. A lot of things
>>> aren’t very well thought out and at the same time, I care very
>>> deeply about this project and it’s community and their future, so
>>> there is a little anxiety doing this little emotional striptease
>>> in front of all of you.
>>>
>>> What we will end up with, is not what I dream up and that’s that,
>>> but I hope I can inform and set the direction of where we are going,
>>> and then we can all together figure out the hard parts, and question
>>> my assumptions and change little thing or lots.
>>>
>>> I don’t want to make this mine, but ours. To keep and to be proud of.
>>>
>>> The last thing I want is to stifle diversity, in thought and code,
>>> and I am very sure that some of you will find a lot to disagree with
>>> what I am saying, and that’s great, because this should, again, be
>>> ours, not mine.
>>>
>>> But the one thing I am convinced of is the little pivot that this
>>> project hinges on* between relative obscurity and blasting success
>>> is that we need to find our version of a simplified, streamlined
>>> and aligned way of defining, building and communicating what Apache
>>> CouchDB is.
>>>
>>> (* I suck at metaphors)
>>>
>>> And yes that means that some thing that *YOU* think are important
>>> are getting a second row seat instead of the front row. Heck even
>>> some of my pet features get a second row seat, but that is fine
>>> because they aren’t gone, there is still room for all the crazy
>>> and not-so-crazy-but-not-essential stuff that people love in the
>>> plugin system, one click away. All this so we can benefit from
>>> being able to focus on building a modern, compelling, fun, humble
>>> and clever database that we can build the future, our future, on.
>>>
>>>
>>> * * *
>>>
>>> I want to live in a world where people are empowered to understand
>>> and are capable to decide where their data lives.
>>>
>>>
>>> I want to live in a world where technology solves more problems than
>>> it creates.
>>>
>>>
>>> My primary motivation for working on Apache CouchDB is to help build
>>> the world I want to live in.
>>>
>>>
>>> The ONE feature that makes CouchDB relevant is multi-master replication.
>>>
>>>
>>> I want to learn from understanding what the PRIMARY and SECONDARY
>>> features for CouchDB are.
>>>
>>>
>>> Apache CouchDB is the focal point for The Replicating Society.
>>>
>>>
>>> I don’t want to make this mine, but ours. To keep and to be proud of.
>>>
>>>
>>> * * *
>>>
>>>
>>> CouchDB is a database that replicates.
>>>
>>> I’m excited about your feedback! <3
>>>
>>> Sincerely,
>>> Jan
>>> --
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thanks to Noah for kicking off this way overdue discussion.
>>>
>>>
>>> On Jul 24, 2013, at 15:28 , Noah Slater <ns...@apache.org> wrote:
>>>
>>> Okay, here are some rough thoughts.
>>>>
>>>> Why?
>>>>
>>>> - We believe that distributed data should be easy
>>>>
>>>> How?
>>>>
>>>> - Painless multi-master replication
>>>> - Effortless clustering and sharding
>>>> - Co-location of data, queries, and views
>>>> - Deep browser and platform integration
>>>> - Built of the Web
>>>>
>>>> What?
>>>>
>>>> - Erlang
>>>> - HTTP
>>>> - JSON
>>>> - JavaScript
>>>> - MapReduce
>>>>
>>>> (That last list could go on, and on, and on...)
>>>>
>>>> Anyway. This is just a rough sketch of the sort of hierarchy I am
>>>>
>>> thinking
>>>
>>>> about.
>>>>
>>>> Whatever this ends up looking like, I think this is how we should talk
>>>> about CouchDB. This structure could be a template for anything. A talk,
>>>> a
>>>> sales pitch, the homepage itself. The important thing is that we start
>>>>
>>> from
>>>
>>>> "why?" and we build up from foundations.
>>>>
>>>>
>>>> On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
>>>>
>>>> I'm trying to imagine what our "I have a dream" speech would be like
>>>>> for
>>>>> CouchDB. If we were the Wright brothers, we might stand up and say "I
>>>>>
>>>> have
>>>
>>>> a dream that one day man will fly." We might say, "I have a dream that
>>>>> distributed data will be easy." (I mean, that about covers it, right?
>>>>> Doesn't have to be complex. The hard part is making sure we actually
>>>>>
>>>> focus
>>>
>>>> in on the root dream we all have.)
>>>>>
>>>>> Jan mentioned a few months ago that CouchDB almost wants to be the Git,
>>>>> for databases. What is Git? What would Git's "dream" be? I can imagine
>>>>> Linus saying "I have a dream that distributed version control will be
>>>>> easy." Same sorta thing, right?
>>>>>
>>>>>
>>>>> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
>>>>>
>>>>> Benoit,
>>>>>>
>>>>>> You should defo watch that video and see what you think. Note that it
>>>>>> does not matter if we are a company. This insight applies to
>>>>>> companies,
>>>>>> products, loose groups of people working towards one thing (like the
>>>>>>
>>>>> Wright
>>>
>>>> brothers) and even individuals. (i.e. What is your personal "why" and
>>>>>>
>>>>> how
>>>
>>>> are the things you are doing working towards that.)
>>>>>>
>>>>>> I also want to put you at ease by saying that having a single shared
>>>>>> "why" doesn't mean that anybody's vision, or personal goals have to be
>>>>>>
>>>>> left
>>>
>>>> by the wayside. People can still come to the project with their own
>>>>>>
>>>>> goals,
>>>
>>>> and their own perspective. But the project itself should have a clear
>>>>>>
>>>>> sense
>>>
>>>> of what we are trying to accomplish.
>>>>>>
>>>>>> I think the "why" we come up with can easily be something that
>>>>>> inspires
>>>>>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp
>>>>>>
>>>>> peeps,
>>>
>>>> the "big data" peeps, the mobile platform peeps. Think about a why that
>>>>>> might evolve out of "your data, everywhere". Who (in our existing
>>>>>> communities) wouldn't love that and want to rally behind that? (But
>>>>>>
>>>>> this is
>>>
>>>> just one idea.)
>>>>>>
>>>>>> Asking "what are the core features" misses the point. Why are these
>>>>>>
>>>>> core
>>>
>>>> features? Why did we add them in the first place? What are we working
>>>>>> towards? See, you hit on it in your final sentence: "relax we take
>>>>>> care
>>>>>> about your data and the way you exchange and render them wherever they
>>>>>> are". This! This is the kind of thing that I think we should hone, and
>>>>>> figure out, and document.
>>>>>>
>>>>>> Once we have that, it can inform our "how". When we're talking about
>>>>>> features, about product direction (i.e. what we add, what we subtract)
>>>>>>
>>>>> we
>>>
>>>> can say "well, how is this related to what we're trying to do here?"
>>>>>>
>>>>> Do you
>>>
>>>> see what I mean? :)
>>>>>>
>>>>>> "Painless distributed systems" is also a step in the right direction
>>>>>>
>>>>> for
>>>
>>>> answering the question "why?"
>>>>>>
>>>>>> So far we have:
>>>>>>
>>>>>> * Relax
>>>>>> * Decentralised web
>>>>>> * Peer-to-peer replication of apps and datasets
>>>>>> * Your data, everywhere
>>>>>> * Put the data where you need it
>>>>>> * We handle your data / you handle display
>>>>>> * Painless distributed systems
>>>>>>
>>>>>> Somewhere in here ^ (and perhaps in a follow up reply) is a single
>>>>>>
>>>>> shared
>>>
>>>> value system. Something we all hold dear.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>>
>>>>>> Anyway, CouchDB is not like apple or dell. This isn't a company. And
>>>>>>>
>>>>>> we
>>>
>>>> don't have to share all the same vision, but only common values, a
>>>>>>>
>>>>>> core.
>>>
>>>> I'm not sure it enter in the what you describe. What kind of vision
>>>>>>>
>>>>>> are
>>>
>>>> you
>>>>>>> speaking about?
>>>>>>>
>>>>>>> Also I would remove any pro-tip from your mail if we want to start
>>>>>>>
>>>>>> from a
>>>
>>>> neutral base.
>>>>>>>
>>>>>>> Couchdb is known for the replication but not only. Couchapps and the
>>>>>>>
>>>>>> way
>>>
>>>> people hack around is another (hoodie, kanso, erica/ couchapp all
>>>>>>> differents visions of what is a couchapp but all are using couchdb
>>>>>>> the
>>>>>>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb
>>>>>>>
>>>>>> as a
>>>
>>>> message hub somehow, not only but a lot of their arch is based on
>>>>>>> changes).
>>>>>>> And now we we can add some kind of big data handling. Not forgetting
>>>>>>> people
>>>>>>> that are using apache couchdb on their mobile, they exists and the
>>>>>>> patches
>>>>>>> will be release.
>>>>>>>
>>>>>>> All have different visions. But they share some common features. I
>>>>>>>
>>>>>> don't
>>>
>>>> want to forget someone because of a vision of some. I only know that
>>>>>>> couchdb has some strong features that could be improved.
>>>>>>>
>>>>>>> All that to say that rather than thinking to a vision, maybe we could
>>>>>>> collect all the usages around and see what emerges from it. What are
>>>>>>>
>>>>>> the
>>>
>>>> core features, What couchdb should focus on and itterrate depending on
>>>>>>> the
>>>>>>> new usage. I guess it's some kind of philosophy: "relax we take care
>>>>>>> about
>>>>>>> your data and the way you exchange and render them wherever they
>>>>>>> are".
>>>>>>>
>>>>>>> - benoit
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org>
>>>>>>>
>>>>>> wrote:
>>>
>>>> Hi devs,
>>>>>>>>
>>>>>>>> I came across this video recently:
>>>>>>>>
>>>>>>>> Simon Sinek: How great leaders inspire action
>>>>>>>>
>>>>>>>> http://www.ted.com/talks/**simon_sinek_how_great_leaders_**
>>> inspire_action.html<http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html>
>>>
>>>> In it he sets out what he calls the Golden Circle:
>>>>>>>>
>>>>>>>> Why
>>>>>>>>
>>>>>>>> - What's your purpose?
>>>>>>>> - What's your cause?
>>>>>>>> - What's your belief?
>>>>>>>>
>>>>>>>> How
>>>>>>>>
>>>>>>>> - How do we do it?
>>>>>>>> - How does our product differentiate?
>>>>>>>> - How are we different?
>>>>>>>> - How are we better?
>>>>>>>>
>>>>>>>> What
>>>>>>>>
>>>>>>>> - What do we do?
>>>>>>>> - What do we make?
>>>>>>>>
>>>>>>>> He points out that the difference between companies like Apple and
>>>>>>>> companies like Dell.
>>>>>>>>
>>>>>>>> Dell tells you what they do, and how. "We make great computers.
>>>>>>>>
>>>>>>> They're
>>>
>>>> well designed and work well. Wanna buy a computer?" Most companies do
>>>>>>>>
>>>>>>> it
>>>>>>>
>>>>>>>> like this. But they often miss out the "why".
>>>>>>>>
>>>>>>>> But then you look at Apple, and they do it the other way around.
>>>>>>>>
>>>>>>> Apple
>>>
>>>> tell
>>>>>>>
>>>>>>>> you what their purpose is. The rest is almost an afterthought. "We
>>>>>>>>
>>>>>>> believe
>>>>>>>
>>>>>>>> in challenging the status quo. We believe in thinking different. We
>>>>>>>>
>>>>>>> do
>>>
>>>> that
>>>>>>>
>>>>>>>> with great design and a focus on the user experience. We just happen
>>>>>>>>
>>>>>>> to
>>>
>>>> make computers." He then joking quips: "Ready to buy one yet?"
>>>>>>>>
>>>>>>>> (His talk gives several other examples, with his thesis being that
>>>>>>>>
>>>>>>> telling
>>>>>>>
>>>>>>>> your story from the outside in is what separates all the great
>>>>>>>>
>>>>>>> companies
>>>>>>>
>>>>>>>> and leaders. One of his main examples is the Wright brothers.)
>>>>>>>>
>>>>>>>> He comments that if you talk about what you believe, you will
>>>>>>>> attract
>>>>>>>>
>>>>>>> those
>>>>>>>
>>>>>>>> that believe what you believe. That when you talk about what you
>>>>>>>>
>>>>>>> believe,
>>>>>>>
>>>>>>>> people will join you for their own reasons, for their own purpose.
>>>>>>>>
>>>>>>> And
>>>
>>>> that
>>>>>>>
>>>>>>>> what you do simply serves as proof of what you believe. Or as he
>>>>>>>>
>>>>>>> quips:
>>>
>>>> "Martin Luther King gave his 'I have a dream' speech, not his 'i
>>>>>>>>
>>>>>>> have a
>>>
>>>> plan' speech."
>>>>>>>>
>>>>>>>> Why am I bringing this to the dev list?
>>>>>>>>
>>>>>>>> Because our message stinks. "Apache CouchDB™ is a database that uses
>>>>>>>>
>>>>>>> JSON
>>>>>>>
>>>>>>>> for documents, JavaScript for MapReduce queries, and regular HTTP
>>>>>>>> for
>>>>>>>>
>>>>>>> an
>>>>>>>
>>>>>>>> API" is a terrible way to introduce who we are, what we stand for,
>>>>>>>>
>>>>>>> and
>>>
>>>> why
>>>>>>>
>>>>>>>> we build this thing. (And I'm allowed to say all that, because I'm
>>>>>>>>
>>>>>>> the
>>>
>>>> one
>>>>>>>
>>>>>>>> who wrote it, with lots of help from Jan.)
>>>>>>>>
>>>>>>>> So what am I proposing? I'm proposing that we figure out our why.
>>>>>>>>
>>>>>>> That
>>>
>>>> we
>>>>>>>
>>>>>>>> figure out what we stand for, what we believe in. And then we figure
>>>>>>>>
>>>>>>> out
>>>>>>>
>>>>>>>> how we're gonna do that (pro tip: replication is more important than
>>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>> data format we use). Not only will this define a consistent internal
>>>>>>>>
>>>>>>> vision
>>>>>>>
>>>>>>>> for the project (what *are* we working towards anyway?) but it will
>>>>>>>>
>>>>>>> help us
>>>>>>>
>>>>>>>> to attract people who believe in what we believe.
>>>>>>>>
>>>>>>>> So, if you have any thoughts about this, speak up!
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --
>>>>>>>> NS
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> NS
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> NS
>>>>>
>>>>>
>>>>
>>>> --
>>>> NS
>>>>
>>>
>>>
> The needs and benefits and USP of Couchdb/rcouch/Bigcouch/**spatial
> hybrid are different
> and also the motivations for inclusion or exclusion and extension of any
> need or want is
> different for SaaS and distributed or mobile application.
>
> This makes it difficult to answer the superficially easy "why" question.
>
> It is only the possibilities of the "how" and "what" questions that will
> answer the "why" in devastating unanswerable logic.
>
> Refuge.io and Rcouch have the best "how", why?
>
> --
> David Martin
>
>
--
Noah Slater
https://twitter.com/nslater
Re: What's our Why?
Posted by david martin <da...@lymegreen.co.uk>.
On 25/07/13 09:52, Benoit Chesneau wrote:
> So even if Noah didn't noticed I finished my previous mail with this
> kind of philosophy "relax we take care about your data and the way you
> exchange and render them wherever they are". Of course it was without
> the lyricism but it is defining the vision I have since the beginning
> with couchdb modulo the fact that the replication wasn't existing at the
> beginning. I join Jan for some parts. One sure thing is that you can't
> separate the why from the how. Anyway let me share my own experience of
> CouchDB, it will help somehow to explain why I am *using* Couchdb, and
> *how* I envision it.
>
> The first thing that interested me in couchdb was its simplicity of
> usage and customization. An HTTP API, a small code base. The HTTP API is
> more important than some are saying today. Of course we could use a
> binary protocol it would be faster. But it is just a matter of time.
> With HTTP 2.0 coming at the end of the year, the already working
> implementations using SPDY, the HTTP couchdb api will be exchanged in
> binary stream. Using couchdb over and on the web is really one of its
> key features.
>
> Anyway, when I started to use couchdb (long time ago) I created some
> applications. One of the first was Friendpaste. The replication was
> just starting to exist (or on the point to, I can't remember) and the
> first reason I used CouchDB for Friendpaste was because it allowed me
> to view/maps the documents to my application quite in an intuitive and
> natural way. I didn't have to query them across multiple tables, simply
> map them then query them to match some pattern. I didn't have to
> organize them at first in tables or columns. I just had to store my
> document and create views (index) on them. The views can be later edited
> or edited, but the documents, the way I store the data don't change.
> Which was perfectly fit the way I code, iterating over features ans
> sometimes completely change the way I'm using/view the data in the code.
> CouchDB was giving me way to manipulate data I didn't have since a
> while, since I played with hypercard or lotus notes. A documented
> oriented database by itself is a concept, a way to handler your data.
> And couchdb has its own particular way to do it. Even copied like it
> some databases I won't name it it is different. Incremented views and
> the way couchdb is storing the data are designed for the new storages we
> have today (ssds and others). All new databases that are designed today
> are using such system. Of course it should be improved.
>
> When the changes feeds were introduced in couchdb it was
> revolutionnizing the way couchdb can be used and improved a lot the
> replication. CouchDB was one of the first modern database to allow
> anyone to listen on document changes and replicate them in a continuous
> manner. At that time synchronization was not so trendy and there wasn't
> many solutions allowing master-master replication. I created many
> applications based on it since. One of them was the afgwardiary an
> application to view the data leaked by wikileaks about the afghanistan
> war [1], a couchapp entirely hosted in couchdb using geocouch to
> manipulate the in formations This experimentation was really
> interesting in the sense that it allowed people to exchange the leaked
> data in a P2P fashion using the replication but also to render them.
> That without installing anything but a patched couchdb with geocouch
> (later becoming rcouch). I continued my experimentation with the
> diplomatic cables.
>
> Eventually, frustrated by the time it took to put the code in couchdb,
> and the lack of real review (lot of devs were busy to do other things)
> and also the need to have a database that I can easily deploy and
> customize I forked couchdb to create rcouch [3]. Rcouch is part of a
> more global project refuge [4].
>
> In a sense, rcouch share the vision of Jan. To do rcouch I created a
> couch core that can be extended by adding new erlang application and in
> the new revision coming next week load/unload dynamically some plugins.
> The rcouch core is articulated today in different apps: couch,
> couch_changes, couch_stats, couch_replicator, couch_httpd, couch_index
> and couch_mrview (which is based on couch_index). More details on the
> wiki [5]. With rcouch are coming different extensions: refuge_spatial
> (forked geocouch to work with latest couch core), random docs, db
> updates... This core still has the shows and lists included. Not because
> they are efficient, they aren't but because they are a pretty cool way
> to manipulate/transform the data coming from the view index or the
> database before sending them to your application or the user. Back in
> the past, shows and lists was called forms and were created as way to
> transform the data. For me the couchapps are not the shows and list, not
> even these HTML5 apps that are a very limited view of what is possible.
> Couchapps are mostly script to render the data over an index. In my
> view we should ditch shows and lists to a concept of apps getting a
> request object when they are exposed to the web or just an environ when
> they are used as a script to extend the internal API (like redis
> scripts).
>
> In the mean time I continued to maintain and improve the versions of
> couchdb for ios and android, ported rcouch to different arm platforms
> (minicomputer, raspberry, ....) and helped to design some interresting
> systems using Couchdb to replicate a lot of data between mobiles and
> servers on different locations but also using couchdb as a message hub.
>
> If I would like today define couchdb based on my rcouch experience and
> the ports I did, I would say: "Apache Couchdb allows you to handle and
> synchronize your data between different locations and devices in quasi
> realtime over and on the web in a P2P manner without SPOF".
>
> So for me couchdb isn't only a database that replicate, it is also a way
> to ease the usage of your data, the way you can view them in your
> applications or directly on the web and over the web.
>
> - benoit
>
> [1] https://github.com/benoitc/afgwardiary
> [2] https://github.com/benoitc/nymphormation
> [3] https://github.com/refuge/rcouch/wiki
> [4] http://refuge.io
> [5] https://github.com/refuge/rcouch/wiki/refactoring
>
>
> On Wed, Jul 24, 2013 at 11:36 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> I have a dream…
>>
>> (pardon the plagiarism)
>>
>> I want to live in a world where people are empowered to understand
>> and are capable to decide where their data lives. I want to live in
>> a world where developers build apps that support that, not because
>> they went out of their way to implement it, but because it is a
>> feature of the software platform they are using.
>>
>> I want to be able to help people improve their lives in regions of
>> the world where ubiquitous network access isn’t — and sometimes that
>> is just a major western capital’s subway — but more likely is it a
>> lesser developed location, or a rural area that will never see mobile
>> broadband, let alone wired broadband because there is no financial
>> incentive.
>>
>> I want to live in a world where technology solves more problems than
>> it creates. One of those ways is allow people to use software wherever
>> they are in whatever context they need it in. More often than not,
>> that means far away from fast network access (Despite what @dhh is
>> trying to tell you).
>>
>> My primary motivation for working on Apache CouchDB is to help build
>> the world I want to live in. The same motivation drives my motivation
>> behind Hoodie (http://hood.ie), which builds on top of CouchDB and
>> wouldn’t be possible without it.
>>
>>
>> * * *
>>
>> In the past year I have interviewed a fair number of people, let’s
>> say 50, from those who have heard about CouchDB to users to core devs.
>>
>> The ONE feature that makes CouchDB relevant is multi-master replication.
>> There is no exception, this is the ONE thing that makes CouchDB
>> exceptional. NOBODY else has that, and even the decent proprietary
>> solutions that are just coming to market suck where we KICK ASS.
>>
>> There are many other things that people like about CouchDB: reliability,
>> no schema, HTTP interface, the view system, etc. But NONE of these people
>> would care if CouchDB didn’t have multi-master replication.
>>
>>
>> * * *
>>
>> The number one thing that people did NOT like about CouchDB is that it
>> is confused. CouchDB has a torn identity, half database, half
>> application server. It wasn’t clear (and I am part responsible for this)
>> what CouchDB is and wants to be. In everybody’s defence, I think, it
>> just took a while to figure it out. Now is a good time to put our
>> findings in writing and fix this.
>>
>> The number one request from people was to clear up CouchDB’s story,
>> to have a clear, bold vision that captures people and that they can
>> easily understand and share and support and move forward.
>>
>>
>> * * *
>>
>> Here is a narrative about what CouchDB has, that has formed in my head
>> in the past year. I have shared this with some people privately for some
>> feedback and they all liked it, so it has that going for it. I also tried
>> out bringing some of these issues up in presentations I have given, to
>> again great feedback.
>>
>> E.g.:
>>
>> http://www.youtube.com/watch?v=7mdG-iAizVc or
>> http://www.youtube.com/watch?v=edbi9jJZkpg
>>
>> Before I lay it out, I understand that I will be ruffling some feathers.
>> I think that is both necessary and healthy. I think the picture I am
>> going to paint will make a lot of people in the CouchDB community happy,
>> some with concessions, but I utterly and strongly believe that this
>> vision of what CouchDB is has the power to set the course for the next
>> five years of the project and attract a whole lot of new people both
>> as users and contributors.
>>
>>
>>
>> * * *
>>
>> CouchDB is a database that replicates.
>>
>> Think of it as git for your data-layer. Not in a sense where you manage
>> text files and diff and merge, but in the sense that you have a local
>> version of your data and one or multiple remote ones and you can
>> seamlessly move your data between them, back and forth and crossover.
>>
>> Imagine a local checkout of your data that you can work on, and then
>> share it with Lucie across the table, she finds some issues and fixes
>> up the data, and shares it with Tim across the room. Tim fixes two
>> more issues and you pull both their changes into your copy. We conclude
>> the whole thing is golden and we push it to staging, where our continuous
>> integration runs and decides that the data is good to go into production,
>> so it pushes it to production. There the data is picked up from various
>> clients, some mobile over there, some web over here, a backup system
>> in the Tokyo office…
>>
>> Or you have hospitals in remote regions in Africa that collect local
>> health data, like how many malaria infections a region has and they all
>> share their results over unreliable mobile connections and the data
>> still makes it eventually maybe with a few hours delay and the malaria
>> expert in the capital city sees an increased outbreak of some illness
>> and is able to send out medicine in time to arrive for the patients
>> to help. Where today the expert takes months to travel between the
>> hospitals to collect that data manually and find out that there was
>> a lethal outbreak two months ago and everybody died.
>>
>> (Somebody built this, CouchDB does save lives, I get teary every time
>> I tell this story (like now). Our work doesn’t get more noble than
>> this.)
>>
>> Or imagine millions of mobile users with access to terabytes of
>> data in the cloud, replicating the bits they need to their phones
>> and tablets, allowing super-fast low-latency access for a stellar
>> user experience, while giving access to sheer amounts of data and
>> allowing full write access on the mobile device to be replicated
>> back to the cloud when connections exist.
>>
>> (Our friends at Cloudant have a couple of those customers.)
>>
>>
>> That is the power of CouchDB.
>>
>>
>> * * *
>>
>> Replication is the PRIMARY feature of CouchDB. “is a database” means
>> “stores your data, safely and securely”, “that replicates” highlights
>> the primary feature.
>>
>> There are many more very cool features of CouchDB, even the details
>> on how we achieve reliability and data safety or how replication
>> works are mindblowingly cool. The simple HTTP interface, the JSON
>> store, the app-server features, map reduce views, all very excellent
>> things that make CouchDB unique, but it is very important to understand
>> that they are SECONDARY features.
>>
>>
>> * * *
>>
>> I want to learn from understanding what the PRIMARY and SECONDARY
>> features for CouchDB are. I already feel a bit bad about that the
>> PRIMARY ones are two (“a database” *and* “that replicates”), but I
>> think that is as little as it gets.
>>
>> I want CouchDB’s new identity to be a database that replicates. I want
>> to provide a slide deck for a “CouchDB in 25 minutes” presentation* that
>> everybody can take and give and customise, but I want that one of the
>> first things you say “CouchDB is a database that replicates”. I want
>> that if you ask anyone inside the CouchDB developer community (you!)
>> about what CouchDB is to answer “CouchDB is a database that replicates”
>> and then follow up explaining what we mean, and *then* add a few more
>> of the SECONDARY features that you particularly like.
>>
>> * https://dl.dropboxusercontent.com/u/82149/CouchDB-in-25-Minutes.pdf
>> Full talk at: http://vimeo.com/62599420 (sorry this one is German,
>> still trying to find an English version of this)
>>
>> I want that people who barely look at CouchDB comment on an unrelated
>> Hacker News thread write “…CouchDB is a database that replicates, maybe
>> that is a better fit for your problem”.
>>
>> I want that the CTO of the newly funded startup thinks “I seem to have
>> a replication problem to solve, maybe CouchDB can help.”
>>
>> I want to move CouchDB’s development forward, and when we ask ourselves
>> whether to add a feature, we run it by our PRIMARY feature set and ask
>> “does it support ‘CouchDB is a database that replicates’” and if it does
>> we go ahead and build it, and if it doesn’t we may consider it as a
>> SECONDARY feature, or we discard it altogether.
>>
>> (I don’t actually care what the final slogan will be, and please bike-shed
>> this to no avail, but it should capture what I mean with “CouchDB is a
>> database that replicates”, a phrase that we can burn into everybody’s
>> head that captures CouchDB’s PRIMARY feature, its PRIMARY value
>> proposition, the ONE thing that explains WHY we are excited about
>> CouchDB.)
>>
>>
>> * * *
>>
>> Now, you might be miffed that your pet feature didn’t make the PRIMARY
>> list.
>> Do not worry, I believe I have a solution for that.
>>
>> I have brought this up before, but I really do think the holy grail to all
>> this is a very well done plugin system that allows us to follow the “small
>> core, massive plugin repository” paradigm that other’s ever so successfully
>> pioneered.
>>
>> This allows us to focus on what CouchDB is for internal and external
>> communication, for roadmap discussions and attraction of developer talent.
>>
>> More importantly, it allows us to keep all the fringe things that makes
>> CouchDB so very appealing to a lot of different people. It also allows us
>> to open up development to people who feel intimidated working on core
>> CouchDB, but can easily write a little plugin or three (this is basically
>> me, I have like 20 branches on GitHub that are useful to maybe 5% of our
>> users and they don’t get used any).
>>
>> A wise person once said “Core is where features go to rot.”, and if you
>> look at a number of CouchDB features, you can see that we suffer from that.
>>
>> We need a kick-ass plugin system that allows us to easily create, publish,
>> maintain and update little pieces of code that allow our users to make
>> their CouchDB their own. (I am signing up to build that, but I will need
>> your help, there is a shit ton of work to do :)
>>
>>
>> * * *
>>
>> ALERT: OPINION (your opinion may differ and we need to hear it)
>>
>> There is a discussion we need to have what the “small core” means for
>> CouchDB. There is a discrepancy between the absolute minimum to fulfil
>> the “CouchDB is a database that replicates“ mantra and what would be
>> a useful-out-of-the-box product that our users could set up and be
>> productive with.
>>
>> My minimum set looks roughly like this:
>>
>> - core database management (crud dbs & json/mime-docs, clustering)
>> - remote & local replication
>> - MR-views & GeoCouch enabled by default (ideally abstracted
>> away with nice “query dsl”)
>> - HTTP interface
>> - Fu/Fauxton
>> - configuration
>> - stats
>> - docs
>> - plugin system with Erlang (and in the future JavaScript support
>> via Node.js)
>>
>> This makes for a useful CouchDB default setup.
>>
>> Everything else should be a plugin. A piece of code that can be installed
>> with a quick search and a click of a button in Futon (or a `curl`-call on
>> the HTTP interface). Not far away, definitely not “siberia” (if you get
>> the PHP reference), but close to the core and encouraged to be used.
>>
>> And yes, this explicitly includes things like shows and lists and update
>> functions and rewrites and vhosts. We should make it super simple to add
>> these, but for a default experience, they are very, very confusing. We
>> should have a single plugin “CouchApp Engine” which includes Benoit’s
>> vision of CouchApps done right that is just a click away to install.
>>
>> In terms of highlighting the strengths of the core CouchDB “product”, this
>> is what I’d put on the website:
>>
>> - Apache CouchDB implements the CouchDB vision:
>> It is a database that replicates.
>>
>> - Document Database:
>> - Data records are standard JSON.
>> - Unlimited Binary data storage with attachments.
>> - (alternatively arbitrary mime docs with special rules for JSON docs)
>>
>> - Fault-tolerant:
>> - Data is always safe. Tail-append storage ensures no messing with
>> already committed data.
>> - Errors are isolated, recovery is local and doesn’t affect other
>> parallel requests.
>> - Recovery of fatal errors is immediate. There is no “fixup phase”
>> after a restart.
>> - Software updates and bugfix deployment without downtime.
>>
>> - Highly Concurrent:
>> - Erlang makes good use of massively parallel network server
>> installations.
>> - Garbage collection happens roughly on a per-request basis.
>> GC in one request doesn’t affect other requests.
>>
>> - Cluster / BigCouch / Big Data:
>> - Includes a Dynamo-style clustering and cluster-management
>> feature that allows to spread data and load over multiple
>> physical machines.
>> - Scales up to Petabytes of data.
>>
>> - Secondary 2D and 3D indexing
>> - Using incremental and asynchronous index updates for
>> high-performance queries.
>>
>> - Makes good use of hardware:
>> - Tail-append storage allows for serial write access to
>> storage media, which is a best-case-scenario for spinning
>> disks and SSDs.
>>
>> - Small Core & Flexible Plugin System:
>> - Some features are only useful for a small group of people, these
>> can be installed with a super simple plugin management system that
>> is built into the admin interface.
>> - Get new features with a click or tap.
>> - Plugins can be written in Erlang (and in JavaScript in the future).
>>
>> - Cross Platform Support
>> - Runs on any POSIX UNIX as well as Windows.
>> - Support for some embedded devices like Android and RaspberryPi.
>>
>>
>> I think this would make for a compelling list of technical features.
>>
>> (I’d probably also add a blip about the ASF and the Apache 2.0 License
>> for good measure)
>>
>> ALERT END
>>
>>
>> * * *
>>
>> And then, CouchDB is one more thing. CouchDB isn’t just the Erlang
>> implementation of this whole replicating database idea. CouchDB is also
>> the wire protocol, the specification that makes all the magic work.
>> Apache CouchDB is the focal point for The Replicating Society*.
>>
>> (* cue your Blade Runner jokes)
>>
>> Apache CouchDB is THE standard for data freedom and exchange and is
>> the clearing house, the centre for an ecosystem that includes fantastic
>> projects like PouchDB and the TouchDBs, MAx Ogden’s `dat` and whichever
>> else follow these. Not saying we merge those projects in, they can stand
>> on their own, but we should embrace everything that makes the
>> interoperable replication world a reality.
>>
>> http://couchdb.apache.org is going to be the centre of the data
>> replication universe.
>>
>>
>> * * *
>>
>> Now all of this is my vision and I bringing it to this table now.
>> I have to admit that I am very nervous about this. A lot of things
>> aren’t very well thought out and at the same time, I care very
>> deeply about this project and it’s community and their future, so
>> there is a little anxiety doing this little emotional striptease
>> in front of all of you.
>>
>> What we will end up with, is not what I dream up and that’s that,
>> but I hope I can inform and set the direction of where we are going,
>> and then we can all together figure out the hard parts, and question
>> my assumptions and change little thing or lots.
>>
>> I don’t want to make this mine, but ours. To keep and to be proud of.
>>
>> The last thing I want is to stifle diversity, in thought and code,
>> and I am very sure that some of you will find a lot to disagree with
>> what I am saying, and that’s great, because this should, again, be
>> ours, not mine.
>>
>> But the one thing I am convinced of is the little pivot that this
>> project hinges on* between relative obscurity and blasting success
>> is that we need to find our version of a simplified, streamlined
>> and aligned way of defining, building and communicating what Apache
>> CouchDB is.
>>
>> (* I suck at metaphors)
>>
>> And yes that means that some thing that *YOU* think are important
>> are getting a second row seat instead of the front row. Heck even
>> some of my pet features get a second row seat, but that is fine
>> because they aren’t gone, there is still room for all the crazy
>> and not-so-crazy-but-not-essential stuff that people love in the
>> plugin system, one click away. All this so we can benefit from
>> being able to focus on building a modern, compelling, fun, humble
>> and clever database that we can build the future, our future, on.
>>
>>
>> * * *
>>
>> I want to live in a world where people are empowered to understand
>> and are capable to decide where their data lives.
>>
>>
>> I want to live in a world where technology solves more problems than
>> it creates.
>>
>>
>> My primary motivation for working on Apache CouchDB is to help build
>> the world I want to live in.
>>
>>
>> The ONE feature that makes CouchDB relevant is multi-master replication.
>>
>>
>> I want to learn from understanding what the PRIMARY and SECONDARY
>> features for CouchDB are.
>>
>>
>> Apache CouchDB is the focal point for The Replicating Society.
>>
>>
>> I don’t want to make this mine, but ours. To keep and to be proud of.
>>
>>
>> * * *
>>
>>
>> CouchDB is a database that replicates.
>>
>> I’m excited about your feedback! <3
>>
>> Sincerely,
>> Jan
>> --
>>
>>
>>
>>
>>
>>
>> Thanks to Noah for kicking off this way overdue discussion.
>>
>>
>> On Jul 24, 2013, at 15:28 , Noah Slater <ns...@apache.org> wrote:
>>
>>> Okay, here are some rough thoughts.
>>>
>>> Why?
>>>
>>> - We believe that distributed data should be easy
>>>
>>> How?
>>>
>>> - Painless multi-master replication
>>> - Effortless clustering and sharding
>>> - Co-location of data, queries, and views
>>> - Deep browser and platform integration
>>> - Built of the Web
>>>
>>> What?
>>>
>>> - Erlang
>>> - HTTP
>>> - JSON
>>> - JavaScript
>>> - MapReduce
>>>
>>> (That last list could go on, and on, and on...)
>>>
>>> Anyway. This is just a rough sketch of the sort of hierarchy I am
>> thinking
>>> about.
>>>
>>> Whatever this ends up looking like, I think this is how we should talk
>>> about CouchDB. This structure could be a template for anything. A talk, a
>>> sales pitch, the homepage itself. The important thing is that we start
>> from
>>> "why?" and we build up from foundations.
>>>
>>>
>>> On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
>>>
>>>> I'm trying to imagine what our "I have a dream" speech would be like for
>>>> CouchDB. If we were the Wright brothers, we might stand up and say "I
>> have
>>>> a dream that one day man will fly." We might say, "I have a dream that
>>>> distributed data will be easy." (I mean, that about covers it, right?
>>>> Doesn't have to be complex. The hard part is making sure we actually
>> focus
>>>> in on the root dream we all have.)
>>>>
>>>> Jan mentioned a few months ago that CouchDB almost wants to be the Git,
>>>> for databases. What is Git? What would Git's "dream" be? I can imagine
>>>> Linus saying "I have a dream that distributed version control will be
>>>> easy." Same sorta thing, right?
>>>>
>>>>
>>>> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
>>>>
>>>>> Benoit,
>>>>>
>>>>> You should defo watch that video and see what you think. Note that it
>>>>> does not matter if we are a company. This insight applies to companies,
>>>>> products, loose groups of people working towards one thing (like the
>> Wright
>>>>> brothers) and even individuals. (i.e. What is your personal "why" and
>> how
>>>>> are the things you are doing working towards that.)
>>>>>
>>>>> I also want to put you at ease by saying that having a single shared
>>>>> "why" doesn't mean that anybody's vision, or personal goals have to be
>> left
>>>>> by the wayside. People can still come to the project with their own
>> goals,
>>>>> and their own perspective. But the project itself should have a clear
>> sense
>>>>> of what we are trying to accomplish.
>>>>>
>>>>> I think the "why" we come up with can easily be something that inspires
>>>>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp
>> peeps,
>>>>> the "big data" peeps, the mobile platform peeps. Think about a why that
>>>>> might evolve out of "your data, everywhere". Who (in our existing
>>>>> communities) wouldn't love that and want to rally behind that? (But
>> this is
>>>>> just one idea.)
>>>>>
>>>>> Asking "what are the core features" misses the point. Why are these
>> core
>>>>> features? Why did we add them in the first place? What are we working
>>>>> towards? See, you hit on it in your final sentence: "relax we take care
>>>>> about your data and the way you exchange and render them wherever they
>>>>> are". This! This is the kind of thing that I think we should hone, and
>>>>> figure out, and document.
>>>>>
>>>>> Once we have that, it can inform our "how". When we're talking about
>>>>> features, about product direction (i.e. what we add, what we subtract)
>> we
>>>>> can say "well, how is this related to what we're trying to do here?"
>> Do you
>>>>> see what I mean? :)
>>>>>
>>>>> "Painless distributed systems" is also a step in the right direction
>> for
>>>>> answering the question "why?"
>>>>>
>>>>> So far we have:
>>>>>
>>>>> * Relax
>>>>> * Decentralised web
>>>>> * Peer-to-peer replication of apps and datasets
>>>>> * Your data, everywhere
>>>>> * Put the data where you need it
>>>>> * We handle your data / you handle display
>>>>> * Painless distributed systems
>>>>>
>>>>> Somewhere in here ^ (and perhaps in a follow up reply) is a single
>> shared
>>>>> value system. Something we all hold dear.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>
>>>>>> Anyway, CouchDB is not like apple or dell. This isn't a company. And
>> we
>>>>>> don't have to share all the same vision, but only common values, a
>> core.
>>>>>> I'm not sure it enter in the what you describe. What kind of vision
>> are
>>>>>> you
>>>>>> speaking about?
>>>>>>
>>>>>> Also I would remove any pro-tip from your mail if we want to start
>> from a
>>>>>> neutral base.
>>>>>>
>>>>>> Couchdb is known for the replication but not only. Couchapps and the
>> way
>>>>>> people hack around is another (hoodie, kanso, erica/ couchapp all
>>>>>> differents visions of what is a couchapp but all are using couchdb the
>>>>>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb
>> as a
>>>>>> message hub somehow, not only but a lot of their arch is based on
>>>>>> changes).
>>>>>> And now we we can add some kind of big data handling. Not forgetting
>>>>>> people
>>>>>> that are using apache couchdb on their mobile, they exists and the
>>>>>> patches
>>>>>> will be release.
>>>>>>
>>>>>> All have different visions. But they share some common features. I
>> don't
>>>>>> want to forget someone because of a vision of some. I only know that
>>>>>> couchdb has some strong features that could be improved.
>>>>>>
>>>>>> All that to say that rather than thinking to a vision, maybe we could
>>>>>> collect all the usages around and see what emerges from it. What are
>> the
>>>>>> core features, What couchdb should focus on and itterrate depending on
>>>>>> the
>>>>>> new usage. I guess it's some kind of philosophy: "relax we take care
>>>>>> about
>>>>>> your data and the way you exchange and render them wherever they are".
>>>>>>
>>>>>> - benoit
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org>
>> wrote:
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> I came across this video recently:
>>>>>>>
>>>>>>> Simon Sinek: How great leaders inspire action
>>>>>>>
>> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>>>>>>> In it he sets out what he calls the Golden Circle:
>>>>>>>
>>>>>>> Why
>>>>>>>
>>>>>>> - What's your purpose?
>>>>>>> - What's your cause?
>>>>>>> - What's your belief?
>>>>>>>
>>>>>>> How
>>>>>>>
>>>>>>> - How do we do it?
>>>>>>> - How does our product differentiate?
>>>>>>> - How are we different?
>>>>>>> - How are we better?
>>>>>>>
>>>>>>> What
>>>>>>>
>>>>>>> - What do we do?
>>>>>>> - What do we make?
>>>>>>>
>>>>>>> He points out that the difference between companies like Apple and
>>>>>>> companies like Dell.
>>>>>>>
>>>>>>> Dell tells you what they do, and how. "We make great computers.
>> They're
>>>>>>> well designed and work well. Wanna buy a computer?" Most companies do
>>>>>> it
>>>>>>> like this. But they often miss out the "why".
>>>>>>>
>>>>>>> But then you look at Apple, and they do it the other way around.
>> Apple
>>>>>> tell
>>>>>>> you what their purpose is. The rest is almost an afterthought. "We
>>>>>> believe
>>>>>>> in challenging the status quo. We believe in thinking different. We
>> do
>>>>>> that
>>>>>>> with great design and a focus on the user experience. We just happen
>> to
>>>>>>> make computers." He then joking quips: "Ready to buy one yet?"
>>>>>>>
>>>>>>> (His talk gives several other examples, with his thesis being that
>>>>>> telling
>>>>>>> your story from the outside in is what separates all the great
>>>>>> companies
>>>>>>> and leaders. One of his main examples is the Wright brothers.)
>>>>>>>
>>>>>>> He comments that if you talk about what you believe, you will attract
>>>>>> those
>>>>>>> that believe what you believe. That when you talk about what you
>>>>>> believe,
>>>>>>> people will join you for their own reasons, for their own purpose.
>> And
>>>>>> that
>>>>>>> what you do simply serves as proof of what you believe. Or as he
>> quips:
>>>>>>> "Martin Luther King gave his 'I have a dream' speech, not his 'i
>> have a
>>>>>>> plan' speech."
>>>>>>>
>>>>>>> Why am I bringing this to the dev list?
>>>>>>>
>>>>>>> Because our message stinks. "Apache CouchDB™ is a database that uses
>>>>>> JSON
>>>>>>> for documents, JavaScript for MapReduce queries, and regular HTTP for
>>>>>> an
>>>>>>> API" is a terrible way to introduce who we are, what we stand for,
>> and
>>>>>> why
>>>>>>> we build this thing. (And I'm allowed to say all that, because I'm
>> the
>>>>>> one
>>>>>>> who wrote it, with lots of help from Jan.)
>>>>>>>
>>>>>>> So what am I proposing? I'm proposing that we figure out our why.
>> That
>>>>>> we
>>>>>>> figure out what we stand for, what we believe in. And then we figure
>>>>>> out
>>>>>>> how we're gonna do that (pro tip: replication is more important than
>>>>>> the
>>>>>>> data format we use). Not only will this define a consistent internal
>>>>>> vision
>>>>>>> for the project (what *are* we working towards anyway?) but it will
>>>>>> help us
>>>>>>> to attract people who believe in what we believe.
>>>>>>>
>>>>>>> So, if you have any thoughts about this, speak up!
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --
>>>>>>> NS
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> NS
>>>>>
>>>>
>>>>
>>>> --
>>>> NS
>>>>
>>>
>>>
>>> --
>>> NS
>>
The needs and benefits and USP of Couchdb/rcouch/Bigcouch/spatial hybrid are different
and also the motivations for inclusion or exclusion and extension of any need or want is
different for SaaS and distributed or mobile application.
This makes it difficult to answer the superficially easy "why" question.
It is only the possibilities of the "how" and "what" questions that will answer the "why" in devastating unanswerable logic.
Refuge.io and Rcouch have the best "how", why?
--
David Martin
Re: What's our Why?
Posted by Benoit Chesneau <bc...@gmail.com>.
So even if Noah didn't noticed I finished my previous mail with this
kind of philosophy "relax we take care about your data and the way you
exchange and render them wherever they are". Of course it was without
the lyricism but it is defining the vision I have since the beginning
with couchdb modulo the fact that the replication wasn't existing at the
beginning. I join Jan for some parts. One sure thing is that you can't
separate the why from the how. Anyway let me share my own experience of
CouchDB, it will help somehow to explain why I am *using* Couchdb, and
*how* I envision it.
The first thing that interested me in couchdb was its simplicity of
usage and customization. An HTTP API, a small code base. The HTTP API is
more important than some are saying today. Of course we could use a
binary protocol it would be faster. But it is just a matter of time.
With HTTP 2.0 coming at the end of the year, the already working
implementations using SPDY, the HTTP couchdb api will be exchanged in
binary stream. Using couchdb over and on the web is really one of its
key features.
Anyway, when I started to use couchdb (long time ago) I created some
applications. One of the first was Friendpaste. The replication was
just starting to exist (or on the point to, I can't remember) and the
first reason I used CouchDB for Friendpaste was because it allowed me
to view/maps the documents to my application quite in an intuitive and
natural way. I didn't have to query them across multiple tables, simply
map them then query them to match some pattern. I didn't have to
organize them at first in tables or columns. I just had to store my
document and create views (index) on them. The views can be later edited
or edited, but the documents, the way I store the data don't change.
Which was perfectly fit the way I code, iterating over features ans
sometimes completely change the way I'm using/view the data in the code.
CouchDB was giving me way to manipulate data I didn't have since a
while, since I played with hypercard or lotus notes. A documented
oriented database by itself is a concept, a way to handler your data.
And couchdb has its own particular way to do it. Even copied like it
some databases I won't name it it is different. Incremented views and
the way couchdb is storing the data are designed for the new storages we
have today (ssds and others). All new databases that are designed today
are using such system. Of course it should be improved.
When the changes feeds were introduced in couchdb it was
revolutionnizing the way couchdb can be used and improved a lot the
replication. CouchDB was one of the first modern database to allow
anyone to listen on document changes and replicate them in a continuous
manner. At that time synchronization was not so trendy and there wasn't
many solutions allowing master-master replication. I created many
applications based on it since. One of them was the afgwardiary an
application to view the data leaked by wikileaks about the afghanistan
war [1], a couchapp entirely hosted in couchdb using geocouch to
manipulate the in formations This experimentation was really
interesting in the sense that it allowed people to exchange the leaked
data in a P2P fashion using the replication but also to render them.
That without installing anything but a patched couchdb with geocouch
(later becoming rcouch). I continued my experimentation with the
diplomatic cables.
Eventually, frustrated by the time it took to put the code in couchdb,
and the lack of real review (lot of devs were busy to do other things)
and also the need to have a database that I can easily deploy and
customize I forked couchdb to create rcouch [3]. Rcouch is part of a
more global project refuge [4].
In a sense, rcouch share the vision of Jan. To do rcouch I created a
couch core that can be extended by adding new erlang application and in
the new revision coming next week load/unload dynamically some plugins.
The rcouch core is articulated today in different apps: couch,
couch_changes, couch_stats, couch_replicator, couch_httpd, couch_index
and couch_mrview (which is based on couch_index). More details on the
wiki [5]. With rcouch are coming different extensions: refuge_spatial
(forked geocouch to work with latest couch core), random docs, db
updates... This core still has the shows and lists included. Not because
they are efficient, they aren't but because they are a pretty cool way
to manipulate/transform the data coming from the view index or the
database before sending them to your application or the user. Back in
the past, shows and lists was called forms and were created as way to
transform the data. For me the couchapps are not the shows and list, not
even these HTML5 apps that are a very limited view of what is possible.
Couchapps are mostly script to render the data over an index. In my
view we should ditch shows and lists to a concept of apps getting a
request object when they are exposed to the web or just an environ when
they are used as a script to extend the internal API (like redis
scripts).
In the mean time I continued to maintain and improve the versions of
couchdb for ios and android, ported rcouch to different arm platforms
(minicomputer, raspberry, ....) and helped to design some interresting
systems using Couchdb to replicate a lot of data between mobiles and
servers on different locations but also using couchdb as a message hub.
If I would like today define couchdb based on my rcouch experience and
the ports I did, I would say: "Apache Couchdb allows you to handle and
synchronize your data between different locations and devices in quasi
realtime over and on the web in a P2P manner without SPOF".
So for me couchdb isn't only a database that replicate, it is also a way
to ease the usage of your data, the way you can view them in your
applications or directly on the web and over the web.
- benoit
[1] https://github.com/benoitc/afgwardiary
[2] https://github.com/benoitc/nymphormation
[3] https://github.com/refuge/rcouch/wiki
[4] http://refuge.io
[5] https://github.com/refuge/rcouch/wiki/refactoring
On Wed, Jul 24, 2013 at 11:36 PM, Jan Lehnardt <ja...@apache.org> wrote:
> I have a dream…
>
> (pardon the plagiarism)
>
> I want to live in a world where people are empowered to understand
> and are capable to decide where their data lives. I want to live in
> a world where developers build apps that support that, not because
> they went out of their way to implement it, but because it is a
> feature of the software platform they are using.
>
> I want to be able to help people improve their lives in regions of
> the world where ubiquitous network access isn’t — and sometimes that
> is just a major western capital’s subway — but more likely is it a
> lesser developed location, or a rural area that will never see mobile
> broadband, let alone wired broadband because there is no financial
> incentive.
>
> I want to live in a world where technology solves more problems than
> it creates. One of those ways is allow people to use software wherever
> they are in whatever context they need it in. More often than not,
> that means far away from fast network access (Despite what @dhh is
> trying to tell you).
>
> My primary motivation for working on Apache CouchDB is to help build
> the world I want to live in. The same motivation drives my motivation
> behind Hoodie (http://hood.ie), which builds on top of CouchDB and
> wouldn’t be possible without it.
>
>
> * * *
>
> In the past year I have interviewed a fair number of people, let’s
> say 50, from those who have heard about CouchDB to users to core devs.
>
> The ONE feature that makes CouchDB relevant is multi-master replication.
> There is no exception, this is the ONE thing that makes CouchDB
> exceptional. NOBODY else has that, and even the decent proprietary
> solutions that are just coming to market suck where we KICK ASS.
>
> There are many other things that people like about CouchDB: reliability,
> no schema, HTTP interface, the view system, etc. But NONE of these people
> would care if CouchDB didn’t have multi-master replication.
>
>
> * * *
>
> The number one thing that people did NOT like about CouchDB is that it
> is confused. CouchDB has a torn identity, half database, half
> application server. It wasn’t clear (and I am part responsible for this)
> what CouchDB is and wants to be. In everybody’s defence, I think, it
> just took a while to figure it out. Now is a good time to put our
> findings in writing and fix this.
>
> The number one request from people was to clear up CouchDB’s story,
> to have a clear, bold vision that captures people and that they can
> easily understand and share and support and move forward.
>
>
> * * *
>
> Here is a narrative about what CouchDB has, that has formed in my head
> in the past year. I have shared this with some people privately for some
> feedback and they all liked it, so it has that going for it. I also tried
> out bringing some of these issues up in presentations I have given, to
> again great feedback.
>
> E.g.:
>
> http://www.youtube.com/watch?v=7mdG-iAizVc or
> http://www.youtube.com/watch?v=edbi9jJZkpg
>
> Before I lay it out, I understand that I will be ruffling some feathers.
> I think that is both necessary and healthy. I think the picture I am
> going to paint will make a lot of people in the CouchDB community happy,
> some with concessions, but I utterly and strongly believe that this
> vision of what CouchDB is has the power to set the course for the next
> five years of the project and attract a whole lot of new people both
> as users and contributors.
>
>
>
> * * *
>
> CouchDB is a database that replicates.
>
> Think of it as git for your data-layer. Not in a sense where you manage
> text files and diff and merge, but in the sense that you have a local
> version of your data and one or multiple remote ones and you can
> seamlessly move your data between them, back and forth and crossover.
>
> Imagine a local checkout of your data that you can work on, and then
> share it with Lucie across the table, she finds some issues and fixes
> up the data, and shares it with Tim across the room. Tim fixes two
> more issues and you pull both their changes into your copy. We conclude
> the whole thing is golden and we push it to staging, where our continuous
> integration runs and decides that the data is good to go into production,
> so it pushes it to production. There the data is picked up from various
> clients, some mobile over there, some web over here, a backup system
> in the Tokyo office…
>
> Or you have hospitals in remote regions in Africa that collect local
> health data, like how many malaria infections a region has and they all
> share their results over unreliable mobile connections and the data
> still makes it eventually maybe with a few hours delay and the malaria
> expert in the capital city sees an increased outbreak of some illness
> and is able to send out medicine in time to arrive for the patients
> to help. Where today the expert takes months to travel between the
> hospitals to collect that data manually and find out that there was
> a lethal outbreak two months ago and everybody died.
>
> (Somebody built this, CouchDB does save lives, I get teary every time
> I tell this story (like now). Our work doesn’t get more noble than
> this.)
>
> Or imagine millions of mobile users with access to terabytes of
> data in the cloud, replicating the bits they need to their phones
> and tablets, allowing super-fast low-latency access for a stellar
> user experience, while giving access to sheer amounts of data and
> allowing full write access on the mobile device to be replicated
> back to the cloud when connections exist.
>
> (Our friends at Cloudant have a couple of those customers.)
>
>
> That is the power of CouchDB.
>
>
> * * *
>
> Replication is the PRIMARY feature of CouchDB. “is a database” means
> “stores your data, safely and securely”, “that replicates” highlights
> the primary feature.
>
> There are many more very cool features of CouchDB, even the details
> on how we achieve reliability and data safety or how replication
> works are mindblowingly cool. The simple HTTP interface, the JSON
> store, the app-server features, map reduce views, all very excellent
> things that make CouchDB unique, but it is very important to understand
> that they are SECONDARY features.
>
>
> * * *
>
> I want to learn from understanding what the PRIMARY and SECONDARY
> features for CouchDB are. I already feel a bit bad about that the
> PRIMARY ones are two (“a database” *and* “that replicates”), but I
> think that is as little as it gets.
>
> I want CouchDB’s new identity to be a database that replicates. I want
> to provide a slide deck for a “CouchDB in 25 minutes” presentation* that
> everybody can take and give and customise, but I want that one of the
> first things you say “CouchDB is a database that replicates”. I want
> that if you ask anyone inside the CouchDB developer community (you!)
> about what CouchDB is to answer “CouchDB is a database that replicates”
> and then follow up explaining what we mean, and *then* add a few more
> of the SECONDARY features that you particularly like.
>
> * https://dl.dropboxusercontent.com/u/82149/CouchDB-in-25-Minutes.pdf
> Full talk at: http://vimeo.com/62599420 (sorry this one is German,
> still trying to find an English version of this)
>
> I want that people who barely look at CouchDB comment on an unrelated
> Hacker News thread write “…CouchDB is a database that replicates, maybe
> that is a better fit for your problem”.
>
> I want that the CTO of the newly funded startup thinks “I seem to have
> a replication problem to solve, maybe CouchDB can help.”
>
> I want to move CouchDB’s development forward, and when we ask ourselves
> whether to add a feature, we run it by our PRIMARY feature set and ask
> “does it support ‘CouchDB is a database that replicates’” and if it does
> we go ahead and build it, and if it doesn’t we may consider it as a
> SECONDARY feature, or we discard it altogether.
>
> (I don’t actually care what the final slogan will be, and please bike-shed
> this to no avail, but it should capture what I mean with “CouchDB is a
> database that replicates”, a phrase that we can burn into everybody’s
> head that captures CouchDB’s PRIMARY feature, its PRIMARY value
> proposition, the ONE thing that explains WHY we are excited about
> CouchDB.)
>
>
> * * *
>
> Now, you might be miffed that your pet feature didn’t make the PRIMARY
> list.
> Do not worry, I believe I have a solution for that.
>
> I have brought this up before, but I really do think the holy grail to all
> this is a very well done plugin system that allows us to follow the “small
> core, massive plugin repository” paradigm that other’s ever so successfully
> pioneered.
>
> This allows us to focus on what CouchDB is for internal and external
> communication, for roadmap discussions and attraction of developer talent.
>
> More importantly, it allows us to keep all the fringe things that makes
> CouchDB so very appealing to a lot of different people. It also allows us
> to open up development to people who feel intimidated working on core
> CouchDB, but can easily write a little plugin or three (this is basically
> me, I have like 20 branches on GitHub that are useful to maybe 5% of our
> users and they don’t get used any).
>
> A wise person once said “Core is where features go to rot.”, and if you
> look at a number of CouchDB features, you can see that we suffer from that.
>
> We need a kick-ass plugin system that allows us to easily create, publish,
> maintain and update little pieces of code that allow our users to make
> their CouchDB their own. (I am signing up to build that, but I will need
> your help, there is a shit ton of work to do :)
>
>
> * * *
>
> ALERT: OPINION (your opinion may differ and we need to hear it)
>
> There is a discussion we need to have what the “small core” means for
> CouchDB. There is a discrepancy between the absolute minimum to fulfil
> the “CouchDB is a database that replicates“ mantra and what would be
> a useful-out-of-the-box product that our users could set up and be
> productive with.
>
> My minimum set looks roughly like this:
>
> - core database management (crud dbs & json/mime-docs, clustering)
> - remote & local replication
> - MR-views & GeoCouch enabled by default (ideally abstracted
> away with nice “query dsl”)
> - HTTP interface
> - Fu/Fauxton
> - configuration
> - stats
> - docs
> - plugin system with Erlang (and in the future JavaScript support
> via Node.js)
>
> This makes for a useful CouchDB default setup.
>
> Everything else should be a plugin. A piece of code that can be installed
> with a quick search and a click of a button in Futon (or a `curl`-call on
> the HTTP interface). Not far away, definitely not “siberia” (if you get
> the PHP reference), but close to the core and encouraged to be used.
>
> And yes, this explicitly includes things like shows and lists and update
> functions and rewrites and vhosts. We should make it super simple to add
> these, but for a default experience, they are very, very confusing. We
> should have a single plugin “CouchApp Engine” which includes Benoit’s
> vision of CouchApps done right that is just a click away to install.
>
> In terms of highlighting the strengths of the core CouchDB “product”, this
> is what I’d put on the website:
>
> - Apache CouchDB implements the CouchDB vision:
> It is a database that replicates.
>
> - Document Database:
> - Data records are standard JSON.
> - Unlimited Binary data storage with attachments.
> - (alternatively arbitrary mime docs with special rules for JSON docs)
>
> - Fault-tolerant:
> - Data is always safe. Tail-append storage ensures no messing with
> already committed data.
> - Errors are isolated, recovery is local and doesn’t affect other
> parallel requests.
> - Recovery of fatal errors is immediate. There is no “fixup phase”
> after a restart.
> - Software updates and bugfix deployment without downtime.
>
> - Highly Concurrent:
> - Erlang makes good use of massively parallel network server
> installations.
> - Garbage collection happens roughly on a per-request basis.
> GC in one request doesn’t affect other requests.
>
> - Cluster / BigCouch / Big Data:
> - Includes a Dynamo-style clustering and cluster-management
> feature that allows to spread data and load over multiple
> physical machines.
> - Scales up to Petabytes of data.
>
> - Secondary 2D and 3D indexing
> - Using incremental and asynchronous index updates for
> high-performance queries.
>
> - Makes good use of hardware:
> - Tail-append storage allows for serial write access to
> storage media, which is a best-case-scenario for spinning
> disks and SSDs.
>
> - Small Core & Flexible Plugin System:
> - Some features are only useful for a small group of people, these
> can be installed with a super simple plugin management system that
> is built into the admin interface.
> - Get new features with a click or tap.
> - Plugins can be written in Erlang (and in JavaScript in the future).
>
> - Cross Platform Support
> - Runs on any POSIX UNIX as well as Windows.
> - Support for some embedded devices like Android and RaspberryPi.
>
>
> I think this would make for a compelling list of technical features.
>
> (I’d probably also add a blip about the ASF and the Apache 2.0 License
> for good measure)
>
> ALERT END
>
>
> * * *
>
> And then, CouchDB is one more thing. CouchDB isn’t just the Erlang
> implementation of this whole replicating database idea. CouchDB is also
> the wire protocol, the specification that makes all the magic work.
> Apache CouchDB is the focal point for The Replicating Society*.
>
> (* cue your Blade Runner jokes)
>
> Apache CouchDB is THE standard for data freedom and exchange and is
> the clearing house, the centre for an ecosystem that includes fantastic
> projects like PouchDB and the TouchDBs, MAx Ogden’s `dat` and whichever
> else follow these. Not saying we merge those projects in, they can stand
> on their own, but we should embrace everything that makes the
> interoperable replication world a reality.
>
> http://couchdb.apache.org is going to be the centre of the data
> replication universe.
>
>
> * * *
>
> Now all of this is my vision and I bringing it to this table now.
> I have to admit that I am very nervous about this. A lot of things
> aren’t very well thought out and at the same time, I care very
> deeply about this project and it’s community and their future, so
> there is a little anxiety doing this little emotional striptease
> in front of all of you.
>
> What we will end up with, is not what I dream up and that’s that,
> but I hope I can inform and set the direction of where we are going,
> and then we can all together figure out the hard parts, and question
> my assumptions and change little thing or lots.
>
> I don’t want to make this mine, but ours. To keep and to be proud of.
>
> The last thing I want is to stifle diversity, in thought and code,
> and I am very sure that some of you will find a lot to disagree with
> what I am saying, and that’s great, because this should, again, be
> ours, not mine.
>
> But the one thing I am convinced of is the little pivot that this
> project hinges on* between relative obscurity and blasting success
> is that we need to find our version of a simplified, streamlined
> and aligned way of defining, building and communicating what Apache
> CouchDB is.
>
> (* I suck at metaphors)
>
> And yes that means that some thing that *YOU* think are important
> are getting a second row seat instead of the front row. Heck even
> some of my pet features get a second row seat, but that is fine
> because they aren’t gone, there is still room for all the crazy
> and not-so-crazy-but-not-essential stuff that people love in the
> plugin system, one click away. All this so we can benefit from
> being able to focus on building a modern, compelling, fun, humble
> and clever database that we can build the future, our future, on.
>
>
> * * *
>
> I want to live in a world where people are empowered to understand
> and are capable to decide where their data lives.
>
>
> I want to live in a world where technology solves more problems than
> it creates.
>
>
> My primary motivation for working on Apache CouchDB is to help build
> the world I want to live in.
>
>
> The ONE feature that makes CouchDB relevant is multi-master replication.
>
>
> I want to learn from understanding what the PRIMARY and SECONDARY
> features for CouchDB are.
>
>
> Apache CouchDB is the focal point for The Replicating Society.
>
>
> I don’t want to make this mine, but ours. To keep and to be proud of.
>
>
> * * *
>
>
> CouchDB is a database that replicates.
>
> I’m excited about your feedback! <3
>
> Sincerely,
> Jan
> --
>
>
>
>
>
>
> Thanks to Noah for kicking off this way overdue discussion.
>
>
> On Jul 24, 2013, at 15:28 , Noah Slater <ns...@apache.org> wrote:
>
> > Okay, here are some rough thoughts.
> >
> > Why?
> >
> > - We believe that distributed data should be easy
> >
> > How?
> >
> > - Painless multi-master replication
> > - Effortless clustering and sharding
> > - Co-location of data, queries, and views
> > - Deep browser and platform integration
> > - Built of the Web
> >
> > What?
> >
> > - Erlang
> > - HTTP
> > - JSON
> > - JavaScript
> > - MapReduce
> >
> > (That last list could go on, and on, and on...)
> >
> > Anyway. This is just a rough sketch of the sort of hierarchy I am
> thinking
> > about.
> >
> > Whatever this ends up looking like, I think this is how we should talk
> > about CouchDB. This structure could be a template for anything. A talk, a
> > sales pitch, the homepage itself. The important thing is that we start
> from
> > "why?" and we build up from foundations.
> >
> >
> > On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
> >
> >> I'm trying to imagine what our "I have a dream" speech would be like for
> >> CouchDB. If we were the Wright brothers, we might stand up and say "I
> have
> >> a dream that one day man will fly." We might say, "I have a dream that
> >> distributed data will be easy." (I mean, that about covers it, right?
> >> Doesn't have to be complex. The hard part is making sure we actually
> focus
> >> in on the root dream we all have.)
> >>
> >> Jan mentioned a few months ago that CouchDB almost wants to be the Git,
> >> for databases. What is Git? What would Git's "dream" be? I can imagine
> >> Linus saying "I have a dream that distributed version control will be
> >> easy." Same sorta thing, right?
> >>
> >>
> >> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
> >>
> >>> Benoit,
> >>>
> >>> You should defo watch that video and see what you think. Note that it
> >>> does not matter if we are a company. This insight applies to companies,
> >>> products, loose groups of people working towards one thing (like the
> Wright
> >>> brothers) and even individuals. (i.e. What is your personal "why" and
> how
> >>> are the things you are doing working towards that.)
> >>>
> >>> I also want to put you at ease by saying that having a single shared
> >>> "why" doesn't mean that anybody's vision, or personal goals have to be
> left
> >>> by the wayside. People can still come to the project with their own
> goals,
> >>> and their own perspective. But the project itself should have a clear
> sense
> >>> of what we are trying to accomplish.
> >>>
> >>> I think the "why" we come up with can easily be something that inspires
> >>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp
> peeps,
> >>> the "big data" peeps, the mobile platform peeps. Think about a why that
> >>> might evolve out of "your data, everywhere". Who (in our existing
> >>> communities) wouldn't love that and want to rally behind that? (But
> this is
> >>> just one idea.)
> >>>
> >>> Asking "what are the core features" misses the point. Why are these
> core
> >>> features? Why did we add them in the first place? What are we working
> >>> towards? See, you hit on it in your final sentence: "relax we take care
> >>> about your data and the way you exchange and render them wherever they
> >>> are". This! This is the kind of thing that I think we should hone, and
> >>> figure out, and document.
> >>>
> >>> Once we have that, it can inform our "how". When we're talking about
> >>> features, about product direction (i.e. what we add, what we subtract)
> we
> >>> can say "well, how is this related to what we're trying to do here?"
> Do you
> >>> see what I mean? :)
> >>>
> >>> "Painless distributed systems" is also a step in the right direction
> for
> >>> answering the question "why?"
> >>>
> >>> So far we have:
> >>>
> >>> * Relax
> >>> * Decentralised web
> >>> * Peer-to-peer replication of apps and datasets
> >>> * Your data, everywhere
> >>> * Put the data where you need it
> >>> * We handle your data / you handle display
> >>> * Painless distributed systems
> >>>
> >>> Somewhere in here ^ (and perhaps in a follow up reply) is a single
> shared
> >>> value system. Something we all hold dear.
> >>>
> >>>
> >>>
> >>>
> >>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
> >>>
> >>>> Anyway, CouchDB is not like apple or dell. This isn't a company. And
> we
> >>>> don't have to share all the same vision, but only common values, a
> core.
> >>>> I'm not sure it enter in the what you describe. What kind of vision
> are
> >>>> you
> >>>> speaking about?
> >>>>
> >>>> Also I would remove any pro-tip from your mail if we want to start
> from a
> >>>> neutral base.
> >>>>
> >>>> Couchdb is known for the replication but not only. Couchapps and the
> way
> >>>> people hack around is another (hoodie, kanso, erica/ couchapp all
> >>>> differents visions of what is a couchapp but all are using couchdb the
> >>>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb
> as a
> >>>> message hub somehow, not only but a lot of their arch is based on
> >>>> changes).
> >>>> And now we we can add some kind of big data handling. Not forgetting
> >>>> people
> >>>> that are using apache couchdb on their mobile, they exists and the
> >>>> patches
> >>>> will be release.
> >>>>
> >>>> All have different visions. But they share some common features. I
> don't
> >>>> want to forget someone because of a vision of some. I only know that
> >>>> couchdb has some strong features that could be improved.
> >>>>
> >>>> All that to say that rather than thinking to a vision, maybe we could
> >>>> collect all the usages around and see what emerges from it. What are
> the
> >>>> core features, What couchdb should focus on and itterrate depending on
> >>>> the
> >>>> new usage. I guess it's some kind of philosophy: "relax we take care
> >>>> about
> >>>> your data and the way you exchange and render them wherever they are".
> >>>>
> >>>> - benoit
> >>>>
> >>>>
> >>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org>
> wrote:
> >>>>
> >>>>> Hi devs,
> >>>>>
> >>>>> I came across this video recently:
> >>>>>
> >>>>> Simon Sinek: How great leaders inspire action
> >>>>>
> >>>>
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
> >>>>>
> >>>>> In it he sets out what he calls the Golden Circle:
> >>>>>
> >>>>> Why
> >>>>>
> >>>>> - What's your purpose?
> >>>>> - What's your cause?
> >>>>> - What's your belief?
> >>>>>
> >>>>> How
> >>>>>
> >>>>> - How do we do it?
> >>>>> - How does our product differentiate?
> >>>>> - How are we different?
> >>>>> - How are we better?
> >>>>>
> >>>>> What
> >>>>>
> >>>>> - What do we do?
> >>>>> - What do we make?
> >>>>>
> >>>>> He points out that the difference between companies like Apple and
> >>>>> companies like Dell.
> >>>>>
> >>>>> Dell tells you what they do, and how. "We make great computers.
> They're
> >>>>> well designed and work well. Wanna buy a computer?" Most companies do
> >>>> it
> >>>>> like this. But they often miss out the "why".
> >>>>>
> >>>>> But then you look at Apple, and they do it the other way around.
> Apple
> >>>> tell
> >>>>> you what their purpose is. The rest is almost an afterthought. "We
> >>>> believe
> >>>>> in challenging the status quo. We believe in thinking different. We
> do
> >>>> that
> >>>>> with great design and a focus on the user experience. We just happen
> to
> >>>>> make computers." He then joking quips: "Ready to buy one yet?"
> >>>>>
> >>>>> (His talk gives several other examples, with his thesis being that
> >>>> telling
> >>>>> your story from the outside in is what separates all the great
> >>>> companies
> >>>>> and leaders. One of his main examples is the Wright brothers.)
> >>>>>
> >>>>> He comments that if you talk about what you believe, you will attract
> >>>> those
> >>>>> that believe what you believe. That when you talk about what you
> >>>> believe,
> >>>>> people will join you for their own reasons, for their own purpose.
> And
> >>>> that
> >>>>> what you do simply serves as proof of what you believe. Or as he
> quips:
> >>>>> "Martin Luther King gave his 'I have a dream' speech, not his 'i
> have a
> >>>>> plan' speech."
> >>>>>
> >>>>> Why am I bringing this to the dev list?
> >>>>>
> >>>>> Because our message stinks. "Apache CouchDB™ is a database that uses
> >>>> JSON
> >>>>> for documents, JavaScript for MapReduce queries, and regular HTTP for
> >>>> an
> >>>>> API" is a terrible way to introduce who we are, what we stand for,
> and
> >>>> why
> >>>>> we build this thing. (And I'm allowed to say all that, because I'm
> the
> >>>> one
> >>>>> who wrote it, with lots of help from Jan.)
> >>>>>
> >>>>> So what am I proposing? I'm proposing that we figure out our why.
> That
> >>>> we
> >>>>> figure out what we stand for, what we believe in. And then we figure
> >>>> out
> >>>>> how we're gonna do that (pro tip: replication is more important than
> >>>> the
> >>>>> data format we use). Not only will this define a consistent internal
> >>>> vision
> >>>>> for the project (what *are* we working towards anyway?) but it will
> >>>> help us
> >>>>> to attract people who believe in what we believe.
> >>>>>
> >>>>> So, if you have any thoughts about this, speak up!
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> --
> >>>>> NS
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> NS
> >>>
> >>
> >>
> >>
> >> --
> >> NS
> >>
> >
> >
> >
> > --
> > NS
>
>
Re: What's our Why?
Posted by Jan Lehnardt <ja...@apache.org>.
I have a dream…
(pardon the plagiarism)
I want to live in a world where people are empowered to understand
and are capable to decide where their data lives. I want to live in
a world where developers build apps that support that, not because
they went out of their way to implement it, but because it is a
feature of the software platform they are using.
I want to be able to help people improve their lives in regions of
the world where ubiquitous network access isn’t — and sometimes that
is just a major western capital’s subway — but more likely is it a
lesser developed location, or a rural area that will never see mobile
broadband, let alone wired broadband because there is no financial
incentive.
I want to live in a world where technology solves more problems than
it creates. One of those ways is allow people to use software wherever
they are in whatever context they need it in. More often than not,
that means far away from fast network access (Despite what @dhh is
trying to tell you).
My primary motivation for working on Apache CouchDB is to help build
the world I want to live in. The same motivation drives my motivation
behind Hoodie (http://hood.ie), which builds on top of CouchDB and
wouldn’t be possible without it.
* * *
In the past year I have interviewed a fair number of people, let’s
say 50, from those who have heard about CouchDB to users to core devs.
The ONE feature that makes CouchDB relevant is multi-master replication.
There is no exception, this is the ONE thing that makes CouchDB
exceptional. NOBODY else has that, and even the decent proprietary
solutions that are just coming to market suck where we KICK ASS.
There are many other things that people like about CouchDB: reliability,
no schema, HTTP interface, the view system, etc. But NONE of these people
would care if CouchDB didn’t have multi-master replication.
* * *
The number one thing that people did NOT like about CouchDB is that it
is confused. CouchDB has a torn identity, half database, half
application server. It wasn’t clear (and I am part responsible for this)
what CouchDB is and wants to be. In everybody’s defence, I think, it
just took a while to figure it out. Now is a good time to put our
findings in writing and fix this.
The number one request from people was to clear up CouchDB’s story,
to have a clear, bold vision that captures people and that they can
easily understand and share and support and move forward.
* * *
Here is a narrative about what CouchDB has, that has formed in my head
in the past year. I have shared this with some people privately for some
feedback and they all liked it, so it has that going for it. I also tried
out bringing some of these issues up in presentations I have given, to
again great feedback.
E.g.:
http://www.youtube.com/watch?v=7mdG-iAizVc or
http://www.youtube.com/watch?v=edbi9jJZkpg
Before I lay it out, I understand that I will be ruffling some feathers.
I think that is both necessary and healthy. I think the picture I am
going to paint will make a lot of people in the CouchDB community happy,
some with concessions, but I utterly and strongly believe that this
vision of what CouchDB is has the power to set the course for the next
five years of the project and attract a whole lot of new people both
as users and contributors.
* * *
CouchDB is a database that replicates.
Think of it as git for your data-layer. Not in a sense where you manage
text files and diff and merge, but in the sense that you have a local
version of your data and one or multiple remote ones and you can
seamlessly move your data between them, back and forth and crossover.
Imagine a local checkout of your data that you can work on, and then
share it with Lucie across the table, she finds some issues and fixes
up the data, and shares it with Tim across the room. Tim fixes two
more issues and you pull both their changes into your copy. We conclude
the whole thing is golden and we push it to staging, where our continuous
integration runs and decides that the data is good to go into production,
so it pushes it to production. There the data is picked up from various
clients, some mobile over there, some web over here, a backup system
in the Tokyo office…
Or you have hospitals in remote regions in Africa that collect local
health data, like how many malaria infections a region has and they all
share their results over unreliable mobile connections and the data
still makes it eventually maybe with a few hours delay and the malaria
expert in the capital city sees an increased outbreak of some illness
and is able to send out medicine in time to arrive for the patients
to help. Where today the expert takes months to travel between the
hospitals to collect that data manually and find out that there was
a lethal outbreak two months ago and everybody died.
(Somebody built this, CouchDB does save lives, I get teary every time
I tell this story (like now). Our work doesn’t get more noble than
this.)
Or imagine millions of mobile users with access to terabytes of
data in the cloud, replicating the bits they need to their phones
and tablets, allowing super-fast low-latency access for a stellar
user experience, while giving access to sheer amounts of data and
allowing full write access on the mobile device to be replicated
back to the cloud when connections exist.
(Our friends at Cloudant have a couple of those customers.)
That is the power of CouchDB.
* * *
Replication is the PRIMARY feature of CouchDB. “is a database” means
“stores your data, safely and securely”, “that replicates” highlights
the primary feature.
There are many more very cool features of CouchDB, even the details
on how we achieve reliability and data safety or how replication
works are mindblowingly cool. The simple HTTP interface, the JSON
store, the app-server features, map reduce views, all very excellent
things that make CouchDB unique, but it is very important to understand
that they are SECONDARY features.
* * *
I want to learn from understanding what the PRIMARY and SECONDARY
features for CouchDB are. I already feel a bit bad about that the
PRIMARY ones are two (“a database” *and* “that replicates”), but I
think that is as little as it gets.
I want CouchDB’s new identity to be a database that replicates. I want
to provide a slide deck for a “CouchDB in 25 minutes” presentation* that
everybody can take and give and customise, but I want that one of the
first things you say “CouchDB is a database that replicates”. I want
that if you ask anyone inside the CouchDB developer community (you!)
about what CouchDB is to answer “CouchDB is a database that replicates”
and then follow up explaining what we mean, and *then* add a few more
of the SECONDARY features that you particularly like.
* https://dl.dropboxusercontent.com/u/82149/CouchDB-in-25-Minutes.pdf
Full talk at: http://vimeo.com/62599420 (sorry this one is German,
still trying to find an English version of this)
I want that people who barely look at CouchDB comment on an unrelated
Hacker News thread write “…CouchDB is a database that replicates, maybe
that is a better fit for your problem”.
I want that the CTO of the newly funded startup thinks “I seem to have
a replication problem to solve, maybe CouchDB can help.”
I want to move CouchDB’s development forward, and when we ask ourselves
whether to add a feature, we run it by our PRIMARY feature set and ask
“does it support ‘CouchDB is a database that replicates’” and if it does
we go ahead and build it, and if it doesn’t we may consider it as a
SECONDARY feature, or we discard it altogether.
(I don’t actually care what the final slogan will be, and please bike-shed
this to no avail, but it should capture what I mean with “CouchDB is a
database that replicates”, a phrase that we can burn into everybody’s
head that captures CouchDB’s PRIMARY feature, its PRIMARY value
proposition, the ONE thing that explains WHY we are excited about
CouchDB.)
* * *
Now, you might be miffed that your pet feature didn’t make the PRIMARY list.
Do not worry, I believe I have a solution for that.
I have brought this up before, but I really do think the holy grail to all
this is a very well done plugin system that allows us to follow the “small
core, massive plugin repository” paradigm that other’s ever so successfully
pioneered.
This allows us to focus on what CouchDB is for internal and external
communication, for roadmap discussions and attraction of developer talent.
More importantly, it allows us to keep all the fringe things that makes
CouchDB so very appealing to a lot of different people. It also allows us
to open up development to people who feel intimidated working on core
CouchDB, but can easily write a little plugin or three (this is basically
me, I have like 20 branches on GitHub that are useful to maybe 5% of our
users and they don’t get used any).
A wise person once said “Core is where features go to rot.”, and if you
look at a number of CouchDB features, you can see that we suffer from that.
We need a kick-ass plugin system that allows us to easily create, publish,
maintain and update little pieces of code that allow our users to make
their CouchDB their own. (I am signing up to build that, but I will need
your help, there is a shit ton of work to do :)
* * *
ALERT: OPINION (your opinion may differ and we need to hear it)
There is a discussion we need to have what the “small core” means for
CouchDB. There is a discrepancy between the absolute minimum to fulfil
the “CouchDB is a database that replicates“ mantra and what would be
a useful-out-of-the-box product that our users could set up and be
productive with.
My minimum set looks roughly like this:
- core database management (crud dbs & json/mime-docs, clustering)
- remote & local replication
- MR-views & GeoCouch enabled by default (ideally abstracted
away with nice “query dsl”)
- HTTP interface
- Fu/Fauxton
- configuration
- stats
- docs
- plugin system with Erlang (and in the future JavaScript support
via Node.js)
This makes for a useful CouchDB default setup.
Everything else should be a plugin. A piece of code that can be installed
with a quick search and a click of a button in Futon (or a `curl`-call on
the HTTP interface). Not far away, definitely not “siberia” (if you get
the PHP reference), but close to the core and encouraged to be used.
And yes, this explicitly includes things like shows and lists and update
functions and rewrites and vhosts. We should make it super simple to add
these, but for a default experience, they are very, very confusing. We
should have a single plugin “CouchApp Engine” which includes Benoit’s
vision of CouchApps done right that is just a click away to install.
In terms of highlighting the strengths of the core CouchDB “product”, this
is what I’d put on the website:
- Apache CouchDB implements the CouchDB vision:
It is a database that replicates.
- Document Database:
- Data records are standard JSON.
- Unlimited Binary data storage with attachments.
- (alternatively arbitrary mime docs with special rules for JSON docs)
- Fault-tolerant:
- Data is always safe. Tail-append storage ensures no messing with
already committed data.
- Errors are isolated, recovery is local and doesn’t affect other
parallel requests.
- Recovery of fatal errors is immediate. There is no “fixup phase”
after a restart.
- Software updates and bugfix deployment without downtime.
- Highly Concurrent:
- Erlang makes good use of massively parallel network server
installations.
- Garbage collection happens roughly on a per-request basis.
GC in one request doesn’t affect other requests.
- Cluster / BigCouch / Big Data:
- Includes a Dynamo-style clustering and cluster-management
feature that allows to spread data and load over multiple
physical machines.
- Scales up to Petabytes of data.
- Secondary 2D and 3D indexing
- Using incremental and asynchronous index updates for
high-performance queries.
- Makes good use of hardware:
- Tail-append storage allows for serial write access to
storage media, which is a best-case-scenario for spinning
disks and SSDs.
- Small Core & Flexible Plugin System:
- Some features are only useful for a small group of people, these
can be installed with a super simple plugin management system that
is built into the admin interface.
- Get new features with a click or tap.
- Plugins can be written in Erlang (and in JavaScript in the future).
- Cross Platform Support
- Runs on any POSIX UNIX as well as Windows.
- Support for some embedded devices like Android and RaspberryPi.
I think this would make for a compelling list of technical features.
(I’d probably also add a blip about the ASF and the Apache 2.0 License
for good measure)
ALERT END
* * *
And then, CouchDB is one more thing. CouchDB isn’t just the Erlang
implementation of this whole replicating database idea. CouchDB is also
the wire protocol, the specification that makes all the magic work.
Apache CouchDB is the focal point for The Replicating Society*.
(* cue your Blade Runner jokes)
Apache CouchDB is THE standard for data freedom and exchange and is
the clearing house, the centre for an ecosystem that includes fantastic
projects like PouchDB and the TouchDBs, MAx Ogden’s `dat` and whichever
else follow these. Not saying we merge those projects in, they can stand
on their own, but we should embrace everything that makes the
interoperable replication world a reality.
http://couchdb.apache.org is going to be the centre of the data
replication universe.
* * *
Now all of this is my vision and I bringing it to this table now.
I have to admit that I am very nervous about this. A lot of things
aren’t very well thought out and at the same time, I care very
deeply about this project and it’s community and their future, so
there is a little anxiety doing this little emotional striptease
in front of all of you.
What we will end up with, is not what I dream up and that’s that,
but I hope I can inform and set the direction of where we are going,
and then we can all together figure out the hard parts, and question
my assumptions and change little thing or lots.
I don’t want to make this mine, but ours. To keep and to be proud of.
The last thing I want is to stifle diversity, in thought and code,
and I am very sure that some of you will find a lot to disagree with
what I am saying, and that’s great, because this should, again, be
ours, not mine.
But the one thing I am convinced of is the little pivot that this
project hinges on* between relative obscurity and blasting success
is that we need to find our version of a simplified, streamlined
and aligned way of defining, building and communicating what Apache
CouchDB is.
(* I suck at metaphors)
And yes that means that some thing that *YOU* think are important
are getting a second row seat instead of the front row. Heck even
some of my pet features get a second row seat, but that is fine
because they aren’t gone, there is still room for all the crazy
and not-so-crazy-but-not-essential stuff that people love in the
plugin system, one click away. All this so we can benefit from
being able to focus on building a modern, compelling, fun, humble
and clever database that we can build the future, our future, on.
* * *
I want to live in a world where people are empowered to understand
and are capable to decide where their data lives.
I want to live in a world where technology solves more problems than
it creates.
My primary motivation for working on Apache CouchDB is to help build
the world I want to live in.
The ONE feature that makes CouchDB relevant is multi-master replication.
I want to learn from understanding what the PRIMARY and SECONDARY
features for CouchDB are.
Apache CouchDB is the focal point for The Replicating Society.
I don’t want to make this mine, but ours. To keep and to be proud of.
* * *
CouchDB is a database that replicates.
I’m excited about your feedback! <3
Sincerely,
Jan
--
Thanks to Noah for kicking off this way overdue discussion.
On Jul 24, 2013, at 15:28 , Noah Slater <ns...@apache.org> wrote:
> Okay, here are some rough thoughts.
>
> Why?
>
> - We believe that distributed data should be easy
>
> How?
>
> - Painless multi-master replication
> - Effortless clustering and sharding
> - Co-location of data, queries, and views
> - Deep browser and platform integration
> - Built of the Web
>
> What?
>
> - Erlang
> - HTTP
> - JSON
> - JavaScript
> - MapReduce
>
> (That last list could go on, and on, and on...)
>
> Anyway. This is just a rough sketch of the sort of hierarchy I am thinking
> about.
>
> Whatever this ends up looking like, I think this is how we should talk
> about CouchDB. This structure could be a template for anything. A talk, a
> sales pitch, the homepage itself. The important thing is that we start from
> "why?" and we build up from foundations.
>
>
> On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
>
>> I'm trying to imagine what our "I have a dream" speech would be like for
>> CouchDB. If we were the Wright brothers, we might stand up and say "I have
>> a dream that one day man will fly." We might say, "I have a dream that
>> distributed data will be easy." (I mean, that about covers it, right?
>> Doesn't have to be complex. The hard part is making sure we actually focus
>> in on the root dream we all have.)
>>
>> Jan mentioned a few months ago that CouchDB almost wants to be the Git,
>> for databases. What is Git? What would Git's "dream" be? I can imagine
>> Linus saying "I have a dream that distributed version control will be
>> easy." Same sorta thing, right?
>>
>>
>> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
>>
>>> Benoit,
>>>
>>> You should defo watch that video and see what you think. Note that it
>>> does not matter if we are a company. This insight applies to companies,
>>> products, loose groups of people working towards one thing (like the Wright
>>> brothers) and even individuals. (i.e. What is your personal "why" and how
>>> are the things you are doing working towards that.)
>>>
>>> I also want to put you at ease by saying that having a single shared
>>> "why" doesn't mean that anybody's vision, or personal goals have to be left
>>> by the wayside. People can still come to the project with their own goals,
>>> and their own perspective. But the project itself should have a clear sense
>>> of what we are trying to accomplish.
>>>
>>> I think the "why" we come up with can easily be something that inspires
>>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp peeps,
>>> the "big data" peeps, the mobile platform peeps. Think about a why that
>>> might evolve out of "your data, everywhere". Who (in our existing
>>> communities) wouldn't love that and want to rally behind that? (But this is
>>> just one idea.)
>>>
>>> Asking "what are the core features" misses the point. Why are these core
>>> features? Why did we add them in the first place? What are we working
>>> towards? See, you hit on it in your final sentence: "relax we take care
>>> about your data and the way you exchange and render them wherever they
>>> are". This! This is the kind of thing that I think we should hone, and
>>> figure out, and document.
>>>
>>> Once we have that, it can inform our "how". When we're talking about
>>> features, about product direction (i.e. what we add, what we subtract) we
>>> can say "well, how is this related to what we're trying to do here?" Do you
>>> see what I mean? :)
>>>
>>> "Painless distributed systems" is also a step in the right direction for
>>> answering the question "why?"
>>>
>>> So far we have:
>>>
>>> * Relax
>>> * Decentralised web
>>> * Peer-to-peer replication of apps and datasets
>>> * Your data, everywhere
>>> * Put the data where you need it
>>> * We handle your data / you handle display
>>> * Painless distributed systems
>>>
>>> Somewhere in here ^ (and perhaps in a follow up reply) is a single shared
>>> value system. Something we all hold dear.
>>>
>>>
>>>
>>>
>>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
>>>
>>>> Anyway, CouchDB is not like apple or dell. This isn't a company. And we
>>>> don't have to share all the same vision, but only common values, a core.
>>>> I'm not sure it enter in the what you describe. What kind of vision are
>>>> you
>>>> speaking about?
>>>>
>>>> Also I would remove any pro-tip from your mail if we want to start from a
>>>> neutral base.
>>>>
>>>> Couchdb is known for the replication but not only. Couchapps and the way
>>>> people hack around is another (hoodie, kanso, erica/ couchapp all
>>>> differents visions of what is a couchapp but all are using couchdb the
>>>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb as a
>>>> message hub somehow, not only but a lot of their arch is based on
>>>> changes).
>>>> And now we we can add some kind of big data handling. Not forgetting
>>>> people
>>>> that are using apache couchdb on their mobile, they exists and the
>>>> patches
>>>> will be release.
>>>>
>>>> All have different visions. But they share some common features. I don't
>>>> want to forget someone because of a vision of some. I only know that
>>>> couchdb has some strong features that could be improved.
>>>>
>>>> All that to say that rather than thinking to a vision, maybe we could
>>>> collect all the usages around and see what emerges from it. What are the
>>>> core features, What couchdb should focus on and itterrate depending on
>>>> the
>>>> new usage. I guess it's some kind of philosophy: "relax we take care
>>>> about
>>>> your data and the way you exchange and render them wherever they are".
>>>>
>>>> - benoit
>>>>
>>>>
>>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
>>>>
>>>>> Hi devs,
>>>>>
>>>>> I came across this video recently:
>>>>>
>>>>> Simon Sinek: How great leaders inspire action
>>>>>
>>>> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>>>>>
>>>>> In it he sets out what he calls the Golden Circle:
>>>>>
>>>>> Why
>>>>>
>>>>> - What's your purpose?
>>>>> - What's your cause?
>>>>> - What's your belief?
>>>>>
>>>>> How
>>>>>
>>>>> - How do we do it?
>>>>> - How does our product differentiate?
>>>>> - How are we different?
>>>>> - How are we better?
>>>>>
>>>>> What
>>>>>
>>>>> - What do we do?
>>>>> - What do we make?
>>>>>
>>>>> He points out that the difference between companies like Apple and
>>>>> companies like Dell.
>>>>>
>>>>> Dell tells you what they do, and how. "We make great computers. They're
>>>>> well designed and work well. Wanna buy a computer?" Most companies do
>>>> it
>>>>> like this. But they often miss out the "why".
>>>>>
>>>>> But then you look at Apple, and they do it the other way around. Apple
>>>> tell
>>>>> you what their purpose is. The rest is almost an afterthought. "We
>>>> believe
>>>>> in challenging the status quo. We believe in thinking different. We do
>>>> that
>>>>> with great design and a focus on the user experience. We just happen to
>>>>> make computers." He then joking quips: "Ready to buy one yet?"
>>>>>
>>>>> (His talk gives several other examples, with his thesis being that
>>>> telling
>>>>> your story from the outside in is what separates all the great
>>>> companies
>>>>> and leaders. One of his main examples is the Wright brothers.)
>>>>>
>>>>> He comments that if you talk about what you believe, you will attract
>>>> those
>>>>> that believe what you believe. That when you talk about what you
>>>> believe,
>>>>> people will join you for their own reasons, for their own purpose. And
>>>> that
>>>>> what you do simply serves as proof of what you believe. Or as he quips:
>>>>> "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
>>>>> plan' speech."
>>>>>
>>>>> Why am I bringing this to the dev list?
>>>>>
>>>>> Because our message stinks. "Apache CouchDB™ is a database that uses
>>>> JSON
>>>>> for documents, JavaScript for MapReduce queries, and regular HTTP for
>>>> an
>>>>> API" is a terrible way to introduce who we are, what we stand for, and
>>>> why
>>>>> we build this thing. (And I'm allowed to say all that, because I'm the
>>>> one
>>>>> who wrote it, with lots of help from Jan.)
>>>>>
>>>>> So what am I proposing? I'm proposing that we figure out our why. That
>>>> we
>>>>> figure out what we stand for, what we believe in. And then we figure
>>>> out
>>>>> how we're gonna do that (pro tip: replication is more important than
>>>> the
>>>>> data format we use). Not only will this define a consistent internal
>>>> vision
>>>>> for the project (what *are* we working towards anyway?) but it will
>>>> help us
>>>>> to attract people who believe in what we believe.
>>>>>
>>>>> So, if you have any thoughts about this, speak up!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>> NS
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> NS
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
Okay, here are some rough thoughts.
Why?
- We believe that distributed data should be easy
How?
- Painless multi-master replication
- Effortless clustering and sharding
- Co-location of data, queries, and views
- Deep browser and platform integration
- Built of the Web
What?
- Erlang
- HTTP
- JSON
- JavaScript
- MapReduce
(That last list could go on, and on, and on...)
Anyway. This is just a rough sketch of the sort of hierarchy I am thinking
about.
Whatever this ends up looking like, I think this is how we should talk
about CouchDB. This structure could be a template for anything. A talk, a
sales pitch, the homepage itself. The important thing is that we start from
"why?" and we build up from foundations.
On 24 July 2013 13:15, Noah Slater <ns...@apache.org> wrote:
> I'm trying to imagine what our "I have a dream" speech would be like for
> CouchDB. If we were the Wright brothers, we might stand up and say "I have
> a dream that one day man will fly." We might say, "I have a dream that
> distributed data will be easy." (I mean, that about covers it, right?
> Doesn't have to be complex. The hard part is making sure we actually focus
> in on the root dream we all have.)
>
> Jan mentioned a few months ago that CouchDB almost wants to be the Git,
> for databases. What is Git? What would Git's "dream" be? I can imagine
> Linus saying "I have a dream that distributed version control will be
> easy." Same sorta thing, right?
>
>
> On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
>
>> Benoit,
>>
>> You should defo watch that video and see what you think. Note that it
>> does not matter if we are a company. This insight applies to companies,
>> products, loose groups of people working towards one thing (like the Wright
>> brothers) and even individuals. (i.e. What is your personal "why" and how
>> are the things you are doing working towards that.)
>>
>> I also want to put you at ease by saying that having a single shared
>> "why" doesn't mean that anybody's vision, or personal goals have to be left
>> by the wayside. People can still come to the project with their own goals,
>> and their own perspective. But the project itself should have a clear sense
>> of what we are trying to accomplish.
>>
>> I think the "why" we come up with can easily be something that inspires
>> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp peeps,
>> the "big data" peeps, the mobile platform peeps. Think about a why that
>> might evolve out of "your data, everywhere". Who (in our existing
>> communities) wouldn't love that and want to rally behind that? (But this is
>> just one idea.)
>>
>> Asking "what are the core features" misses the point. Why are these core
>> features? Why did we add them in the first place? What are we working
>> towards? See, you hit on it in your final sentence: "relax we take care
>> about your data and the way you exchange and render them wherever they
>> are". This! This is the kind of thing that I think we should hone, and
>> figure out, and document.
>>
>> Once we have that, it can inform our "how". When we're talking about
>> features, about product direction (i.e. what we add, what we subtract) we
>> can say "well, how is this related to what we're trying to do here?" Do you
>> see what I mean? :)
>>
>> "Painless distributed systems" is also a step in the right direction for
>> answering the question "why?"
>>
>> So far we have:
>>
>> * Relax
>> * Decentralised web
>> * Peer-to-peer replication of apps and datasets
>> * Your data, everywhere
>> * Put the data where you need it
>> * We handle your data / you handle display
>> * Painless distributed systems
>>
>> Somewhere in here ^ (and perhaps in a follow up reply) is a single shared
>> value system. Something we all hold dear.
>>
>>
>>
>>
>> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>> Anyway, CouchDB is not like apple or dell. This isn't a company. And we
>>> don't have to share all the same vision, but only common values, a core.
>>> I'm not sure it enter in the what you describe. What kind of vision are
>>> you
>>> speaking about?
>>>
>>> Also I would remove any pro-tip from your mail if we want to start from a
>>> neutral base.
>>>
>>> Couchdb is known for the replication but not only. Couchapps and the way
>>> people hack around is another (hoodie, kanso, erica/ couchapp all
>>> differents visions of what is a couchapp but all are using couchdb the
>>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb as a
>>> message hub somehow, not only but a lot of their arch is based on
>>> changes).
>>> And now we we can add some kind of big data handling. Not forgetting
>>> people
>>> that are using apache couchdb on their mobile, they exists and the
>>> patches
>>> will be release.
>>>
>>> All have different visions. But they share some common features. I don't
>>> want to forget someone because of a vision of some. I only know that
>>> couchdb has some strong features that could be improved.
>>>
>>> All that to say that rather than thinking to a vision, maybe we could
>>> collect all the usages around and see what emerges from it. What are the
>>> core features, What couchdb should focus on and itterrate depending on
>>> the
>>> new usage. I guess it's some kind of philosophy: "relax we take care
>>> about
>>> your data and the way you exchange and render them wherever they are".
>>>
>>> - benoit
>>>
>>>
>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
>>>
>>> > Hi devs,
>>> >
>>> > I came across this video recently:
>>> >
>>> > Simon Sinek: How great leaders inspire action
>>> >
>>> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>>> >
>>> > In it he sets out what he calls the Golden Circle:
>>> >
>>> > Why
>>> >
>>> > - What's your purpose?
>>> > - What's your cause?
>>> > - What's your belief?
>>> >
>>> > How
>>> >
>>> > - How do we do it?
>>> > - How does our product differentiate?
>>> > - How are we different?
>>> > - How are we better?
>>> >
>>> > What
>>> >
>>> > - What do we do?
>>> > - What do we make?
>>> >
>>> > He points out that the difference between companies like Apple and
>>> > companies like Dell.
>>> >
>>> > Dell tells you what they do, and how. "We make great computers. They're
>>> > well designed and work well. Wanna buy a computer?" Most companies do
>>> it
>>> > like this. But they often miss out the "why".
>>> >
>>> > But then you look at Apple, and they do it the other way around. Apple
>>> tell
>>> > you what their purpose is. The rest is almost an afterthought. "We
>>> believe
>>> > in challenging the status quo. We believe in thinking different. We do
>>> that
>>> > with great design and a focus on the user experience. We just happen to
>>> > make computers." He then joking quips: "Ready to buy one yet?"
>>> >
>>> > (His talk gives several other examples, with his thesis being that
>>> telling
>>> > your story from the outside in is what separates all the great
>>> companies
>>> > and leaders. One of his main examples is the Wright brothers.)
>>> >
>>> > He comments that if you talk about what you believe, you will attract
>>> those
>>> > that believe what you believe. That when you talk about what you
>>> believe,
>>> > people will join you for their own reasons, for their own purpose. And
>>> that
>>> > what you do simply serves as proof of what you believe. Or as he quips:
>>> > "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
>>> > plan' speech."
>>> >
>>> > Why am I bringing this to the dev list?
>>> >
>>> > Because our message stinks. "Apache CouchDB™ is a database that uses
>>> JSON
>>> > for documents, JavaScript for MapReduce queries, and regular HTTP for
>>> an
>>> > API" is a terrible way to introduce who we are, what we stand for, and
>>> why
>>> > we build this thing. (And I'm allowed to say all that, because I'm the
>>> one
>>> > who wrote it, with lots of help from Jan.)
>>> >
>>> > So what am I proposing? I'm proposing that we figure out our why. That
>>> we
>>> > figure out what we stand for, what we believe in. And then we figure
>>> out
>>> > how we're gonna do that (pro tip: replication is more important than
>>> the
>>> > data format we use). Not only will this define a consistent internal
>>> vision
>>> > for the project (what *are* we working towards anyway?) but it will
>>> help us
>>> > to attract people who believe in what we believe.
>>> >
>>> > So, if you have any thoughts about this, speak up!
>>> >
>>> > Thanks,
>>> >
>>> > --
>>> > NS
>>> >
>>>
>>
>>
>>
>> --
>> NS
>>
>
>
>
> --
> NS
>
--
NS
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
I'm trying to imagine what our "I have a dream" speech would be like for
CouchDB. If we were the Wright brothers, we might stand up and say "I have
a dream that one day man will fly." We might say, "I have a dream that
distributed data will be easy." (I mean, that about covers it, right?
Doesn't have to be complex. The hard part is making sure we actually focus
in on the root dream we all have.)
Jan mentioned a few months ago that CouchDB almost wants to be the Git, for
databases. What is Git? What would Git's "dream" be? I can imagine Linus
saying "I have a dream that distributed version control will be easy." Same
sorta thing, right?
On 24 July 2013 13:06, Noah Slater <ns...@apache.org> wrote:
> Benoit,
>
> You should defo watch that video and see what you think. Note that it does
> not matter if we are a company. This insight applies to companies,
> products, loose groups of people working towards one thing (like the Wright
> brothers) and even individuals. (i.e. What is your personal "why" and how
> are the things you are doing working towards that.)
>
> I also want to put you at ease by saying that having a single shared "why"
> doesn't mean that anybody's vision, or personal goals have to be left by
> the wayside. People can still come to the project with their own goals, and
> their own perspective. But the project itself should have a clear sense of
> what we are trying to accomplish.
>
> I think the "why" we come up with can easily be something that inspires
> and is important to the Hoodie peeps, the Kanso peeps, the CouchApp peeps,
> the "big data" peeps, the mobile platform peeps. Think about a why that
> might evolve out of "your data, everywhere". Who (in our existing
> communities) wouldn't love that and want to rally behind that? (But this is
> just one idea.)
>
> Asking "what are the core features" misses the point. Why are these core
> features? Why did we add them in the first place? What are we working
> towards? See, you hit on it in your final sentence: "relax we take care
> about your data and the way you exchange and render them wherever they
> are". This! This is the kind of thing that I think we should hone, and
> figure out, and document.
>
> Once we have that, it can inform our "how". When we're talking about
> features, about product direction (i.e. what we add, what we subtract) we
> can say "well, how is this related to what we're trying to do here?" Do you
> see what I mean? :)
>
> "Painless distributed systems" is also a step in the right direction for
> answering the question "why?"
>
> So far we have:
>
> * Relax
> * Decentralised web
> * Peer-to-peer replication of apps and datasets
> * Your data, everywhere
> * Put the data where you need it
> * We handle your data / you handle display
> * Painless distributed systems
>
> Somewhere in here ^ (and perhaps in a follow up reply) is a single shared
> value system. Something we all hold dear.
>
>
>
>
> On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> Anyway, CouchDB is not like apple or dell. This isn't a company. And we
>> don't have to share all the same vision, but only common values, a core.
>> I'm not sure it enter in the what you describe. What kind of vision are
>> you
>> speaking about?
>>
>> Also I would remove any pro-tip from your mail if we want to start from a
>> neutral base.
>>
>> Couchdb is known for the replication but not only. Couchapps and the way
>> people hack around is another (hoodie, kanso, erica/ couchapp all
>> differents visions of what is a couchapp but all are using couchdb the
>> same_.. Message hub is another (nodejistsu, hoodie are using couchdb as a
>> message hub somehow, not only but a lot of their arch is based on
>> changes).
>> And now we we can add some kind of big data handling. Not forgetting
>> people
>> that are using apache couchdb on their mobile, they exists and the patches
>> will be release.
>>
>> All have different visions. But they share some common features. I don't
>> want to forget someone because of a vision of some. I only know that
>> couchdb has some strong features that could be improved.
>>
>> All that to say that rather than thinking to a vision, maybe we could
>> collect all the usages around and see what emerges from it. What are the
>> core features, What couchdb should focus on and itterrate depending on the
>> new usage. I guess it's some kind of philosophy: "relax we take care about
>> your data and the way you exchange and render them wherever they are".
>>
>> - benoit
>>
>>
>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> > Hi devs,
>> >
>> > I came across this video recently:
>> >
>> > Simon Sinek: How great leaders inspire action
>> >
>> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>> >
>> > In it he sets out what he calls the Golden Circle:
>> >
>> > Why
>> >
>> > - What's your purpose?
>> > - What's your cause?
>> > - What's your belief?
>> >
>> > How
>> >
>> > - How do we do it?
>> > - How does our product differentiate?
>> > - How are we different?
>> > - How are we better?
>> >
>> > What
>> >
>> > - What do we do?
>> > - What do we make?
>> >
>> > He points out that the difference between companies like Apple and
>> > companies like Dell.
>> >
>> > Dell tells you what they do, and how. "We make great computers. They're
>> > well designed and work well. Wanna buy a computer?" Most companies do it
>> > like this. But they often miss out the "why".
>> >
>> > But then you look at Apple, and they do it the other way around. Apple
>> tell
>> > you what their purpose is. The rest is almost an afterthought. "We
>> believe
>> > in challenging the status quo. We believe in thinking different. We do
>> that
>> > with great design and a focus on the user experience. We just happen to
>> > make computers." He then joking quips: "Ready to buy one yet?"
>> >
>> > (His talk gives several other examples, with his thesis being that
>> telling
>> > your story from the outside in is what separates all the great companies
>> > and leaders. One of his main examples is the Wright brothers.)
>> >
>> > He comments that if you talk about what you believe, you will attract
>> those
>> > that believe what you believe. That when you talk about what you
>> believe,
>> > people will join you for their own reasons, for their own purpose. And
>> that
>> > what you do simply serves as proof of what you believe. Or as he quips:
>> > "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
>> > plan' speech."
>> >
>> > Why am I bringing this to the dev list?
>> >
>> > Because our message stinks. "Apache CouchDB™ is a database that uses
>> JSON
>> > for documents, JavaScript for MapReduce queries, and regular HTTP for an
>> > API" is a terrible way to introduce who we are, what we stand for, and
>> why
>> > we build this thing. (And I'm allowed to say all that, because I'm the
>> one
>> > who wrote it, with lots of help from Jan.)
>> >
>> > So what am I proposing? I'm proposing that we figure out our why. That
>> we
>> > figure out what we stand for, what we believe in. And then we figure out
>> > how we're gonna do that (pro tip: replication is more important than the
>> > data format we use). Not only will this define a consistent internal
>> vision
>> > for the project (what *are* we working towards anyway?) but it will
>> help us
>> > to attract people who believe in what we believe.
>> >
>> > So, if you have any thoughts about this, speak up!
>> >
>> > Thanks,
>> >
>> > --
>> > NS
>> >
>>
>
>
>
> --
> NS
>
--
NS
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
Benoit,
You should defo watch that video and see what you think. Note that it does
not matter if we are a company. This insight applies to companies,
products, loose groups of people working towards one thing (like the Wright
brothers) and even individuals. (i.e. What is your personal "why" and how
are the things you are doing working towards that.)
I also want to put you at ease by saying that having a single shared "why"
doesn't mean that anybody's vision, or personal goals have to be left by
the wayside. People can still come to the project with their own goals, and
their own perspective. But the project itself should have a clear sense of
what we are trying to accomplish.
I think the "why" we come up with can easily be something that inspires and
is important to the Hoodie peeps, the Kanso peeps, the CouchApp peeps, the
"big data" peeps, the mobile platform peeps. Think about a why that might
evolve out of "your data, everywhere". Who (in our existing communities)
wouldn't love that and want to rally behind that? (But this is just one
idea.)
Asking "what are the core features" misses the point. Why are these core
features? Why did we add them in the first place? What are we working
towards? See, you hit on it in your final sentence: "relax we take care
about your data and the way you exchange and render them wherever they
are". This! This is the kind of thing that I think we should hone, and
figure out, and document.
Once we have that, it can inform our "how". When we're talking about
features, about product direction (i.e. what we add, what we subtract) we
can say "well, how is this related to what we're trying to do here?" Do you
see what I mean? :)
"Painless distributed systems" is also a step in the right direction for
answering the question "why?"
So far we have:
* Relax
* Decentralised web
* Peer-to-peer replication of apps and datasets
* Your data, everywhere
* Put the data where you need it
* We handle your data / you handle display
* Painless distributed systems
Somewhere in here ^ (and perhaps in a follow up reply) is a single shared
value system. Something we all hold dear.
On 24 July 2013 12:48, Benoit Chesneau <bc...@gmail.com> wrote:
> Anyway, CouchDB is not like apple or dell. This isn't a company. And we
> don't have to share all the same vision, but only common values, a core.
> I'm not sure it enter in the what you describe. What kind of vision are you
> speaking about?
>
> Also I would remove any pro-tip from your mail if we want to start from a
> neutral base.
>
> Couchdb is known for the replication but not only. Couchapps and the way
> people hack around is another (hoodie, kanso, erica/ couchapp all
> differents visions of what is a couchapp but all are using couchdb the
> same_.. Message hub is another (nodejistsu, hoodie are using couchdb as a
> message hub somehow, not only but a lot of their arch is based on changes).
> And now we we can add some kind of big data handling. Not forgetting people
> that are using apache couchdb on their mobile, they exists and the patches
> will be release.
>
> All have different visions. But they share some common features. I don't
> want to forget someone because of a vision of some. I only know that
> couchdb has some strong features that could be improved.
>
> All that to say that rather than thinking to a vision, maybe we could
> collect all the usages around and see what emerges from it. What are the
> core features, What couchdb should focus on and itterrate depending on the
> new usage. I guess it's some kind of philosophy: "relax we take care about
> your data and the way you exchange and render them wherever they are".
>
> - benoit
>
>
> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
>
> > Hi devs,
> >
> > I came across this video recently:
> >
> > Simon Sinek: How great leaders inspire action
> >
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
> >
> > In it he sets out what he calls the Golden Circle:
> >
> > Why
> >
> > - What's your purpose?
> > - What's your cause?
> > - What's your belief?
> >
> > How
> >
> > - How do we do it?
> > - How does our product differentiate?
> > - How are we different?
> > - How are we better?
> >
> > What
> >
> > - What do we do?
> > - What do we make?
> >
> > He points out that the difference between companies like Apple and
> > companies like Dell.
> >
> > Dell tells you what they do, and how. "We make great computers. They're
> > well designed and work well. Wanna buy a computer?" Most companies do it
> > like this. But they often miss out the "why".
> >
> > But then you look at Apple, and they do it the other way around. Apple
> tell
> > you what their purpose is. The rest is almost an afterthought. "We
> believe
> > in challenging the status quo. We believe in thinking different. We do
> that
> > with great design and a focus on the user experience. We just happen to
> > make computers." He then joking quips: "Ready to buy one yet?"
> >
> > (His talk gives several other examples, with his thesis being that
> telling
> > your story from the outside in is what separates all the great companies
> > and leaders. One of his main examples is the Wright brothers.)
> >
> > He comments that if you talk about what you believe, you will attract
> those
> > that believe what you believe. That when you talk about what you believe,
> > people will join you for their own reasons, for their own purpose. And
> that
> > what you do simply serves as proof of what you believe. Or as he quips:
> > "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
> > plan' speech."
> >
> > Why am I bringing this to the dev list?
> >
> > Because our message stinks. "Apache CouchDB™ is a database that uses JSON
> > for documents, JavaScript for MapReduce queries, and regular HTTP for an
> > API" is a terrible way to introduce who we are, what we stand for, and
> why
> > we build this thing. (And I'm allowed to say all that, because I'm the
> one
> > who wrote it, with lots of help from Jan.)
> >
> > So what am I proposing? I'm proposing that we figure out our why. That we
> > figure out what we stand for, what we believe in. And then we figure out
> > how we're gonna do that (pro tip: replication is more important than the
> > data format we use). Not only will this define a consistent internal
> vision
> > for the project (what *are* we working towards anyway?) but it will help
> us
> > to attract people who believe in what we believe.
> >
> > So, if you have any thoughts about this, speak up!
> >
> > Thanks,
> >
> > --
> > NS
> >
>
--
NS
Re: What's our Why?
Posted by Benoit Chesneau <bc...@gmail.com>.
Anyway, CouchDB is not like apple or dell. This isn't a company. And we
don't have to share all the same vision, but only common values, a core.
I'm not sure it enter in the what you describe. What kind of vision are you
speaking about?
Also I would remove any pro-tip from your mail if we want to start from a
neutral base.
Couchdb is known for the replication but not only. Couchapps and the way
people hack around is another (hoodie, kanso, erica/ couchapp all
differents visions of what is a couchapp but all are using couchdb the
same_.. Message hub is another (nodejistsu, hoodie are using couchdb as a
message hub somehow, not only but a lot of their arch is based on changes).
And now we we can add some kind of big data handling. Not forgetting people
that are using apache couchdb on their mobile, they exists and the patches
will be release.
All have different visions. But they share some common features. I don't
want to forget someone because of a vision of some. I only know that
couchdb has some strong features that could be improved.
All that to say that rather than thinking to a vision, maybe we could
collect all the usages around and see what emerges from it. What are the
core features, What couchdb should focus on and itterrate depending on the
new usage. I guess it's some kind of philosophy: "relax we take care about
your data and the way you exchange and render them wherever they are".
- benoit
On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
> Hi devs,
>
> I came across this video recently:
>
> Simon Sinek: How great leaders inspire action
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>
> In it he sets out what he calls the Golden Circle:
>
> Why
>
> - What's your purpose?
> - What's your cause?
> - What's your belief?
>
> How
>
> - How do we do it?
> - How does our product differentiate?
> - How are we different?
> - How are we better?
>
> What
>
> - What do we do?
> - What do we make?
>
> He points out that the difference between companies like Apple and
> companies like Dell.
>
> Dell tells you what they do, and how. "We make great computers. They're
> well designed and work well. Wanna buy a computer?" Most companies do it
> like this. But they often miss out the "why".
>
> But then you look at Apple, and they do it the other way around. Apple tell
> you what their purpose is. The rest is almost an afterthought. "We believe
> in challenging the status quo. We believe in thinking different. We do that
> with great design and a focus on the user experience. We just happen to
> make computers." He then joking quips: "Ready to buy one yet?"
>
> (His talk gives several other examples, with his thesis being that telling
> your story from the outside in is what separates all the great companies
> and leaders. One of his main examples is the Wright brothers.)
>
> He comments that if you talk about what you believe, you will attract those
> that believe what you believe. That when you talk about what you believe,
> people will join you for their own reasons, for their own purpose. And that
> what you do simply serves as proof of what you believe. Or as he quips:
> "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
> plan' speech."
>
> Why am I bringing this to the dev list?
>
> Because our message stinks. "Apache CouchDB™ is a database that uses JSON
> for documents, JavaScript for MapReduce queries, and regular HTTP for an
> API" is a terrible way to introduce who we are, what we stand for, and why
> we build this thing. (And I'm allowed to say all that, because I'm the one
> who wrote it, with lots of help from Jan.)
>
> So what am I proposing? I'm proposing that we figure out our why. That we
> figure out what we stand for, what we believe in. And then we figure out
> how we're gonna do that (pro tip: replication is more important than the
> data format we use). Not only will this define a consistent internal vision
> for the project (what *are* we working towards anyway?) but it will help us
> to attract people who believe in what we believe.
>
> So, if you have any thoughts about this, speak up!
>
> Thanks,
>
> --
> NS
>
Re: What's our Why?
Posted by Noah Slater <ns...@apache.org>.
:)
Well, the first question to answer is "why?" Why are we doing this? What do
we believe in? What is our purpose?
(I think this is going to be a tough nut to crack. Simon actually runs a
course you can go on to figure it out.)
But once we have that, I think the rest will follow.
On 24 July 2013 12:28, Benoit Chesneau <bc...@gmail.com> wrote:
> Finally. Maybe we could start by listing the selling points of Apache
> CouchDB?
>
> - benoit
>
>
> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
>
> > Hi devs,
> >
> > I came across this video recently:
> >
> > Simon Sinek: How great leaders inspire action
> >
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
> >
> > In it he sets out what he calls the Golden Circle:
> >
> > Why
> >
> > - What's your purpose?
> > - What's your cause?
> > - What's your belief?
> >
> > How
> >
> > - How do we do it?
> > - How does our product differentiate?
> > - How are we different?
> > - How are we better?
> >
> > What
> >
> > - What do we do?
> > - What do we make?
> >
> > He points out that the difference between companies like Apple and
> > companies like Dell.
> >
> > Dell tells you what they do, and how. "We make great computers. They're
> > well designed and work well. Wanna buy a computer?" Most companies do it
> > like this. But they often miss out the "why".
> >
> > But then you look at Apple, and they do it the other way around. Apple
> tell
> > you what their purpose is. The rest is almost an afterthought. "We
> believe
> > in challenging the status quo. We believe in thinking different. We do
> that
> > with great design and a focus on the user experience. We just happen to
> > make computers." He then joking quips: "Ready to buy one yet?"
> >
> > (His talk gives several other examples, with his thesis being that
> telling
> > your story from the outside in is what separates all the great companies
> > and leaders. One of his main examples is the Wright brothers.)
> >
> > He comments that if you talk about what you believe, you will attract
> those
> > that believe what you believe. That when you talk about what you believe,
> > people will join you for their own reasons, for their own purpose. And
> that
> > what you do simply serves as proof of what you believe. Or as he quips:
> > "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
> > plan' speech."
> >
> > Why am I bringing this to the dev list?
> >
> > Because our message stinks. "Apache CouchDB™ is a database that uses JSON
> > for documents, JavaScript for MapReduce queries, and regular HTTP for an
> > API" is a terrible way to introduce who we are, what we stand for, and
> why
> > we build this thing. (And I'm allowed to say all that, because I'm the
> one
> > who wrote it, with lots of help from Jan.)
> >
> > So what am I proposing? I'm proposing that we figure out our why. That we
> > figure out what we stand for, what we believe in. And then we figure out
> > how we're gonna do that (pro tip: replication is more important than the
> > data format we use). Not only will this define a consistent internal
> vision
> > for the project (what *are* we working towards anyway?) but it will help
> us
> > to attract people who believe in what we believe.
> >
> > So, if you have any thoughts about this, speak up!
> >
> > Thanks,
> >
> > --
> > NS
> >
>
--
NS
Re: What's our Why?
Posted by Benoit Chesneau <bc...@gmail.com>.
Finally. Maybe we could start by listing the selling points of Apache
CouchDB?
- benoit
On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <ns...@apache.org> wrote:
> Hi devs,
>
> I came across this video recently:
>
> Simon Sinek: How great leaders inspire action
> http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
>
> In it he sets out what he calls the Golden Circle:
>
> Why
>
> - What's your purpose?
> - What's your cause?
> - What's your belief?
>
> How
>
> - How do we do it?
> - How does our product differentiate?
> - How are we different?
> - How are we better?
>
> What
>
> - What do we do?
> - What do we make?
>
> He points out that the difference between companies like Apple and
> companies like Dell.
>
> Dell tells you what they do, and how. "We make great computers. They're
> well designed and work well. Wanna buy a computer?" Most companies do it
> like this. But they often miss out the "why".
>
> But then you look at Apple, and they do it the other way around. Apple tell
> you what their purpose is. The rest is almost an afterthought. "We believe
> in challenging the status quo. We believe in thinking different. We do that
> with great design and a focus on the user experience. We just happen to
> make computers." He then joking quips: "Ready to buy one yet?"
>
> (His talk gives several other examples, with his thesis being that telling
> your story from the outside in is what separates all the great companies
> and leaders. One of his main examples is the Wright brothers.)
>
> He comments that if you talk about what you believe, you will attract those
> that believe what you believe. That when you talk about what you believe,
> people will join you for their own reasons, for their own purpose. And that
> what you do simply serves as proof of what you believe. Or as he quips:
> "Martin Luther King gave his 'I have a dream' speech, not his 'i have a
> plan' speech."
>
> Why am I bringing this to the dev list?
>
> Because our message stinks. "Apache CouchDB™ is a database that uses JSON
> for documents, JavaScript for MapReduce queries, and regular HTTP for an
> API" is a terrible way to introduce who we are, what we stand for, and why
> we build this thing. (And I'm allowed to say all that, because I'm the one
> who wrote it, with lots of help from Jan.)
>
> So what am I proposing? I'm proposing that we figure out our why. That we
> figure out what we stand for, what we believe in. And then we figure out
> how we're gonna do that (pro tip: replication is more important than the
> data format we use). Not only will this define a consistent internal vision
> for the project (what *are* we working towards anyway?) but it will help us
> to attract people who believe in what we believe.
>
> So, if you have any thoughts about this, speak up!
>
> Thanks,
>
> --
> NS
>