couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: What's our Why?
Date Thu, 25 Jul 2013 09:32:43 GMT
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 :)


On Jul 25, 2013, at 10: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]
> [2]
> [3]
> [4]
> [5]
> On Wed, Jul 24, 2013 at 11:36 PM, Jan Lehnardt <> 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 (, 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.:
>> or
>> 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.
>> *
>>  Full talk at: (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)
>> * * *
>> 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.
>> 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 <> 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 <> 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 <> 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 <> wrote:
>>>>>> Anyway, CouchDB is not like apple or dell. This isn't a company.
>> we
>>>>>> don't have to share all the same vision, but only common values,
>> 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
>> way
>>>>>> people hack around is another (hoodie, kanso, erica/ couchapp all
>>>>>> differents visions of what is a couchapp but all are using couchdb
>>>>>> 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.
>> 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
>> the
>>>>>> core features, What couchdb should focus on and itterrate depending
>>>>>> 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
>>>>>> - benoit
>>>>>> On Wed, Jul 24, 2013 at 1:24 PM, Noah Slater <>
>> wrote:
>>>>>>> Hi devs,
>>>>>>> I came across this video recently:
>>>>>>> Simon Sinek: How great leaders inspire action
>>>>>>> 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
>>>>>>> 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
>>>>>> 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.
>>>>>> believe
>>>>>>> in challenging the status quo. We believe in thinking different.
>> do
>>>>>> that
>>>>>>> with great design and a focus on the user experience. We just
>> to
>>>>>>> make computers." He then joking quips: "Ready to buy one yet?"
>>>>>>> (His talk gives several other examples, with his thesis being
>>>>>> 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
>>>>>> those
>>>>>>> that believe what you believe. That when you talk about what
>>>>>> 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
>> quips:
>>>>>>> "Martin Luther King gave his 'I have a dream' speech, not his
>> 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
>> and
>>>>>> why
>>>>>>> we build this thing. (And I'm allowed to say all that, because
>> the
>>>>>> one
>>>>>>> who wrote it, with lots of help from Jan.)
>>>>>>> So what am I proposing? I'm proposing that we figure out our
>> That
>>>>>> we
>>>>>>> figure out what we stand for, what we believe in. And then we
>>>>>> out
>>>>>>> how we're gonna do that (pro tip: replication is more important
>>>>>> 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
>>>>>> 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

View raw message