couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Wed, 06 May 2015 17:12:45 GMT

> On 06 May 2015, at 18:54, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
> 
> Jan Lehnardt wrote:
>>> On 06 May 2015, at 17:57, Giovanni Lenzi<g.lenzi@smileupps.com> wrote:
>>> 
>>> Given the importance of the topic: the future of couchapp... I'm moving
>>> this from the @marketing to the user@ mailing list.
>> I’d say this is too early, would prefer we keep this on marketing@ until
>> we have the messaging right. Everything else follows from them. Given that
>> user@ is missing the entire “the why of CouchDB” context that marketing@
>> has, I’d say moving this is premature.
>> 
>> I also *could* see this as a cheap ploy to quickly garner public pressure
>> against my position, but in good faith, I won’t assume this is your motive.
> 
> If this is the kind of discussion going on, on the marketing list, then you REALLY need
to open it up to user feedback.  I think you're going off track.

Noted.

> 
> Re. a couple of things below:
>>> This should be definitely something @users should be involved in.. at least
>>> those interested in Couchapps.
>>> 
>>> To recap:
>>> Jan: wants to remove Couchapp name and design doc functions because it
>>> finds them to be source of confusion
>> This does not adequately reflects my position. I don’t suggest to remove
>> any of the things that make CouchApps possible.
>> 
>> My larger argument can be foundhttp://markmail.org/message/no3jfksdxjcgxz4d andhttp://markmail.org/message/xla3hulea4lo5duw
>> 
>> tl;dr: I’d like us to think about how the CouchApp (or whatever the
>> final name might be) story fits into the larger CouchDB story of “Data where
>> you need it.” — Not necessarily how the slogan made be “true” in the context
>> of CouchApps (e.g. “Data (and logic) where you need it.”, but more:
>> 
>> - CouchDB’s core feature is geographically distributed replication.
> 
> Really?  That's the argument that lead to CouchBase.

I’m a Couchbase co-founder and I can assure you you are mistaken.

> 
> Yes, MVCC w/ replication is A core feature, but, at least to me, Couch's core feature
is a full-featured HTTP interface -- everything is a resource, accessed through RESTful HTTP
operations.

What is the one thing that make CouchDB unique? REST or Replication?

To wit, this isn’t about removing everything that isn’t replication. REST will stay around,
we may have other interfaces too at some point, but not anytime soon. Either way, REST is
not what makes CouchDB unique.

I understand it is an important feature to you, much like many other features are very important
to other people. But overall, CouchDB’s unique feature is replication.


> 
>> 
>> - We also have somewhat quirky, while technically neat, applications that can
>> live inside CouchDB.
>> 
>> I don’t think that last bit helps paint the big picture CouchDB story at all.
>> Granted, I’m making a deliberately weak attempt of tying things together
>> (because I don’t know any better), but this is to get you thinking about how
>> this could fit in our larger narrative, if at all.
> 
> From this user's perspective, you're 100% wrong on this.

In your opinion.


> The fact that you can use CouchDB as an App Server is of particularly high value; the
more so that the Apps can run in a browser.  More to the point - it's an HTML5 WebApp server,
making it a full platform for RESTful applications.

This is a great approach to get this into the core narrative of CouchDB, would love for you
to join the discussion on marketing@.


> 
>> My current thinking is that we can’t make it clear and thus should figure out a
>> plan to retire “CouchApp”, while still allowing all the cool tech, and find a
>> new name for the concept that can live on without making CouchDB’s core message
>> unclear.
>> 
> 
> Hell no!

Hell yes, let’s keep CouchDB a confusing mess.


> Maybe the tooling for CouchApps is a bit funky, but the support for them is (IMHO) core
features of Couch.  And the notion of Couch as an App Server is pretty straightforward - and
the term fits quite nicely.

I’ve spent most of my time since 2007 advocating CouchDB to thousands of people in person
and even more online. CouchDB’s “AppServer” features are neither straightforward nor
does the term fit nicely. People are confused by the fact that there are three different “couchapp”
tools in various languages, that you need one of them to manage design docs, just to query
CouchDB (I’m sure glad we have mango now, where the steps are “create index, start querying”,
like in every other database). There is confusion of using “couchapp” to manage views,
when CouchApps mean so much more than just managing map/reduce functions. I can go on for
hours how this is confusing for first-time experiences that people have told me and keep telling
me.


> 
> Rather than retire the term, or relegate it to obsucrity - market it aggressively!  Perhaps
to the the extent of changing the current tag line on couchdb.apache.org from "A Database
for the Web" to "A Database and Integrated App Server for the Web.”

I’ll refer you to the “The Why of CouchDB” discussion in the marketing@ archives.

Best
Jan
--




> 
>> Please join us on the marketing@couchdb.apache.org list for this discussion.
> 
> Done :-)
> 
> Miles Fidleman
> 
> 
> -- 
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/


Mime
View raw message