couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: What's our Why?
Date Tue, 06 Aug 2013 08:42:08 GMT
On Sun, Aug 4, 2013 at 9:45 PM, Noah Slater <nslater@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 <david.martin@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 <jan@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 <nslater@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 <nslater@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 <nslater@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 <bchesneau@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 <nslater@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message