I think Jan's proposal is excellent. My comments below are merely thoughts about how Jan's proposal MIGHT be improved. I'd like to see proposals very different from Jan's too, because there is wisdom in many counselors.
On 08/29/2015 04:56 AM, Jan Lehnardt wrote: > * * * FWIW: PouchDB nicked the “The database that syncs” from an email > of mine on dev@ two years ago, when this was discussed first (and > kudos to them for realising it is a great slogan and running with > it!). I see no harm in the two projects sharing this, or coordinating, > e.g. CouchDB: The database that syncs. PouchDB: The JavaScript > database that syncs, or somesuch. (not saying this is a proposal of > mine, but if anyone wants to advocate it, I’d be happy to listen and > hear a proposal). * * * Because PouchDB and CouchDB share the same synchronization protocol, and the same goal of synchronizing within one ecosystem of software through that same protocol, you could say they share the same feature. In philosophical terms, you could almost say their sync features share not only "specific identity" (they are the same kind) but "numeric identity" (they are the same entity). At least it is appropriate to call both PouchDB and CouchDB equally "The database that syncs," because they intentionally sync with each other using the same protocol. I like the simplicity of the slogan, "The database that syncs." But I wonder whether the exclusivity of the word "The" is a problem, because in actual fact, PouchDB (or CouchDB) is not the only database which syncs using this specific protocol. (Not to mention that there are other synchronization protocols and respective databases.) My first paragraph above, and Jan's "Mission Statement" and "Description" make me think the protocol is more fundamental than the database which implements it, and it would be wise to consider whether the protocol should somehow feature in the slogan--something like "The hub of your syncing ecosystem," but more eloquently expressed. "The hub of your data federation"? (I suppose the only reason it's the "hub" is that it was originally easiest to install on the server, and too hard for average users to install on their personal computers (on the "client" side). This isn't the case anymore now that PouchDB works easily on the client and the server.) Regardless, Jan's "Mission Statement" and "Description" give prominence to the protocol and the idea of an ecosystem of software that syncs data, and that is sufficient to make the point. I recognize that both of the following slogans are actually speaking of the "WHAT" rather than the "WHY," and maybe it is wise for the slogan not to get into the "WHAT" very much: "The database that syncs," "The hub of your syncing ecosystem." So maybe "Data where you need it" is a better idea, because it is intended to focus on the "WHY." I would say the key reason I've chosen to use CouchDB (and now Hoodie) for one project, at least, is that I want the software we're creating to do filtered replications of data between multiple installations or "nodes" of the application. Federated data is powerful! I find it interesting that one of CouchDB's creators sees this as the central purpose of CouchDB. There are other reasons I like CouchDB which were enough to convince me to use it instead of MySQL on a couple other projects, but like others have said, the prospect of a syncing ecosystem is its killer feature! It seems to me that if CouchDB communicated this in its top-level marketing message it could help people make the right decision about whether to use it. I remember watching a talk by Mikeal Rogers some years ago now where he showed a picture with either many CouchDBs talking to each other, or many NodeJS changes listeners listening to one CouchDB instance, or both. That's the syncing ecosystem idea which is a fundamentally different application architecture than the typical three-tier web application architecture of most PHP & MySQL, Rails, etc. apps--it's a picture many people won't imagine when they first start learning about CouchDB unless someone shows it to them. Instead, many would still imagine CouchDB is just another database to use in a three-tier architecture. I would imagine this picture basically as a network--a spiderweb of nodes. I still like the idea of relaxing on a couch -- that fits with how you use one node. But CouchDB is also intended to replicate in a peer-to-peer, master-to-master fashion, and I don't see this given top-level prominence in the current marketing. I don't know the best way to create an image which conveys both relaxing on a couch and a network of couches (and I don't like spiderwebs), but maybe someone with better graphical design chops could tackle it. Tim
