Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of nslater@tumbolia.org
 designates 209.85.213.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120924134656.GC23483@shimaore.net>
References: <20120924134656.GC23483@shimaore.net>
Date: Tue, 9 Oct 2012 21:42:40 +0100
Message-ID: 
 <CA+Y+445OF6Qi4k1L65JpmJgfPGYadfsJh1MzRGpavvwgJBHy4A@mail.gmail.com>
Subject: Re: Follow-up on: What's up dev?
From: Noah Slater <nslater@tumbolia.org>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7bd6aed216fc1104cba661ee

--047d7bd6aed216fc1104cba661ee
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the feedback! Useful stuff. I'll let other people reply to
specific points if they want to.

On Mon, Sep 24, 2012 at 2:46 PM, <stephane@shimaore.net> wrote:

> Hi,
>
> I'm writing as an contributor on the wiki, CouchDB advocate, and
> user.
>
> I wanted to follow-up on the initial question about project energy,
> and Noah's response, first to say that I'd be glad to help with things
> such as documentation, use examples, etc.
>
> Noah asked about "areas [people] give a shit about", so here's what I care
> about (if there are any trolls just have mercy and ignore them, thanks):
>
> - As a user (that is, a developer who uses CouchDB as a back-end
>   database and front-end in some cases), CouchDB is:
>     1. an API;
>     2. the API is what Futon tests;
>     3. as long as things are "fast-enough" I'm happy.
>
>   Most other things I can work around by writing code.
>   (For example: the replicator is muchly useful but not core --
>   replicate[1] might be a viable option --; and even though it is a very
>   good idea, I never used the _replicator database because I had coded
>   for that before it was there.)
>
>   I really don't care whether I use Apache CouchDB, or something
>   written in Erlang, or anything else -- as long as it conforms to the API.
>   ... I use Apache CouchDB because I want the reference API.
>
>   For couchapps I rely on a modified node.couchapps.js & Sammy.js but
>   that's my playground, not the server's.
>
>   The API must be clearly documented, backward-compatible.
>   I'd like to see more index types (GeoCouch, longest-match) integrated.
>
>   I depend enough on the technology that I'd start my own version of the
>   server if things went really bad.
>
> - As a system administrator I want to be able to deploy private,
>   distributed CouchDB simply and reliably. I want to distribute it over
>   multiple physical locations, multiple clouds if I can.
>
>   As a sysadmin I understand there are a lot of moving pieces, and the
>   most visible ones (view server) aren't necessarily in Erlang.
>
>   I care enough about the stability of my CouchDB installations to
>   package my own builds.
>
>   OTP has little practical impact because package managers just do "stop"
>   and "start" on upgrades.
>
>   ... I use Apache CouchDB because there's little momentum behind
>   BigCouch, and I believed it was going to be integrated anyway.
>
> - As an advocate I had to learn to answer "isn't it dead?" questions.
>   On the other hand I have fun when people mention binary protocols.
>   But overall I'm advocating for a technology, not a given
>   implementation. (And I'd love to have fellow developers prove me wrong,
>   obviously.)
>
> S.
>
> [1] https://github.com/mikeal/replicate
>


-- 
NS

--047d7bd6aed216fc1104cba661ee--