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 :)
Best Jan -- On Jul 25, 2013, at 10:52 , Benoit Chesneau <[email protected]> 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 > [2] https://github.com/benoitc/nymphormation > [3] https://github.com/refuge/rcouch/wiki > [4] http://refuge.io > [5] https://github.com/refuge/rcouch/wiki/refactoring > > > On Wed, Jul 24, 2013 at 11:36 PM, Jan Lehnardt <[email protected]> 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 or >> 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 >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >>>>>>> >>>>>>> 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 >> >>
